Core Web Vitals are Google's set of user experience metrics used as ranking signals. They measure how fast your page loads from a user's perspective, how stable it is while loading, and how quickly it responds to interaction.

Understanding and fixing Core Web Vitals is no longer optional — they directly affect your position in Google's search results.

The Three Core Web Vitals

LCP — Largest Contentful Paint

LCP measures how long it takes for the largest visible element on the page to load. This is typically a hero image, a large heading, or a video thumbnail. Google wants LCP under 2.5 seconds.

What causes poor LCP: - Large, unoptimised images - Render-blocking JavaScript and CSS - Slow server response times (TTFB over 600ms) - No CDN, serving assets from a single origin server How to fix LCP: 1. Convert images to WebP or AVIF format — typically 25-40% smaller than JPEG with equal quality 2. Add explicit width and height attributes to images so the browser can reserve space 3. Use lazy loading for below-the-fold images (but never for the LCP element itself) 4. Preload your LCP image using 5. Defer non-critical JavaScript 6. Enable server-side caching and use a CDN

CLS — Cumulative Layout Shift

CLS measures visual stability — how much the page jumps around while loading. When content shifts unexpectedly, users click the wrong thing or lose their place. Google wants CLS below 0.1.

What causes poor CLS: - Images without explicit dimensions (browser doesn't know how much space to reserve) - Ads, embeds or iframes that load late and push content down - Web fonts causing text to jump when they load (FOUT/FOIT) - Dynamically injected content above existing content - Cookie banners appearing at the top of the page How to fix CLS: 1. Always set explicit width and height on every image and video element 2. Reserve space for ads using CSS min-height on ad containers 3. Use font-display: optional or font-display: swap with size-adjust to prevent font shifts 4. Position cookie banners and popups to overlay content rather than push it down 5. Avoid inserting content above existing content after page load

INP — Interaction to Next Paint

INP replaced FID (First Input Delay) as a Core Web Vital in March 2024. It measures the delay between a user interaction — a click, tap or keypress — and when the browser next paints a visual response. Google wants INP below 200 milliseconds.

What causes poor INP: - Heavy JavaScript executing on the main thread - Long tasks blocking the browser from responding - Third-party scripts (analytics, chat widgets, ad code) consuming main thread time - Unoptimised event handlers doing too much work on click How to fix INP: 1. Audit your JavaScript for long tasks using Chrome DevTools Performance panel 2. Break up long tasks using setTimeout or scheduler.yield() 3. Defer or remove unnecessary third-party scripts 4. Use web workers for heavy computation off the main thread 5. Optimise event handlers — defer non-critical work to after the paint

Measuring Core Web Vitals

There are two types of data: lab data (simulated, like Lighthouse) and field data (real users, like Chrome User Experience Report). Google uses field data for ranking, so prioritise fixing issues shown in Google Search Console's Core Web Vitals report, not just Lighthouse scores.

Tools to use: - Google Search Console — Core Web Vitals report shows real user data by URL group - PageSpeed Insights — Shows both lab and field data for individual URLs - Chrome DevTools — For diagnosing specific issues - AIPageSEO PageSpeed tool — Runs a full audit with actionable fix recommendations

Prioritising Fixes

Start with your highest-traffic pages and the metric showing the most failures. A 10-point improvement in PageSpeed on your homepage will have more impact than perfecting a low-traffic page.

Core Web Vitals improvements compound — fixing your LCP image often also improves your overall performance score, reduces bounce rate, and increases conversions.