Support
Support

90 Minute Audit to Speed Up WordPress Sites for Agencies

Three changes deliver most of the gain: move the site to PHP 8.3+ on modern hosting, switch on server-level caching, and fix the hero image so it loads first, not last. Measure Largest Contentful Paint and Time to First Byte before you touch anything, then again after. The rest of this guide, starting with the ten quick wins below, fills in everything else you need to make a WordPress website faster without breaking client sites.

TL;DR:

  • Moving to PHP 8.3+ and enabling OPcache can significantly reduce server response times and improve overall speed.
  • Converting hero images to WebP or AVIF and preloading them addresses the largest contentful paint and reduces perceived load time.
  • Layering caching strategies, including server-level caching, object caching, and CDN, must be done in proper order with careful invalidation to avoid stale content.
  • Optimizing images with responsive srcsets, proper dimensions, and avoiding lazy-loading the hero image can improve Core Web Vitals, especially LCP and CLS.
  • Regularly auditing autoloaded options, database optimization, and monitoring third-party scripts prevent slowdowns caused by untracked data or excessive external tags.

Table of Contents

Top quick wins: 10 immediate speed fixes to apply now

Most agencies inherit sites nobody has touched since launch. Before scoping a rebuild or a hosting migration, run through this list. Each item takes 30 to 90 minutes and the combined effect is usually the difference between a client complaining about load times and a client asking what you did.

  1. Move to PHP 8.3 or newer and enable OPcache. Older PHP versions are slower at everything WordPress does: rendering templates, querying the database, running plugin logic. OPcache caches compiled PHP so the server doesn’t recompile the same files on every request. Most managed hosts enable this by default, but budget and reseller hosting often don’t.
  2. Turn on server-level page caching or microcaching. If your host offers Nginx FastCGI cache or similar, use it before reaching for a plugin. Server-level caching sits closer to the request and skips PHP entirely for cached pages.
  3. Install a cache plugin with conservative defaults. WP-Optimize handles page caching, minification and database cleanup from one dashboard, which suits agencies managing several client sites with limited time per site.
  4. Convert the hero image to WebP or AVIF and preload it. The image above the fold is almost always the Largest Contentful Paint element. Preloading it and serving it in a modern format shaves real seconds off perceived load time.
  5. Lazy-load everything below the fold. Images, embedded videos and iframes further down the page don’t need to load until the visitor scrolls near them. Native lazy loading (loading="lazy") works in every modern browser.
  6. Defer non-critical JavaScript. Chat widgets, analytics snippets and marketing pixels rarely need to run before the page is visible. Delay them until after first paint or until a user interacts with the page.
  7. Remove heavy frontend plugins rather than counting plugins. Plugin count is a weak signal. Jetpack’s own research on plugin load found that a single heavy plugin can carry more JavaScript and autoloaded data than a dozen lightweight ones combined. Audit by asset weight, not by how many icons sit in the plugins list.
  8. Enable a CDN for any site with visitors outside its host’s region. A content delivery network serves static assets from a location physically closer to the visitor, cutting latency on images, fonts and scripts.
  9. Set long cache headers on static assets. Images, CSS and JS files rarely change between deployments. A cache lifetime of 30 days or more means returning visitors barely download anything.
  10. Run a PageSpeed or WebPageTest scan before you start, and another when you finish. Without a before-and-after number, you can’t prove the work happened, and you can’t charge for it with confidence.

Pro Tip: Do items 1, 3 and 4 in that order on every new client site before you look at anything else. They’re the three changes most likely to move Core Web Vitals into the “good” range on the first pass, and they take under two hours combined.

Read through four proven WordPress speed fixes agencies can apply for a deeper walkthrough of the conversion impact behind these changes, particularly the 0.1 second effect on checkout completion rates.

How to measure your site: tools, target metrics and interpreting results

Guessing at speed is how agencies end up arguing with clients about a problem nobody can actually point to. Use the right tool for the right question, and know the numbers you’re aiming for before you start.

Which tool for which job:

The three Core Web Vitals plus one non-Vital metric matter most:

A waterfall chart tells you whether a problem is server-side or front-end. A long first bar before anything else starts loading points at TTFB and hosting. A cluster of blocking requests after that points at render-blocking CSS and JavaScript, which sits in the front-end fixes covered later.

Realistically, most agency client sites should target a PageSpeed score in the 80s to low 90s on mobile, LCP under 2.5 seconds, and TTFB under 500 milliseconds on cached pages. Chasing a perfect 100 on every page usually costs more engineering time than it returns in conversions.

