Page experience and Core Web Vitals

Updated 16 October 2026 · 16 min read

Andy Bright

Director of Product and Technology

On this page

How much speed affects rankings
The three measurements
How Google decides whether a page passes
Where to find your numbers
Improving LCP
Improving INP
Improving CLS
The rest of page experience
Speed, crawlers and AI agents
What to do next
Further reading

Page experience is Google's name for how easy a page is to use, apart from what it says. It includes how fast the page loads, whether it works on a phone, whether it's secure, and whether pop-ups get in the way.

Core Web Vitals are three measurements of page experience that Google uses in its rankings. They measure how quickly the main content appears, how quickly the page responds when you click or tap, and how much the page jumps around while it loads. Google takes these measurements from real visitors using the Chrome browser.

This chapter explains:

how much speed affects rankings
what each of the three measurements means, and the scores that count as good
how Google decides whether a page passes
where to find the numbers for your own site
what developers can do to improve each one
the rest of page experience: mobile pages, HTTPS, pop-ups and ads
why speed also affects crawlers and AI agents

How much speed affects rankings

Speed affects rankings, but only up to a point. Google's page experience documentation⁠(opens in a new tab) says its ranking systems look to reward pages that give a good page experience, and that "Core Web Vitals are used by our ranking systems".

The same page says good scores don't guarantee top rankings, and that aiming for a perfect score only for SEO reasons may not be the best use of your time. A September 2026 update added that "Beyond Core Web Vitals, other page experience aspects don't directly help your website rank higher in search results".

A fast page that doesn't answer the searcher's question won't beat a slower page that does. Fix pages that fail Core Web Vitals, and don't spend weeks making a page that already passes slightly faster. Slow pages also lose visitors, get crawled less, and are harder for AI agents to use, as the last section of this chapter explains.

The three measurements

Fernhill Coffee's product page for its Ethiopian coffee, at /products/ethiopia-yirgacheffe, has a large photo of the coffee bag at the top, a description, a price and an "Add to basket" button. Each Core Web Vital describes something a visitor to that page would notice.

Largest Contentful Paint (LCP) measures loading. It's the time from when someone opens the page until the biggest image or block of text in their screen's visible area appears. On Fernhill's page, that's usually the photo of the coffee bag.

Interaction to Next Paint (INP) measures responsiveness. It's the delay between someone clicking, tapping or pressing a key and the page visibly reacting. If a visitor taps "Add to basket" and nothing happens for a second, that page has a poor INP. INP covers every interaction during the visit, not only the first.

Cumulative Layout Shift (CLS) measures stability. It's a score for how much the content on screen moves unexpectedly. If a cookie banner appears at the top of Fernhill's page and pushes the "Add to basket" button down just as someone goes to tap it, that movement counts towards CLS.

Here are the scores for each. "ms" means milliseconds, thousandths of a second. CLS is a score rather than a time, so it has no unit.

Measurement	Good	Needs improvement	Poor
Largest Contentful Paint (LCP)	2.5 seconds or less	2.5 to 4 seconds	More than 4 seconds
Interaction to Next Paint (INP)	200 ms or less	200 to 500 ms	More than 500 ms
Cumulative Layout Shift (CLS)	0.1 or less	0.1 to 0.25	More than 0.25

The scores come from Google's Core Web Vitals page⁠(opens in a new tab) and web.dev's pages on Web Vitals⁠(opens in a new tab), INP⁠(opens in a new tab) and CLS⁠(opens in a new tab). web.dev is Google's Chrome team's website for developers.

How Google decides whether a page passes

Google uses measurements from real visitors, collected from Chrome users who share usage data. This collection is called the Chrome UX Report, or CrUX. Measurements from real visitors are called field data.

A page passes a measurement when at least 75% of visits meet the "good" score (Web Vitals⁠(opens in a new tab)). This is called the 75th percentile. Mobile and desktop visits are measured separately, so a page can pass on desktop and fail on mobile.

You'll also see lab data, which comes from a test that loads the page once in a simulated browser. Tools like Lighthouse, which is built into Chrome, produce lab data. Lab data is useful for finding causes, but it isn't what Google uses to judge your page. A good Lighthouse score on a fast office computer can hide a poor experience for visitors on older phones.

When the two disagree, web.dev's LCP guide⁠(opens in a new tab) says field data from CrUX likely gives the more accurate picture.

INP is harder to test in the lab, because it needs someone to interact with the page. web.dev says INP can be measured⁠(opens in a new tab) in the lab as well as in the field, but some lab tools can't report it because they only watch the page load. Lighthouse's standard test is one of them. It reports Total Blocking Time (TBT) instead, which is a reasonable stand-in but not a replacement. Lighthouse's timespan mode and the Performance panel in Chrome's developer tools do measure INP, for the interactions you make yourself.

