Core Web Vitals for web applications: what a failed assessment means, and what to ask whoever builds yours

Core Web Vitals are three measurements of how a page feels to the people using it. They say how soon its main content appears, how quickly it reacts to a click or a key press, and how steady it stays on screen. Google's ranking systems use them, but as one signal among many: according to Google, Search always seeks to show the most relevant content, even if the page experience is sub-par.

What does "Core Web Vitals assessment failed" mean?

It means that on at least one of the three measurements, more than a quarter of real visits in Chrome fell short of what Google counts as good. PageSpeed Insights looks at the last 28 days, and a page or a whole site passes only when at least three visits in four are good on all three.

Where there is too little data on INP, loading and stability decide alone. With too little data on either of those, there is no assessment at all.

For a web application, read the result with care. These figures only cover pages that are publicly discoverable, judged the way a search engine judges them, so the screens behind your sign-in will not normally appear one by one. But your application may share its address with your public website, rather than run on a subdomain of its own. Then the visits of signed-in users still count in the figures for the whole site.

What are the three Core Web Vitals and their thresholds?

There are three: LCP measures loading, INP responsiveness and CLS visual stability. The thresholds below are the ones Google gives on web.dev. Each is measured at the 75th percentile of page loads, with phones and computers counted separately.

• LCP, Largest Contentful Paint (loading): when the largest image or block of text in view has appeared. Good is 2.5 seconds or less; poor is more than 4 seconds.
• INP, Interaction to Next Paint (responsiveness): how long the page takes to show a reaction to a click, a tap or a key press, judged over the whole visit. Good is 200 milliseconds or less; poor is more than 500 milliseconds.
• CLS, Cumulative Layout Shift (visual stability): how much the content moves unexpectedly, over the whole life of the page. Good is 0.1 or less; poor is more than 0.25.

For a web application, INP deserves the closest look. Chrome's usage data shows that 90% of a user's time on a page is spent after it loads, and an application is where people click, type and filter all day.

The thresholds are harder to reach than they sound. In the HTTP Archive's Web Almanac 2024, 43% of websites had good Core Web Vitals on phones, and 54% on computers.

Why a web application can fail them

A common way to build a web application is the single-page application: the browser first receives an almost empty page, and JavaScript then fills in the content. That shows in all three measurements.

• Loading: the main content appears only once the JavaScript has arrived and run. The Web Almanac 2024 found that rendering a page fully in the browser has a significantly negative impact on LCP.
• Responsiveness: the amount of JavaScript tends to grow as the application grows, and that can hurt INP. A very large page, such as a long table, can also make each update after a click expensive to draw.
• Stability: content that arrives later, such as data loaded from the server, pushes the layout around if no space was kept for it.

How do you measure them?

Two kinds of data answer two different questions. Field data comes from real visitors and shows whether you pass. Lab data comes from a test run on one machine and helps to find the cause.

• PageSpeed Insights shows both for a public address: the field data of the last 28 days from the Chrome User Experience Report, where there is enough of it, and a lab test run with Lighthouse. Lab tools that only load the page, without clicking anything, cannot report INP.
• Search Console's Core Web Vitals report groups similar pages and gives each group the status of its worst measurement over the last 28 days. Only indexed pages appear in it.
• The web-vitals library measures the three values in your own users' browsers, the way Chrome measures them, and sends them wherever you choose. Of these tools, it is the only one that measures your real users on the screens behind your sign-in.
• Chrome DevTools: its Performance panel shows a developer which work made a single interaction slow.

What should you ask before launch?

Five things: which pages must be found, what the targets are, how the signed-in screens will be measured, what stops a new version from making things slower, and who watches the figures after launch. Whoever builds your web application should be able to answer all five in plain words before it goes live.

1. Which pages must be found on Google, and can a search engine read them? Public pages should arrive as finished HTML, rendered on the server or ahead of time, rather than being drawn by JavaScript after they load. The screens behind your sign-in do not need to be found.
2. What are the targets, and on which devices? Ask for all three values within the good thresholds, measured on a phone as well as on a computer.
3. How will the signed-in screens be measured once real people use them? Google's field data will not show them, so the application has to measure itself.
4. What stops a new version from making things slower? A size limit for the JavaScript, checked with every build, catches part of it before a release.
5. Who watches the figures after launch? A status can change without any change of yours, for example when traffic rises sharply. What software needs once it is live is the subject of our article on software maintenance after launch.

For your developers: fixes in single-page apps

This part uses technical names, so you can pass it on as it stands.

Loading (LCP)

• Never lazy-load the image that is likely to be the LCP element. Let it load as usual and give it fetchpriority="high"; use loading="lazy" only for images further down the page.
• Prerender or server-render the public pages, so that the main content is in the first HTML response.
• Check the server's response time, and serve the files from close to your users, for example through a CDN. In the Web Almanac 2024, Time to First Byte was the largest part of LCP, and websites with poor LCP spent 2.27 seconds on it alone.
• Make large images smaller, by compressing them or serving AVIF or WebP. The LCP element is an image on 73% of mobile pages (Web Almanac 2024), so images are a good place to look.

Responsiveness (INP)

• Split the JavaScript so that each screen loads only what it needs. In React, lazy() with Suspense loads a component's code only when it is first shown.
• Break up long tasks in event handlers and yield to the main thread, so the browser can draw the reaction first.
• Keep the page's DOM small: show long lists and tables in parts, and consider content-visibility for content far below the visible area.

Stability (CLS)

• Give every image and video its width and height, or reserve its space with CSS aspect-ratio.
• Reserve space for anything that arrives later: data from the server, embeds and banners.
• Preload the critical web fonts, and use font-display: optional or a fallback font adjusted with size-adjust, because the switch from one font to the other can move the layout too.

Checklist

• LCP of 2.5 seconds or less on every important page, on a phone and on a computer
• INP of 200 milliseconds or less, tested with real clicks and typing
• CLS of 0.1 or less, checked on a phone in particular
• Public pages arrive as finished HTML, and the LCP image is not lazy-loaded
• Images compressed, in AVIF or WebP, each with its width and height
• Fonts preloaded, with font-display: optional or an adjusted fallback font
• A size limit for the JavaScript, checked with every build
• The web-vitals library connected to your analytics, so the signed-in screens are measured too
• Search Console's report reviewed after every release

Core Web Vitals are not a one-time project but an ongoing process. Measure regularly, set priorities based on the data, and improve step by step.