Core Web Vitals explained for business owners

Core Web Vitals are three measurements Google takes from real visits to a website. Largest Contentful Paint (LCP) is how long the main content takes to appear, Interaction to Next Paint (INP) is how quickly the page responds to a tap, click or key press, and Cumulative Layout Shift (CLS) is how much the layout jumps unexpectedly during a visit. A page passes when each of the three is good for at least three out of four visits, with phones and computers judged separately. Most websites measured for visitors in India fail on phones: in September 2026, 32% of the websites in Google's Chrome data for India passed, against 53% worldwide.

What are the three Core Web Vitals?#

These are the thresholds Search Console's Core Web Vitals report uses:

LCP is the time until the largest image, text block or video on screen has been drawn. In 2025 that element was an image, such as a banner, on 76% of mobile pages and text on nearly all the rest.

INP looks at every click, tap and key press in a visit and reports roughly the slowest response. Scrolling, hovering and zooming do not count.

CLS scores unexpected movement, such as text jumping down when an advert loads above it. It is based on the largest burst of unexpected shifts in a visit, and movement within half a second of a tap or click does not count, so opening a menu is fine.

INP replaced First Input Delay (FID) as a Core Web Vital on 12 March 2024, so a guide that still lists FID is out of date.

How Google decides whether a page passes#

Google judges each metric at the 75th percentile of visits, separately for phones and desktop computers. LCP is good when at least 75% of visits see the main content within 2.5 seconds, and INP and CLS are tested the same way. A page passes only when all three are good. When there are too few taps, clicks and key presses to measure INP, the page passes or fails on LCP and CLS alone. PageSpeed Insights looks at the previous 28 days of visits.

The data comes from the Chrome User Experience Report (CrUX): opted-in Chrome users on Android and desktop. It leaves out Chrome on iPhone, Android apps that open pages in a WebView and other Chromium browsers such as Microsoft Edge. Most page views in India come from the devices and browser CrUX draws on: in September 2026, phones made up 77.3% of page views in India, Android accounted for 93.89% of mobile page views and Chrome had 88.61% of page views across all devices.

Search Console groups pages with a similar experience, gives each group the status of its slowest metric and only includes indexed pages (our technical SEO checklist covers indexing). PageSpeed Insights falls back to the whole site when a page has too few visits, and shows no real-user data when the site has too few. Google does not publish how many visits that takes, so treat any "visits per day" figure you read as a guess.

Search Console also combines visits from all locations, so heavy traffic from a country with slow connections pulls your results down.

How websites visited from India score on phones#

We pulled the figures in this section from HTTP Archive's Technology Report, which is built on CrUX. In September 2026 it covered about 746,000 websites with enough Chrome visits from India on phones to be measured (sites with too few visitors are left out). CrUX sets each visit's country from the visitor's IP address, so the sites themselves can be based anywhere.

On phones, the share of websites visited from India passing all three rose from 25% in September 2024 to 32% in September 2026. Worldwide it rose from 48% to 53%, so the gap only narrowed from 23 points to 21.

Source: the same report's India figures and worldwide figures, and server response from its TTFB view (India TTFB, worldwide TTFB).

Loading is the weak point, and server response, the wait before anything can load, is the weakest number in the table. Layout stability is fine, slightly better than worldwide. INP is the second concern. Across all the websites in CrUX it slipped for several months, and in its notes on the August 2026 data Google's CrUX team called the continued slide "a cause for concern". In September it held level: 85.4% of websites had good INP, 0.1 points more than in August.

Desktop does better: 51% of websites visited from India passed, against 61% worldwide. If your customers are in India, a site that passes on phones is ahead of about two in three of the websites in this data.

How to check your site's Core Web Vitals in four steps#

1. Run PageSpeed Insights on your homepage and your main enquiry page, on the mobile tab. The section headed "Discover what your real users are experiencing" shows real Chrome visits over the last 28 days. Note which metric fails, and whether the figures are for the page or the whole site.
2. If that section is missing, either Google has too few visits to the page and the site in its data (CrUX covers millions of popular websites, but not all of them) or the page is blocked from crawling or indexing. Use the lab test lower down the same report, which simulates a slow mobile connection, and a mid-range Android phone on mobile data. A developer can also collect real visitors' figures with Google's web-vitals library and send them to Google Analytics 4, though reading the 75th percentile there needs GA4's BigQuery export or Data API, not its built-in reports.
3. Open the Core Web Vitals report in Google Search Console, one of the tools we use. Verify the site from an account the business owns, not your developer's (our checklist covers setting up Search Console). Fix groups marked Poor first, as Google recommends; a group usually shares one template, so one fix can move many pages. Once the fix is live, start validation, and Search Console watches the pages for 28 days.
4. Write down the date, the three field numbers and the element that counts as LCP, which the lab report shows, so you can tell later whether the work changed anything.

What the PageSpeed score means#

The 0 to 100 number in the lab section blends five lab measurements: Total Blocking Time 30%, LCP 25%, CLS 25%, First Contentful Paint 10% and Speed Index 10%. Total Blocking Time stands in for INP, because nobody taps during a lab test. The score does not decide whether a page passes. PageSpeed Insights calls 90 or more good, but warns that good lab data "does not necessarily mean real-user experiences will also be good". Lighthouse's documentation calls a perfect 100 "extremely challenging to achieve and not expected", and Google Search Central says chasing one just for SEO "may not be the best use of your time".

Why is my website slow to load? It is rarely the image file#

Google's Chrome team measured where the time goes on real Chrome visits to pages whose main element is an image, and published the results in 2024.

On sites with poor LCP, the median site waits 2,270 milliseconds for the server and 1,290 more before the browser even starts fetching the main image. Most of these sites spend less than 10% of their LCP time on the download, so compressing the image, the usual first tip, rarely fixes a failing page by itself.

