There is a genre of article about website speed that opens with a statistic: a one-second delay costs you 7% of conversions. You will not find one of those here, because the numbers in circulation are mostly repetitions of a handful of studies from specific businesses, at a specific moment, with traffic nothing like yours.
What is worth your attention is less dramatic and much more useful: performance is measurable, the thresholds are published, and a small number of fixes account for most of the improvement on most sites.
What slow actually costs you
Three mechanisms, in rough order of how much they matter to a typical business site.
People leave. A visitor who taps a link from a search result and sees nothing for four seconds does not wait to find out whether your content was good. This is most severe on the pages where you most need it not to be: ad landing pages, where you have paid for the click, and mobile visits over a patchy connection.
Forms and checkouts lose people step by step. A booking flow with four screens, each taking two seconds to respond, feels broken rather than slow. Abandonment in multi-step flows is mostly not caused by the form being long; it is caused by nothing appearing to happen after each submission.
Search engines use it as a signal. Google has documented page experience, including Core Web Vitals, as a ranking consideration — one among many, and secondary to relevance. Its own guidance is explicit that great page experience does not outrank better content. So speed will not rescue a thin page, but between two comparable pages it is a tiebreaker, and it is a tiebreaker you can control.
The honest framing: speed is rarely the reason a business grows. It is often one of several quiet reasons a business grows more slowly than it should.
Core Web Vitals, specifically
Google publishes three metrics with defined thresholds. They are measured on real visits, not in a lab, and assessed at the 75th percentile of your page loads — so you are being judged by the experience of your slower quarter of visitors, which is a reasonable proxy for "people on ordinary phones and ordinary connections".
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| LCP — Largest Contentful Paint | When the main content becomes visible | ≤ 2.5s | > 4.0s |
| INP — Interaction to Next Paint | How quickly the page responds to input | ≤ 200ms | > 500ms |
| CLS — Cumulative Layout Shift | How much the layout jumps while loading | ≤ 0.1 | > 0.25 |
Anything between the two columns is "needs improvement". The definitions and current thresholds are maintained at web.dev/vitals, and the ranking context is in Google's page experience documentation. Check those rather than any article's summary, including this one — the metric set has changed before. INP replaced First Input Delay as the responsiveness metric in 2024.
Two things worth understanding about these three.
LCP is usually an image problem, not a server problem. On most content and marketing pages, the largest element is the hero image or heading. If the image is oversized, loaded late, or hidden behind a render-blocking stylesheet, LCP suffers regardless of how fast your backend is.
CLS is the one that annoys people most and is cheapest to fix. It is the page jumping as you start to read: an image loading and pushing the text down, a web font swapping and reflowing a paragraph, a cookie banner appearing above the content. Almost all of it comes from elements without reserved space.
Lab tools versus real users
Lighthouse and PageSpeed Insights run a simulated load on a simulated device. They are excellent for diagnosis — they will tell you which image is the problem — and poor as a verdict. A lab score moves when nothing real has changed.
What counts is field data: Google's Chrome User Experience Report, visible in the "Discover what your real users are experiencing" section of PageSpeed Insights and in Search Console's Core Web Vitals report. That is what the ranking signal uses, and that is what your customers experienced.
A practical consequence: do not chase 100 in Lighthouse. The last fifteen points routinely cost more effort than the first fifty and frequently do not move the field data at all.
Mobile is the real test
Your site's performance on your own laptop, on office wi-fi, with a warm cache, is not data.
Most business sites now take the majority of their traffic from phones, often mid-range Android devices several years old, on mobile networks. Those devices have a fraction of the processing power of a development machine, which matters enormously for anything JavaScript-heavy: downloading a large bundle is one cost, and parsing and executing it on a slow CPU is a larger one.
Test on a real mid-range phone over mobile data. It is consistently the most informative ten minutes available in a performance review.
The fixes that actually move the numbers
In the order we usually work through them, because the order matters more than the list.
1. Images
Almost always the biggest single win, and almost always the least interesting work.
- Right dimensions. A 4000px photograph displayed in a 600px slot wastes most of its bytes. Serve sizes that match the layout.
- Modern formats. WebP and AVIF are substantially smaller than JPEG at equivalent quality and are supported by every current browser.
srcsetandsizes, so a phone downloads a phone-sized file instead of the desktop one.widthandheighton every image. This is the single most effective CLS fix: the browser reserves the right space before the file arrives, so nothing jumps.loading="lazy"below the fold — and never on the LCP image. Lazy-loading your hero image delays the exact element LCP measures.fetchpriority="high"on the lead image, or a<link rel="preload">, so it starts downloading immediately rather than after the stylesheet.
2. The render-blocking path
Before anything appears, the browser must fetch and parse your CSS. Every stylesheet in
<head> sits on that path.
Keep it to one bundled, minified file; drop the CSS no page uses (framework stylesheets are routinely 80% dead weight); and make sure it is compressed in transit. Check the latter rather than assuming it — a 110KB stylesheet should arrive as roughly 20KB of gzip, and server misconfigurations that break this are more common than you would expect.
Fonts belong here too. Self-host them, preload the one or two weights that appear above the
fold, and use font-display: swap so text renders in a fallback rather than staying
invisible.
3. JavaScript you do not need
This is where the heaviest sites get heavy, and it is mostly third parties: analytics, chat widgets, tag managers, heatmaps, A/B testing tools, social embeds. Each is one line of HTML and a meaningful chunk of main-thread work, and they are the usual cause of poor INP.
Audit what is loaded. Remove what nobody looks at — there is almost always something. Defer what remains until after the page is interactive; analytics in particular does not need to compete with your content for the first two seconds.
4. Caching
Two separate layers, both worth having.
Browser caching for static assets — CSS, JS, images, fonts — with long lifetimes and filenames or query strings that change when the file does, so a returning visitor re-downloads nothing.
Server-side caching for generated pages or expensive queries. For a content site this can be close to total; for an application it needs care, because a cached page served to the wrong logged-in user is a security incident rather than a performance improvement.
MDN's HTTP caching guide is the reference for getting the headers right. If your site is an application rather than a set of pages, caching is one of the places where building custom rather than buying changes what is possible, because you control what is safe to cache.
5. The server and the database
Worth reaching for after the above, because it is usually not the bottleneck on a content page — but decisive on an application.
Slow queries, missing indexes, and the N+1 pattern (one query to fetch a list, then one more for each row) are the common culprits, and they get worse as your data grows, which is why a page that was fine at launch is slow two years later. Measure the actual queries rather than guessing. Then: HTTP/2 or HTTP/3, a current PHP or Node version — runtime upgrades deliver real, free performance improvements, and are a good reason to keep an ageing application current beyond the security one — and a CDN if your visitors are geographically spread.
Mistakes we see repeatedly
- Optimising for the score, not the visitor. Deferring every script including the ones needed to render, to win Lighthouse points, while the real page gets worse.
- Adding a caching plugin to a slow site. It hides the problem on cacheable pages and leaves it on the logged-in ones, which are usually the pages that matter.
- Compressing images once, by hand. It works until the next person uploads a 6MB photo through the CMS. Resize on upload, automatically.
- A CDN as the first move. A CDN makes a fast site fast everywhere. It makes a slow site slow everywhere, slightly sooner.
- Measuring only the homepage. Your money is usually made on product, service and checkout pages, which are frequently the heaviest.
- Treating it as a one-off project. Performance regresses. A new plugin, a new tracking script, a marketing page with an uncompressed hero image. Without periodic measurement, a site that was fixed last year is slow again — which is why a performance check belongs in ongoing maintenance rather than in a project that finishes.
Where to start, in order
- Run PageSpeed Insights on your three most important pages, mobile, and read the field data section first.
- Open each page on a real mid-range phone over mobile data.
- Fix the images. Dimensions, format,
width/height, priority on the lead image. - Fix the render-blocking CSS and fonts.
- Audit third-party scripts and delete what you can defend deleting.
- Set caching headers properly.
- Only then look at the server and the database.
- Re-measure in four weeks, when enough real visits have accumulated to move the field data.
Most sites get most of their available improvement from steps 3 to 5, which is frustrating if you were hoping the answer was a faster server, and good news for the budget.
If you would rather someone measured it properly and told you which of these actually applies to your site, that is a contained piece of work and we are happy to do it — we look at the real page rather than the score, and we tell you which fixes are worth the money. It is part of how we build business websites and part of what ongoing support covers afterwards.
