Core Web Vitals for B2B Websites: Thresholds and Fixes

The short answer

A page passes Core Web Vitals when, at the 75th percentile of real visits, Largest Contentful Paint is 2.5 seconds or less, Interaction to Next Paint is 200 milliseconds or less and Cumulative Layout Shift is 0.1 or less¹. Judge mobile and desktop separately, use field data for the verdict and lab data for the diagnosis, and fix your pipeline pages first.

The three metrics and their thresholds

Core Web Vitals are three measurements of how a page feels to a real visitor: how quickly the main content appears, how quickly the page responds when someone clicks or types, and how much the layout jumps around while it loads.

Metric	What it measures	Good	Needs improvement	Poor
Largest Contentful Paint (LCP)	Time until the largest image or text block in the viewport has rendered	2.5 s or less	Over 2.5 s, up to 4 s	Over 4 s
Interaction to Next Paint (INP)	Delay between a click, tap or key press and the next visual update	200 ms or less	Over 200 ms, up to 500 ms	Over 500 ms
Cumulative Layout Shift (CLS)	How much visible content moves unexpectedly	0.1 or less	Over 0.1, up to 0.25	Over 0.25

The bands are the ones PageSpeed Insights and the Search Console Core Web Vitals report use²³. Three details matter when you read them:

The 75th percentile. The score is not an average. It is the value that 75% of visits met or beat, so a page passes only if most visitors, not just a typical visitor, get a good experience¹.
Mobile and desktop are separate. Google recommends segmenting the 75th percentile across mobile and desktop¹, and Search Console reports each device type on its own³. Many B2B buyers research on a laptop, but some first visits happen on a phone, so check both.
The worst metric wins. In Search Console, a group of URLs takes the status of its poorest metric³. A page with excellent LCP and poor INP is "poor".

INP replaced First Input Delay (FID) as a Core Web Vital in 2024¹. If a guide, agency report or plugin still talks about FID, it is out of date.

How much Core Web Vitals matter for B2B search

Google says it "highly recommend[s]" good Core Web Vitals for success with Search, and that they, along with other page experience aspects, align with what its core ranking systems seek to reward⁵. Read that carefully: good scores are worth having, but they are one part of page experience, and they will not lift a page that does not answer the searcher's question. For a B2B team, the stronger reason to care is the buyer comparing suppliers on a slow connection, who meets a page that takes five seconds to show its headline or freezes when they tap "Book a demo".

Passing is not universal. The HTTP Archive Web Almanac 2025, using July 2025 data, found that 48% of mobile websites and 56% of desktop websites had good Core Web Vitals⁷. So a good score is achievable, and many sites still fall short.

Field data and lab data

There are two kinds of performance data, and confusing them is the most common reason teams fix the wrong thing.

	Field data	Lab data
What it is	Measurements from real visits, on real devices and networks	A simulated load of the page on one device with fixed network conditions
Where you see it	Search Console Core Web Vitals report, the top of PageSpeed Insights, the Chrome UX Report (CrUX), your own real user monitoring	Lighthouse, the "Diagnose performance issues" section of PageSpeed Insights, Chrome DevTools
What it is good for	The verdict: are real visitors getting a good experience?	The diagnosis: what on the page is slow, and did a fix help?
Limits	Needs enough traffic; covers the previous 28 days, so it reacts slowly	Cannot measure INP; one device and network; usually a cold cache

The two often disagree, and that is expected. Lab tests use a single device, network and location and usually load the page with a cold cache, while real visitors often have files cached already⁶. A lab test cannot know when a person will click, so it cannot measure INP; it reports Total Blocking Time (TBT) as a diagnostic stand-in, and a page can have a good TBT and still a poor INP⁶. Personalised content and A/B tests can also change which element is the largest and cause layout shifts that only show up in the field⁶.

The practical rule: decide whether you have a problem from field data, then use lab data to find why and to check each fix before it ships.

Low-traffic B2B sites: when there is no field data

Most of the field data in Google's tools comes from the Chrome UX Report. A site with 5,000 to 100,000 visits a month may find that some pages, or the whole site, have none. Knowing why stops you misreading the gaps.

Who is counted in CrUX

