Core Web Vitals 2026: LCP, CLS & INP Explained

Largest Contentful Paint (LCP): Load Performance

Largest Contentful Paint measures the time from when the user navigates to a page until the largest content element visible in the initial viewport finishes rendering. This is typically a hero image, a large block of text, or a video poster image. LCP is the Core Web Vital most directly correlated with perceived page speed — it's what users feel when they assess whether a page is "fast" or "slow."

Thresholds: Good LCP is under 2.5 seconds. Needs Improvement is 2.5–4 seconds. Poor LCP is above 4 seconds. Google's ranking signal triggers when 75% or more of page visits (based on real Chrome field data) fall in the "Good" threshold.

The most common causes of poor LCP are:

• Slow server response time (TTFB): Everything that happens after the browser sends an HTTP request to your server — including database queries, CMS processing, and server-side rendering — delays LCP. If your TTFB exceeds 600ms, focus here first. Solutions include server-side caching, database query optimisation, CDN implementation, and in some cases moving to a faster hosting infrastructure.
• Render-blocking resources: JavaScript and CSS loaded in the document head that haven't been marked as deferred or async will prevent the browser from rendering any content until they've been downloaded, parsed, and executed. Audit render-blocking resources in PageSpeed Insights and defer everything non-critical.
• Unoptimised hero images: If your LCP element is a hero image (the most common case), optimise it aggressively: compress it, serve it in WebP or AVIF format, and critically, preload it using <link rel="preload" as="image">. The preload hint tells the browser to fetch the LCP image immediately rather than waiting to discover it in the HTML parsing phase.
• No CDN: A Content Delivery Network caches your static assets (images, CSS, JS) at edge locations geographically close to your users. This dramatically reduces latency for users far from your origin server. For any site with a geographically distributed audience, a CDN is not optional — it's table stakes for good LCP.

Cumulative Layout Shift (CLS): Visual Stability

Cumulative Layout Shift measures the visual stability of a page — specifically, how much visible content unexpectedly shifts during the page loading process. CLS is measured as a score (not a time), calculated from the impact fraction (how much of the viewport was affected by a shift) multiplied by the distance fraction (how far shifted elements moved). CLS is the Core Web Vital most directly tied to user frustration — few experiences are more aggravating than trying to click a button that moves as you reach for it.

Thresholds: Good CLS is below 0.1. Needs Improvement is 0.1–0.25. Poor CLS is above 0.25.

Common causes and their fixes:

• Images without explicit width and height attributes: When a browser downloads an image, it needs to know how much space to reserve for it. Without explicit dimensions in the HTML, the browser renders the surrounding content first, then causes a layout shift when the image loads and pushes everything down. The fix is simple: always include width and height attributes on every <img> tag — even if you override them with CSS. This preserves the aspect ratio and allows the browser to reserve space before the image loads.
• Dynamically injected content: Content inserted above existing content (banner ads, cookie notices, notification bars, personalised content) that pushes down page elements causes CLS. Reserve space for dynamic content using CSS (e.g., min-height on ad containers), and load it from below or as an overlay rather than in the document flow.
• Web fonts causing FOIT or FOUT: Flash of Invisible Text (FOIT) and Flash of Unstyled Text (FOUT) occur when web fonts load asynchronously, causing text to briefly appear in a fallback font before switching to the intended font. The text reflow causes CLS. Fix with font-display: optional (never swaps — best for CLS) or font-display: swap with a carefully matched fallback font to minimise the reflow distance.
• Ads without reserved space: Display ads are one of the most common CLS culprits, particularly on publisher sites. Always specify minimum dimensions for ad slots in CSS so that if an ad doesn't fill the full slot height, the page doesn't shift when the ad loads.

Interaction to Next Paint (INP): Responsiveness

Interaction to Next Paint replaced First Input Delay (FID) as a Core Web Vital in March 2024. FID only measured the delay before a browser began processing the first user interaction — it didn't measure how long that processing actually took. INP measures the full responsiveness of a page throughout its entire lifetime, capturing the worst-case interaction latency from all interactions a user makes during their visit.

What INP measures: When a user interacts with a page (clicks a button, taps a menu, types in an input), the browser needs to process event handlers and repaint the screen. INP measures the time from the start of the interaction to when the next frame is presented — the moment the user sees a response to their action. High INP makes pages feel sluggish and unresponsive.

