Core Web Vitals are a set of specific, measurable web performance metrics defined by Google that quantify key aspects of the user experience on web pages, focusing on loading performance, interactivity responsiveness, and visual stability. Introduced by Google in 2020 and incorporated as confirmed ranking signals in the Page Experience update in 2021 Core Web Vitals represent Google’s attempt to make user experience measurable and actionable, providing website owners with specific, objective targets that correlate with positive user experiences rather than abstract performance advice.

The three Core Web Vitals metrics are Largest Contentful Paint, LCP, measuring loading performance, Interaction to Next Paint, INP, measuring interactivity responsiveness, and Cumulative Layout Shift, CLS, measuring visual stability. Each metric has defined good, needs improvement, and poor thresholds, allowing site operators to assess whether their pages are delivering acceptable user experiences and to prioritise improvements with clear targets.

Core Web Vitals matter for SEO because Google uses them as ranking signals, pages that achieve good scores on all three metrics receive a ranking boost over equivalent pages that perform poorly. The boost is described by Google as a tiebreaker, when other ranking signals are equal better page experience wins, rather than a dominant factor that overrides content quality. A page with exceptional content and poor Core Web Vitals still outranks a page with poor content and excellent Core Web Vitals. But in competitive search environments where many pages have similarly strong content signals Core Web Vitals performance can be the differentiating factor.

For redirect management Core Web Vitals are relevant because redirects directly affect LCP, the primary loading performance metric, by adding TTFB overhead before destination page content begins loading. Understanding Core Web Vitals and how they are measured clarifies both the SEO stakes of redirect performance and the specific metrics to monitor when evaluating redirect infrastructure performance.

Largest Contentful Paint, LCP

Largest Contentful Paint measures the time from when a page begins loading, the navigation start, to when the largest content element visible in the viewport is fully rendered. LCP captures the perceived loading speed of a page’s main content, the moment when a user can see that the most important content has arrived.

What LCP measures, the largest content element in the viewport at any point during page loading. LCP considers several element types as candidates:

Image elements, <img> tags, including images loaded as background images via CSS. Video elements, using the poster image as the LCP candidate. Block-level elements containing text, paragraphs, headings, divs with significant text content. SVG images containing text.

The LCP element is determined dynamically as the page loads, initially a heading might be the largest element, then as images load a hero image becomes the LCP element. The final LCP time is reported when the largest element that appeared during loading is fully rendered.

LCP thresholds: Good, under 2.5 seconds. Needs Improvement, 2.5 to 4.0 seconds. Poor, over 4.0 seconds.

What affects LCP:

Server response time, TTFB is the foundational LCP factor. The browser cannot begin loading any resources until it receives the first byte of HTML. A TTFB of 800ms means LCP cannot be better than 800ms, the remaining loading work happens after that. Redirects add TTFB overhead, each redirect hop adds its own TTFB before the destination page’s TTFB begins, directly degrading LCP.

Resource load time, the LCP element typically requires loading an image or rendering text with a downloaded font. Slow image loading, large file sizes, slow CDN delivery, delays LCP. Render-blocking resources, CSS that must be downloaded before the browser can render content, extend the time before LCP elements appear.

Client-side rendering, if the LCP element is generated by JavaScript after page load, common in single-page applications, LCP includes JavaScript execution time. Server-side rendering or static generation that includes LCP elements in the initial HTML response achieves better LCP than client-side rendering.

Redirect impact on LCP, each redirect in the critical path adds its TTFB to LCP. A single cross-origin redirect with 300ms TTFB followed by a destination page with 800ms total LCP results in approximately 1100ms LCP, the redirect adds 300ms to the baseline. A redirect chain with two hops each adding 300ms TTFB pushes the same destination page to approximately 1400ms LCP, approaching the needs improvement threshold.

Edge-executed redirects, served from infrastructure near the user, add 20-50ms to LCP rather than 200-400ms. The difference between origin-executed and edge-executed redirects is the difference between a negligible LCP impact and a meaningful one.

