All guides

Site speed and revenue: what the field data shows

Development7 min read

Vodafone ran an experiment on their own site and published the numbers. They improved Largest Contentful Paint by 31%, taking it from 8.3 seconds to 5.7. Sales went up 8%. Their lead-to-visit rate improved 15% and cart-to-visit 11%.

Worth noting what that is not. It is not a page going from slow to fast. Even after the work, 5.7 seconds sits well outside Google’s 2.5-second threshold for a good LCP. An 8% revenue gain came from making a slow page slightly less slow.

Lab scores and field data are different things

Run Lighthouse and you get a lab result: one simulated load, on a simulated device, on a simulated connection, from wherever your machine happens to be. It is repeatable, which makes it useful for catching regressions, and it tells you almost nothing about what your actual visitors experience.

Field data comes from real browsers. Google’s Chrome User Experience Report collects Core Web Vitals from real Chrome users and publishes it per origin, so you can look up your own site and your competitors without either party installing anything. That is the number Google uses, and it is the one worth reporting internally.

The two disagree constantly. A site scoring 95 in Lighthouse can fail Core Web Vitals in the field because half its traffic is on mid-range Android phones on congested mobile networks, which is a device profile almost nobody tests on.

INP changed which sites get punished

In March 2024 Interaction to Next Paint replaced First Input Delay as a Core Web Vitals metric, and that swap mattered more than the name suggests.

FID measured only the delay before the browser started processing the first interaction. A page could be carrying an enormous JavaScript payload and still score well, because the browser registered the tap quickly even if nothing visible happened for another second and a half.

INP measures the whole path from interaction to the next painted frame, across every interaction in the visit rather than just the first. Long tasks on the main thread now show up directly. Since parsing and executing JavaScript is the most common source of long tasks, sites carrying heavy client-side frameworks for largely static content took a measurable hit.

Field data from WebVitals.tools in April 2026, built from CrUX mobile data, puts Astro at an 84% pass rate against SvelteKit at 75%, Next.js at 68%, Nuxt at 60% and Gatsby at 53%. The global pass rate across all origins sat around 56%.

Framework choice is a minority of the problem

The same analysis makes a point that most framework advocacy leaves out. Framework choice accounts for roughly the bottom ten percentage points of a site’s Core Web Vitals pass rate. Hosting and image handling account for most of the rest.

So a rebuild is rarely the first move. We wrote about why Astro suits content sites in why Astro is a great framework for simple content sites, and everything there still holds, but swapping frameworks to fix performance is expensive surgery for a problem that is usually cheaper elsewhere.

Where the time actually goes

Images first, nearly always. An uncompressed hero image is frequently larger than every other asset on the page combined, and it is usually the LCP element, which means it directly determines the metric. Serve modern formats, size them to the space they occupy, and set width and height attributes so the browser reserves the space and avoids a layout shift.

Fonts second. A web font loaded without a display strategy blocks text rendering while it downloads. Set font-display: swap, preconnect to the font host, and consider whether you need four weights when two would do.

Third-party scripts third. Every tag manager container, chat widget, heatmap tool and pixel runs on the same main thread as your page. Audit what is loading. Most sites accumulate scripts for tools nobody has opened in a year, and each one competes with your content for the same thread that INP measures.

Server response time underneath all of it. If the HTML takes 800ms to arrive, nothing you do in the browser recovers that.

Connect it to money before you ask for budget

Performance work gets deprioritised because it is presented as a technical score rather than a business number. Reframe it.

Take your conversion rate and your traffic, then model what a percentage point of improvement is worth in revenue over a year. Compare against the days of engineering time the work needs. That comparison usually makes the decision obvious, and it survives contact with a finance conversation in a way that “our Lighthouse score is 62” does not.

Paid traffic sharpens this further, because there you are paying for every visitor who abandons a slow page before it renders. We covered that connection in where Google Ads budget leaks.

Start here

Look your own origin up in the CrUX data and write down the three numbers. Run the same lookup for two competitors. Then open your heaviest landing page on a real mid-range phone over mobile data, not on your laptop over office wifi, and time it.

That gives you a baseline that is real, a comparison that is fair, and a felt sense of the problem that no dashboard provides. The fixes follow from there, and the first one is nearly always an image.

If you would rather someone else did the measuring and the fixing, that is development work we do regularly. Get in touch.

References