To be included, a page or origin must be publicly discoverable and "sufficiently popular", meaning it has a minimum number of visitors. Google does not disclose the exact number⁴. Only some visits count: those from Chrome users on desktop or Android who have usage statistics reporting and history sync turned on. Chrome on iPhone, other Chromium browsers such as Microsoft Edge, and in-app browsers are not included⁴. On a B2B site where many buyers use Edge on a managed work laptop or Safari on an iPhone, the share of visits CrUX can see may be well below your total.

CrUX data is a rolling 28-day aggregate, updated daily¹⁵. A fix you ship today will take up to four weeks to show fully in the field numbers.

Origin-level fallback

When a single page lacks enough data, Google's tools fall back to the whole site:

PageSpeed Insights shows origin-level data, covering all visits to all pages of the site, when the URL has too little. If the origin also has too little, it shows no real-user data at all².
Search Console groups URLs that have a similar experience. When a group has too little data, it creates a higher-level origin group for all URLs under the same protocol, host and port, and if that has too little, nothing is shown³. Only indexed URLs appear, and a group needs a minimum of data for both LCP and CLS³.

Origin data is an average of your whole site. If your blog posts are light and fast and your pricing page carries a heavy calculator, the origin can pass while the page that matters most fails. Check which level you are looking at: PageSpeed Insights says when it is showing origin data.

What to do if you have little or no field data

Use the origin data as a rough signal for the site as a whole, by device type.
Run lab tests on your pipeline pages (home, main solution pages, pricing, the demo request page) on a throttled mobile profile, and fix what they flag. Lab LCP and CLS are useful proxies; for INP, look at TBT and long tasks.
Try the key interactions yourself on a mid-range Android phone: open the menu, accept the cookie banner, start the demo form.
Consider measuring your own field data. Google's open source web-vitals JavaScript library measures LCP, INP and CLS in real visitors' browsers the same way Chrome does, at about 3 KB compressed, and can send the results to your analytics¹⁴. It can include visits CrUX does not count, in browsers that support the metrics, but on low traffic you should still read it over weeks, not days.

B2B-specific fixes

The same few causes tend to recur on B2B sites. These are the four we would check first.

1. Hero images (LCP)

On most solution and home pages, the largest element is a hero image, illustration or product screenshot. Google's LCP guide breaks LCP into four parts: time to first byte, resource load delay, resource load duration and element render delay⁸. Hero images usually fail on the middle two.

Never lazy-load the hero image. Lazy-loading the LCP image "will always lead to unnecessary resource load delay"⁸. Some themes and page builders lazy-load every image by default; check the hero's loading attribute.
Make it discoverable in the HTML. An image set as a CSS background, or inserted by a slider script, is found late. Use an <img> element in the initial HTML, or preload it⁸.
Raise its priority with fetchpriority="high" on the image you expect to be the LCP element⁸.
Cut its size: serve an appropriately sized image for each screen, in a modern format such as WebP or AVIF, compressed⁸. A 2,400-pixel PNG screenshot shown at 600 pixels on a phone is a common culprit.
Drop the carousel. A rotating hero slider adds script before the first slide can show.
Give it dimensions. Set width and height on images so the browser reserves space and the text below does not jump⁹.

2. Chat widgets (INP and LCP)

Live chat and chatbot widgets are often large scripts, and they typically load on every page for every visitor, including the majority who never open them. The established fix is a facade: a static element that looks like the chat button, which loads the real widget only when someone interacts with it. Google's Lighthouse documentation lists open source facades for live chat tools including Intercom, Drift and Help Scout¹¹.

Load the chat widget on click, or at least after the page has finished loading, rather than in the page head.
Ask whether chat is needed on every page. Many teams find it earns its place on pricing and demo pages and adds little on blog posts.
Expect a trade-off: a facade can lose features that need the full script running, such as proactive messages.

3. Tag managers (INP and CLS)

A B2B tag manager container accumulates tags over the years: analytics, several ad pixels, intent data, heatmaps, A/B testing, event tracking for campaigns long finished. Google's tag guidance reports a correlation between the size of tag managers and poorer INP scores, and notes that tags injecting content into the page can cause layout shifts¹².

