Skip to main content
Backendly
Start
RESEARCHPERFORMANCE ENGINEERING

A field guide to B2B website performance: what to measure and what usually breaks it

Performance advice for B2B sites tends to be either abstract ("be fast") or tool output without interpretation. This guide takes the middle path: what the Core Web Vitals actually measure, the thresholds the industry publicly publishes, and the patterns we repeatedly find when auditing business websites — plus an audit order that works.

Saif Al-Islam TirabFOUNDER & FULL-STACK ENGINEER · BACKEND.LY

PUBLISHED · UPDATED · 4 MIN READ

performanceCore Web Vitalsauditing
REQUEST AN ENGINEERING ASSESSMENT
ON THIS PAGE — 5 SECTIONS
  1. What the three numbers actually mean
  2. Why B2B sites, specifically, get slow
  3. The audit order that works
  4. Performance as a commercial argument
  5. Where engineering help pays for itself

What the three numbers actually mean

Google publishes and openly documents the Core Web Vitals thresholds; we attribute them here rather than pretending they are our opinion:

  • Largest Contentful Paint (LCP) — when the largest content element becomes visible. The public threshold for a good experience is 2.5 seconds or faster; values above 4.0 seconds are poor.
  • Interaction to Next Paint (INP) — responsiveness: how quickly the page reacts to clicks, taps and keys. Good is 200 milliseconds or less; above 500 milliseconds is poor.
  • Cumulative Layout Shift (CLS) — visual stability: how much the page jumps while loading. Good is 0.1 or less.

Two measurement realities matter as much as the thresholds. First, field data (real users) is what search systems act on; lab tests are for diagnosis. Second, the numbers are per-page — a brilliant homepage does not excuse a checkout that measures three times worse.

Why B2B sites, specifically, get slow

After enough audits, the same suspects keep appearing. Not frameworks, not servers — accumulation:

1. Marketing and tracking scripts. Tag managers accreting tags from campaigns long ended, chat widgets loading on every page, heatmaps, A/B snippets, session recorders — each individually justified, together often the single largest JavaScript payload on the page. Scripts also hurt INP directly: every tag competes for the main thread while a buyer tries to click.

2. Oversized, undimensioned media. Hero videos nobody trimmed, PNGs where photos should be WebP/AVIF, desktop images served to phones, images without width and height (which also produces layout shift). Media is the cheapest category to fix and frequently the largest payload on the page.

3. Theme and page-builder bloat. Multipurpose themes ship every feature to every page: sliders, font loaders, icon sets, animation libraries — much of it disabled but still downloaded. B2B sites inherit this from their theme choice years earlier and live with it forever.

4. Uncontrolled embedding. Third-party iframes — forms, calendars, videos — each a separate document with its own cost. Some are worth it; most are unmeasured.

5. Hosting that was adequate at launch. Traffic grew, the plan did not. Cache headers unconfigured, no CDN, TLS handshakes doing avoidable work. Infrastructure reality caps what front-end fixes can achieve.

The audit order that works

Performance work fails when it is done as a list of generic tips. It works when done as diagnosis — evidence before treatment:

  1. Baseline, in the field. Whatever analytics you have, plus lab tooling (Lighthouse, WebPageTest) on the five pages that matter: home, top landing pages, product/service page, and the conversion step.
  2. Inventory the third parties. List every script and iframe, which page loads it, what it costs, and who owns it. This list alone usually explains the majority of the gap.
  3. Weight the media. Payload per page, image formats, lazy-loading, dimensions. Fix the top offenders first; the tail rarely matters.
  4. Cut the main-thread competition. Remove or defer scripts; keep the tags that earn their cost, drop the rest. INP responds to this faster than to anything else.
  5. Fix layout stability — explicit dimensions, reserved space for embeds and ads, no late-arriving banners pushing content.
  6. Then the platform — caching, CDN, server response — once the payload and scripts are honest.
  7. Re-measure and set a budget. A performance budget is a rule ("no new script without removing one; page weight stays under X") that keeps the site fast after the audit ends. Without a budget, entropy wins within a year.

Performance as a commercial argument

The connection to revenue is direct even when the metrics feel abstract. Slow pages leak paid traffic before the message loads. Layout shift makes forms feel untrustworthy at the exact moment of commitment. Poor INP makes navigation feel broken on mid-range phones — which is what much of the world, including B2B buyers on the move, actually uses.

None of this requires believing a specific conversion statistic. It requires only noticing your own behavior on a slow site: you leave.

Where engineering help pays for itself

Most of the list above is diagnosable by anyone patient with tooling. What engineers add is judgment: which third parties can be safely removed, how to restructure media pipelines without breaking editorial workflows, how to enforce the budget in the build system so it survives staff changes. If the audit list found more than you want to take on alone, a structured performance assessment is a reasonable next step — measurement, findings, fixes, re-verification, in that order.

All insights