Server response, or time to first byte (TTFB), is good at 0.8 seconds or less. When a site is hosted in one country and its visitors are elsewhere, the distance adds to the wait, and a content delivery network (CDN) keeps copies of the site closer to them. With good server response on only 22% of websites visited from India, question the hosting first.

The 1,290 milliseconds is time lost before the browser even starts the download, often because it has not found the image yet or does not know it matters most. The browser finds the image soonest when it is a plain img tag in the HTML, so for the main image on every template, ask for four things:

• An img element in the HTML, not a CSS background or a slider built by a script.
• Width and height set, so its space is reserved and the text below does not jump (that protects CLS).
• No lazy-loading. Google's guidance is blunt: "Never lazy-load your LCP image".
• The attribute fetchpriority="high", which tells the browser to start loading it straight away.

Few sites do all four: in 2025, 16 to 17% of pages lazy-loaded their main image, 17% of mobile pages with an image as the main element used fetchpriority="high", and 62% of mobile pages had at least one image without set dimensions. Forward this line to your developer:

<img src="/images/hero-1600.webp" width="1600" height="900" alt="Describe what the photo shows" fetchpriority="high">

Business decisions that slow a site down#

Many slow pages come from decisions made outside the code. Google's guide for business decision makers lists causes that owners and marketing teams control:

• Video at the top of the page, and carousels, which can make the browser download several large images at once.
• Print-quality images from media partners or design agencies. Ask for web-optimised versions.
• Code from expired campaigns left in a tag manager, which is still downloaded and compiled on every page.
• A/B testing tools that hold back the page until the test changes apply. Run them only on the pages being tested, briefly, and remove finished tests.
• Campaign links that pass through redirects or chains of link shorteners. Link to the final address, and ask whoever runs your CDN to ignore UTM parameters when caching.
• Widgets loaded on every page, such as a map that only the contact page needs. In 2025, at least 90% of pages used one or more third parties.
• Cookie notices and offer bars inserted above the content after loading. Show them as overlays instead. The consent tool matters too: in April 2024 Google's CrUX team wrote that Google had been working with consent management platforms, including OneTrust, Complianz and Axeptio, and that this had "resulted in much improved INP for sites using these platforms".

Keep the platform, theme and plugins updated too, or choose a host that does it for you, so the site gets the improvements platforms keep making.

Does the platform matter?#

Somewhat. WordPress runs 40.2% of all websites (W3Techs, October 2026), so it is the platform most owners meet. Of the WordPress sites visited from India, 29% passed on phones in September 2026. In the same report about half of Wix and Shopify sites passed, and only 21% of sites built with Next.js, a framework for custom JavaScript builds, so a custom build is not automatically faster.

The Web Almanac's chapter on content management systems says figures like these "capture the combined effects of platform defaults, hosting choices, themes, plugins, and page builders". Choose the platform for what the site has to do (see our guide to planning a business website), then hold whoever builds it to field results on phones. We build online stores on Shopify, WooCommerce or custom code, and the same test applies to each.

What to ask your developer or agency#

These work for a new build or an existing site. Ask for specific answers, in writing.

1. Will you show me field data on mobile before and after the work, not just the PageSpeed score?
2. Where is the site hosted, and does a CDN serve visitors in India from nearby?
3. How is the main image loaded on each template: in the HTML, sized, not lazy-loaded and marked high priority?
4. Do images, videos, embeds and ad slots have space reserved?
5. Which scripts load on every page, and can maps, chat and video embeds load only where they are used?
6. How do the cookie banner and any A/B testing tool load, and do they delay the page or push content down?
7. Who updates the platform, theme and plugins after launch, and how often?
8. If Google has no field data for our site, how will we see real-visitor numbers? Lab tools cannot measure INP.

Mistakes to avoid#

• Judging the site by the PageSpeed score, or paying for work whose only goal is 100.
• Testing only on office Wi-Fi with a new phone.
• Expecting results within a week. Field data covers 28 days, and so does Search Console's validation.
• Removing a feature customers use, such as booking or chat, instead of loading it only where it is needed.

Do Core Web Vitals affect Google rankings and sales?#

Google's page experience documentation says "Core Web Vitals are used by our ranking systems", but also that good reports do not guarantee top rankings, and that Google "always seeks to show the most relevant content, even if the page experience is sub-par". Where many helpful pages compete for a search, a great page experience "can contribute to success in Search". Google's ranking systems generally judge pages one by one, with "some site-wide assessments".

On sales, two Indian companies published results on web.dev in 2023. The bus booking site redBus reported a 7% increase in sales after improving INP. The Economic Times cut INP nearly fourfold from close to 1,000 milliseconds, while also moving to Next.js, and reported a 50% decrease in bounce rate and a 43% rise in pageviews on topic pages. These are the companies' own figures from several changes made at once, so do not read them as a forecast for your site.

Our reading: fix Core Web Vitals because they describe what your visitors go through, and count any ranking gain as a bonus. Faster loading will not lift a page that does not answer the search, which is why our SEO services work on content and speed together. There is more on search in our SEO guides.

Where to start this month#

1. Measure with PageSpeed Insights, Search Console and a mid-range phone on mobile data, and write the numbers down.
2. Fix the cheap things: the hero image, images without dimensions, unused scripts and widgets, and banners that push content down.
3. If server response is slow, look at hosting and a CDN before paying for anything else.
4. Start validation in Search Console as soon as the fix is live. It then watches the pages for 28 days; when it finishes, compare the field numbers with the ones you wrote down.

If you would rather hand the work over, our website design and development service checks page speed on phones and desktop browsers before a site goes live. There are more website guides on the blog.