Three seconds is not a design target, it is a commercial threshold. Past it, a measurable share of your visitors leave before they have seen anything you paid for. This is the exact sequence we follow on every project to get a business website under that line — and to keep it there a year later.
Why three seconds decides the outcome
Nobody sits with a stopwatch. What actually happens is quieter: a person taps your link from a map result while walking, the screen stays white for a moment too long, and they go back and tap the next restaurant. They will never know they abandoned you, and you will never see it in your inbox. It appears in your analytics only as traffic that did not convert.
The numbers behind that behaviour are consistent across every study published in the last decade. Bounce probability roughly doubles between one and three seconds of load time, and roughly triples by five seconds. On mobile connections — which is where the majority of local business traffic arrives — the effect is stronger, because the person is usually doing something else at the same time.
There is a second, slower penalty. Search engines use loading experience as a ranking signal. It is not the dominant one, but it is a tie-breaker, and local search results are frequently decided by tie-breakers. A slow site loses twice: fewer visitors arrive, and fewer of those who arrive stay.
One client's old site took nine seconds to become usable on a phone. After the rebuild it was 2.1 seconds. Nothing else changed — same texts, same photos, same offer. Enquiries from mobile went up by roughly a third within two months.
Measure first, and measure the right thing
Optimising without measuring is decorating. Before touching anything, get two kinds of data: lab numbers from a controlled test, and field numbers from real visitors on real devices.
The three metrics that matter are the Core Web Vitals, and each of them describes a different kind of annoyance:
| Metric | What the visitor feels | Good | Needs work |
|---|---|---|---|
| LCP — Largest Contentful Paint | How long until the main thing on screen appears | ≤ 2.5 s | > 4.0 s |
| INP — Interaction to Next Paint | How long the page takes to answer a tap | ≤ 200 ms | > 500 ms |
| CLS — Cumulative Layout Shift | Whether the page jumps while they are reading | ≤ 0.1 | > 0.25 |
| TTFB — Time to First Byte | How long the server thinks before answering | ≤ 0.6 s | > 1.2 s |
Two practical rules save an enormous amount of wasted effort. First, always test on a throttled mobile profile, not on your office desktop with fibre — your desktop score is the least representative number you will ever collect. Second, test the pages people actually land on. A homepage scoring well while the menu page scores poorly is a very common and very expensive pattern.
A five-minute baseline
Run a mobile audit on your three most visited pages, note the LCP, and screenshot the result. That screenshot is the only proof you will have later that the work was worth paying for.
Set a performance budget before you design
A performance budget is a number everybody agrees to before there is anything to argue about. Ours, for a typical business website, looks like this:
- Total page weight: under 1 MB on first load, images included
- JavaScript: under 150 KB compressed, and none of it blocking the first paint
- Fonts: at most two families, at most four weights, served from our own domain
- Requests: under 40 on the first view
- Third-party scripts: zero by default; each one added must be justified in writing
The value of a budget is not the number itself, it is that it forces a conversation at the right moment. When somebody asks for a full-screen video hero halfway through the build, the answer is not "no" — it is "that costs 4 MB and about 1.8 seconds of LCP, what shall we take out to pay for it?" That question is answerable. "Do you like this?" is not.
Images: where almost all the weight hides
On a typical small business website, images account for between sixty and eighty per cent of the bytes. Fix them and you have usually fixed the site. There are four separate problems, and doing only one of them is why so many "optimised" sites are still slow.
1. Serve the right dimensions
A photo displayed at 600 pixels wide should not be a 4032-pixel file straight from a phone camera. This single mistake is responsible for more slow websites than every other cause combined. Resize to roughly twice the largest displayed size to cover high-density screens, and no further.
2. Use a modern format
| Format | Typical saving vs JPEG | Use it for |
|---|---|---|
| WebP | 25–35% | Almost everything; universally supported today |
| AVIF | 40–55% | Large hero photographs, with a WebP fallback |
| SVG | 90%+ | Logos, icons, diagrams, maps — anything vector |
| JPEG (quality 78–82) | baseline | Fallback, and photos where compatibility matters most |
3. Let the browser choose
Responsive images let a phone download a phone-sized file while a desktop gets a larger one. It is a handful of extra attributes and it routinely halves mobile page weight:
<img src="dish-800.jpg" srcset="dish-480.jpg 480w, dish-800.jpg 800w, dish-1600.jpg 1600w" sizes="(max-width: 700px) 100vw, 700px" width="800" height="500" alt="…">
4. Always declare width and height
Missing dimensions are the number one cause of layout shift. The browser cannot reserve space for something whose size it does not know, so text jumps down the moment the image arrives — usually just as the visitor starts reading, and occasionally just as they tap something.
Lazy-loading, with one exception
Add loading="lazy" to every image below the fold, and never to the one at the top. Lazy-loading your hero image delays the very thing LCP measures, which makes the score worse while feeling like optimisation.
Fonts without the flash and the delay
Web fonts are the second-largest source of avoidable delay, and the most common source of that unpleasant moment where text appears, disappears, and reappears in a different shape.
- Host them yourself. A third-party font service adds a DNS lookup, a TLS handshake and a round trip before a single letter is drawn. Serving the files from your own domain removes all three.
- Use WOFF2 only. Every browser in current use supports it, and it is roughly thirty per cent smaller than WOFF.
- Subset aggressively. If your site is in English and Spanish, you do not need Cyrillic, Greek or Vietnamese glyphs. Subsetting typically cuts a font file in half.
- Limit the weights. Each weight is a separate file. Four total across the whole site is plenty; most designs genuinely need three.
- Set
font-display: swap. Text renders immediately in a fallback and switches when the web font arrives. Visitors can read during the swap, which is the entire point. - Preload the one that matters. Preload only the font used in your headline. Preloading everything is the same as preloading nothing.
Code, scripts and the third parties nobody remembers adding
The heaviest thing on most small business websites is not the design — it is the accumulated layer of tools that somebody added for a campaign in 2021 and nobody removed.
Open the network panel on your own site and count the domains it contacts. A chat widget, two analytics tools, a heatmap recorder, a cookie banner service, a review widget and a social feed is a very ordinary list, and together they routinely add 800 KB and two seconds. Each one also introduces a dependency: when their server has a bad day, so does your website.
- Audit every third-party script and delete anything that has not been looked at in three months
- Load what survives with
defer, never blocking the first paint - Load heavy widgets only on the page that needs them, not site-wide
- Replace a hosted map iframe with a static image plus a link where a live map is not essential
- Prefer a small hand-written component over a 90 KB library for a single slider
- Inline the critical CSS for the top of the page and load the rest normally
The fastest script is the one you did not include. The second fastest is the one that runs after the page is already usable.
Server, caching and delivery
Once the page itself is lean, the remaining seconds live on the server side. These are the changes with the best ratio of effort to result:
| Change | Typical gain | Effort |
|---|---|---|
| Enable Brotli compression | 15–25% smaller text assets | Minutes |
| Long cache headers on static assets | Near-instant repeat visits | Minutes |
| HTTP/2 or HTTP/3 | Faster on high-latency mobile | Usually a provider setting |
| CDN in front of the origin | 200–600 ms for distant visitors | An hour |
| Server close to your customers | 50–300 ms of TTFB | Choose at setup |
| Static output instead of per-request rendering | 0.3–1.5 s of TTFB | Architectural |
That last row deserves emphasis. A restaurant menu does not change between visitors, so there is no reason to rebuild it from a database on every request. Serving pre-built files is why a well-built brochure site can answer in under 200 milliseconds on hosting that costs less than a coffee per month.
Verify, then stop it from creeping back
Speed is not a project, it is a property that decays. Every new photograph, every added widget, every "small" change moves the number. Three habits keep it stable:
- Re-measure after every content update — especially after somebody uploads photos directly
- Watch field data monthly, not lab data. Real visitors on real devices are the only score that pays you
- Keep the budget visible. Written into the maintenance agreement, it survives staff changes
And keep the perspective right. A site that loads in 1.4 seconds instead of 2.1 is not twice as good; you have already collected the meaningful win. The gap that costs money is the one between three seconds and eight — that is where the visitors are lost, and that is the gap most business websites are still sitting in.
Questions people ask about this
Aim for the largest element on screen to appear within 2.5 seconds on a mid-range phone using a normal mobile connection. Under 2 seconds is comfortable; over 4 seconds you are losing a measurable share of visitors before they see anything.
Yes, but as a tie-breaker rather than a primary factor. Loading experience is one of the signals used to order results, so between two similarly relevant pages the faster one tends to win. The larger commercial effect is behavioural: fast pages keep the visitors that slow pages lose.
Oversized images. On most small business sites, photos uploaded at full camera resolution account for the majority of the page weight. Resizing and converting them to WebP or AVIF frequently halves the load time on its own.
Usually not, if your hosting is physically close to your customers. A CDN earns its place when visitors are spread across countries or continents, or when the site serves a lot of large media.
It can, but it takes discipline: a lightweight theme, very few plugins, page caching, and a build process that produces static output where possible. The common failure is not the platform itself, it is a page builder plus thirty plugins each adding their own stylesheet and script.
The short version
- Measure on a throttled mobile profile before changing anything, and keep the screenshot
- Agree a page-weight budget before design starts, and price every exception against it
- Resize, convert and lazy-load images — but never lazy-load the hero
- Host fonts yourself in WOFF2, subset, three or four weights maximum
- Delete third-party scripts nobody has looked at in three months
- Serve pre-built static pages with compression and long cache headers
- Re-measure after every content update; speed decays quietly
