Speed is the one quality of a website that everybody notices and almost nobody specifies. It rarely appears in a brief. It is not on the list of things reviewed at a design presentation. Then the site launches, someone opens it on a phone outside the office, and it turns out to be the most important thing about it.
The reason speed gets treated as an afterthought is that it looks like a setting: something a plugin, a cache or a faster server can turn on later. Sometimes it partly is. More often speed is a consequence of decisions made months earlier about what the page is made of, and by then improving it means undoing those decisions.
This is what actually determines whether a site is fast, roughly in the order that causes real-world problems.
What "fast" means to the person waiting
Three separate moments, which is why a site can be fast by one measure and painful in practice.
Something appears. The gap between tapping a link and seeing anything other than a blank screen. This one governs whether a visitor stays. A blank white screen for four seconds is indistinguishable from a broken site.
The thing they came for is readable. Not the header and the cookie notice, but the actual content. A site that draws its navigation quickly and its text slowly feels slower than one that arrives all at once.
It responds when touched. A page can look finished and still ignore taps for a second or two while scripts are still working. This is the most irritating of the three, because the visitor has been invited to act and then ignored.
There is a fourth quality that is not speed but is felt as speed: stability. If content jumps as images and fonts arrive late, and the visitor taps the wrong thing because the button moved, the site feels unreliable regardless of how quickly it loaded. Stability is largely free if planned and awkward to retrofit, which is a pattern that will recur below.
The real causes, in order of frequency
One: images
Almost always the largest single cause, and the most fixable. A photograph straight from a camera or a stock library can be several megabytes; the same image sized and compressed for the space it occupies can be a fraction of that with no visible difference.
The frequent version of this problem is a page serving desktop-sized images to phones, so a visitor on mobile data downloads an image four times wider than their screen. Modern formats and responsive sizing address it, and this work is cheap and reliably effective.
Background video deserves a specific mention. A full-screen video on a homepage is the most expensive decoration available in web design, and on a mid-range phone on a weak connection it is often the entire reason the page is slow.
Two: third-party scripts
Everything the site loads from somewhere else: analytics, tag managers, chat widgets, embedded maps, review badges, social feeds, advertising and consent tools.
Each is small on its own and they compound in a particular way: many of them load further code themselves, so what looks like four scripts becomes twenty requests to servers you do not control. Your site is then only as fast as the slowest of them, and none is under your control.
The remedy is unpopular and effective. List everything third-party the site loads, ask what each one is for, and ask who looked at the answer in the last year. Sites regularly carry tracking for a campaign that ended in 2023 and a chat widget nobody monitors.
Three: fonts
Custom typefaces are worth having and cost more than people expect. A page can wait on a font file before showing any text, or show text in a fallback and then reflow when the real font arrives, which is the jumping described above.
Manageable with three habits: use few weights, self-host rather than fetching from a third party, and configure a fallback that occupies close to the same space so the reflow is barely visible. All three are cheap during a build and awkward after it.
Four: too much JavaScript
Here the causes stop being things you can strip out and start being decisions about how the site was made.
A site built as an application in the browser has to download and run a substantial amount of code before it can show anything, even for a page that is only text and pictures. For a genuine application that trade is often correct. For a marketing site it is paying an application's cost for a brochure's job, and the cost is paid by every visitor on every first visit.
This is the point at which speed stops being fixable by optimisation. If a page needs a large amount of code to run before displaying a paragraph, no caching plugin will make it fast on a mid-range phone.
Five: the plugin stack
The common shape on established sites: a general-purpose theme plus a long list of plugins, each loading its own styles and scripts on every page, including the pages that do not use them. A slider plugin used on the homepage loads its code on the contact page. Twenty plugins produce a page carrying twenty sets of code to do the work of about three.
Auditing which plugins actually earn their place is genuinely useful. But past a certain point this is a structural problem, and the honest answer is that the site's foundation is the cause.
Six: the server and the database
Hosting matters less than most people assume and more than nothing. Two cases where it genuinely dominates: a server physically distant from most visitors, where the delay is imposed by geography before anything else happens, and pages that run slow database queries, which is common on sites with large catalogues or heavy filtering.
The reason this sits sixth is that upgrading hosting is the first thing many people try, and on an image-heavy page carrying fifteen third-party scripts it changes very little. Faster hosting speeds up the part that was already fast.
Which fixes reach which problems
| Cause | Typical fix | Cost | Reaches the cause? |
|---|---|---|---|
| Oversized images | Resize, compress, serve by screen size | Low | Yes, completely |
| Background video | Remove it, or replace with a still | Low | Yes |
| Third-party scripts | Audit and remove; defer what remains | Low | Yes, mostly |
| Fonts | Fewer weights, self-hosted, matched fallback | Low | Yes |
| Too much JavaScript | Rendering approach, or a different build | High | Only by rebuilding that part |
| Heavy plugin stack | Audit, then usually a rebuild | Medium to high | Partly, then structurally |
| Distant server | Move hosting or add a content delivery network | Low to medium | Yes, for that portion |
| Slow queries | Indexing, caching, restructuring | Medium | Yes, with technical work |
The pattern is the same one that appears throughout software. The cheap fixes address what is on the page. The expensive ones address how the page is made. A caching layer is often worth having, and it is worth understanding what it does: it stores a finished copy of a page so the server does less work per visit. It does nothing about a five-megabyte image or a chat widget loading from another company's server.
How to measure it honestly
Test on a mid-range phone, on mobile data, away from your office network. Everything else is secondary. Developers and designers work on fast machines on fast connections, which is why sites regularly ship feeling fine to everyone who built them.
Understand what a testing tool is telling you. Tools that measure a single test run in a controlled environment tell you what the page is made of, which is useful for diagnosis. Tools that report what real visitors experienced tell you what is actually happening, including on the devices and connections your customers use. The second is the truth; the first is the explanation.
Do not chase a perfect score. Scores compress several measures into one number and reward things nobody feels. A site that scores in the eighties and shows its content in a second is doing better than one that scores in the high nineties by deferring everything until after the visitor gave up.
Test the pages that matter, not only the homepage. The homepage is usually the most optimised and often the least visited relative to the pages that answer questions.
A note on measurement standards. The named metrics and thresholds used by search engines to assess page experience have been renamed and re-thresholded more than once, most recently within the last few years. The principles above are stable; the specific metric names, targets and their weighting in ranking are not. Check the current definitions before treating any threshold as a requirement.
An illustrative example
A company with a well-regarded site finds that mobile enquiries have fallen while desktop enquiries are steady. The site looks and feels fine in the office.
Examined on a phone on mobile data, the homepage takes seven seconds to show text. The causes, in order of contribution: a background video that autoplays, four hero images exported at full desktop width, a chat widget nobody has monitored for a year, and a tag manager loading three tracking scripts, one for a campaign that ended.
None of these is a design fault or a hosting fault, and all four fixes are days of work rather than a project. That is the ordinary case. The hypothetical here is invented; the composition of causes is the one that turns up most often.
Common questions
Does speed affect search rankings? Yes, though less dramatically than most claims suggest. Page experience is one factor among many, and relevance matters more. The larger effect is behavioural: people abandon slow pages, and abandonment affects enquiries directly whether or not it affects rankings.
Will better hosting fix our slow site? Only if hosting is the cause, which it is in a minority of cases. Diagnose first. Upgrading hosting to fix an image problem is the most commonly wasted spend in this area.
Is a fast site less attractive? No, and the belief that it must be is what puts background video on homepages. Restraint is not the same as plainness. The heaviest elements on most pages are rarely the ones carrying the design.
How fast is fast enough? Something readable within about two seconds on a mid-range phone on a normal mobile connection is a defensible target for a content site. Better is better, and the gains beyond that point are smaller than the gains from getting there.
The short version
- Three moments matter: something appears, the content is readable, and the page responds to touch. Stability, meaning content that does not jump, is felt as speed.
- Images are the most common cause and the cheapest to fix. Background video is the most expensive decoration in web design.
- Third-party scripts compound, and they are the part of your page you do not control. Audit them.
- Heavy JavaScript and a large plugin stack are structural. No plugin fixes them.
- Hosting matters less than most people try first, except when the server is geographically distant or the database is doing slow work.
- Measure on a mid-range phone on mobile data. Prefer what real visitors experienced over a single lab score, and do not chase a perfect number.
Where to take this next
If speed is one of several complaints about a site, it is worth checking the others before commissioning anything: what a business website should actually do includes a test you can run this afternoon.
We are happy to look at a site and tell you which of the six causes above is dominant, which usually settles whether this is a week of work or a larger project. Discuss your idea.
# Visual recommendations
Concepts only. Hairline drawing, ink and brass.
Hero visual — what the page is carrying
Concept. A single page outline drawn in section, with the things it loads stacked beneath it as bands of proportionate thickness: images thickest, then third-party scripts, then fonts, then the site's own code, then the text itself as a hairline sliver at the bottom. A brass bracket marks the sliver with the label what the visitor came for.
Purpose. Carries the article's central observation in one image: the content is the smallest part of what a slow page transfers.
Composition. Vertical, roughly 3:4. Proportions illustrative rather than measured, and captioned as such so it does not read as data.
Alt text. A slow page shown in section, where images, third-party scripts and fonts make up most of what loads and the text the visitor came for is the thinnest layer.
Supporting visual — where a fix reaches
Concept. Two columns. Left, fixes that reach the cause: image sizing, script audit, font handling, each drawn as an arrow that lands cleanly on its band in the hero's stack. Right, fixes that do not: a faster server and a caching plugin, drawn as arrows that stop short of the image and third-party bands.
Purpose. Prevents the most common wasted spend in this area, which is buying hosting to solve an image problem.
Placement. Beside or after the fixes table.
Alt text. Image sizing, script audits and font handling reach the layers causing slowness, while faster hosting and caching stop short of the image and third-party script layers.