Thresholds: Good INP is under 200 milliseconds. Needs Improvement is 200–500ms. Poor INP is above 500ms.

INP problems are almost always caused by JavaScript issues:

• Long tasks on the main thread: JavaScript that runs for more than 50ms without yielding to the browser is considered a "long task" and will block user interactions. The browser's main thread handles both JavaScript execution and rendering — when JavaScript is running, the browser can't process user interactions. Identify long tasks using Chrome DevTools' Performance panel and break them up using techniques like scheduler.yield(), setTimeout() chunking, or requestIdleCallback().
• Heavy event handlers: Click handlers and input handlers that do expensive work synchronously — fetching data, sorting arrays, rendering large DOM updates — block the main thread. Move expensive work to web workers, defer non-critical processing with setTimeout, or use virtual DOM techniques to minimise render cycles.
• Third-party scripts: Analytics tags, chatbots, ad scripts, and A/B testing tools can all add significant main thread load. Audit third-party script impact using the "Block third-party cookies" network throttling option in Chrome DevTools and load non-critical third-party scripts with defer or async attributes, or load them only after the page is interactive.
• Large DOM size: Pages with very large DOMs (tens of thousands of nodes) take longer to process layout and paint changes triggered by interactions. Use virtualization techniques for long lists and paginate content where possible.

How to Measure Core Web Vitals

The most important distinction in CWV measurement is field data vs lab data. Lab data is collected by automated tools in a controlled environment (synthetic testing). Field data is collected from real Chrome users visiting your site (real user measurement, or RUM). Google's ranking signal uses field data — specifically from the Chrome User Experience Report (CrUX) — not lab data.

• PageSpeed Insights: The most accessible tool for checking both field data (from CrUX) and lab data (from Lighthouse). The field data section at the top of the report shows your actual Core Web Vitals as Google measures them. The lab data (Lighthouse audit) provides diagnostic information about what's causing problems. Always prioritise the field data for ranking decisions.
• Google Search Console — Core Web Vitals report: Shows your CWV status across all pages on your site, grouped into Good, Needs Improvement, and Poor. This is the best tool for identifying which pages have the largest-scale CWV problems. Issues listed here are what Google is actually seeing.
• Chrome DevTools — Performance panel: The most detailed diagnostic tool available. The Performance panel shows a full waterfall of everything happening during page load, including LCP timing, layout shifts annotated on the timeline, long tasks highlighted in red, and INP events. Use this for root-cause analysis once you've identified which pages have issues.
• Real User Monitoring (RUM): For production-level CWV monitoring, implement the web-vitals JavaScript library on your site to collect CWV metrics from real users in real time. Send these metrics to your analytics platform or a dedicated RUM tool to monitor CWV trends over time and detect regressions immediately after deployments.

Prioritising Your CWV Fixes

If your site has CWV problems across multiple metrics and multiple pages, knowing where to start is critical. Random fixes waste engineering time and delay results. Here's how to prioritise:

Start with field data, not lab data. Your Google Search Console CWV report shows which pages have confirmed field data issues. These are the pages where improvements will actually impact Google's ranking signal. Lab data issues on pages that pass in field data are lower priority.

Prioritise by traffic volume. CWV improvements on your highest-traffic pages deliver the largest ranking and user experience impact per engineering hour spent. Fixing a CWV issue on a page with 10,000 monthly visits is worth more than fixing the same issue on a page with 100 monthly visits.

Fix LCP first. Among the three CWV metrics, LCP has the most direct correlation with perceived page speed and the clearest ranking impact. It's also typically the most actionable — LCP improvements often come from optimising a single image or reducing server response time, which are well-understood engineering problems.

Then CLS. CLS improvements are often quick wins: adding image dimensions and reserving ad slot space are simple code changes that can dramatically improve CLS. The user experience impact is immediate and measurable.

INP last — it's often the hardest. INP problems require profiling JavaScript execution, identifying long tasks, and restructuring code to yield to the browser more frequently. This work is more complex than LCP and CLS fixes and typically requires developer time rather than just configuration changes. Start with identifying your worst INP offenders in Chrome DevTools and work through them systematically.

Test after every change. CWV improvements interact — optimising images for LCP can inadvertently improve CLS if the image previously caused layout shifts. Use PageSpeed Insights to measure the impact of each change before moving to the next. This prevents regression and helps you isolate which changes are actually moving the needle.