thyran
Forum Replies Created
-
Thanks @jamesosborne — really appreciate you opening the GitHub issue.
A couple of follow-ups:
On the widget scope: Confirmed on our end — Site Kit’s data-fetching is indeed scoped to
/wp-admin/index.phponly, not other admin URLs. That’s working as intended.The challenge though is that the dashboard is the post-login landing page. Every admin login lands there by default. So while the widget only loads on one URL, that URL is the one every administrator unavoidably hits on every fresh session. There’s no “I’ll just avoid the dashboard” workaround for end users — the slow load is the first thing they experience after logging in.
This is part of why a first-class disable setting matters more than it might seem at first glance. If the widget loaded on a discretionary page that admins could choose to visit or not, the slow load would be a “pay the cost when you want the data” pattern. Because it loads on the universal post-login page, it’s a “every admin pays the cost on every cold-cache session whether they want the data or not” pattern.
This is why I’ve ended up removing the widget entirely via the meta box filter across our fleet — the data is still available via the Site Kit menu item, and admins who actively want to see it can click in and accept the cold-load cost as a deliberate choice rather than having it inflicted on every login.
On CDN usage: We’re already on Cloudflare across all 75 sites, including admin paths. In our case the CDN doesn’t help much with this specific pattern because the slow requests are authenticated admin AJAX/REST calls to
/wp-json/google-site-kit/...that make outbound calls to Google’s APIs server-side. Cloudflare faithfully passes those through, so the load on origin PHP workers is the same. We’ve actually added Cloudflare bypass rules for/wp-admin/*to ensure the WAF doesn’t add latency or false-positive 503s on top of Site Kit’s already-slow requests — that part helped eliminate one variable but the core slowness (10-15s per GA4 Data API call) is intrinsic to Google’s API performance, not anything Cloudflare can mitigate.Happy to share Site Health data from an affected site if useful for the GitHub issue. Let me know what would be most helpful.
Thanks again for engaging with this properly — it’s appreciated.
Is it possible for the site kit plugin to add an admin settings > Plugin Settings with a checkbox to enable or disable the Site Kit Widget from the WP-Admin Dashboard like you have done with the
Display relevant page stats in the Admin barObviously disabling it from the screen options would only do it for the account that is logged in and not for all the other administrators.
In the meantime I have found a workaround for our cPanel accounts that have limited resources.
Will be applying this to all our cPanel accounts that are in the reseller shared server environment but obviously this would stop working if for instance the developers decided to change the widget ID to something else.
A setting to disable this widget would be appreciated since the widget practically exhausts cpu and memory resources in shared server environmnets
/**
* Disable Site Kit Dashboard Widget
*
* Site Kit's dashboard widget makes 6+ Google API calls on cold-cache
* dashboard loads (first admin login of the session, or after the 24-hour
* transient cache expires). These calls can take 10-15 seconds each and
* cause 503 errors on shared hosting when they fire concurrently with
* other dashboard widgets (WooCommerce, Yoast, etc).
*
* Removing the widget from the dashboard avoids triggering these calls
* on routine logins. The full Site Kit dashboard remains accessible via
* the Site Kit menu item
*/
add_action('wp_dashboard_setup', function() {
remove_meta_box('google_dashboard_widget', 'dashboard', 'normal');
}, 99);- This reply was modified 3 days, 2 hours ago by thyran.
Should this be marked as resolved then?
@vupdraft do you know when your development team will be releasing a fix for this?
Yes, “Automatically Preload Content after it is purged” is enabled on all of our affected sites and was also enabled on the staging environment used throughout this investigation.
I can confirm that disabling this setting resolves the issue on our staging site as well.
That said, I’d like to flag that disabling preload is a workaround rather than a fix. Automatic preloading after cache purge is a feature we rely on for performance across our client sites, and it should not interfere with WooCommerce admin-ajax.php requests, which should never be cached or preloaded regardless of this setting being enabled.
Could the development team look at fixing the preload logic to explicitly exclude admin-ajax.php and wp-json REST API requests from being intercepted during the preload process? This would allow users to keep preloading enabled without breaking WooCommerce admin functionality.
In the meantime we will disable the preload setting across our affected production sites as a temporary workaround.
Thank you for persisting with this — the time spent on reproduction is appreciated.
Hi @jbgupdraft
I’m unable to determine which version introduced the issue as we were only made aware of it through client reports. However the current version and previous version have the issue.
I’ve since spun up a clean staging environment and can confirm the bug is fully reproducible:
Environment:
- WordPress 6.9.4
- WooCommerce 10.7.0
- WP-Optimize 4.5.2
- PHP 8.3.30
- LiteSpeed server
Steps to reproduce:
- Fresh WooCommerce installation
- Create a variable product with at least one variation
- On each variation, expand it and check “Manage stock” — set a stock quantity
- Enable WP-Optimize page caching
- Edit the product, change a variation stock quantity, click Save Changes
- Spinner runs indefinitely — admin-ajax.php returns an empty response body (4 bytes: 0d 0a 0d 0a)
Note: “Manage stock” must be enabled at the variation level, not just at the product level. This appears to be a key trigger for the issue.
Additional observations:
- Tested with both Divi and Twenty Twenty-Five themes — same result on both, so theme is not a factor
- Product data loads noticeably slower with page caching enabled, even though logged-in user caching is disabled and wp-admin exclusions are configured
- Disabling page caching immediately resolves the issue
- The URL exclusion rules configured in the WP-Optimize UI do not appear to be enforced at the advanced-cache.php level — the output buffer starts unconditionally before WordPress loads, meaning exclusions are evaluated too late
It’s unclear why you’re unable to reproduce this on your end, as it’s consistently reproducible on a clean staging site with just WooCommerce and a default theme. Happy to provide server access or additional diagnostic information if that would help your development team isolate the issue.
Further finding — cache poisoning behaviour identified:
After purging the WP-Optimize cache, the first save of variation stock levels succeeds. However subsequent saves on the same product fail with the spinning wheel as previously reported.
This suggests the following sequence:
- Cache purged — first admin-ajax.php request passes through correctly
- WP-Optimize caches the admin-ajax.php response (or an empty/partial version of it)
- Subsequent admin-ajax.php requests are served the cached response — which is either empty or incomplete — causing the spinner to hang indefinitely
This points to admin-ajax.php responses being cached by advanced-cache.php despite wp-admin exclusions being configured. The exclusion rules are not preventing admin-ajax.php from being cached, they are only preventing it from being served from cache — or they are not being applied at all at the advanced-cache.php level as previously noted.
Reproduction of this specific behaviour:
- Purge WP-Optimize cache
- Edit variable product — change variation stock quantity — Save Changes → succeeds
- Edit same product again — change variation stock quantity — Save Changes → spinner hangs indefinitely
- Purge cache again → first save succeeds again
This confirms admin-ajax.php responses are being written to cache by WP-Optimize and the cached response is being served on subsequent requests, bypassing PHP entirely.
Inspecting advanced-cache.php (written by WP-Optimize 4.5.2) reveals the following admin exclusion check:
if (is_admin()) { return; }This check does not work. advanced-cache.php is loaded via the WP_CACHE constant before WordPress bootstraps, meaning is_admin() is not yet defined at the point this file executes. As a result is_admin() always returns false, and wp-admin requests including admin-ajax.php and REST API calls are never excluded from the cache handler — regardless of what exclusion rules are configured in the plugin UI.
This explains all observed symptoms:
- WooCommerce variation stock saves spin indefinitely (admin-ajax.php response cached/discarded)
- WooCommerce admin REST API requests return 503 (authenticated requests intercepted before PHP runs)
- Exclusion rules for /wp-admin/ configured in the plugin UI have no effect
- Cache purge temporarily resolves the issue because the first request passes through before being cached, but subsequent requests are served the cached empty response
Regards,
ThyranHi @jbgupdraft
Same result in incognito with WP-Optmize page caching enabled
Cahced logged in users is disabled
When you click save changes at the bottom of the variations you get the spinning wheel of death on the product variations which doesnt ever finish.
If you refresh the page the stock change has indeed saved
But the problem is with Wp-Optmize page cache enabled the variations is expecting a response for it to complete which it never recived unless WP-Optmize page cache is disabled.
Happening on all my WooCommerce sites with variable products that have manage stock enabled
- This reply was modified 1 month, 1 week ago by thyran.
Update: Issue persists with latest plugin version 4.5.2
Variable products with manage stock enabled are unable to complete “save changes” in the backend when WP-Optimize page caching is enabled.
Only solution at the moment is to disable page caching entirely.
Forum: Plugins
In reply to: [W3 Total Cache] W3 Total Cache 2.9.3 – REST API broken / Site Health error@joemoto thank you for the feedback. Unfortunately its a too little too late. Since encountering this regression in 2.9.3, we have now migrated all of our sites away from W3 Total Cache. We manage approximately 80 sites, and after completing the migration we’ve actually observed improved performance and reduced server load compared to W3TC, in addition to resolving the REST API introduced by the update.
While we appreciate the beta being made available, we won’t be deploying beta builds to live environments. Please let us know when an official stable release is published that addresses the issue introduced in 2.9.3, and we can then reassess whether to revisit W3 Total Cache.
Forum: Plugins
In reply to: [W3 Total Cache] W3 Total Cache 2.9.3 – REST API broken / Site Health errorThanks everyone for confirming you’re seeing the same behaviour.
As part of troubleshooting this across multiple environments, I tested an alternative caching approach. I typically give caching plugins a fair chance — I previously did this with LiteSpeed Cache as well, but eventually moved away due to performance inconsistencies and updates introducing breaking changes.
Given the regression in 2.9.3, I’ve now migrated away from W3 Total Cache and switched to WP-Optimize page caching (with Redis object cache where available).
So far I have converted ~40 of our ~80 sites, and the results have been:
- REST API issues resolved immediately
- WordPress Site Health warnings gone
- Google Site Kit working again
- Improved Lighthouse performance vs W3TC
- Reduced server load
- No need for REST exclusions
- Simpler configuration (especially with Cloudflare in front)
@jamesosborne Thank you for the feedback.
It is definately the Google Site Kit API calls that is causing the higher resources when loading wp-admin dashboards where the google Site Kit Summary widget is displayed.
I have gone through our 80 sites and have disabled key metrics and visitor groups in google site kit > settings > admin settings.
This has reduced the load considerably when loading the wp-admin dashboards when logging in.
I have however noticed that when admins navigate to the Google Site Kit Dashboard that we are frequently asked to turn these features back on through promotional banners despite opting to not be asked about this again.
See example https://snipboard.io/hmtKyu.jpg
Interestingly enough we have noticed a new connect site kit in Yoasts plugin which also shows a dashboard in Yoast for google site kit with the metrics.
Loading Yoasts version of the dashboard with google site kit metrics takes a second or two vs loading the google site kit dashboard which takes 7-14 seconds.
Not sure how Yoast does it so well…
- This reply was modified 4 months, 2 weeks ago by thyran.
Thanks for the update. We’ve always recommended the Google Site Kit plugin — developed by Google — specifically because it provides an official and streamlined way to manage tracking snippets and integrations for Google Tag Manager, Google Analytics, PageSpeed Insights, Search Console, and Google Ads.
When new features like Key Metrics and Visitor Groups were introduced, they were promoted in the Site Kit dashboard through banners, but there was no indication that these additions might increase API usage or become unsuitable for LiteSpeed server environments, especially those using cPanel accounts with resource isolation. Until recently, we had never experienced any resource-related issues with Site Kit.
The challenge we’re facing now is that these new metrics appear to be overloading resource allocations within WordPress admin dashboards for our clients’ hosting environments. This puts us in a difficult position — Site Kit has been our go-to solution, but if these features can’t be controlled or disabled in a way that prevents these spikes, we may no longer be able to rely on Site Kit for managing Google services.
We’ll continue monitoring this, but if no practical workaround is available, we may have to start looking for third-party alternatives that can manage these integrations without overloading server resources.
Thanks again for looking into this — we appreciate your help and any further guidance you can provide.
Thanks for your detailed response — greatly appreciated.
To clarify a few points based on your feedback:
1. Hosting / Resource Constraints
While I agree that single-core cPanel environments are limited, Site Kit has been running without any issues on these 80+ accounts for over 4 years. Nothing about the hosting specs or server limits has changed, and the performance degradation appeared across all sites simultaneously in the past few months.
This is why we are confident the issue is related to recent updates or new features in Site Kit, not the hosting environment itself.
2. New Features Increasing Load
You mentioned that recent additions such as:
- Visitor Groups
- Key Metrics enhancements
- Non-cached queries fixed only recently
likely increased API calls and server load.
This would align exactly with what we are seeing:
- Multiple high-cost REST API calls spawning simultaneously
- PHP worker saturation on single-core servers
- 503 errors specifically during Site Kit dashboard loads
We are not seeing performance issues anywhere else in wp-admin or the frontend.
3. Caching and API Calls
Your note that Site Kit caches responses for 1 hour is helpful.
However, our logs show identical simultaneous requests firing repeatedly when loading the dashboard — for example:/data/sync-audiences/data/report/data/survey-trigger
These calls trigger enough concurrent PHP processes to max out the CPU, even with caching, which suggests:
- Either cache misses
- Or increased number of endpoints
- Or newly added logic that is heavier than previous versions
This change in behaviour did not exist before mid-late 2024.
4. Modules & Features
We can test disabling:
- Visitor Groups
- Key Metrics
- PageSpeed Insights
…but none of these were historically an issue before mid-late 2024.
5. W3TC, Cloudflare, Wordfence
We have validated that this is not related to:
- Cloudflare proxying (problem persists when disabled)
- W3TC (minify only)
- Wordfence
Only the Site Kit dashboard and widgets causes CPU spikes.
6. What We Can Provide
We are happy to provide:
- Site Health info from an affected site
- A console recording showing the failing requests
- CPU / PHP worker usage snapshots
- REST API timing logs
Please let us know specifically which details would be most useful.
7. Key Concern
The main concern is that the plugin has operated perfectly in this environment for years, and the sudden issues across all sites strongly suggest a performance regression or increased workload introduced in recent versions of Site Kit — not environmental limitations.
We want to avoid simply “throwing more resources” at the problem if it stems from recent changes in Site Kit itself.
Hi there, I just wanted to add that we have also identified this vulnerability flagged by Wordfence and are concerned about the security implications.
Can you please provide an update on when a patch will be released, or if there is a recommended temporary mitigation we can apply in the meantime?
We appreciate your work on this plugin and would like to continue using it, but need to ensure the site remains secure. Looking forward to your response.
Thanks!
Forum: Plugins
In reply to: [Address Book for WooCommerce] Plugin version issueThanks for the feedback.
Yes 3.0.2 was working fine until two months ago maybe a woo update made the version unstable causing the failed orders on address line 1 during payment processing
Would have thought this would have been detected and an update released on ver 3.0.2 rather than having to disagnose the problem ourselves detect it was an issue with ver 3 and manually remove the plugin to install a previous version 2 to get the failed orders to stop in the interim while we wait for a stable version to be released for ver 3