Interaction to Next Paint, INP

Interaction to Next Paint measures the responsiveness of a page to user interactions throughout the entire page visit, capturing the latency from user input to the next visual update the browser paints in response to that input.

What INP measures, the latency of discrete user interactions:

Clicks, mouse clicks and trackpad clicks on interactive elements. Taps, touch events on mobile devices. Keyboard interactions, keypresses that trigger visible responses.

INP is measured as the worst interaction latency observed during a page visit, with some outlier exclusion for pages with many interactions. The INP score represents how responsive the page feels throughout the entire visit, not just on the first interaction.

INP thresholds: Good, under 200 milliseconds. Needs Improvement, 200 to 500 milliseconds. Poor, over 500 milliseconds.

What affects INP:

JavaScript execution, the primary INP factor. Heavy JavaScript execution on the main thread blocks interaction processing. When a user clicks a button while JavaScript is executing the click handler cannot run until the JavaScript completes. Long tasks, JavaScript execution lasting more than 50 milliseconds, are the primary source of high INP.

Third-party scripts, analytics platforms, advertising tags, social media widgets, and other third-party JavaScript execute on the same main thread as the page’s own code. Heavy third-party script execution degrades INP even when the site’s own JavaScript is lean.

Rendering complexity, complex DOM structures, expensive CSS recalculations, and layout thrashing increase the time required to render the visual response to an interaction.

Redirect impact on INP, redirects have minimal direct impact on INP. INP is measured after the destination page has loaded and is interactive, the redirect happens before the page loads and is not part of INP measurement. However redirect chains that delay page loading may delay when JavaScript begins executing, pushing back the point at which the page becomes responsive to interactions.

Cumulative Layout Shift, CLS

Cumulative Layout Shift measures the visual stability of a page during and after loading, quantifying how much visible content moves unexpectedly as the page loads. CLS captures the jarring experience of reading an article when the text suddenly jumps down as an image loads above it, or clicking a button just as an ad loads above it and the button shifts down.

What CLS measures, unexpected layout shifts of visible elements. A layout shift occurs when a visible element moves from its rendered position between one frame and the next without user interaction. The CLS score is the sum of individual layout shift scores, calculated from the fraction of the viewport affected multiplied by the distance elements moved, throughout the page’s lifetime.

Not all layout shifts are penalised, shifts caused by user interaction, clicking a button that expands content below it, are excluded. Only unexpected shifts, caused by resources loading and changing the layout, contribute to CLS.

CLS thresholds: Good, under 0.1. Needs Improvement, 0.1 to 0.25. Poor, over 0.25.

What causes CLS:

Images without declared dimensions, images that load and push surrounding content down because no space was reserved for them. Specifying width and height attributes on all images allows the browser to reserve the correct space before the image loads, preventing layout shifts.

Late-loading advertisements, ad slots whose size is not declared in advance shift content when ads load. Reserving space for ad slots, even when no ad is served, prevents CLS from ad loading.

Web fonts causing FOUT or FOIT, Flash of Unstyled Text or Flash of Invisible Text, when text renders in a fallback font and then reflows when the web font loads. font-display: optional or careful font metric matching prevents font-loading layout shifts.

Dynamically injected content, content added above existing content after the initial load shifts existing content down.

Redirect impact on CLS, redirects have no direct impact on CLS. CLS is measured on the destination page after it loads, the redirect is a pre-load event that does not affect how the destination page’s elements shift during rendering.

Measuring Core Web Vitals

Core Web Vitals are measured through two distinct methodologies, field data from real user experiences and lab data from controlled simulations.

Field data, Chrome User Experience Report, CrUX, anonymised performance data collected from real Chrome browser users who have opted into usage statistics. CrUX data represents actual user experiences on real devices under real network conditions, capturing the full distribution of performance across all visits to a page.