How the measurements change

Google changes the Core Web Vitals occasionally. In March 2024, INP replaced an older measurement called First Input Delay (FID), as recorded in Google's documentation updates⁠(opens in a new tab). Google has committed that "stable Core Web Vitals metrics won't change more than once per year", and that it will give notice before a change (Web Vitals⁠(opens in a new tab)). As of October 2026, the three measurements and scores above are current.

A coming change for single-page apps

A single-page app is a website that loads once and then uses JavaScript to swap in new content as you move around, instead of loading a whole new page. Many sites built with React and Next.js work this way. The JavaScript chapter explains them.

When you move between pages in a single-page app, the browser doesn't load a new page. Until now, Core Web Vitals haven't measured these moves, called soft navigations, as separate page views.

In October 2026, after Chrome 151 added a way to detect soft navigations, CrUX added experimental versions⁠(opens in a new tab) of LCP, INP and CLS that include them. Nothing changes in your scores yet. Google says "Google's stable Core Web Vitals scores remain unchanged while these experimental versions are evaluated alongside them". It aims to make the new measurements official in May 2027, after which "Search Console will switch to use the new data".

If your site is a single-page app, ask your developer to look at the experimental data now. Moves between pages that feel slow to visitors may start to count against your scores.

Where to find your numbers

There are four places to look.

Google Search Console's Core Web Vitals report groups similar pages together and shows which groups pass or fail, using CrUX data. It's the best place to start, because it shows problems across the whole site.

PageSpeed Insights, at pagespeed.web.dev, shows CrUX data for a single page and for your whole site, on mobile and desktop. It also runs a Lighthouse lab test on the page.

The Performance panel in Chrome's developer tools measures all three on your own computer, shows CrUX field data alongside, and breaks LCP into its parts (web.dev⁠(opens in a new tab)). This is mainly for developers.

Real user monitoring (RUM) means collecting the measurements from your own visitors with a small script on your site. It's the most detailed source, because it can tell you exactly which image or button caused a problem.

Low-traffic pages often have no CrUX data of their own. In that case PageSpeed Insights shows data for your whole site, which can hide a problem that affects only one page (web.dev's LCP guide⁠(opens in a new tab)). Real user monitoring covers those pages too.

If your site doesn't have real user monitoring yet, Google's open-source web-vitals library is a simple way to add it. This code sends each visitor's measurements to your own analytics, along with details of what caused each one:

import { onLCP, onINP, onCLS } from 'web-vitals/attribution'

function send(metric) {
  navigator.sendBeacon('/analytics/vitals', JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,          // 'good' | 'needs-improvement' | 'poor'
    page: location.pathname,
    attribution: metric.attribution // what caused it
  }))
}

onLCP(send)
onINP(send)
onCLS(send)

Improving LCP

The rest of this chapter's fixes are mostly work for a developer. Knowing what they are will help you understand what your developer tells you, and ask the right questions.

web.dev's LCP guide⁠(opens in a new tab) splits LCP into four parts. Finding which part takes longest is the quickest way to find the fix.

Part	What happens	Rough share of the time on a fast page
Time to first byte (TTFB)	The server prepares the page and starts sending it	About 40%
Resource load delay	The wait before the browser starts downloading the main image or font	Less than 10%
Resource load duration	The time to download it	About 40%
Element render delay	The wait between the download finishing and the image appearing	Less than 10%

web.dev calls these shares guidelines, not rules. The two "delay" parts should be close to zero, because they're time spent waiting rather than working. These fixes come from the same guide, roughly in order of impact.

1. Put the main image in the HTML

The browser can only start downloading an image once it knows the image exists. If the main image is added by JavaScript, set as a background in a CSS file, or lazy loaded (loaded only when it comes into view), the browser finds it late. Put it in the page's HTML as a normal <img> tag.

2. Don't lazy-load the main image, and give it priority

Lazy loading is good for images further down the page, but not for the main image. The fetchpriority="high" setting tells the browser to download the main image before other files:

<!-- Main image: in the HTML, high priority, not lazy -->
<img src="/images/ethiopia-yirgacheffe-1200.avif"
     srcset="/images/ethiopia-yirgacheffe-800.avif 800w, /images/ethiopia-yirgacheffe-1200.avif 1200w"
     sizes="100vw" width="1200" height="600"
     fetchpriority="high" alt="A bag of Fernhill Ethiopia Yirgacheffe coffee beans">