Hosting and server‑level optimisations that set the ceiling

Every front-end fix you make sits on top of the server’s response time. If TTFB is 1.8 seconds, no amount of image compression or JavaScript deferring will get overall load time under three seconds. Hosting is the ceiling; everything else just gets you closer to it.

Hosting and server‑level optimisations that set the ceiling — overview diagram

A community discussion on autoloaded WordPress data makes a point worth repeating to any client who thinks a CDN alone will fix a slow site: a CDN distributes static files faster, but it does nothing for a slow origin server generating dynamic pages. Fix the origin first.

What to look for in a host:

Signs a hosting move is overdue:

If two or more of those apply, no amount of plugin tuning closes the gap. That’s a hosting conversation, not a caching one, and it’s usually the single biggest speed decision you’ll make on a client’s behalf all year.

Caching strategy: page cache, object cache and CDN best practice

Layer caching in order, not all at once. Get the first layer working properly before adding the next, because stacking three caching systems without understanding how they interact is the fastest way to create a support ticket about a page that “won’t update.”

The order that works:

Exclusions matter as much as the caching itself. Never cache the WordPress admin area, the cart or checkout pages on a WooCommerce site, or any REST API endpoint that returns dynamic, user-specific data. Getting this wrong shows a stale cart total to one customer and someone else’s session data to another, which is a far worse problem than a slow page.

Pro Tip: If a client reports content changes not appearing after a publish, check for conflicting cache layers before touching anything else. A server-level cache, a caching plugin and a CDN edge cache can each hold a different version of the same page, and clearing only one of them leaves the others serving stale content.

An agency guide to WordPress speed for client sites makes a similar point: layered caching only works with sensible invalidation logic, so add each layer deliberately rather than switching everything on at once and hoping it behaves.

Images and media: formats, responsive sizing and LCP handling

Media is usually the single heaviest part of a WordPress page, and it’s where the HTTP Archive’s page weight research consistently finds the biggest opportunity for improvement across the web. The 2024 page weight almanac shows that modern formats and responsive sizing cut typical image payload significantly compared with unoptimised JPEG and PNG uploads.

Rules that fix most image problems in one pass:

Get these five right and you’ve usually addressed both LCP and CLS from one round of work, which is rare: most fixes only move one metric at a time.

CSS and JavaScript: reduce render‑blocking work

Render-blocking assets delay the moment a browser can paint anything. A stylesheet or script sitting in the <head> with no defer or async attribute forces the browser to stop, download it, execute it, and only then continue building the page.

Cut this down with three techniques:

Pro Tip: Test critical CSS changes on a staging copy before pushing to production. Getting the above-the-fold selection wrong doesn’t crash the site, but it can cause a visible flash of unstyled content on first load, which looks worse to a client than the slow page you started with.

Database and WordPress internals that slow every request

WordPress stores site-wide settings in the wp_options table, and a chunk of that table loads on every single page request whether it’s needed or not. This is the “autoload” mechanism, and it’s one of the least visible causes of a slow site because nothing in the admin area flags it as a problem.

Database autoload settings slowing page requests

When autoloaded data grows past roughly 800 KB to 1.5 MB, it starts materially increasing both TTFB and the memory each PHP worker needs to allocate on every request, according to analysis behind the page weight almanac. Pruning that autoloaded weight is often the single fastest way to cut TTFB on uncached, logged-in, or dynamic pages, faster than most server upgrades.

Database tasks worth running on every client site, in order of impact:

These are invisible fixes. Nobody sees a smaller wp_options table. But they’re often what separates a site that’s fast on a good day from one that’s fast every day, under real traffic, at the end of a campaign send.

Third‑party scripts and tags: audit, delay and server-side options

Third-party scripts are the least controllable part of any client site’s performance, because you don’t own the code and it can change without warning. A tag manager container that was lightweight six months ago can silently balloon after a marketing team adds five new pixels.

Run this audit on every site with a tag manager installed:

The rule of thumb: defer what’s genuinely still in use, remove what isn’t, and never assume a script is harmless just because nobody complained about it yet.

A practical 90‑minute agency audit and prioritisation workflow

