Critical Performance Regression

  • Resolved aksel777

    (@aksel777)


    2 months ago

    Critical Performance Regression: Resource Exhaustion and Asset Bloat in ProfileGrid

    Dear ProfileGrid Development Team,

    I am writing this not just as a user, but as a developer concerned about the current architecture of your plugin. After a deep dive into my server logs and performance profiling, I feel compelled to highlight some “architectural sins” that are, frankly, embarrassing for a top-tier WP solution in 2026.1. The “Death by AJAX” Polling Model

    Your messenger module uses a primitive long-polling approach via admin-ajax.php (specifically the pm_get_messenger_notification action) with an aggressive interval of 3–5 seconds.

    • The Technical Reality: Every single poll bootstraps the entire WordPress core, loads all active plugins, and initializes the theme. On a site with even moderate traffic, this creates a massive overhead on PHP-FPM workers, leading to inevitable L7 resource exhaustion.
    • The Solution: In an era of REST API and WebSockets, relying on synchronous admin-ajax calls for a “background” notification system is a relic of 2015. It’s a silent server-killer.

    2. Global Asset Injection (Bloatware approach)

    ProfileGrid seems to operate under the assumption that it is the only plugin on the site. Your JS and CSS files are enqueued globally across the entire frontend, regardless of whether a ProfileGrid shortcode or functionality is present on the page.

    • The Impact: Loading your heavy UI assets on a clean SEO-optimized blog post increases the DOM size and triggers significant “Total Blocking Time” (TBT) and “Largest Contentful Paint” (LCP) regressions.
    • The Scientific Critique: This is a violation of the Principle of Least Privilege in asset management. Conditional loading (wp_dequeue_script) shouldn’t be the user’s job; it should be the plugin’s default behavior.

    Conclusion

    We are building high-performance, modular systems. Seeing a plugin “spam” the server logs with 200-OK responses that do absolutely nothing but consume CPU cycles is disappointing. It forces developers to either gut the plugin’s code or disable core features (like Messaging) just to keep the server alive.

    I strongly urge you to reconsider your asset enqueuing logic and move away from legacy AJAX polling toward a more modern, event-driven architecture.

    Best regards

Viewing 1 replies (of 1 total)
  • Plugin Support profilegridsupport1

    (@profilegridsupport1)

    1 month, 4 weeks ago

    Hello @aksel777,

    Thank you for taking the time to document these issues so thoroughly. We genuinely appreciate the level of technical detail you’ve shared — it helps us strengthen ProfileGrid in the right ways.

    We want to assure you that the concerns you’ve raised are valid, and they align with areas we are already actively restructuring. Over the past few weeks, our team has been working on a series of architectural updates aimed at addressing exactly the points you highlighted:

    1. Messenger Polling & Notification Architecture

    We fully agree that the current AJAX‑based polling model needs to evolve. A redesigned, event‑driven notification system — built around modern REST endpoints and more efficient background processes — is already in development. This will significantly reduce PHP worker load and eliminate unnecessary WordPress bootstrap cycles.

    2. Conditional Asset Loading

    You are absolutely right about the need for more granular, context‑aware asset enqueuing. We have a new asset‑loading strategy rolling out that ensures ProfileGrid scripts and styles are only loaded when required by active components or shortcodes. This will reduce page weight, improve Core Web Vitals, and prevent unnecessary frontend bloat.

    3. Broader Architectural Improvements

    These changes are part of a larger, multi‑phase modernization of ProfileGrid’s internal architecture. Over the coming weeks, you’ll see incremental releases that improve performance, reduce overhead, and align the plugin with current WordPress development standards.

    We appreciate your patience and your willingness to surface these issues so constructively. Feedback like this directly shapes our roadmap, and we’re committed to delivering the improvements you — and the broader community — expect from a plugin of this scale.

    If you have additional insights, we’d be glad to details.

Viewing 1 replies (of 1 total)

You must be logged in to reply to this topic.