A B2B website is slow for different reasons than an online store, and the speed advice written for stores mostly doesn’t apply to it. A marketing site has thirty to two hundred pages, few images that matter, and a demo form that is the whole point; what it carries that a store doesn’t is the marketing stack: the form embed, the chat widget, the visitor-identification script, the consent banner, the tag manager with everything inside it, the ad pixels, the heatmap. Eight to twelve third-party scripts on the page where the deal starts. That is where the speed goes, and compressing the hero image doesn’t bring it back.
The second difference is what “fast” has to mean. Google measures Core Web Vitals from real Chrome users, per URL where there’s enough traffic and per group of similar URLs where there isn’t, and a B2B site rarely has enough traffic on any single page except the homepage. In practice B2B website speed exists as three to five numbers, one per template, and the goal is for those templates to pass in field data; a Lighthouse score of 100 is a different thing and nobody is paid for it.
Why B2B website speed matters: four places it shows
The case for speed on a B2B site shows in four places on the site’s own data, and none of them is a conversion curve borrowed from retail. The form page: a demo page whose embed and consent banner render late loses the share of sessions that arrived ready to fill it in, and that share is visible in GA4 as form-page exits before the first field event. The buying committee: six to ten people open the same solution page over several weeks, mostly on corporate networks with an ad blocker and a VPN, and a page that stalls for each of them is read as a product that will too. Rankings: the solution templates compete on commercial queries where failing the vitals is a signal against the page, and on a short list of competing vendors that signal is one of the few that separates them. And the agents behind AI search, which fetch the same templates without rendering them; a slow origin gets fewer fetches, and a page that isn’t fetched isn’t quoted. The business case is those four, measured on the site’s own numbers.
What “fast enough” means for B2B website speed
The thresholds that define B2B website speed are Google’s, and they don’t change for B2B: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, Cumulative Layout Shift under 0.1, each at the 75th percentile of real users over the previous 28 days. INP replaced First Input Delay in March 2024, and a performance brief that still names FID predates that. A page that passes all three is “good,” and Google’s documentation says the page experience signal rewards passing and doesn’t rank a 1.2-second page above a 2.1-second one. Past the threshold, speed stops being an SEO question and becomes a conversion one, and the two shouldn’t be argued with the same numbers.
Lab and field are different measurements, and B2B sites are usually optimized for the wrong one. Lighthouse and PageSpeed Insights’ lab section simulate one load on one throttled device; the field section, drawn from the Chrome User Experience Report, is what actual visitors got. A page can score 95 in the lab and fail LCP in the field because the lab load didn’t wait for the consent banner, didn’t have a returning visitor’s chat widget restore its state, and ran on a connection the sales director’s hotel Wi-Fi doesn’t resemble. The field number is the one that ranks and the one that converts. The lab number is for finding out why.
Which pages Google measures on a B2B site
CrUX reports a URL only when it has enough traffic in the period, and most B2B URLs don’t, which is why B2B website speed is a handful of group numbers and not a page-by-page score. For the rest, PageSpeed Insights falls back to origin-level data, which is the whole site averaged, and Search Console’s Core Web Vitals report groups URLs by template and reports the group. A site with 120 pages therefore has field data for the homepage, maybe the pricing page, and then for three or four groups: solution pages, blog posts, case studies, the demo or contact page. Those groups are the unit of work. A fix on a single blog post changes nothing Google can see; a fix in the blog template changes a group.
The order of the groups is by distance to the pipeline, which on a B2B site is short: the demo and pricing pages first, because that’s where the form is and where the heaviest scripts are loaded; solution and product pages second, because they rank for commercial queries and carry the proof blocks; the homepage, which usually has the traffic to be reported on its own; then the blog, which has the most pages and the lightest template. Case study pages are typically the slowest template on the site, because each one embeds a video, a logo wall and three screenshots, and they are also the ones that matter least to measure first.
What slows a B2B marketing site
The scripts, grouped by what they do and which metric they hit. This table is what I fill in first on a B2B website speed review, and the owners are the point of it: INP fails on the sum of these, and every team says the slow one wasn’t theirs.
| What’s on the page | What it does to the metrics | Owner | What to do |
|---|---|---|---|
| Form embed (HubSpot, Marketo, Pardot) | Loads its own JavaScript and styles before the form renders; CLS when the form appears late and pushes content down | Marketing ops | Reserve the form’s height; load the embed on the pages that have a form, not site-wide |
| Chat widget (Drift, Intercom, HubSpot chat) | Among the heaviest single scripts on the site; main-thread work at load, INP when it initializes during the first interaction | Sales / marketing ops | Load on first interaction or after the page is idle, behind a static placeholder button (the façade pattern) |
| Visitor identification (Clearbit, 6sense, Demandbase, ZoomInfo) | Network requests and script execution on every page view, on pages where nobody fills anything in | Sales ops | Defer until after load; restrict to the pages where the data is used |
| Consent manager | Blocks every other tag until it decides, then fires them all at once; the banner itself is often the LCP element or a CLS source | Legal / marketing ops | Size the banner so it doesn’t shift the layout; make sure it doesn’t delay the hero |
| Tag manager with everything inside | One request, then twenty: GA4, ads, LinkedIn Insight, Meta, remarketing, A/B testing, each a script | Marketing ops | An inventory with a reason per tag; remove the ones nobody can name a report for; move what can move to server-side tagging |
| A/B testing tool | Hides the page until the variant is decided, which delays LCP on every visit for everyone, including the 95% not in a test | Growth | Load it only on pages with a live test; remove the anti-flicker snippet when nothing is running |
| Heatmap and session recording | Continuous main-thread work while the user scrolls and types; INP | Product marketing | Sample, don’t record everyone; turn off when the study is over |
| Video embeds and hero animation | A YouTube or Vimeo iframe loads a player before anyone presses play; a Lottie or background video competes with the LCP element | Design | Poster image with a click-to-load player; animation after the first paint, never as the hero |
| Web fonts | Two families, four weights each, from a third-party host; text invisible or swapping late (CLS) | Design | Self-host, subset, preload the one used above the fold, font-display: swap with matched fallback metrics |
| The CMS and its page builder | WordPress with a visual builder ships every component’s CSS and JavaScript on every page; HubSpot CMS and Webflow ship less but add their own tracking | Development | Per-template asset loading; a design system of components instead of a builder (Step 4 of the B2B website redesign guide) |
Images are on this list only as the hero. The one LCP failure that is a build mistake rather than a stack decision is loading="lazy" on the hero image, which tells the browser to defer the one element the metric measures; the hero gets fetchpriority="high" and nothing else on the page needs special handling beyond dimensions and a modern format. The full image and mobile list is in the mobile SEO checklist, and on a B2B site it’s an afternoon of work. The stack is the quarter.
Desktop and mobile: two numbers with two jobs
Speed guides say mobile first, and for indexing that’s right, though B2B website speed is the one case where I read the desktop column first: since the mobile-first cutover completed in July 2024, Googlebot Smartphone is what fetches and indexes the page, and the mobile Core Web Vitals are what the page experience signal reads for mobile results. The desktop numbers feed desktop results separately. A B2B site’s traffic splits differently from a store’s: commercial queries and demo requests arrive during business hours from a desktop browser on a corporate network, often with an ad blocker, while the blog gets read on phones in the evening. Both sets of numbers exist in CrUX and both appear in the Core Web Vitals report, and they fail for different reasons: mobile LCP fails on the connection and the device, desktop INP fails on the stack, because the desktop page has every widget enabled and the user is actually interacting with the form.
The practical split: the mobile numbers are the SEO floor for every template, and the desktop numbers on the demo, pricing and solution templates are the conversion work. A pricing page that passes on mobile and has a 400-millisecond INP on desktop is passing the test that doesn’t matter for it.
The fix order for B2B website speed
Not image compression first, which is where the generic guides start and where a B2B site has the least to gain. I count the third-party requests on the demo page before I open PageSpeed Insights, because the count usually explains the score.
- Inventory the stack. Every third-party request on the demo page, with the tag it came from, the team that owns it and the report it feeds. The Network panel or WebPageTest’s request map gives the list in ten minutes. Anything without an owner comes out that week.
- Set a third-party budget per template and give it an owner, because without one, every new tool gets added by whoever has tag-manager access and the number only grows. The budget is a line in the definition of done, alongside the other rows in the acceptance table from the web development and SEO guide.
- Defer what can be deferred. Chat, identification, heatmaps and A/B tooling load after the page is interactive or on first interaction; nothing in that group needs to be present before the hero paints.
- LCP on the five templates. Hero in the server HTML, no lazy-loading on it, fonts preloaded, the consent banner sized. Server response under 800 milliseconds, which on a marketing site is a caching question, since none of the pages are personalized until the form.
- CDN and caching last, because they’re usually already there and because they don’t touch the stack, which is the problem.
Measuring B2B website speed without fooling yourself
Search Console’s Core Web Vitals report for the groups and the trend; PageSpeed Insights with the field tab open for a specific URL; the CrUX dashboard in Looker Studio for the origin over time; and, if the site has the traffic for it, a real-user monitoring script, which is the one third-party addition this article recommends, because it is the only way to see the numbers by page, by device and by hour. Business hours matter: a site measured at night on a developer’s connection passes; the same site at 10 a.m. on Tuesday with the sales team’s own tools loaded in every visitor’s browser is the one prospects see.
After a change, the field data takes 28 days to turn over fully, so the first honest read of a fix is a month out. Lab testing confirms the mechanism moved the same day; it doesn’t confirm the metric.
The B2B website speed benchmarks that circulate, and what they’re worth
Every page ranking for this query carries a number, and the numbers deserve dates before they go into a deck.
| The figure | Where it comes from | What it measures |
|---|---|---|
| “B2B sites average a 7.05-second mobile LCP” | A Searchmetrics study of about two million URLs, published in 2021, before INP existed | A five-year-old average across industries’ top results, on devices and networks that have moved since |
| “100 ms costs 1% of sales” / “half a second costs 20% of traffic” | Amazon and Google experiments from 2006–2009, retold | Retail and web search at a scale and session shape a marketing site doesn’t have |
| “About half of all sites pass Core Web Vitals” | HTTP Archive and CrUX, updated monthly | The share of all origins with enough Chrome traffic to be measured, every industry mixed; the one number here that is current, and it says nothing about B2B specifically |
| Vendor pass-rate reports by vertical | Agencies’ own crawls, usually of a few hundred sites, often undated | Whatever sample the agency picked; read the method before the percentage |
I don’t have a B2B website speed benchmark from field data that I’d quote, and I haven’t found one built on current CrUX data by anyone who shows the sample. The replacement takes fifteen minutes: the CrUX API, or PageSpeed Insights’ field tab, run against the origins of the eight or ten vendors a buyer would shortlist alongside you. That gives mobile and desktop LCP, INP and CLS for the competitive set at the 75th percentile, this month, and it is the only benchmark that answers the question a B2B site is asking, which is not “how fast is the web” but “how fast are the sites the buyer opens in the next tab.”
Speed and the pipeline: what can be claimed
The studies quoted in every speed article, Amazon’s 100 milliseconds, Google’s half-second, Walmart’s conversion curve, are about retail at a scale and a session shape a B2B site doesn’t have. A buyer who has read three solution pages and a case study is not abandoning the demo form because it took 2.8 seconds instead of 2.4. What slow pages cost a B2B site I measure on two things: the share of sessions that reach the form page and bounce before the form renders, which is the form-embed and consent problem from the table, and the rankings of the solution templates on commercial queries, where failing the threshold is a signal against the page. Both can be measured on the site’s own data: form-page conversion bucketed by LCP in the RUM tool or GA4, and the Core Web Vitals report read next to the Performance report for the same template. Those numbers belong in the business case; someone else’s retail curve doesn’t.
B2B website speed FAQ
What is a good page speed for a B2B website?
Passing Core Web Vitals in field data on each template: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1 at the 75th percentile. There is no separate B2B threshold, and there is no ranking bonus for going well past the line.
Does website speed affect B2B SEO?
Yes, as a threshold. Pages that fail the vitals carry a weaker page experience signal in the results, mobile and desktop measured separately; pages that pass are treated alike. The larger SEO effect on a B2B site is indirect: a slow solution template gets crawled less and tested less, and the fix for both is the same.
Why is my B2B site slow when the images are optimized?
The stack. Count the third-party requests on the demo page; on most B2B sites the chat widget, the form embed, the consent manager and the tag manager’s contents together outweigh every image on the page, and they load before the hero does.
Is a high Lighthouse score enough?
No. Lighthouse is one simulated load with no consent banner, no returning visitor’s chat state and no corporate network in the way; it tells you which mechanism to fix, and the field data in the Core Web Vitals report tells you whether the fix landed. A template at 95 in Lighthouse and failing LCP in the field is common on B2B sites, and the field number is the one that counts.
How often should B2B website speed be checked?
The field data turns over every 28 days, so a monthly read of the Core Web Vitals report per group is the floor. The event that should trigger a check between reads is a change in the tag manager, because that is where B2B sites get slower without a deploy: a new tool added by whoever had access, with no owner and no budget line.