A site that takes ten seconds to appear does not lose a few percentage points of conversion: it loses most of them. The relationship between load time and conversion rate is not linear, it collapses in steps.
Core Web Vitals are no longer a technical metric reserved for your developers. They are commercial indicators, and what follows sets out where your site stands, what to measure, and a four-week plan to act on it.
The 2025 figures that change the game
The most important point, and the least well understood: the relationship between load time and conversion is not linear, it is exponential. A second lost does not cost the same depending on where you sit on the curve.
Under three seconds, each additional second costs a moderate share of conversion. Beyond five, the penalty per second becomes far heavier. Put differently: going from 9 to 8 seconds gains you more than going from 2 to 1, but only the second threshold puts you level with your faster competitors.
The order of magnitude worth remembering: on the sites I audit, the gap between an eight-second load and a two-second load is not a few percentage points of conversion, it is a multiple. It is the only acquisition lever that costs nothing in extra media budget.
One further dimension arrived in March 2024: Interaction to Next Paint (INP) replaced FID. It measures the lag felt on a click, not just on first contact. A site that paints fast but responds slowly still fails on what the user perceives.
Where your site stands against the competition
The gaps between sectors are wide. Fintech sites and SaaS platforms, where speed is part of the product argument, often sit around two seconds of LCP. Industrial and professional services sites are frequently twice as slow, because nobody has ever measured them.
If you are in industry or professional services with a 3-second LCP, you are already above your sector's median. You still sit behind the handful of players under 2 seconds, and that gap is paid for on the visitors who arrive from search.
Hosting location matters too. Many French and Belgian B2B sites show a Time to First Byte well above standard, simply because the server answers from a single location with no delivery network in front of it. That is an infrastructure fix, not a code one.
B2B Core Web Vitals also show that mobile is the new battleground. A majority of B2B traffic now arrives from a mobile device, and that is precisely where sites least often clear the "Good" Core Web Vitals thresholds. The gap between your mobile score and your desktop score is the first place to look.
The trap to avoid: optimising the wrong metrics
Many sites focus on "page fully loaded" as measured by GTmetrix or Pingdom. Big mistake. This metric counts the loading of every pixel, every tracking script, every third-party widget.
But the user does not care. They want to see the main content quickly (LCP) and be able to click without lag (INP). A site with a "fully loaded" time above ten seconds can have an LCP under 2.5 seconds and convert perfectly well.
If you spend 3 months optimising for a perfect score on generic tools, you may be optimising for elements invisible to the user. Core Web Vitals measure the actual perceived experience, not technical perfection.
The second trap: neglecting Cumulative Layout Shift (CLS). It is the "forgotten" metric because it does not directly affect speed. Yet a page whose layout moves during loading pushes the click-through rate on action buttons down sharply, for a mechanical reason.
In practical terms: your "Request a demo" button shifts when a cookie banner appears. The user clicks beside it, tries again, or gives up. Google measures this and factors it into how it assesses the page.
The domino effect across your entire funnel
The effect does not stop at the landing page. Visitors who see a fast page place greater trust in the rest of the process: they fill in more optional fields, they read more documentation, and they come back more readily.
Visitors who see a fast page place greater trust in the rest of the process. They fill in more optional form fields. They view more documentation pages. The entire experience becomes smoother.
Load time doesn't just affect the first page. It shapes the perception of reliability for your entire offering. A slow B2B site signals a company that could be slow to respond, deliver, and support.
The effect compounds in B2B. On a decision cycle where a visitor returns several times before converting, every micro-friction repeats on every visit. A slow site loses twice: on the immediate conversion, and on the odds the visitor comes back at all.
The 4-week action plan
Week 1: Measure the current state
Set up Google Search Console and PageSpeed Insights on your 10 most critical pages: homepage, main product/service pages, campaign landing pages, contact form. Collect real user data (RUM data), not lab tests.
Identify your current LCP, INP, and CLS. Note the specific elements flagged: unoptimised images, render-blocking JavaScript, heavy third-party scripts. Establish a quantified baseline of current conversion rates on these pages.
Week 2: Quick wins
Compress your images to WebP or AVIF: it is almost always the fastest LCP gain available. Enable browser caching on all static assets. Move analytics and tracking scripts to the end of body with defer or async.
These three actions take two days of dev time and typically deliver most of the LCP gain available without a rebuild. That's the best effort-to-result ratio. Measure the impact after 5 days of data.
Week 3: Structural optimisations
Audit your Critical Rendering Path. Identify the critical CSS and JS needed for initial render. Inline critical CSS (under 14KB) directly in the HTML. Load the rest deferred.
Implement native lazy loading on all images below the fold. Preload critical resources with <link rel="preload">. These changes require 3 to 5 days of dev depending on your stack's complexity.
Week 4: Adjustments and validation
Test on real mobile devices, not just emulation. Measurements taken in Chrome DevTools emulation are almost always kinder than what a mid-range phone on a mobile network actually experiences. Adjust lazy loading thresholds and loading priorities.
Validate that your INP stays under 200ms on key interactions: menu opening, action button clicks, form submission. Then compare your conversion rates in week 4 against week 1. A one to two-second improvement on LCP usually delivers a visible conversion gain, measured on your own data rather than against a market benchmark.
The tools that truly matter
Google PageSpeed Insights remains the reference because it's the data Google uses for ranking. But you need to understand its two modes: Lab data (simulation) and Field data (real users via CrUX).
Lab data is useful for diagnostics. Field data (when available) is what matters for your business. If you don't have enough traffic to appear in CrUX, use Google Analytics 4 with Web Vitals metrics enabled.
Don't waste time on tools that give you a global score. You want actionable metrics: which file blocks rendering, which image slows the LCP, which script degrades INP.
WebPageTest offers the most granular diagnostics with its detailed waterfall and filmstrip. It's the go-to tool for understanding why your site is slow. Configure it for France/Belgium location and the dominant device type in your Analytics.
Lighthouse CI lets you automate tests with every deployment. You set performance budgets: "LCP must not exceed 2.5s, INP must stay under 200ms". If a commit exceeds them, the deployment is blocked. That's how you maintain performance over time.
The real ROI of speed
The calculation runs on your own numbers, and it fits in four lines. Take your monthly visitors, your current conversion rate, the average value of a customer and your closing rate. Then estimate the conversion gain you expect from the optimisation, cautiously, and compare it with the development cost.
Take a cautious assumption rather than an optimistic one: even a moderate improvement in conversion rate, applied across twelve months of traffic, generally exceeds the cost of a performance project. If it does not with your numbers, your site's problem lies somewhere other than its speed, and that is useful to know.
Speed isn't a technical "nice to have". It's a direct growth lever, and one of the few whose result you can measure on your own numbers, before and after.
