What one second actually costs you

Here is a statistic that should bother anyone selling something online: conversion rates fall from 3.05% at a one-second load to 0.41% at five seconds. That is not a dip. That is losing seven out of every eight sales you were going to make, to nothing but waiting.

The supporting numbers are consistent. Around 53% of mobile visits are abandoned after three seconds. Every extra 100ms of load time costs roughly 1% of conversions. And despite a decade of people saying speed matters, only about half of the mobile web actually passes Core Web Vitals.

Which means speed is still, in 2026, an advantage you can simply buy.

The number that makes it real

Abstract percentages are easy to nod at and ignore. So do the arithmetic on your own business.

A one-second delay is generally measured at about a 7% reduction in conversions. If you turn over $100,000 a month, that one second is roughly $84,000 a year. Most small business sites we're handed are not one second slow. They're four.

The case studies are blunter still. Rakuten 24 improved its Largest Contentful Paint and saw revenue per visitor rise 53%. Vodafone Italy improved LCP by 31% and recorded 8% more sales. These are not redesigns. Nothing about the offer changed. The pages just arrived sooner.

Why most sites are slow

Almost never because of the images, which is what people assume and what most "speed plugins" address.

Sites are slow because of what's underneath:

• Page builders that ship a framework to render a paragraph. A typical builder page loads several hundred kilobytes of JavaScript to display text and a photograph.
• Plugin sprawl. Twenty plugins, each loading its own stylesheet and script on every page, whether the page uses it or not.
• Third-party scripts. Chat widgets, three analytics tools, a heatmap recorder, two pixels. Each one is a request to somebody else's server before your page is usable.
• Render-blocking fonts. A font that must download before any text appears.

You cannot optimise your way out of an architecture that was slow by design. This is the honest reason we hand-code sites in Next.js rather than assembling them: it's not craft for its own sake, it's that the fast version and the cheap-to-build version are different buildings.

What "fast" should mean when you buy it

If you're commissioning a site, "it'll be fast" is not a specification. These are:

Ask for	Why it matters
A Lighthouse score, on mobile, at launch	Desktop scores flatter everyone
Core Web Vitals passing on real traffic	Lab scores and field data diverge
A named budget for third-party scripts	This is where speed goes to die post-launch
Who owns performance after launch	Usually nobody, which is the problem

We put Lighthouse 100 in writing on launch day. That's not a boast — it's a checkable claim, which is the only kind worth making. It's also why our care plans exist: a site that launches fast and is never looked at again will be slow within a year, because someone will add a chat widget.

When this doesn't matter much

If you're a B2B firm whose enquiries come from referrals and a founder's LinkedIn, and your site is a credibility check people spend forty seconds on, shaving 800ms will not change your revenue. Be honest about which business you are. Speed compounds where traffic is large and intent is fragile — e-commerce, paid acquisition, local search. It matters much less where the buyer already trusts you before arriving.

If you're in the first category and you don't know your numbers, run PageSpeed Insights against your own site right now. It takes thirty seconds and the mobile number is usually the one that stings.

---

Sources: Core Web Vitals and conversion statistics 2026 · Page speed and revenue impact 2026 · Website speed statistics, Searchlab