SEO
Every year someone declares that page speed "doesn't really matter for rankings anymore," and every year the sites that load fastest keep quietly outperforming the ones that don't. The reason is simple: speed isn't just a ranking signal, it's a filter on whether anyone sticks around to be ranked at all.
It's easy to treat Core Web Vitals as a box-ticking exercise for search engines. But long before Google decides how a slow page affects its position, a real visitor has already decided whether to wait for it. A few extra seconds of load time is enough for someone to hit back and choose a competitor instead — and that bounce is a signal too.
Before changing anything, it's worth knowing whether you're looking at lab data (a simulated test run, like Lighthouse in Chrome DevTools or WebPageTest) or field data (real measurements from actual visitors, via the Chrome User Experience Report). They can disagree, and both are useful for different reasons:
A site can look perfectly fast in a lab test run on a fast laptop and still fail Core Web Vitals in the field, because most of its visitors are on mid-range phones on 4G. Chase the field data first — that's the number that reflects reality and the one search engines actually use for ranking signals.
In practice, the same handful of culprits show up again and again. It's rarely one dramatic villain — it's several smaller ones stacked on top of each other.
loading="lazy", so the browser downloads every image on the page even if half of them are below the foldwidth and height attributes, so the browser can't reserve space and the layout jumps as each image loads in<head> without defer or async, holding up everything below themfont-display: swap, leaving text invisible until the font arrives<link rel="preload"> on the fonts that appear in the very first viewportNot every fix is worth the same amount of effort, and it's worth being honest about which category something falls into before promising a client a timeline.
font-display: swap, deferring non-critical scripts, removing unused third-party embeds.Most sites get 70–80% of the way to a good score from the quick wins alone. The structural fixes matter more for sites that are already fighting an architecture that wasn't built with performance in mind.
Most of the time, a meaningful speed improvement comes from a short, targeted list: compressing and correctly sizing images, deferring non-critical scripts, self-hosting fonts with sensible fallbacks, and cutting anything loaded "just in case" that isn't earning its place. It's rarely one dramatic fix — it's a dozen small ones that add up.
Once changes go out, measure again with the same tool you started with, ideally more than once — a single test run can be noisy, and it's easy to mistake normal variance for progress (or a regression) that isn't really there.
If you're not sure where your own site stands, that's usually the first thing worth checking before any redesign work starts.
A quick technical audit usually turns up a handful of fixes worth making before anything else.