How to manage WordPress performance across multiple sites

Record each site's host, PHP version, theme, important plugins, CDN, server-level cache and WordPress cache plugin. Note whether it runs WooCommerce, a membership system, bookings or another feature that depends on logged-in or personalised content.

Test the same homepage, content page and conversion page on each site while logged out. Save the results and record whether the problem is slow server response, large assets, render-blocking files or a slow third-party service. Performance work is ongoing, so keep a simple before-and-after record rather than chasing a perfect score.

Decide which layer owns page caching on each site: the host, a CDN, or a WordPress caching plugin. Do not run multiple page-cache systems with overlapping controls unless the host documents that setup. Check which layer purges when content changes and whether it also caches at the CDN or edge.

The manual route is to open each site's performance settings separately, configure one cache solution, and document the settings. This is fine for a small portfolio, but it becomes slow and error-prone when sites drift apart or a cache must be cleared during an urgent fix.

Start with low-risk changes: resize and compress images, remove unused plugins and themes, update supported software, reduce unnecessary third-party scripts, and use a CDN where it suits the site's visitors. Enable minification, deferred loading or delayed JavaScript one change at a time, then check the front end.

Do not assume the same settings work everywhere. Check navigation, search, forms, login, checkout, cart fragments, cookie notices and page-builder layouts. If a feature breaks, turn off the last change or exclude the affected file or URL rather than adding random exclusions.

After changing cache, CSS or JavaScript settings, purge the affected cache and check the site in a private browser window. If the cache supports preloading, let it rebuild from the site's sitemap or approved URLs. Preloading requires publicly reachable pages and working WP-Cron or server cron; host-level caching can also prevent a plugin's own cache folder from being used.

Do not purge every site automatically after every update. A full purge can briefly increase origin traffic, and a large site may take time to preload. Purge and preload in batches, and exclude sites with unusual traffic or long-running preload jobs when necessary.

Recheck the saved test pages on mobile and desktop, both logged out and logged in where relevant. Submit a form, complete a test purchase, open the menu, search the site and confirm that images, fonts, consent tools and analytics still work.

Compare server response time, page load experience and real user reports over several days. A faster synthetic score is not a win if checkout fails or cached pages show private information. Clear browser, page, object and CDN caches separately when diagnosing a stale result.

For a larger portfolio, install and activate the required cache plugin on each child site, then connect those sites to your MainWP Dashboard. MainWP Rocket can centralise WP Rocket preferences and let you clear or preload cache without opening every site's WordPress admin.

Keep site-specific exceptions documented and apply changes to one representative site first. MainWP's cache controls can also send purge requests to detected cache plugins and services, but you still need to review the result for each site.

Fast way: use MainWP Rocket to manage the shared WP Rocket settings, select the relevant child sites, clear and preload their caches after approved changes, then spot-check the homepage and one important conversion page on each site.