Core Web Vitals: the fixes that actually move the needle

Core Web Vitals are Google's user-experience metrics for loading, responsiveness and visual stability. Each has a "good" threshold, and a page passes when at least 75% of real visits meet it, assessed separately for mobile and desktop.

• Largest Contentful Paint (LCP): how long until the largest image or text block in the viewport renders. Good is 2.5 seconds or less; poor is over 4 seconds.
• Interaction to Next Paint (INP): how quickly the page visibly responds to clicks, taps and key presses, across the whole visit. Good is 200 milliseconds or less; poor is over 500 milliseconds. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. Unlike FID, which only measured the delay before the first interaction was handled, INP covers the full time to the next frame for interactions throughout the visit.
• Cumulative Layout Shift (CLS): how much visible content moves unexpectedly. Good is 0.1 or less; poor is over 0.25.

Google has said Core Web Vitals are used by its ranking systems, but that relevant, helpful content matters more. The stronger commercial case is usually conversion: fast, stable pages are simply easier to buy from.

The most common mistake is chasing a Lighthouse score. Lighthouse is a lab test: one simulated load on one simulated device. Core Web Vitals are assessed on field data from real Chrome users, collected in the Chrome UX Report over a rolling 28-day window.

• PageSpeed Insights shows field data at the top (when the page or site has enough traffic) and a Lighthouse lab run below. Prioritise the top section.
• Search Console's Core Web Vitals report groups similar URLs, so you can see which templates are failing rather than chasing individual pages.
• Lighthouse cannot measure INP, because there is no real user interacting. Total Blocking Time is a useful lab proxy for main-thread congestion, but it is not the same metric.

Because field data is a 28-day rolling window, improvements take a few weeks to show fully. Fix by template, ship, then watch the trend rather than refreshing daily. If you need faster feedback, add real-user monitoring with a library such as Google's web-vitals.

LCP is best diagnosed by splitting it into four parts: time to first byte, the delay before the LCP resource starts loading, the time to download it, and the delay before it renders. Most slow LCPs are dominated by one of them.

1. Make the LCP image discoverable early. If the hero image is set in CSS or injected by JavaScript, the browser finds it late. Use a real img element in the initial HTML.
2. Never lazy-load the LCP image. Lazy loading above-the-fold images is one of the most frequent causes of poor LCP. Add fetchpriority="high" to the hero image instead.
3. Serve the right size and format. Use responsive srcset and modern formats such as AVIF or WebP so mobile users are not downloading desktop-sized images.
4. Reduce time to first byte. Cache HTML at the edge where possible, serve from a CDN close to your users, and cut slow server-side work such as uncached database queries.
5. Remove render-blocking resources. Inline critical CSS, defer non-essential scripts, and avoid hiding the page behind client-side rendering or an anti-flicker snippet from an A/B testing tool.

INP measures three things for each interaction: input delay (waiting for the main thread to be free), processing time (your event handlers running) and presentation delay (the browser working out layout and painting the next frame). The underlying cause is nearly always too much JavaScript on the main thread.

• Audit third-party scripts. Chat widgets, tag managers, heatmaps, review widgets and ad pixels are frequent offenders. Remove what nobody uses, and delay the rest until after the page is interactive.
• Break up long tasks. Any task over 50 milliseconds blocks input. Split work into smaller chunks and yield to the main thread between them, for example with scheduler.yield() where supported or a setTimeout fallback.
• Do the visible update first. In an event handler, update the UI immediately and defer analytics calls and non-urgent work.
• Keep the DOM lean. Very large pages make every style recalculation and layout slower. Paginate or virtualise long lists, and consider content-visibility for off-screen sections.
• Watch hydration cost. On JavaScript-heavy frameworks, large bundles hydrating on load can make early taps feel unresponsive. Ship less client-side code where the page does not need it.

Layout shift is often the easiest of the three to fix, because the causes are predictable.

• Give every image, video and iframe dimensions. Set width and height attributes or a CSS aspect-ratio so the browser reserves space before the file arrives.
• Reserve space for late content. Cookie banners, promotional bars, ads and embeds should load into a container of known size, or overlay the page rather than pushing it down.
• Tame web fonts. Preload key fonts and use fallback font metrics (for example size-adjust) so text does not reflow when the web font swaps in.
• Animate with transforms. Animating top, height or margin shifts layout; transform and opacity do not.
• Keep pages eligible for the back/forward cache. Instant back navigation avoids a fresh load, and its associated shifts, entirely.

With limited time, work in this order:

1. Identify failing templates in Search Console, starting with the ones that carry the most revenue: product, category and landing pages.
2. Fix CLS first where it fails. It is usually quick and low-risk.
3. Fix LCP on those templates, starting with the hero image and server response time.
4. Tackle INP by cutting third-party scripts before touching your own code.
5. Put real-user monitoring and a performance budget in place so the next redesign or marketing tag does not undo the work.

As an example of what focused work can achieve, one of our case studies covers a D2C homeware replatform where LCP improved from around 4.2 seconds to under 1.5 seconds.

Performance sits between development and SEO, which is why it often falls through the gap between suppliers. Our SEO and growth work includes technical fixes like these, and our managed hosting runs across 18 edge regions to keep server response times low. If you would like to know which fixes would matter most on your site, start with a free audit through our contact page.