Performance advice tends to arrive as an undifferentiated list of ninety optimisations. In reality, on most sites, three or four issues account for nearly all the damage — and they are usually not the ones the audit tool puts at the top.
Largest Contentful Paint is the one that pays
LCP measures when the main content becomes visible. It correlates with bounce rate more directly than any other metric, and on almost every site we audit it is dominated by a single element: the hero image.
The fixes are unglamorous and effective. In rough order of return per hour spent:
- Serve the hero image in a modern format at the size it actually renders — not a 3000px JPEG scaled down in CSS.
- Preload it explicitly so the browser does not discover it late in the parse.
- Remove render-blocking resources ahead of it, particularly third-party fonts and tag managers.
- Server-render the page so the hero exists in the HTML rather than after a JavaScript bundle executes.
Cumulative Layout Shift is cheap to fix and infuriating to users
CLS measures how much content jumps around while loading. It is the metric behind tapping a button and hitting an ad instead, and it is usually caused by a handful of identifiable culprits.
- Images and video without explicit dimensions or aspect ratio reserved in CSS.
- Web fonts swapping in at different metrics from the fallback.
- Banners, cookie notices, and ads injected above existing content.
- Content that expands after an asynchronous fetch resolves.
Every one of these is a small fix. Collectively they are often the difference between a passing and a failing assessment, which makes CLS the best return on effort of the three.
Interaction to Next Paint matters most on interactive pages
INP measures responsiveness to input. On a brochure site it is rarely the binding constraint. On a checkout, a filterable catalogue, or a dashboard, it is frequently the whole problem.
The usual cause is too much JavaScript executing on the main thread. Ship less of it, split what remains by route, and move genuinely expensive work off the critical path. Before optimising, though, check whether the code needs to run on the client at all — a surprising amount of it does not.
The third-party script problem
It is common to spend a week optimising a bundle and then hand the gains straight back to a chat widget, three analytics tools, a heatmap recorder, and two remarketing pixels.
Audit them ruthlessly. For each one, ask who looked at its output in the last quarter. Load what survives that question lazily, after interaction where possible, and never let a third-party script block the hero.
The fastest code is the code you did not ship. The second fastest is the code that runs after the page is already useful.
A realistic sequence
If you have a week rather than a quarter, spend it in this order: fix the hero image, remove render-blocking resources, reserve space for anything that loads late, audit third-party scripts, then look at JavaScript volume. That sequence gets most sites into the green without touching the architecture.
