Performance audits produce long lists. Compress images, defer scripts, preconnect to this, lazy-load that. Most of it is correct and most of it is also not where the time should go first. Here's the order we actually work through with clients, ranked by how much each item tends to move real user experience, not just a lab score.
1. Fix layout stability before anything else
Unexpected layout shift — content jumping around as a page loads — is the single most noticeable performance problem to an actual visitor, even though it's not really a "speed" issue at all. The fix is almost always the same: reserve space for anything that loads asynchronously.
- Set explicit
widthandheightattributes on every image, or use anaspect-ratioin CSS. - Reserve space for ad slots and embeds before they load, rather than letting them push content down once they arrive.
- Load custom web fonts with
font-display: swapplus a matched fallback font so text doesn't visibly reflow when the real font arrives.
This is usually a few hours of work and it's the one fix visitors notice immediately, because it stops the page from feeling like it's fighting them.
2. Get the largest image or text block rendering fast
This is what Largest Contentful Paint measures: how long it takes for the biggest visible element — usually a hero image or headline — to actually appear. Two things tend to cause slow LCP:
- The hero image is too large and uncompressed. Serve modern formats (WebP or AVIF), sized for the container it's actually displayed in, not the camera's native resolution.
- The hero element is discovered late. If the image is set via CSS
background-imageor loaded by JavaScript after the page renders, the browser can't start fetching it early. A plain<img>tag near the top of the HTML, with afetchpriority="high"hint, gets discovered immediately.
The fastest image is the one the browser finds out about first, not the one that's been compressed the hardest.
3. Reduce what runs before the page is interactive
Interaction responsiveness suffers most from JavaScript that runs early and blocks the main thread — third-party scripts especially. A practical process:
- Audit every third-party script (chat widgets, analytics, ad tags) and defer anything that isn't needed for the first interaction.
- Load non-critical JavaScript with
defer, and reserveasyncfor scripts with no dependencies on page content. - Break up large JavaScript bundles so the browser can interleave rendering work between chunks, rather than one long blocking task.
Where Google Ads fits in
If you're running paid traffic, page speed compounds: a slower landing page raises cost per click through Quality Score and lowers conversion rate on top of that. The three fixes above are usually enough to move a landing page from "acceptable" to "fast" without a full rebuild.
4. Everything else, roughly in order
| Fix | Typical effort | Typical impact |
|---|---|---|
| Image compression & modern formats | Low | High |
| Reserved space for images/embeds | Low | High |
| Deferring third-party scripts | Medium | High |
| Font loading strategy | Low | Medium |
| Server response time / hosting | Medium–High | Medium |
| Code-splitting a JS bundle | High | Medium |
| Preconnect / DNS-prefetch hints | Low | Low–Medium |
A note on chasing the score
Lab tools are useful for diagnosis, not as a target in themselves. A page can hit a perfect lab score and still feel slow to a real visitor on a real connection, and the reverse happens too. Use field data — real user metrics from actual visitors — as the source of truth, and treat the lab score as a way to find and reproduce a specific problem, not the finish line.