Website speed optimisation is both a ranking factor and a conversion factor. A 1-second delay reduces conversions by up to 7%, and since 2021 Google's Core Web Vitals have been part of the ranking signals for both mobile and desktop search. In 2026, with mobile-first indexing fully standard, the version of your site Google evaluates is the one on a mid-range phone over a real mobile connection — not your desktop dev machine on fibre.
The Three Key Metrics
LCP (Largest Contentful Paint) — aim for under 2.5 seconds. This measures how long it takes the largest visible element (usually a hero image or heading) to render. Optimise your hero image by using WebP or AVIF format, serving correctly-sized images (not a 4000px image scaled down in CSS), preloading it with <link rel="preload">, and putting static assets behind a CDN.
CLS (Cumulative Layout Shift) — aim for under 0.1. This measures visual stability: how much content jumps around as the page loads. Always specify width and height attributes (or an aspect-ratio in CSS) on images, video embeds, and ad slots, and reserve space for web fonts with font-display: optional or matching fallback metrics.
INP (Interaction to Next Paint) — aim for under 200ms. This replaced FID in March 2024 and measures how responsive the page feels across every click, tap, and keypress during the visit, not just the first one. Long-running JavaScript on the main thread is the usual culprit — break up long tasks, and move anything that doesn't need to block rendering off the critical path.
How to Measure It
Don't guess — measure. Google Search Console's Core Web Vitals report shows real-user (field) data grouped by URL pattern, which is what actually affects rankings. PageSpeed Insights and Lighthouse give you a lab-data breakdown you can act on immediately, including exactly which resources are blocking render. If your site has enough traffic, the Chrome UX Report (CrUX) dashboard shows trends over time across real visitors' devices and connections.
Quick Wins
- Enable server-side compression (gzip or Brotli — Brotli typically compresses 15-20% smaller)
- Implement browser caching headers (
Cache-Controlwith a longmax-agefor static assets, versioned filenames for cache-busting) - Defer non-critical JavaScript with
deferorasync, and split large bundles so pages only load the code they actually use - Use a CDN for static assets so they're served from a location close to the visitor
- Convert images to WebP or AVIF format — typically 25-50% smaller than JPEG/PNG at equivalent quality
- Self-host web fonts (or use
font-display: swap) instead of blocking render on a third-party font request
For WordPress Sites
Install WP Rocket or LiteSpeed Cache, use Cloudflare as your CDN, and leverage lazy loading for images below the fold. Be selective with plugins — every extra plugin is extra PHP execution and often extra JavaScript on the front end. Audit your plugin list against what's actually still in use before optimising anything else.
Common Mistakes We See
The most common mistake is optimising Lighthouse's lab score while ignoring the Search Console field data — they can disagree, and field data (real visitors, real devices, real networks) is what Google actually uses for ranking. The second most common mistake is fixing LCP with image compression alone while the real bottleneck is server response time (TTFB): if your server takes 800ms to respond before the browser can even start downloading that hero image, no amount of image optimisation will get you under a 2.5-second LCP.
What each metric is actually measuring
The names obscure fairly simple ideas, and knowing what each one responds to tells you which fix applies.
| Metric | The question it asks | Usually caused by |
|---|---|---|
| LCP Largest Contentful Paint | How long until the main thing appears? | Slow server response, an unoptimised hero image, render-blocking CSS or fonts |
| INP Interaction to Next Paint | When someone taps, how long until something happens? | Heavy JavaScript occupying the main thread |
| CLS Cumulative Layout Shift | Does the page move under the reader's finger? | Images and ads without reserved space, late-loading fonts, injected banners |
INP replaced First Input Delay because FID measured only the delay before processing began, not how long the response actually took — which meant pages could score well while feeling sluggish. INP measures the whole interaction, so it is a harder test and a fairer one.
Field data versus lab data
This distinction causes more confusion than any other, and it explains why your tooling disagrees with itself.
Lab data comes from a simulated load on a synthetic device. It is reproducible, available instantly, and useful for debugging a specific change. Field data comes from real visitors on real devices and connections, gathered over a rolling window. It is what Google actually uses.
So a perfect Lighthouse score on your laptop tells you very little if your visitors are on mid-range Android handsets on mobile data. Debug in the lab, judge in the field, and expect field data to lag your fixes by weeks because of the rolling window.
The fixes ranked by effect per hour spent
- Size and format your images. Serve modern formats, size them to their display dimensions, and set explicit width and height so space is reserved. This single item routinely fixes both LCP and CLS.
- Stop fonts blocking the render. Use
font-display: swap, preload the one face you need above the fold, and subset it. Late fonts cause both a slow paint and a visible shift. - Audit third-party scripts. Chat widgets, heat maps, tag managers and analytics compound. Each one is somebody else's code on your main thread. Remove what nobody reads.
- Defer non-critical JavaScript. Anything not needed for the first screen should not compete with it.
- Reserve space for anything injected late — banners, notices, embeds. A fixed-height container costs nothing and prevents the shift.
- Improve server response time. Caching and decent hosting. Less glamorous than the rest and it sets the floor for everything.
Where the effort stops being worth it
Diminishing returns arrive earlier than performance enthusiasts suggest. Core Web Vitals are a ranking signal, not the ranking signal, and they matter most as a tie-breaker between pages of comparable relevance.
Moving from poor to good is genuinely worth doing, for conversion reasons as much as ranking ones — people abandon slow pages. Moving from good to marginally better is usually not, and the hours are better spent on content that answers the query more completely.
Measuring it without buying anything
The free tooling is sufficient for almost every business. Search Console's Core Web Vitals report shows your real field data grouped by page type, which is where to start because it reflects actual visitors. PageSpeed Insights shows field and lab data side by side for a single URL. Chrome DevTools with network and CPU throttling reproduces a mid-range phone on cellular data, which is the condition that matters and the one office wifi hides.
Test the templates rather than every page — product pages, category pages, articles. Pages built from the same template share the same problems, so fixing the template fixes them all at once.
Frequently Asked Questions
What's a good Core Web Vitals score in 2026?
Google reports Core Web Vitals as pass/fail against three thresholds: LCP under 2.5s, CLS under 0.1, and INP under 200ms, measured at the 75th percentile of real visits. "Good" means passing all three — a single failing metric puts the whole page into "Needs Improvement" or "Poor" in Search Console.
Does Core Web Vitals actually affect my Google ranking?
Yes, but as one signal among many, folded into Google's "page experience" ranking factors alongside mobile-friendliness, HTTPS, and safe-browsing status. It matters more as a tiebreaker between otherwise similarly relevant pages than as a standalone ranking lever — but a genuinely slow, janky page will also hurt conversions directly, independent of any ranking effect.
How often should I re-check my Core Web Vitals?
Search Console's field-data report updates on a rolling 28-day window, so check monthly rather than after every single change — a single visit's data is noise, but a shift in the 28-day trend after a deploy is a real signal.
Our web development team conducts free performance audits. Book yours today.
What are Core Web Vitals measuring?
Three plain questions. Largest Contentful Paint asks how long until the main thing appears, and is usually hurt by slow server response, an unoptimised hero image or render-blocking CSS and fonts. Interaction to Next Paint asks how long after a tap before something happens, and is usually caused by heavy JavaScript occupying the main thread. Cumulative Layout Shift asks whether the page moves under the reader's finger, and comes from images without reserved space, late-loading fonts and injected banners.
Why does my Lighthouse score disagree with Search Console?
Because they measure different things. Lighthouse gives lab data from a simulated load on a synthetic device — reproducible, instant, and useful for debugging a specific change. Search Console reports field data gathered from real visitors on real devices and connections over a rolling window, and that is what Google actually uses. A perfect score on your laptop tells you little if your visitors are on mid-range Android handsets on mobile data. Debug in the lab, judge in the field, and expect field data to lag your fixes by weeks.
How much should I invest in page speed?
Moving from poor to good is genuinely worth it, for conversion reasons as much as ranking ones, since people abandon slow pages. Moving from good to marginally better usually is not, and those hours are better spent on content that answers the query more completely. Core Web Vitals are a ranking signal rather than the ranking signal, and they matter most as a tie-breaker between pages of comparable relevance. If your page passes all three in field data and still does not rank, performance is not your problem.
