Great consolidation tool, but needs honest documentation about resource use

We manage 75+ WordPress sites for clients and have Site Kit installed on most of them. The plugin’s core value — consolidating tracking code insertion for Analytics, Search Console, Tag Manager, Ads, and PageSpeed Insights into a single managed plugin — is genuinely useful. We rely on it to keep clients’ Google service integrations consistent and centrally managed. That part deserves credit.

However, since 2025 the plugin has become increasingly problematic on shared hosting and resource-isolated environments (cPanel/CloudLinux reseller accounts in our case). The Site Kit dashboard widget fires 6+ parallel Google API requests on cold-cache admin loads, with each GA4 Data API call now taking 10-15 seconds (vs sub-second on the old Universal Analytics API). When these requests fire concurrently with other admin widgets (WooCommerce, Yoast, Wordfence), they exhaust CPU, memory, and I/O limits on standard shared hosting accounts, producing 503 errors and 20-40 second dashboard load times.

This isn’t a bug — it’s an architectural consequence of how the widget loads data — but it’s also not mentioned anywhere in the plugin’s documented requirements. The current minimum requirements list WordPress version, PHP version, browser support, and REST API availability, but nothing about hosting resources, concurrent connections, or worker capacity. For an agency deploying Site Kit at scale, this gap led to weeks of diagnostic work across multiple sites before identifying the plugin’s resource burst pattern as the cause.

Two specific requests:

1. Add a setting to disable the dashboard widget. A toggle in Admin Settings (similar to the existing “Display relevant page stats in the Admin bar” option) would let administrators disable the Summary widget across all users at once. Currently the only options are unchecking it per-user via Screen Options (doesn’t propagate to other admins) or adding custom code to remove the meta box (fragile if the widget ID changes).
2. Document the resource requirements honestly. The plugin should mention that the dashboard widget makes concurrent Google API calls on cold cache, that these calls can take 10+ seconds each, and that shared hosting environments may need to disable the widget or upgrade hosting resources to handle the burst.

Workaround for other agencies hitting this:

Until a first-class setting exists, this code (placed in a mu-plugin or child theme functions.php) removes the Site Kit dashboard widget for all users:

/**
 * Disable Site Kit Dashboard Widget
 *
 * Site Kit's dashboard widget makes 6+ Google API calls on cold-cache
 * dashboard loads. On resource-constrained hosting these can exhaust
 * account limits and cause 503 errors. 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);

Note: the widget ID (google_dashboard_widget) is current as of Site Kit at time of writing, but could change in future releases.

Detailed diagnostic data, network waterfalls, and the support thread tracking this is at: Wordpres Support Topics unable to add link here just search: Sudden high CPU and 503 errors on Site Kit dashboards across 80+ sites

We’ll continue using Site Kit because the consolidated tracking management is genuinely valuable for agency workflows. Better documentation of these characteristics would have saved significant diagnostic time and would help other agencies set hosting expectations correctly when deploying Site Kit at scale.