<!-- Images further down the page can be lazy -->
<img src="/images/brewing-guide.avif" loading="lazy" width="800" height="400" alt="Coffee brewing in a cafetière">

Use fetchpriority="high" on only one or two images. web.dev notes that setting it on more makes it unhelpful.

3. Remove work that blocks the page

Some files stop the browser showing anything until they've loaded. These are called render-blocking files. The usual fixes are to include the small amount of CSS the top of the page needs directly in the HTML and load the rest later, and to add defer or async to scripts in the <head> so they don't hold the page up. web.dev says it's almost never necessary to load scripts in the head without one of these. Developers can also tell the browser to connect early to other websites the page needs, such as an image service.

4. Build the page on the server

When the server builds the HTML, images are in the HTML where the browser can find them, and the browser doesn't have to wait for JavaScript. web.dev says building pages ahead of time is generally the better choice for speed where the site's setup allows it. The same change lets AI crawlers read the page, as the JavaScript chapter explains, so it fixes two problems at once.

5. Make the server respond faster

Time to first byte depends on the server. Ways to reduce it include using a CDN (content delivery network), a service that stores copies of your pages on servers around the world so they're sent from somewhere close to each visitor. Other ways include keeping slow database lookups from holding up the page, and cutting out redirects.

Be careful with tracking codes in addresses, such as campaign tags added to links in emails. Each different address can look like a new page to a CDN, so it fetches a fresh copy from your server every time instead of using the stored one.

6. Make the image smaller

Use modern image formats such as AVIF and WebP, provide different sizes for different screens with srcset, and compress images. web.dev notes that download time often isn't the main problem, so check the four-part breakdown before anyone spends a week compressing images.

Improving INP

INP depends on what happens after the page has loaded. Chrome's data shows that "90% of a user's time on a page is spent after it loads" (web.dev on INP⁠(opens in a new tab)). A page that loads quickly but freezes when someone opens a menu still fails.

Poor INP almost always means the browser was busy when the visitor clicked. The browser runs JavaScript and responds to clicks in the same place, called the main thread, and it can only do one thing at a time there. If a long piece of JavaScript is running when someone taps "Add to basket", the tap waits until it finishes.

web.dev's INP guide⁠(opens in a new tab) splits each interaction into three parts. Each part has its own fixes.

Input delay: the wait before the browser starts responding

This is usually caused by long tasks running while the page loads, often the browser processing JavaScript files. The fixes are to send less JavaScript, split it into smaller files, and delay or remove third-party scripts that aren't essential.

Third-party scripts are code from other companies that runs on your pages. On marketing sites, the usual causes of slow responses are tag managers, chat widgets, A/B testing tools and session recording tools. Whoever manages your tag manager should be part of fixing INP.

Processing time: running the code that responds

Keep the code that runs on each click short. Do the visible update first, and run everything else afterwards (web.dev⁠(opens in a new tab)):

textBox.addEventListener('input', (event) => {
  updateTextBox(event) // the change the visitor needs to see now

  // Run the rest after the next screen update
  requestAnimationFrame(() => {
    setTimeout(() => {
      updateWordCount()
      checkSpelling()
      saveDraft()
    }, 0)
  })
})

In that code, the browser also has to work out the page layout again if the code changes styles and then reads sizes or positions straight away. Developers call this layout thrashing. Grouping all the reads together, and all the changes together, avoids it.

Presentation delay: drawing the result on screen

Pages with a very large number of HTML elements take longer to update. Keep pages lean, and use the CSS content-visibility property to skip drawing sections that are off screen.

Building large parts of a page with JavaScript is also slow, because the browser doesn't respond to anything else until it finishes. HTML sent from the server is processed in small pieces instead (web.dev⁠(opens in a new tab)). Large JavaScript frameworks can also leave a page unresponsive while they hydrate, the step where JavaScript takes over a page built on the server. React Server Components and partial hydration reduce this.

Heavy calculations can also be moved off the main thread into a web worker, a separate background process that doesn't block clicks.

Improving CLS

Layout shifts happen when something appears or changes size above the content someone is looking at. They can also make AI agents click the wrong thing, as the last section explains. These are the usual causes, with the fix for each:

Images and videos without a set size. Always give them a width and height, or a CSS aspect-ratio, so the browser saves space for them before they load.
Ads, embedded videos and banners that load late. Give each a fixed space. When a cookie banner or promotion bar appears, show it on top of the page or in space saved for it, rather than pushing the content down.
Web fonts that replace the standard font once they load, changing the size of the text. Set the font-display value with care, load important fonts early, and match the size of the standard font to the web font (for example with the size-adjust setting) so the text doesn't move.
Content added above what's already on screen, such as a "related products" box that loads late. Add it below instead, or save a space of the right size.
Animations that change the layout. Animate with the CSS transform and opacity properties instead, which don't move other content.

