Speeding up one WordPress site is a project. Speeding up a fleet is a policy. The agencies we see winning on performance did not optimize 200 sites by hand; they decided what “fast” meant, set defaults that every site inherits, and used monitoring to find the handful that drift. This guide covers the policy, the layers, and the tooling.
Define the fleet target
Pick one number set and hold every site to it. Google’s thresholds are the natural choice because clients can verify them in Search Console:
| Metric | Good | Fleet rule |
|---|---|---|
| LCP (Largest Contentful Paint) | under 2.5s | Every site passes on mobile, field data |
| INP (Interaction to Next Paint) | under 200ms | Every site passes; builders and sliders are the usual culprits |
| CLS (Cumulative Layout Shift) | under 0.1 | Every site passes; fonts and ad slots are the usual culprits |
Measure field data (CrUX, real users), not just lab scores. A site can score 95 in Lighthouse and still fail Core Web Vitals in the field because real visitors are on cheap phones over mobile networks.
Report the pass rate as a fleet number: “184 of 200 sites pass all three.” That number is what you improve month over month, and it is a strong line in your care-plan renewals.
Layer the caching, then stop fiddling
Most WordPress performance problems are solved by four caching layers in the right order. Configure them once as a standard, then apply to every site.
- Edge / CDN cache. Put Cloudflare or the host’s CDN in front, cache static assets aggressively, and cache full HTML for anonymous visitors where the site allows it. This alone removes most of the server from the equation for brochure sites.
- Page cache. Server-level (Nginx FastCGI, LiteSpeed, Varnish) if the host provides it; a page-cache plugin if not. Never both at once; they fight.
- Object cache. Redis or Memcached for any site with WooCommerce, memberships, or a lot of logged-in users. Brochure sites do not need it.
- Browser cache. Long
Cache-Controlheaders on versioned assets. This is usually handled by layers 1 and 2 but worth verifying.
Document the standard configuration per host you work with. The same fleet often spans three or four hosts, and “our Cloudflare + Kinsta setup” and “our Cloudflare + DreamHost setup” are different runbooks.
Image policy: the biggest single win
On typical agency fleets, images account for more than half the page weight, and the fix is boring and mechanical:
- Serve WebP or AVIF via a plugin or the CDN; keep originals.
- Cap upload dimensions at 2560px on the long edge and auto-resize on upload. Clients will upload 6,000px camera originals forever otherwise.
- Lazy-load everything below the fold but never the LCP image. Many sites fail LCP purely because the hero is lazy-loaded.
- Set explicit width and height on images and embeds to kill CLS.
- Preload the hero image and the primary web font in the head.
Run a fleet-wide audit for sites with uploads over 1MB, fix them in bulk, and put the upload cap in your onboarding checklist so it never recurs.
Plugin hygiene
Every plugin is a tax on every page load. Fleet rules that keep the bill down:
- Standard stack. Define an approved list (SEO, forms, caching, security, backups) and use the same plugins on every site unless a client has a documented reason. Fewer variants means fewer surprises and faster troubleshooting.
- Delete, do not deactivate. Deactivated plugins are still an attack surface and still show up in updates.
- Audit the heavy hitters. Sliders, social feeds, chat widgets, and anything that loads a third-party script on every page. Replace or conditionally load them.
- Cap the count. A brochure site above 20 active plugins deserves a look; above 35 deserves a conversation with the client.
- Watch for duplicates. Two SEO plugins, two caching plugins, three “optimization” plugins on one site is common on inherited work.
Use the fleet inventory to find these in bulk. “Which sites run more than one caching plugin” should be one query, not a manual sweep.
Third-party scripts and fonts
The remaining budget usually goes to things outside WordPress: tag managers with twelve tags, embedded video, chat widgets, and web fonts. Load analytics with defer or via a consent-gated tag manager, self-host fonts where the license allows (fewer connections, better CLS), use lightweight facade embeds for YouTube, and ask hard questions about any widget that loads on every page but converts on one.
Monitoring: find the drifters
Sites do not stay fast. Someone installs a slider, a plugin update adds a script, a client uploads a 9MB banner. Without monitoring, you find out when the client emails you a Lighthouse screenshot.
Fleet-level performance monitoring should give you three views:
- Fleet pass rate for Core Web Vitals, tracked weekly.
- Movers: the ten sites whose LCP or INP got worst this week, so you investigate causes, not symptoms.
- Per-site history, so you can line up a regression with the update that caused it.
WP Maintain includes MainMonitor for exactly this: synthetic and field performance data across every site you manage, with alerts when a site crosses the threshold and a timeline you can match against update logs. Performance reports then go into the same white-label monthly report as uptime and security.
A fleet speed sprint, in order
- Pull the inventory: hosts, caching plugins, image plugins, plugin counts, CWV status.
- Apply the caching standard to every site that does not have it.
- Bulk-convert images and set the upload cap.
- Remove duplicate and dormant plugins fleet-wide.
- Hand-tune the 10 to 20 sites still failing (these are almost always page-builder sites or stores).
- Turn on monitoring and report the pass rate monthly.
Most agencies see the majority of the fleet pass after steps two through four, with very little per-site work.
Next step
Fast fleets stay fast because someone is watching. WP Maintain combines maintenance, monitoring, and MainMonitor performance tracking so you can see every site’s Core Web Vitals in one place and catch regressions before your clients do. Bring your fleet and we will show you which sites are dragging the number down.