Core Web Vitals: A Practical Guide for B2B Websites in 2026

Core Web Vitals are the three metrics Google uses to measure real-world user experience on a web page: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. A page passes when at least 75% of real visits record a good score on all three, meaning LCP at or under 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1. Google measures these from field data in the Chrome User Experience Report over a rolling 28-day window, then uses the result as a ranking signal.

This guide covers what each metric measures, what has changed recently, how to measure your own site, and how to decide what to fix first.

What are Core Web Vitals?

Core Web Vitals are a standardized set of three metrics that quantify how a page feels to the people actually using it. Google introduced them to replace proxy measures like page weight and total load time with something closer to perceived experience: how quickly the main content appears, how quickly the page responds when someone taps or clicks, and whether the layout stays still while it loads.

The three are deliberately narrow. Largest Contentful Paint measures the moment the largest visible content element finishes rendering. Interaction to Next Paint measures the delay between a user interaction and the next visual update, assessed across the whole session rather than the first tap alone. Cumulative Layout Shift measures how much visible content moves unexpectedly during loading.

What separates Core Web Vitals from most performance metrics is the data behind them. Scores come from the Chrome User Experience Report, which collects anonymized measurements from real Chrome users on real devices and real connections. Google evaluates the 75th percentile over a rolling 28-day window, so a page passes only when at least three out of four real visits hit the good threshold. A fast result on your own machine means very little if your audience is on older phones and slower networks.

Assessment happens at the URL group level rather than the individual page. Google clusters similar URLs, typically pages sharing a template, and assigns a score to the group. That has a practical consequence worth holding onto: fixing one page rarely moves the number, and fixing the template behind a hundred pages usually does.

Core Web Vitals became a ranking signal for mobile search between June and August 2021, and for desktop in February 2022. Google has consistently said the effect is modest. They do not override relevance or content quality, but they act as a tiebreaker when comparable pages compete for the same query.

Core Web Vitals thresholds at a glance

Three metrics, three thresholds. Google assesses a page against all of them together.

Source: web.dev, Google. Thresholds apply at the 75th percentile of real visits.

Two rules govern how these thresholds are applied, and both are routinely missed.

First, a page must pass every metric that has enough data behind it. A site with excellent Largest Contentful Paint and Interaction to Next Paint but a Cumulative Layout Shift of 0.3 does not pass. There is no partial credit and no weighted average. If a metric has too few real visits to report, it is excluded from the assessment rather than counted as a failure, which is why a site can pass with one metric marked as unavailable.

Second, the threshold applies to the 75th percentile of real visits, not the average. A page where half of visits load in one second and a third take five seconds will fail LCP even though the average looks acceptable. Averages hide the visits that fail, and those visits are exactly the population Google is measuring.

What has changed, and what has not

The three metrics and their thresholds have been stable since March 2024. The most recent structural change was replacing First Input Delay with Interaction to Next Paint on 12 March 2024, and nothing of that scale has happened since.

First Input Delay measured only the delay on a visitor’s first interaction, which made it easy to pass and a poor reflection of how a site felt in use. Many sites passed First Input Delay while still feeling sluggish through a multi-step form or a filtered list. Interaction to Next Paint evaluates the slowest interaction across the whole page lifecycle, which is a far better proxy for the lag people actually notice.

What has changed is the context around the metrics, not the metrics themselves. A growing share of search impressions now resolve inside an AI-generated answer, where the visitor may never click through to your page at all. That does not make performance irrelevant, but it does change the arithmetic. If fewer impressions produce a visit, each visit that does arrive carries more weight, and a slow or unstable landing experience wastes a scarcer resource.

Why Core Web Vitals matter for B2B websites

Core Web Vitals matter for B2B sites because they shape the first impression during the research phase, which is the part of the buying cycle a vendor has the least control over. They also feed into Google’s broader page experience signals and related quality signals, so the ranking effect is usually incremental rather than dramatic.

B2B purchases involve long evaluation periods and several stakeholders. Most of that evaluation happens before anyone contacts you, on pages you will never see attributed to a deal. A prospect comparing three vendors forms a judgment about competence from the website experience itself. A page that jumps while they are reading, or a form that lags on every keystroke, reads as carelessness at exactly the moment you are asking to be trusted with a budget.