/* Save space for an embedded video */
.video-embed { aspect-ratio: 16 / 9; width: 100%; }

/* Save space for an advert */
.ad-slot { min-height: 250px; }

The rest of page experience

Google's page experience guidance⁠(opens in a new tab) includes a checklist that covers more than Core Web Vitals. Apart from Core Web Vitals, these don't directly affect rankings, but they affect whether visitors stay, and whether search engines can read your content.

Mobile pages

Google uses "the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking", according to its mobile-first indexing guidance⁠(opens in a new tab). This is called mobile-first indexing. Since July 2024, Google has crawled websites only with its smartphone crawler, and a site whose content "is not accessible at all with a mobile device" can no longer be indexed (Google's announcement⁠(opens in a new tab)).

This means Google judges your site on what the mobile version contains:

The mobile page needs the same content as the desktop page. If Fernhill's mobile product page left out the tasting notes to save space, Google would treat the tasting notes as missing.
Both versions need the same title, description, structured data and robots tags.
Don't make visitors interact to load the main content. In Google's words, "Google won't load content that requires user interactions (for example, swiping, clicking, or typing) to load."

HTTPS

HTTPS is the secure version of the web's communication method, shown by the padlock in a browser's address bar. Every page should use it. Pages at old http:// addresses should send visitors to the https:// version with a single permanent redirect. Developers can also turn on HSTS, a setting that tells browsers to always use HTTPS for the site, once every part of the site, including subdomains, works over HTTPS.

Pop-ups

A pop-up that covers the page as soon as someone arrives from a search result makes the page harder to use. Google calls these intrusive interstitials. Its guidance on pop-ups⁠(opens in a new tab) says "Don't obscure the entire page with interstitials", and says not to send visitors to a separate page to ask for their consent or details.

Pop-ups required by law, such as age checks, are exempt. Even then, Google recommends showing them on top of the page rather than on a separate page. If a site sends every address to one age-check page, Google says that "will remove all but that one page from search results".

For Fernhill, a newsletter sign-up box that covers the product page the moment someone arrives would go against this guidance. A small banner at the bottom of the screen wouldn't.

Ads and clutter

Google's checklist also asks whether ads get in the way of the main content, and whether visitors can easily tell the main content apart from everything else on the page. Chrome now offers experimental CrUX measurements of the number of ads, how much of the page they cover, and how heavy they are, if you want to measure this (page experience⁠(opens in a new tab)).

Google's guide to optimising for AI search⁠(opens in a new tab) recommends "making it easy for people to distinguish your main content from other elements on the page". If the answer someone is looking for sits between adverts and widgets, people and AI systems both have a harder time finding it.

Speed, crawlers and AI agents

Every measurement in this chapter describes something a visitor feels: the wait for the page, the button that doesn't respond, the paragraph that moves as they start to read it. Speed also affects crawlers and AI agents.

Google crawls fast sites more. Its crawl budget guide⁠(opens in a new tab) says the number of pages Google is willing to fetch goes up when a site responds quickly and goes down when it slows down or returns errors. It also recommends letting Google check whether a page has changed without downloading it again, which servers do by answering with a 304 Not Modified status. A slow server means fewer pages crawled, which affects large sites most.

AI companies don't publish similar guidance for their crawlers. A fast response that a CDN can store and reuse gives any crawler the best chance of fetching the whole page, but no AI company has documented how its crawler handles slow pages.

AI agents are AI tools that use websites on someone's behalf, for example to compare prices or place an order. Pages that move while they load cause them problems. web.dev's guidance on websites that work for AI agents⁠(opens in a new tab) recommends stable layouts, because content that moves can make an agent click the wrong thing. Lighthouse includes a layout stability check in its experimental Agentic Browsing category. The AI search chapter covers agents in more detail.

What to do next

Open the Core Web Vitals report in Google Search Console. Start with groups of pages that fail on mobile.
Choose the worst type of page, such as product pages, rather than individual pages. Pages built from the same template usually share the same problems.
Run one example through PageSpeed Insights, and ask your developer to find the cause: which part of LCP is slow, which interaction is slow, or which element moves.
After a fix goes live, watch the field data. CrUX covers the previous 28 days, so improvements appear gradually rather than the day after the fix.
Ask your developer to add real user monitoring if your site doesn't have it, so the next problem shows up within days.
Ask your developer to add a performance budget to the site's build process. This is a limit, such as a maximum file size, that stops changes going live if they would make pages slower.