Running the same audit every time is what makes speed work scale across a client roster instead of eating a full day per site. Here’s the sequence that fits in 90 minutes on a typical WordPress client site.

  1. Baseline test (10 minutes). Run PageSpeed Insights and WebPageTest, record LCP, INP, CLS and TTFB. Screenshot the results before touching anything.
  2. Server check (10 minutes). Confirm PHP version, OPcache status and whether server-level caching is available. Flag a hosting move here if TTFB is already over 800 milliseconds with nothing else installed.
  3. Plugin and theme audit (15 minutes). Check asset weight per plugin, not plugin count, and remove anything unused.
  4. Apply the standard config (30 minutes). Cache plugin with cache exclusions set for admin, cart and API endpoints; image conversion run across the media library; critical CSS and JS deferral enabled.
  5. Hero image fix (10 minutes). Preload the LCP image, confirm it isn’t lazy-loaded, set width and height attributes.
  6. Retest and compare (10 minutes). Run the same tests from step one and log the delta against the baseline screenshot.
  7. Watch for regressions (15 minutes). Click through checkout, forms and any custom functionality. Caching and CSS deferral are the two most common causes of a broken checkout or a layout that looks fine on desktop and wrong on mobile.

If TTFB doesn’t move after this sequence, that’s the signal to escalate to a hosting migration or a deeper engineering fix rather than repeating front-end work that’s already been done. The full agency audit methodology covers what to do when a site needs that deeper pass.

Expert notes from Marcel and how WPCTO approaches speed for agencies

Standardisation is what makes speed work profitable rather than a time sink. Running a bespoke investigation on every client site burns hours that never get billed properly, which is exactly why WPCTO builds one repeatable stack and audit process, then applies it consistently across every agency client site it manages.

One agency partner came to WPCTO with a client site returning a PageSpeed mobile score in the low 30s and an LCP past 5 seconds. The fix wasn’t exotic: PHP upgrade, server-level caching, hero image preload and a database autoload cleanup. Within a week, the same site was scoring in the high 80s with LCP under 2.2 seconds, and the agency billed the work as a discrete optimisation project rather than absorbing it as unpaid support time.

That pattern repeats constantly. The gap between “slow” and “fast” is rarely a mystery once you measure it properly. The harder problem for most agencies isn’t knowing what to fix, it’s finding the hours to fix it across a dozen client sites while also delivering new project work.

That’s the gap a tool like the WordPress Profit Calculator is built to show clearly. It takes under 90 seconds to see how much revenue is sitting uncaptured in an agency’s existing WordPress client base, work that’s happening informally and unbilled right now.

Common mistakes agencies make and how to fix them

The mistake I see most often isn’t a bad fix, it’s the wrong sequence. Agencies install a caching plugin, see the PageSpeed number jump, and stop there, without ever checking whether checkout still works or whether the admin area got cached by accident. Speed work done in the wrong order creates new problems faster than it solves old ones.

The second recurring mistake is treating speed as a one-off project rather than ongoing maintenance. A site optimised in January can be back to a low score by June, because a new plugin got added, a marketing team dropped in three more tracking pixels, or a theme update quietly re-enabled render-blocking assets. I’ve seen an agency lose a client renewal over exactly this: the site was fast at handover, nobody monitored it for eight months, and by the time the client noticed, the relationship had already soured.

The fix is process, not heroics. Put speed checks into your CI pipeline or staging gate before anything reaches production. Whitelist the plugins your team trusts and question anything outside that list. Treat performance as a recurring line item, checked monthly, not a box ticked once at launch.

— Marcel

How WPCTO helps: managed speed packages, quick fixes and the profit calculator

WPCTO is the alternative to building an in-house performance function you don’t have time to staff. Agencies come to WPCTO because the standard 90-minute audit above, the hosting checks, the caching layers, the database cleanup, the ongoing monitoring, becomes someone else’s job, delivered under a Service Level Agreement, either white-labelled under the agency’s own name or as a named specialist partner.

Wpcto

The services map directly onto everything covered here: performance optimisation as a one-off quick fix for a single struggling site, or as part of an ongoing maintenance and care plan that keeps a whole client roster fast month after month. For agencies that want the work fully invisible to their clients, the white-label WordPress support option keeps the agency’s brand front and centre while WPCTO handles delivery behind the scenes.

Typical time-to-value on a speed engagement looks like this:

Engagement type Typical turnaround What changes
Quick fix (single site) 1–3 days Hero image, caching, PHP version, quick audit fixes
Full performance pass 1–2 weeks Hosting review, database cleanup, caching layers, monitoring setup
Ongoing care plan Continuous Monthly checks, regression monitoring, proactive fixes

Before committing to anything, run your own client base through the WordPress Profit Calculator. It takes under 90 seconds and shows exactly how much recurring revenue is sitting unclaimed in the support work you’re already doing for free. Start there, then talk to WPCTO about turning that gap into a billed agency services relationship.

Sources

Secret Link