Core Web Vitals for B2B: a guide for marketing leaders who do not write code

Core Web Vitals are three measurements of how a page feels to a real visitor. You do not need to know how they are calculated. You need to know what each means for a buyer, what good looks like, and who owns it.

Largest Contentful Paint (LCP) is loading: how long until the biggest thing on screen, usually the hero image or headline, has appeared. Interaction to Next Paint (INP) is responsiveness: how long the page takes to react visibly when someone clicks a menu, a tab or a form field. INP replaced First Input Delay as a Core Web Vital in March 2024. Cumulative Layout Shift (CLS) is visual stability: how much the page jumps around while it loads, the moment a visitor goes to click a button and it moves.

Google evaluates each metric at the 75th percentile of page loads, separately for mobile and desktop. A page passes only when all three are good at that percentile. In practice that means three out of four visits must be good, not your own visit on the office network.

Google’s own words are more measured than most vendor articles. Its page experience documentation says Core Web Vitals are used by its ranking systems, and it recommends that site owners achieve good Core Web Vitals for success with Search. It does not say how much weight they carry.

It also sets limits. Google says there is no single page experience signal; its core ranking systems look at a variety of signals that align with overall page experience. It says Search always seeks to show the most relevant content, even if the page experience is sub-par. And it says good results do not guarantee top rankings, and that chasing a perfect score only for SEO may not be the best use of your time.

Our reading for B2B: Core Web Vitals will not rescue a page that does not answer the buyer’s question, but where several pages are equally helpful, a good experience counts. Treat them as hygiene, then spend the rest of the effort on content and offers. Our technical SEO checklist puts them in context with crawling, indexing and schema.

Most published speed research comes from retail, so be careful with borrowed numbers. One study that did look at lead generation is Milliseconds make millions, commissioned by Google and run by 55 and Deloitte across 37 European and American brand sites and more than 30 million user sessions at the end of 2019. When mobile pages got 0.1 seconds faster across the journey, lead generation sites saw progression from the homepage to the first form step rise 5.5%, progression from the first form step to submission rise 21.6%, and page views rise 7%.

That is one study, not a forecast for your site. It does point to where speed hurts a B2B funnel most: the form and the pages just before it, where marketing tends to add chat and tracking scripts.

The wider web is not starting from a strong position either. The HTTP Archive Web Almanac 2025, based on July 2025 Chrome UX Report data, found that 48% of websites had good Core Web Vitals on mobile and 56% on desktop. LCP was the hardest metric, good on 62% of mobile pages, while INP was good on 77% of mobile pages and 97% of desktop pages.

There are two kinds of data, and mixing them up is the most common mistake we see in leadership reviews. Field data is what real Chrome users experienced. Lab data is one simulated test run. Search Console reports the first; developers debug with the second.

• Search Console, Core Web Vitals report: your starting point. It uses Chrome UX Report field data, groups similar URLs, reports mobile and desktop separately and gives each group the status of its worst metric. Only indexed URLs appear.
• PageSpeed Insights, top panel: real-user field data over the previous 28 days, at the 75th percentile. With too little page traffic it falls back to the whole site (the origin), and with too little site traffic it shows no data.
• PageSpeed Insights, lower panel: the Lighthouse lab test on a simulated phone or desktop. The score out of 100 lives here. Google describes lab data as useful for debugging; it can miss what real users hit.
• Chrome UX Report (CrUX): the public dataset behind both tools, also available through CrUX Vis, its API and BigQuery. Pages appear only when they are publicly discoverable and have enough visitors.

So when a vendor shows you a green 100, ask which panel it came from. Our own homepage scored 100 in all four desktop categories on PageSpeed Insights, while the field panel still showed No Data because the site did not yet have enough Chrome traffic to report. We explain what we did and what the score does not prove in how we scored 100 on PageSpeed Insights.

On B2B sites the theme, the CMS and the hosting are rarely the main problem. The weight comes from what marketing added over the years. Images are the LCP element on 76% of mobile pages and 85% of desktop pages in the Web Almanac 2025 data, about 16 to 17% of pages still lazy-load that image, and 62% of mobile pages have at least one image without set dimensions.

Tag managers and chat widgets: web.dev notes that tags get added but are rarely removed, and that it has seen a correlation between the size of tag managers and poorer INP. Give every tag and widget an owner and a reason to exist.

Hero video: for a video, LCP is measured on the poster image or the first frame, whichever comes first, so a light poster keeps the brand moment without the cost.

Consent banners and fonts: web.dev lists injected content such as cookie notices among common causes of layout shift, and notes that swapping from a fallback font to a web font can shift text too. The banner is mandatory in many markets; the shift is not.

You do not need to read a performance trace to hold a team accountable. These questions turn a vague goal into an owned plan.

• What do our field Core Web Vitals look like in Search Console, on mobile and desktop, and which URL groups are poor or need improvement?
• For each poor group, which metric fails and what is the cause on that template?
• Which third-party scripts load on our key pages, who owns each one, and which could load after the page or on interaction?
• Is our hero image or video the LCP element, and is it ever lazy-loaded?
• What performance budget does every release have to meet, and what happens when a change breaks it?
• How will we confirm a fix: a Search Console validation, field data over the next 28 days, or only a lab score?

Be wary of any answer that only quotes a Lighthouse score. Search Console validation of a fix runs for 28 days and passes only if the issue does not reappear on any URL in that window.

This sequence assumes one marketing owner, one developer or agency, and authority to remove tags.

1. Days 1 to 3: export the Search Console report for mobile and desktop and match each poor URL group to a template (homepage, service, article, landing page).
2. Days 4 to 7: run PageSpeed Insights on one URL per failing template and identify the LCP element on each.
3. Days 8 to 12: audit the tag manager and third-party scripts. Remove unused tags, give the rest an owner, and move chat and non-essential tags to after load.
4. Days 13 to 18: fix the hero on each template: compress the image, swap autoplay video for a poster, remove lazy loading and set dimensions on every image.
5. Days 19 to 22: stabilise the layout. Reserve space for the consent banner, trim font files and match fallback fonts.
6. Days 23 to 25: write a performance budget per template and add it to the release checklist.
7. Days 26 to 30: start validation in Search Console and report field trends alongside form progression and pipeline.

Field data trails your fixes, because it covers the previous 28 days of real visits. Expect the report to catch up over the following month, and keep the budget in place so the gains survive the next campaign launch.

We treat speed as part of pipeline work, not a separate engineering project. On our own site, consent defaults to denied, the tag manager and chat scripts load on first interaction or after the page has loaded, and video ships as a poster image only until a visitor presses play. Every pull request is checked against performance, accessibility and SEO budgets before a person approves it.

For clients we build and run the same foundation through our website development service, and we read the results in the CRM, so a faster form is judged by the meetings and opportunities it produces.

If your Search Console report shows poor or needs improvement on the pages that matter for pipeline, talk to our team and we will come back with a plan for your stack.