WPIntell

Source evidence

WordPress 7.0 Frontend Crash / Memory Exhaustion

Site Kit by Google – Analytics, Search Console, AdSense, Speed · support · 2026-05-22T20:57:00+00:00

complaintsentiment
highseverity
0.74relevance
2replies
Evidence linked to opportunitycommercial context

Proof Health

Open evidence

Commercial opportunities need traceable source links before they are treated as build-worthy.

7 / 36 rows with source links

19.4% of this page's analysis has direct source links.

0 build-decision rows missing links

0 rows here require auditable proof before promotion.

29 rows with no attached evidence

0 rows have source counts but still need direct links.

Conversation

support
Aristocles resolved
After updating to WordPress 7.0, the frontend of my site began crashing with repeated PHP memory exhaustion errors. The WordPress admin/dashboard continued working normally. Through troubleshooting, I isolated the issue specifically to the Google Site Kit plugin. Environment: WordPress 7.0 Elementor active Custom theme PHP memory limit initially set to 128M Symptoms: Frontend pages would fail to load WordPress admin area remained functional Repeated “Allowed memory size exhausted” fatals Elementor stack traces appeared initially, but Elementor was not the root cause The issue stopped immediately after disabling Google Site Kit. I also confirmed: Increasing the PHP memory limit to 512M allowed the site to function temporarily, but this appears to only mask the underlying issue rather than resolve it The recurring stack trace appears to indicate recursive behavior involving REST route preloading and asset callbacks. Relevant stack trace sections: Google\Site_Kit\Core\Assets\Assets->run_before_print_callbacks() Repeated recursively: Assets.php(1101) Assets.php(1101) Assets.php(1101) Additional related calls: WP_REST_Server->get_routes() rest_preload_api_request() wp_print_head_scripts() wp_head() This appears to be either: A recursion issue introduced with WordPress 7.0 compatibility Or a conflict involving REST preload handling Disabling Site Kit resolves the issue completely. Please let me know if you would like the full debug log or any additional environment details. Thanks for reaching out @aristocles , and sharing your findings. On the front end of a users site, the only requests for regular visitors to your site that are Site Kit related are the requests to the services you choose to connect within Site Kit, ie. Analytics, AdSensnse, Tag Manager. There are no “Site Kit” specific requests or additional load. These are the same requests a user would encounter if implementing these services manually, without using Site Kit. We have more on this here . Ads placed request in additional network requests to ad servers, as can tags added via Tag Manager. What you may be facing on the front end, depending on how you performed some checks, are requests related to the plugins admin toolbar feature. These requests do reference Site Kit, although they’re only visible to you as a logged in administrator, and other administrators or users with access. You can disable this if you wish. As regards the admin dashboard, if this is working as expected, when you mention it remained functional, this is great and more indicative of possible conflicts or additional load on the front end only. On the admin dashboard, Site Kit loads requests primarily on Site Kit endpoints, with a widget also displaying on the main WordPress dashboard. While I do suspect this may be either related to possible hosting or shared hosting related resources and possibly a conflict or additional load related to third party plugins, please do feel free to share your Site Health information and full stack trace from any errors via this form . I’ll also do some testing with WordPress 7 to see if I notice any peculiarities, although I believe much of the team have performed such checks. I’ll check in with them also. Thank you. Many thanks for your patience on this. I spent some time on this and I don’t notice any performance regression when upgrading from WordPress 6.9 or lower to WordPress 7. Some test results from one site can be found below: WordPress 6.9.4 (Site Kit 1.181.0) Without the Site Kit admin toolbar active: 71 performance score in Devtools Lighthouse With the Site Kit toolbar active: 71 performance score i n Devtools Lighthouse WordPress 7.0 (Site Kit 1.181.0) Without the Site Kit admin toolbar active: 92 performance score in Devtools Lighthouse With the Site Kit toolbar active: 70 performance score in Devtools Lighthouse Note that with any lighthouse, PageSpeed Insights or other performance measurement tool, there are a large number of factors, including latency, hosting environment, CDN etc. I did test a few sites and I noticed an improvement overall, primarily I suspect based on overall WordPress core changes, not specific to Site Kit. I’ll close this support topic but do ask if you have any further queries on this.

Comments

2 shown
James Osborne 2026-05-25T09:59:00+00:00

Thanks for reaching out @aristocles , and sharing your findings. On the front end of a users site, the only requests for regular visitors to your site that are Site Kit related are the requests to the services you choose to connect within Site Kit, ie. Analytics, AdSensnse, Tag Manager. There are no “Site Kit” specific requests or additional load. These are the same requests a user would encounter if implementing these services manually, without using Site Kit. We have more on this here . Ads placed request in additional network requests to ad servers, as can tags added via Tag Manager. What you may be facing on the front end, depending on how you performed some checks, are requests related to the plugins admin toolbar feature. These requests do reference Site Kit, although they’re only visible to you as a logged in administrator, and other administrators or users with access. You can disable this if you wish. As regards the admin dashboard, if this is working as expected, when you mention it remained functional, this is great and more indicative of possible conflicts or additional load on the front end only. On the admin dashboard, Site Kit loads requests primarily on Site Kit endpoints, with a widget also displaying on the main WordPress dashboard. While I do suspect this may be either related to possible hosting or shared hosting related resources and possibly a conflict or additional load related to third party plugins, please do feel free to share your Site Health information and full stack trace from any errors via this form . I’ll also do some testing with WordPress 7 to see if I notice any peculiarities, although I believe much of the team have performed such checks. I’ll check in with them also. Thank you.

James Osborne 2026-06-23T12:03:00+00:00

Many thanks for your patience on this. I spent some time on this and I don’t notice any performance regression when upgrading from WordPress 6.9 or lower to WordPress 7. Some test results from one site can be found below: WordPress 6.9.4 (Site Kit 1.181.0) Without the Site Kit admin toolbar active: 71 performance score in Devtools Lighthouse With the Site Kit toolbar active: 71 performance score i n Devtools Lighthouse WordPress 7.0 (Site Kit 1.181.0) Without the Site Kit admin toolbar active: 92 performance score in Devtools Lighthouse With the Site Kit toolbar active: 70 performance score in Devtools Lighthouse Note that with any lighthouse, PageSpeed Insights or other performance measurement tool, there are a large number of factors, including latency, hosting environment, CDN etc. I did test a few sites and I noticed an improvement overall, primarily I suspect based on overall WordPress core changes, not specific to Site Kit. I’ll close this support topic but do ask if you have any further queries on this.