Every page speed article lists the same ten tips: compress images, enable caching, use a CDN. They’re not wrong, and they’re not where your seconds are going. Here’s what we actually find when auditing real sites, in the order it usually matters.
Measure the right thing first
“Page speed” isn’t one number. Google measures three things, and they fail for different reasons:
- Largest Contentful Paint (LCP) — how long until the main content appears. Usually an image, a heading, or a hero block.
- Interaction to Next Paint (INP) — how long the page takes to respond when someone taps something. Almost always JavaScript.
- Cumulative Layout Shift (CLS) — how much the page jumps around while loading. Usually images or ads without reserved space.
Run PageSpeed Insights, but read the field data at the top, not the lab score below it. Field data is real visitors on real connections. The lab score is a simulation, and optimising for it is how people end up with a green number and a slow site.
The things that actually cost seconds
1. Third-party scripts you forgot about
This is the biggest one, and it almost never appears in generic advice. On one audit, a single form-protection widget was pulling 1.4MB on every page view — including pages with no form on them at all, because the form sat in the footer.
On the same site: an ad plugin injecting 113KB of inline JavaScript, a duplicate analytics tag firing twice, and two separate captcha services loading simultaneously with different site keys.
None of that is your theme. None of it shows up as an obvious line item. All of it loads on every page.
What to do: open the Network tab, sort by size, and look at every request going to a domain that isn’t yours. For each one, ask whether it needs to load on this page or just on one page. Most can be gated.
2. Assets loading where they’re not used
A plugin that adds a feature to one page typically loads its CSS and JavaScript on all of them. Multiply by twenty plugins and the homepage is carrying code for features it doesn’t have.
Contact form styles on pages without forms. Slider scripts on pages without sliders. Ecommerce assets on a blog post. It adds up quietly.
What to do: conditional loading — dequeue assets on pages where the relevant shortcode or block isn’t present. This is usually the single largest saving available on a mature site.
3. Images that were never optimised
Not “compress your images” — specifically:
- Serving a 2000px image into a 600px slot. The browser downloads all of it and then shrinks it.
- No WebP. Typically 25–35% smaller than JPEG at the same visual quality.
- Lazy loading the hero image. Worse than not lazy loading at all — it delays the exact element LCP measures. Lazy load everything below the fold.
- No width and height attributes. The browser can’t reserve space, so the page jumps. That’s your CLS score.
4. Render-blocking resources
CSS and JavaScript in the <head> stop the page rendering until they download. Some of that is necessary. Most isn’t.
Web fonts deserve particular attention. A font loaded from a third-party host adds a DNS lookup, a connection and a download before any text appears. Self-hosting it removes two of those three steps.
5. Database and server-side weight
Less visible, because it happens before anything reaches the browser — but it’s the delay before the first byte arrives.
On WordPress specifically, watch autoload weight: options loaded on every single request. Themes and plugins write settings there and frequently don’t clean up when removed. On one site we migrated, clearing out data left behind by three retired themes took autoload from 1,131KB down to 540KB. That weight was being loaded on every page view, for years, for nothing.
Things that help less than you’ve been told
- Switching hosts. Sometimes right, rarely the main problem. A fast server still has to send whatever you’re asking it to send.
- Switching themes. Theme choice is maybe 10% of your page weight. The plugin stack and configuration is the rest.
- Aggressive “optimisation” plugins. Features like automatic script deferral can break JavaScript by changing its execution order. We’ve seen more sites broken by these settings than sped up by them.
- Chasing 100/100. Going from 45 to 85 is worth real money. Going from 85 to 100 usually costs more than it returns.
A sensible order to work in
- Pull the field data and find out which metric is actually failing
- Open the Network tab and find the largest requests
- Remove or gate third-party scripts that don’t need to be there
- Gate plugin assets to the pages that use them
- Fix the LCP image: right size, WebP, not lazy loaded
- Add width and height to every image to fix layout shift
- Self-host fonts, or remove them
- Clean up database and autoload weight
- Then consider caching and CDN configuration
Most sites are fixed by steps 3 and 4. Most advice starts at step 9.
Where to start
Run PageSpeed Insights on your slowest page, read the field data, then open the Network tab and sort by size. The answer is usually visible within two minutes, and it’s usually something nobody remembered installing.
If you’d rather someone else looked, we do a free written audit that names the specific causes in priority order.