Audit the container. List every tag, its owner and its purpose. Pause or remove unused tags rather than blocking them with a trigger exception¹².
Fire non-essential tags later. Google suggests firing non-essential tags after Window Loaded so they do not compete with the page load¹².
Be wary of Custom HTML tags, which are easy to misuse in ways that hurt performance¹². A Custom HTML tag that loads another vendor's script is a script you are not reviewing.

4. Cookie banners (CLS and LCP)

Almost every UK B2B site shows a consent banner, and a badly built one can hurt all three metrics.

Overlay, do not push. Banners at the top of the screen that push content down are "a very common source of layout shift". Use a sticky footer or a modal that sits on top of the page instead¹³.
Load the consent script asynchronously. A synchronous script blocks the parser and delays page load and LCP¹³.
Watch for the banner becoming the LCP element. On a phone, a banner with a large block of text can be the largest thing on screen, so its loading speed becomes your LCP¹³.
Avoid entrance animations that move content, which can cause layout shifts depending on how they are built¹³.

Also worth checking

Embedded forms and video. Forms and videos loaded by script appear late and push content down. Reserve their space with a minimum height or an aspect-ratio⁹, and use a lightweight facade for video embeds¹¹.
Web fonts. A late font swap can shift text. Self-host fonts, and match the fallback font's size with size-adjust or use font-display: optional⁹.
Long tasks on interaction. If the menu or a form field is slow to respond, look for long JavaScript tasks and break them up so the browser can respond in between¹⁰.
Slow servers. A high time to first byte can make a 2.5 second LCP hard or impossible⁸. Caching pages at a CDN usually helps most.

A prioritised checklist

Open the Search Console Core Web Vitals report. Note the status for mobile and desktop, and which URL groups are poor or need improvement.
List your pipeline pages and run each through PageSpeed Insights. Note whether it shows page-level or origin-level field data.
For each failing page, identify the failing metric and its cause using the lab diagnostics.
Fix in this order: anything that affects every page (tag manager, chat widget, cookie banner, fonts), then pipeline page heroes, then individual pages.
Check each fix in a lab test before and after, on the same mobile profile.
Record the date of each fix. Wait 28 days, then check the field data again. In Search Console, starting validation on an issue begins a 28-day monitoring session³.
Re-audit the tag manager and third-party scripts each quarter.

A perfect score on a page nobody visits achieves little. Start with the pages that carry buyers towards a conversation. For the wider picture of how performance fits alongside content, titles and internal links, see our B2B website SEO guide; for fixes you can find in an afternoon from search data, see Search Console quick wins.

How to judge whether a fix worked

Record the field and lab numbers before, ship one change, and compare after a full 28-day window. A campaign that shifts your device mix can move field numbers on its own, and if the lab result improved but the field data is too thin to read, say so rather than claiming a win. Our guide on how to measure the impact of a website change covers the method.

Where Artiweave fits

Artiweave finds improvement opportunities from evidence, including performance data, and proposes specific changes. Your team approves, edits or rejects each one, and approved changes are published with automatic rollback. Outcomes are reported honestly, including "inconclusive" and "insufficient traffic" where the field data cannot yet support a verdict. It is in private beta.

Frequently asked questions

What are the Core Web Vitals thresholds?

A page is good when, at the 75th percentile of visits, Largest Contentful Paint is 2.5 seconds or less, Interaction to Next Paint is 200 milliseconds or less and Cumulative Layout Shift is 0.1 or less. Poor starts above 4 seconds, 500 milliseconds and 0.25 respectively; anything between is needs improvement.

Why does PageSpeed Insights show a different score from Search Console?

PageSpeed Insights shows two things: field data from real Chrome visits over the previous 28 days at the top, and below it a Lighthouse performance score from one simulated lab load. Search Console reports only the field data. They measure different things, so they often differ. Use field data for the verdict and lab data to diagnose.

Why does my site have no Core Web Vitals data?

Field data comes from the Chrome UX Report, which only includes pages and origins with enough eligible visits; Google does not publish the threshold. Low-traffic pages fall back to origin-level data, and if the whole origin is below the threshold, no field data is shown.

Sources

Turn performance evidence into approved changes.

Artiweave proposes specific changes from evidence, your team approves each one, and approved changes are published with automatic rollback. It is in private beta.

Join the waitlist