Why website speed matters more than most businesses think

Every business owner who has approved a website has seen it at its fastest: on a good laptop, on office Wi-Fi, usually after visiting it a dozen times so most of it is already cached. That is the one situation almost none of your visitors will ever be in.

Your visitors are on phones. Often mid-range phones, several years old, on mobile data that drops from 4G to something slower as they walk between rooms. They've never been to your site before, so nothing is cached. They clicked from a search result, and if nothing useful appears quickly, they go back and click the next one.

Speed is part of the impression, not a technical detail

People don't experience "page load time" as a number. They experience it as a feeling about your business. A site that appears quickly and responds instantly feels competent. A site that shows a white screen, then a spinner, then text that jumps as an image pops in above it, feels careless, even if the design, once it arrives, is excellent.

That's why we'd argue speed belongs in the design conversation, not only the engineering one. The loading experience is the first thing anyone sees, so it is part of the design whether anyone designed it or not.

How speed is actually measured

"Fast" is vague, so it helps to know the measurements that matter. Google's Core Web Vitals are the most widely used:

Google assesses these at the 75th percentile of real visits, so it's not enough for the site to be fast for your best-connected visitors.

Two tools are worth knowing:

• PageSpeed Insights shows both lab data (a simulated test) and, if your site has enough traffic, field data from real Chrome users. The field data is the truth; the lab score is a diagnostic.
• Lighthouse, built into Chrome's developer tools, runs the same kind of lab test locally and lists specific problems.

A Lighthouse score is useful but easy to over-read. A 95 in the lab doesn't guarantee a good experience for real users, and chasing the last few points is rarely the best use of money. The Core Web Vitals for real visitors are the numbers to care about.

Does speed affect Google rankings?

Somewhat, and it's worth being precise. Google's documentation says Core Web Vitals are used by its ranking systems, but also that great page experience doesn't override relevance: a fast page with the wrong content won't outrank a slower page with the right answer. Treat speed as something that helps you compete when content is comparable, and as something that affects every visitor you do get. Don't expect it to move rankings on its own, and be wary of anyone who promises that it will.

Where the time actually goes

When a business website is slow, it's rarely the server. It's usually the weight and number of things the page asks the phone to download and run.

Images and video

The most common culprit by far. A photographer delivers a 6000-pixel-wide image, it gets uploaded as-is, and every phone downloads several megabytes to display it at 400 pixels wide.

Fixes that make the biggest difference:

• Serve modern formats like WebP or AVIF instead of large JPEGs and PNGs.
• Serve different sizes to different screens (the srcset attribute does this).
• Give every image its width and height so the layout doesn't jump when it arrives. This is most of what fixes CLS.
• Lazy-load images below the fold, but not the main hero image; lazy-loading your LCP image makes it slower.
• For background video, show a small still image first and don't load the video until it's needed. On our own homepage, a product film was pulling a hosted video player of roughly 4.4 MB on first load for a clip most people never scrolled to. It now shows a single still frame until someone asks to play it.

JavaScript

Every script has to be downloaded, parsed and run, and on a slower phone the running is often the expensive part. Heavy JavaScript is the main cause of poor INP: the page looks ready but doesn't respond to taps.

Typical sources: page builders that ship code for every feature whether you use it or not, animation libraries loaded for one effect, sliders, and old code nobody has dared remove. The fix is less JavaScript: remove what isn't used, load what's needed only when it's needed, and prefer plain HTML and CSS for things that don't need scripting.

Fonts

Custom fonts are part of a brand's character and usually worth keeping. The problems come from quantity and loading strategy: four or five weights across two families, each a separate file, loaded in a way that hides text until they arrive. Keep to the weights you actually use, host them yourself where possible, and make sure text is visible while fonts load.

Third-party scripts

Chat widgets, analytics tools, heatmaps, social embeds, cookie banners, ad pixels. Each is small in isolation and each was added for a reason. Together they're often heavier than the entire rest of the site, and you don't control how fast their servers are.

It's worth auditing them once a year. For each one, ask: is anyone actually looking at the data this collects? If not, remove it.

Hosting and caching

Hosting matters most for dynamic sites, WordPress for example, where each page is assembled on request. Without caching, every visit makes the server do that work again. A good host, page caching, and a content delivery network (a CDN, which serves your files from a location near the visitor) make a large difference. Static sites, which are built once and served as ready-made files, sidestep much of this, which is one reason we favour them for marketing websites. The trade-offs are covered in custom website vs WordPress.

An example of how it adds up

Here's a hypothetical but very typical homepage:

• A hero image, uploaded straight from the camera: 3.8 MB.
• Two font families in four weights each: eight font files.
• A page builder's CSS and JavaScript for dozens of features, of which the page uses six.
• A slider library for one testimonial carousel.
• A chat widget, two analytics tools and a social media pixel.

On a fast laptop it loads in under two seconds and nobody notices a thing. On a mid-range phone on an average mobile connection, the headline appears after several seconds, the layout shifts twice as the fonts and image arrive, and the first tap on the menu does nothing for a noticeable moment because the phone is still busy running scripts.

None of those choices was unreasonable on its own. Together they make a site that feels slow to exactly the people it was built to impress.

Performance budgets: the fix that lasts

The most effective single practice is also the least glamorous: agree a performance budget before design starts. A budget might be a maximum page weight, a maximum number of requests, or target Core Web Vitals on a mid-range phone. web.dev's introduction to performance budgets is a good primer.

A budget changes the conversation. Instead of "can we add a video background?", the question becomes "what would we take out to afford one?" That's a design decision the whole team can make together, rather than a problem engineering discovers after launch.

What to do this week

If you're not planning a rebuild, you can still make meaningful progress:

1. Run your homepage and your most-visited page through PageSpeed Insights. Note the LCP, INP and CLS.
2. Compress and resize every image over about 300 KB. This alone often halves page weight.
3. List every third-party script on the site and remove the ones nobody uses.
4. Check your fonts. Remove weights you don't use.
5. If you're on WordPress, make sure page caching is on and your host isn't the cheapest shared plan.
6. Test again, on your own phone, on mobile data.

If the numbers are still poor after that, the problem is usually structural: a heavy theme or page builder, or a design that simply asks for too much. That's when a rebuild starts to make sense.

The fastest request is the one the page never makes.