The clearest published evidence comes from Vodafone Italy, which improved Largest Contentful Paint by 31% and recorded an 8% increase in sales, a 15% rise in leads, and an 11% improvement in cart-to-visit rate (web.dev case study). That is a consumer business with a short purchase path, so treat the shape of the result as instructive rather than the figures as transferable, but it still shows how better Core Web Vitals can improve users’ experience, engagement, and conversion rates.

In our own work, the pattern is consistent. The performance problems that cost the most rarely show up in a homepage speed test. They show up on the templates prospects actually spend time in: service pages, case studies, and resource articles. Those are usually the last templates to get performance attention and the first ones a serious prospect reads.

On the ranking side, expect a modest effect. Core Web Vitals are a tiebreaker, not a lever. If your content is genuinely the best answer, passing will not transform your position, and failing will not bury you. The real battle is in the crowded middle, where several comparable pages compete for rankings, and small signals decide the order.

Largest Contentful Paint (LCP)

Largest Contentful Paint (LCP) measures how long it takes for the largest visible content element to finish rendering, which makes it a key signal for both page speed and loading speed. On a B2B marketing site, that largest visible page content during the initial load is almost always a hero image, a large headline block, or a featured card near the top of the page. The passing threshold is 2.5 seconds or less at the 75th percentile.

Largest Contentful Paint is the hardest of the three to pass, and the causes usually sit upstream of the page itself. Slow server response time, render-blocking CSS and JavaScript, oversized hero imagery, and third-party scripts can all delay page load and drag down the site’s performance. In the WordPress sites we take over, an unoptimized hero image and a stack of marketing scripts firing before first paint account for most LCP failures.

For the diagnostic detail, including how to identify the LCP element, image format and sizing strategy, and reducing server response time, read Largest Contentful Paint: a practical guide for web designers and developers.

Interaction to Next Paint (INP)

Interaction to Next Paint (INP) is a Core Web Vital that measures responsiveness to user input during real user interactions by tracking the delay between an action and the next visual update on screen and taking the slowest interaction across the page session. The passing threshold is 200 milliseconds or less at the 75th percentile. Above roughly 200 milliseconds, an interface starts to feel as though it is lagging behind the person using it.

Interaction to Next Paint problems are almost always JavaScript problems. Large bundles block the main thread, event handlers do too much work in response to a single click, and long tasks stop the browser from painting a response. Sites built on heavy front-end frameworks and sites carrying years of accumulated plugin JavaScript are the two populations that struggle most.

Failing interactions are rarely the obvious ones. Navigation usually responds fine. Filtering a list, opening a modal, or slow clicks, taps, or typing into a form field can produce the lag this metric captures.

For code-splitting, task yielding and framework-specific patterns, read Interaction to Next Paint: a practical guide for UX-focused teams.

Cumulative Layout Shift (CLS)

Cumulative Layout Shift (CLS) measures how much visible content moves unexpectedly while a page loads. The passing threshold is 0.1 or less at the 75th percentile, and this is the easiest of the three to fix because the causes are well understood and mostly structural.

CLS reflects how stable the page layout remains as page elements load. Unexpected layout shifts often happen when the browser does not know how much space something needs until it arrives, often because of missing image dimensions, late-loading embeds, unstable CSS code, or a swapping web font. The cost is not only aesthetic. A button that moves as someone reaches for it produces a mis-tap, and on a contact form a mis-tap is a lost enquiry.

Google measures Cumulative Layout Shift within a session window of roughly five seconds containing the largest burst of movement, rather than summing every shift across the whole visit.

For aspect ratio techniques, font loading strategy and handling dynamic content, read Cumulative Layout Shift: practical guide for web designers, developers, and marketing teams.

Field data and lab data are not the same thing

Field data determines your Core Web Vitals assessment. Lab data does not.

Field data comes from real visits by real people, collected as Core Web Vitals data from field sources such as the Chrome User Experience Report (including CrUX data) or a real user monitoring platform. It reflects the devices, networks and locations of your actual audience, including the older phone on a weak connection. Google uses this information from actual users for ranking and for the Core Web Vitals report in Search Console.

