Core Web Vitals Explained: LCP, INP and CLS - And How to Fix Them

In May 2021, Google made it official: how fast your page feels is now a ranking signal. Not just a nice-to-have - a factor Google's algorithm directly weighs when deciding where your page appears in search results. The vehicle for this change was Core Web Vitals, a set of three metrics that together measure the real-world experience of loading, interacting with, and visual stability of a webpage. Years on, most sites still fail at least one of them. This guide explains exactly what each metric measures, what causes them to fail, and - most importantly - how to fix them.

Why Page Speed Became a Google Ranking Factor

Google has cared about page speed since 2010, but for years speed signals were blunt - mostly server response times and basic load metrics that did not reflect what users actually experienced. Everything changed with the 2021 Page Experience update, which introduced Core Web Vitals as ranking signals. The crucial shift was from technical metrics to user-centric metrics. Instead of measuring when a server responds, Core Web Vitals measure what the user actually sees and feels: Did the main content appear quickly? Did the page jump around unexpectedly? Did it respond when I clicked something? A 1-second improvement in page load time can improve conversions by 7%, and pages passing Core Web Vitals are 24% less likely to be abandoned.

LCP - Largest Contentful Paint

LCP measures how long it takes for the largest visible content element on the page to fully render. That element is usually a hero image, a large above-the-fold photograph, or a block of text. LCP is the closest proxy Core Web Vitals has to 'How long until the page feels loaded?' The thresholds Google uses are: Good - under 2.5 seconds. Needs Improvement - 2.5 to 4 seconds. Poor - over 4 seconds. These are measured at the 75th percentile of your page visits, meaning 75% of your real users need to hit the threshold.

• Unoptimised hero images - Large PNGs or JPEGs that are not compressed, resized for viewport, or served in modern formats like WebP or AVIF
• Render-blocking resources - CSS and JavaScript files in the head that the browser must download and parse before it can paint anything
• Slow server response times (TTFB) - If the server takes more than ~600ms to send the first byte of HTML, LCP will suffer no matter what else you do
• No resource hints for the LCP element - Failing to use a preload link for the LCP image means the browser discovers it late
• Client-side rendering - SPAs that build content in JavaScript give the browser nothing to paint until scripts execute

INP - Interaction to Next Paint

INP replaced FID (First Input Delay) as a Core Web Vital in March 2024 - a significant change that many sites have not yet adapted to. Where FID only measured the delay before the browser began responding to the very first user interaction, INP measures the full responsiveness of every interaction throughout the page's life: clicks, taps, and key presses. The thresholds are: Good - under 200 milliseconds. Needs Improvement - 200 to 500 milliseconds. Poor - over 500 milliseconds. INP failures are most commonly caused by heavy JavaScript that blocks the main thread.

• Long JavaScript tasks on the main thread - Tasks over 50ms block input processing; tasks over 200ms will almost always produce a poor INP
• Third-party scripts - Analytics, chat widgets, ad tags, and social embeds often run expensive JavaScript that the site owner has no control over
• Inefficient event handlers - Click or input handlers that do too much synchronous work before yielding back to the browser
• Large DOM sizes - Pages with tens of thousands of DOM nodes take longer to update after an interaction triggers a layout change
• Unnecessary re-renders in React/Vue/Angular - Framework-level performance issues that cause the entire component tree to re-render on simple interactions

CLS - Cumulative Layout Shift

CLS measures visual stability: how much the page's layout unexpectedly shifts during and after loading. You have experienced poor CLS when you go to tap a button and suddenly an image loads above it and shifts everything down - and you accidentally tap something else entirely. The thresholds are: Good - under 0.1. Needs Improvement - 0.1 to 0.25. Poor - over 0.25. CLS is calculated from the fraction of the viewport affected by shifting elements multiplied by the distance they moved.

• Images without explicit width and height attributes - The browser does not know how much space to reserve, so it pushes content down when the image loads
• Ads, embeds, and iframes without reserved space - Dynamic content that appears above existing content is the single biggest CLS culprit
• Web fonts causing layout flash - Text renders in a fallback font, then jumps to the web font when it loads, shifting surrounding elements
• Dynamically injected content - Cookie banners, notification bars, or personalisation elements injected above existing content after the page has rendered
• CSS animations that trigger layout - Animating properties like top, left, width, or height causes layout recalculations and shifts

How Core Web Vitals Actually Affect Your Rankings

Here is what Google has been clear about: Core Web Vitals are a tiebreaker, not a trump card. A page with weak content and poor backlinks will not outrank a page with great content and strong authority just because it has perfect CWV scores. Relevance and authority still dominate. What CWV does is act as a differentiator between pages that are otherwise closely matched - if two pages compete for the same query at similar authority levels, the one with better page experience signals has an edge.

The Mobile vs Desktop Gap - and Why It Matters

Many site owners are surprised to discover that Google uses mobile CWV scores for ranking purposes, not desktop. This is a consequence of mobile-first indexing, which Google completed rolling out. Mobile scores are almost always worse than desktop scores. A hero image that loads in 1.2 seconds on desktop fibre might take 4.5 seconds on a mid-range Android device on a 4G connection. Always look at the Mobile tab in PageSpeed Insights and check the field data (real user measurements) rather than relying solely on lab data.

Quick Wins: The Fixes With the Highest Return

1. Convert images to WebP or AVIF - Modern formats are 25-50% smaller than JPEG/PNG at equivalent quality. Apply compression site-wide for immediate LCP improvements.
2. Add width and height attributes to all img tags - This single change eliminates most CLS caused by images. The browser can reserve the correct space before the image loads.
3. Preload your LCP image - Add a preload link tag in the head for your hero image. This tells the browser to fetch it early, before it would normally discover it.
4. Defer non-critical JavaScript - Any script that is not needed for the initial render should use defer or async. Scripts that do not need to run until the user interacts should be loaded lazily.
5. Use font-display: swap - This tells the browser to show a fallback font immediately and swap to the web font when it arrives, eliminating invisible text.
6. Load third-party scripts after user interaction - Analytics, chat widgets, and ad scripts can often be loaded only after the first user scroll or click rather than blocking initial paint.
7. Enable server-side caching and use a CDN - Slow TTFB is the root cause of poor LCP more often than image size. A CDN and server-level caching can cut TTFB from 800ms to under 100ms.