Core Web Vitals Explained: LCP, INP and CLS for Web Designers

The Three Metrics and Their Thresholds

Google’s Core Web Vitals are three metrics, each covering one part of the experience of using a page: loading, responsiveness and visual stability. Each has published thresholds for “good” and “poor”, with “needs improvement” in between.

A page meets the standard when it reaches “good” on all three (an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less) at the 75th percentile of page loads, measured separately on mobile and desktop. In practice, three out of four real visits have to meet the target. A fast result on the designer’s own laptop says little about the slowest quarter of visitors on mid-range phones and mobile networks.

INP became a Core Web Vital on March 12, 2024, replacing First Input Delay (FID). FID measured only the delay before the first interaction was handled; INP considers interactions across the whole visit, so a page that passed on FID does not necessarily pass on INP. Older reports and screenshots, including the one in the photograph above, still show FID.

Passing is not the norm. The HTTP Archive’s 2025 Web Almanac found good Core Web Vitals on 48% of mobile websites and 56% of desktop websites. On mobile, LCP was the hardest of the three: 62% of sites had a good LCP, against 77% for INP and 81% for CLS.

Field Data and Lab Data

Core Web Vitals are field metrics. The figures Google uses come from the Chrome UX Report (CrUX), which aggregates measurements from real Chrome users as a 28-day rolling average. That window is why a fix shows up in Search Console gradually rather than the day after it ships.

Lab tools such as Lighthouse load a page once in a controlled, simulated environment. They are for diagnosing problems and testing changes before release. A standard lab run measures LCP and CLS but never interacts with the page, so it cannot report INP; Total Blocking Time (TBT) is the lab metric that stands in for it. To measure INP during development, interact with the page while the Chrome DevTools Performance panel records; it captures INP for your own interactions.

CrUX does not cover every site. It includes only publicly discoverable pages with enough traffic from Chrome users who share usage statistics, and it excludes Chrome on iOS. New sites and low-traffic pages often have no field data at all, and Search Console shows nothing for them. For those pages, collecting your own measurements with the web-vitals library is the only way to see real-user results. Since Safari 26.2 added support for LCP and INP in December 2025, those measurements can include Safari visitors too.

How Core Web Vitals Affect Rankings

Google confirms that “Core Web Vitals are used by our ranking systems”, as one part of page experience. The same documentation is careful about their weight: good scores do not guarantee top rankings, and “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” Where many pages are similarly helpful for a query, Google says a great page experience “can contribute to success in Search”.

The accurate way to explain this to a client is that Core Web Vitals help most when competing pages are otherwise close, and that their larger effect is on visitors. A page that loads slowly or moves under the reader’s thumb loses people whether or not it loses rankings, which makes user experience the stronger business case for the work.

Largest Contentful Paint (LCP)

LCP marks when the largest image or text block in the viewport finishes rendering. On most marketing sites that is the hero image, a video poster frame, or the main headline. Google’s LCP optimization guide divides the time into four parts, and each points to a different fix.

The same guide gives a useful rule: the LCP resource should start loading at the same time as the first resource the page loads. Anything that makes the browser discover the hero late breaks that rule. The common design-side causes are:

• Hero images set as CSS backgrounds. The browser cannot find them until the stylesheet has loaded. Use an <img> element, or preload the image with a high fetch priority.
• Lazy-loading on every image. Google’s guidance is to “never lazy-load your LCP image”. Lazy-load only the images below the fold.
• Carousels and video heroes that load several large files before the first slide or frame appears.
• Web fonts on the headline that hold back text rendering when the LCP element is text.

Interaction to Next Paint (INP)

INP measures the time from a click, tap or key press to the next frame the browser paints, and reports close to the slowest interaction of the visit. Hovering, scrolling and zooming are not counted. The time splits into three phases: input delay, processing duration and presentation delay. That is the wait before the event handlers start, the time they take to run, and the time until the browser paints the result.

A slow INP almost always means the browser’s main thread was busy running JavaScript when the visitor acted. Google defines any task that runs longer than 50 milliseconds as a long task, because it stops the browser from responding. On agency-built sites the cause is usually accumulation rather than one bad script: a page builder’s runtime, a tag manager with several marketing tags, a chat widget, a consent banner, an A/B testing tool and an animation library, all competing for the same thread.

• Audit third-party scripts. Remove the ones nobody uses. Load the rest only on the pages that need them, and after the page becomes interactive where the tool allows it.
• Break up long tasks. Yield to the main thread between chunks of work so input can be handled in between. scheduler.yield() is available in Chromium browsers and Firefox, with setTimeout as the fallback elsewhere.
• Respond visually first. In event handlers, update what the visitor sees (the open menu, the pressed button) and defer the rest of the work.
• Keep the DOM small. Lighthouse warns above 800 DOM nodes and flags the DOM as excessive above 1,400, and a large DOM makes every update slower.

Mega menus, filter panels, accordions and add-to-cart buttons are the usual INP problems, because they run the most code on interaction. Test them on a mid-range Android phone, not only on a desktop.

Cumulative Layout Shift (CLS)

CLS measures how much visible content moves without the visitor causing it. Each unexpected shift is scored by how much of the viewport moves and how far. Shifts are grouped into session windows (bursts with less than a second between shifts, up to five seconds long), and the page’s CLS is its worst window. Shifts within 500 milliseconds of a tap, click or key press are excluded, so content that expands because the visitor asked for it does not count.

Fixes a designer controls

• Give media dimensions. Set width and height attributes, or a CSS aspect-ratio, on images, video and iframes so the browser reserves space before the file arrives. Keep the same aspect ratio across every size in a srcset.
• Reserve space for late content. Embeds, ads, review widgets, cookie banners and announcement bars all arrive after the first render. One inserted above the header pushes the entire page down.
• Match font fallbacks. Use size-adjust and the related font descriptors so the fallback font takes up the same space as the web font, or font-display: optional where the brand allows it.
• Animate with transform. Move elements with transform and opacity rather than top, left or height, which change the layout.

Design Decisions That Affect the Scores

Most Core Web Vitals problems are designed in before they are coded, so the cheapest place to prevent them is the design review. The table maps common choices to the metric they put at risk and an alternative that keeps the design intent.

Building Performance Into Agency Projects

Performance is cheaper to design in than to retrofit, and easier to protect when it is part of the project scope.

1. Set targets in the proposal. State the Core Web Vitals thresholds the build will be tested against, and a budget for what usually breaks them: hero image weight, font files and third-party scripts.
2. Test during the build, on mobile. Use Lighthouse and the Performance panel in Chrome DevTools with a throttled mobile profile, not only the designer’s own machine.
3. Review third-party requests. Before adding a widget or tag the client asks for, check what it costs on the pages it runs on.
4. Check field data after launch. Once 28 days of real-user data have accumulated, review PageSpeed Insights and the Search Console report, and check again after major content or plugin changes.

Core Web Vitals are one section of a full technical SEO audit, and a redesign is the best opportunity to fix them; the website redesign SEO checklist covers the rest of that launch.