Lab data comes from synthetic tests run under controlled conditions, as Lighthouse and WebPageTest produce. Conditions stay consistent between runs, making lab data excellent for catching regressions before they ship. It is also useful for in-depth analysis and can surface additional performance metrics, but it does not replace field data when you need to know what your audience experiences.

The two disagree regularly, and the disagreement is not a malfunction. A Lighthouse score of 95 alongside a failing field assessment usually means your audience is slower than your test environment. That is information, not an error.

Use each for what it does best. Lab data belongs in development, where it catches problems early and gives a repeatable number to work against. Field data belongs in monitoring, where it tells you whether the work made a difference to anyone. One timing caution: Search Console reflects a 28-day rolling window, so a fix deployed today will not be fully visible in field data for several weeks. Teams routinely conclude a change did nothing when they simply measured too early.

How to measure Core Web Vitals

Start with Google Search Console, because the best way to test Core Web Vitals is to begin there: it shows the site’s Core Web Vitals assessment from Google’s field data. The Core Web Vitals report groups your URLs into good, needs improvement and poor, organized by URL group rather than individual page, which tells you which templates are failing rather than which pages.

Use PageSpeed Insights as a free tool for checking individual web pages. It shows field data from the Chrome User Experience Report alongside a Lighthouse lab run for the same URL, with separate results for mobile and desktop devices, which makes it the quickest way to see whether a problem is real or an artifact of test conditions. If a URL has too little traffic to collect field data, PageSpeed Insights returns lab results only, and you should treat those as a hypothesis rather than a measurement. For a walkthrough of the tool, read how to boost your site speed with Google PageSpeed Insights.

Use Chrome DevTools when you need to find the cause, not just confirm the symptom. The Web Vitals Chrome extension can give you instant feedback while browsing, before you move into deeper debugging. The Performance panel shows the specific LCP element, the tasks blocking the main thread, and the exact frames where layout shifted.

Use real user monitoring when you need segmentation. Site owners can use it to spot Core Web Vitals issues and monitor Google Core Web Vitals metrics across the site, and a platform built on the web-vitals JavaScript library will break Core Web Vitals metrics down by geography, device category and traffic source, which matters when a single underperforming segment is dragging your 75th percentile below the threshold.

For the wider set of diagnostic metrics sitting behind the three Core Web Vitals, including Time to First Byte and Total Blocking Time, read the website performance metrics that matter.

Where to start: how to prioritize the work

Start with the template, not the page. Because Google assesses URL groups rather than individual URLs, the unit of work is the template and the components inside it. A hero component with a poorly sized image affects every page using it, and fixing it once moves the assessment for the whole group. Auditing page by page produces a long list and very little movement.

Rank templates by business value rather than traffic alone. Our order is: templates with a conversion action first, then templates prospects read before converting, then everything else. In practice, that means contact and quote pages, then service pages and case studies, then the blog. A high-traffic article with no commercial role is rarely the right place to spend engineering time first.

Attack the cheapest failing metric first. Cumulative Layout Shift is usually the fastest to fix because the causes are structural and the remedies are well defined: size your images, reserve space for anything injected late, and load fonts predictably. Largest Contentful Paint comes next and often needs infrastructure attention as well as page work. Interaction to Next Paint is usually the most expensive, because it means changing what JavaScript runs and when.

Separate what your marketing team can do from what needs a developer. Compressing and correctly sizing images before upload, removing tracking scripts nobody reads anymore, and simplifying what sits above the fold are content-team decisions that move real numbers. Refactoring JavaScript bundles, changing image delivery formats, introducing server-side rendering and tuning database queries are engineering work with engineering timelines. Mixing the two into one backlog is how performance projects stall.

Finally, set a performance budget and hold it. Agree a target for the weight and script count of your key templates at the start of a project, then check every new component against it before it ships. Performance is far cheaper to protect than to recover, and every site we inherit that fails Core Web Vitals got there one reasonable-sounding addition at a time. Holding that line is central to how we approach website speed optimization on the sites we maintain.