Field data is the authoritative source for Core Web Vitals assessment, Google’s Search Console reports and PageSpeed Insights use CrUX data for the official page experience signals that affect rankings. A page’s Core Web Vitals assessment in Google Search Console is based on the 75th percentile of CrUX field data, meaning 75% of real users must experience the metric within the good threshold for the page to receive a good assessment.

Field data requires sufficient traffic to generate reliable measurements, pages with low traffic may not have enough CrUX data for assessment. Google Search Console may report insufficient data for low-traffic pages.

Lab data, Lighthouse, controlled performance measurements executed in a simulated environment. Lighthouse runs in a headless Chrome browser with configured device emulation, simulating a mid-tier Android device on a 4G connection by default, and measures performance under these controlled conditions.

Lab data is useful for development and debugging, consistent simulated conditions enable reproducible measurements and before/after comparisons. Lab data is available for every page regardless of traffic. However lab data does not reflect real user experiences, actual performance varies significantly by device capability, network quality, and geographic location.

Google Search Console Core Web Vitals report, aggregates CrUX field data for all URLs on a site, showing the proportion of pages with good, needs improvement, and poor assessments for each Core Web Vitals metric. The report groups pages with similar URL patterns, enabling identification of which page types or sections have performance problems.

PageSpeed Insights, combines CrUX field data, when available, with Lighthouse lab measurements for a single URL. The field data section shows the 75th percentile values from real users. The lab section shows Lighthouse-measured values. Both perspectives are valuable, field data shows real performance, lab data provides actionable diagnostics.

Improving Core Web Vitals

Different Core Web Vitals metrics require different improvement strategies, the optimisations that improve LCP are mostly distinct from those that improve INP.

Improving LCP:

Reduce TTFB, deploy a CDN, implement server-side caching, optimise database queries. Every millisecond saved in TTFB directly improves LCP.

Minimise redirect chains, each redirect adds TTFB overhead. Collapse multi-hop chains to direct single-hop redirects. Use edge-executed redirects for minimal TTFB overhead.

Optimise LCP resource, if the LCP element is an image compress it aggressively using WebP or AVIF format, serve it from a CDN edge location, and preload it with <link rel="preload"> to prioritise its loading.

Eliminate render-blocking resources, CSS and synchronous JavaScript that must load before rendering begins delays LCP. Inline critical CSS and defer non-critical CSS. Defer or async non-critical JavaScript.

Improving INP:

Reduce long JavaScript tasks, break up tasks longer than 50ms using setTimeout, scheduler.yield, or similar techniques to yield to the browser between chunks of work.

Remove unnecessary third-party scripts, audit all third-party scripts and remove those with low value relative to their performance cost. Load necessary third-party scripts with async or defer attributes.

Use web workers, move non-rendering JavaScript work to background web worker threads, keeping the main thread free for interaction handling.

Improving CLS:

Declare image dimensions, add width and height attributes to all <img> elements, or use CSS aspect-ratio, to reserve space before images load.

Reserve space for dynamic content, use minimum heights for elements that load content dynamically, advertisements, embeds, dynamically loaded components.

Use font-display: optional, prevent font-swap layout shifts by only using web fonts when they are available within a brief loading window rather than swapping in after fallback fonts have been rendered.

Core Web Vitals and redirect infrastructure

Redirect management platforms have specific Core Web Vitals implications, the performance of redirect infrastructure directly affects the LCP of pages reached through redirects.

Edge redirect serving for LCP preservation, redirect management platforms that serve redirect responses from edge nodes near users minimise the TTFB overhead added by each redirect, preserving LCP performance of destination pages. The difference between a 30ms edge-executed redirect and a 300ms origin-executed redirect is a 270ms LCP difference, the difference between a good and poor LCP assessment for pages near the 2.5 second threshold.

Redirect chain auditing for LCP, regularly auditing redirect configurations to identify and collapse multi-hop chains directly improves LCP for pages reached through those chains. Each eliminated redirect hop removes its TTFB from the LCP calculation. For pages with good LCP that are approaching the threshold eliminating a redirect chain may be the difference between maintaining good status and degrading to needs improvement.