How to improve Core Web Vitals

Most sites fail Core Web Vitals for the same five reasons. Fix them in this order, and you will usually pass all three metrics without a rebuild.

1. Fix server response time first. Every other improvement waits for the first byte. A shared hosting plan, no server-side cache, or an overloaded database puts the page behind before anything loads. Move to managed hosting with page caching and a CDN, keep PHP current, and check that uncached requests return in under 600 ms. On WordPress, a slow plugin query is the usual cause.
2. Deliver images properly. Images are the LCP element on most pages. Serve them in WebP or AVIF at the size the layout displays, not the size they were uploaded. Give the hero image a fixed width and height and load it eagerly; lazy-load everything below the fold. One oversized hero image can add two seconds on mobile on its own.
3. Reserve space for anything that loads late. Layout shift comes from content arriving after the page has drawn: ads, embeds, cookie banners, web fonts and injected forms. Set explicit dimensions on images and iframes, reserve a container for banners and embeds, and use font-display: swap with a fallback font sized to match. If a cookie banner is your largest element, move it out of the initial layout.
4. Cut third-party scripts. Analytics, chat widgets, tag managers and tracking pixels all compete for the main thread and are the most common cause of a failing INP score. Remove any script you do not act on. Load the rest after the page is interactive, and route tags through one tag manager so you can see what fires.
5. Stop CSS and JavaScript from blocking the first paint. The browser cannot draw anything until it has parsed every stylesheet in the head. Inline the CSS the first screen needs, defer the rest, and defer or async every script that is not needed for first render. Remove unused CSS from plugins and the theme.

How to know it worked. Change one thing at a time and measure in field data, not lab scores. PageSpeed Insights shows both; Google ranks on the field section at the top. Lab scores move the same day. Field data takes 28 days to catch up, so check back a month after each change.

How we handle Core Web Vitals at Parachute

We treat performance as a build constraint first and a maintenance commitment after. We specify hero image dimensions and formats during design, not during development. Components reserve space for anything that loads late. Plugin stacks are kept deliberately small, because every plugin is someone else’s JavaScript running on your critical path.

Live sites then drift. A large image gets uploaded, a marketing tag gets added, a plugin update starts loading its stylesheet on pages that have no use for it. None of that is visible from inside the CMS, and none of it announces itself, so every site we support gets a scheduled health check that reads the live page rather than a dashboard: what actually loads, in what order, and what the browser sits waiting on.

A recent health check for Patronscan, an identity verification platform serving venue operators across North America, produced a short and specific list. Image delivery at the CDN. Preloaded files, no template rendered. Form library CSS and JavaScript loading on pages with no form. Duplicate font requests competing with each other. We corrected the delivery configuration on our side, Patronscan’s marketing team handled the tag audit and image formats on theirs, and we re-measured on the same tool and the same URL eleven days apart.

The PageSpeed Insights performance score moved from 54 to 98 on mobile and 63 to 100 on desktop. Those numbers are directional lab indicators for Core Web Vitals scores, not the field assessment Google ranks on. The field result matters: as of September 15, 2026, patronscan.com passes its Core Web Vitals assessment on real user data for both the homepage and the origin, improving the site’s user experience in practice. On the homepage, Largest Contentful Paint sits at 2.3 seconds on mobile and 1.4 seconds on desktop, and Cumulative Layout Shift at 0 and 0.01. Interaction to Next Paint returned insufficient data in the reporting window, which is common on sites where visitors read more than they click. A metric without enough real visits to report is excluded from the assessment rather than counted against you.

The method is deliberately unglamorous. Measure the live page, fix the cause rather than the symptom, re-measure on the same instrument, and report the difference honestly. It is worth being clear about what that buys. This work improves the site’s user experience and, on the paid side, feeds Google’s quality scoring and can lower cost per click. It does not lift organic traffic volume on its own, and we would rather say so up front than let you expect it.

You can see the work in our case studies, and if you want to see where your site stands, get in touch.

---

Jay Eckert, RGD, CDP

Jay is a recognized web design leader having helped some of North America’s most exciting brands maximize their digital marketing.

More from Jay