What Actually Makes a Website Fast

Speed is mostly three problems

We have audited a lot of slow business sites and the causes repeat. It is almost never the language, the framework or the hosting. It is images that are far too large, third-party scripts loading before anything renders, and CSS or fonts blocking the first paint.

Fixing those three usually takes two or three days and moves a site from failing to comfortably passing. Everything after that is diminishing returns.

1. Images, which are usually most of the problem

• Serve the size actually displayed — a 4,000px photo in a 600px slot is a pure waste
• Use modern formats with fallbacks; the saving is typically 25–50%
• Lazy-load anything below the fold, never the main image
• Always set width and height so the layout does not jump
• Compress: quality 80 is visually identical and dramatically smaller

The single most common finding in our speed audits is a hero image over two megabytes that could have been ninety kilobytes.

2. Third-party scripts

Analytics, chat widgets, tag managers, tracking pixels, embedded video, review widgets, font services. Each one is a request to a server you do not control, and several block rendering while they load.

The exercise is simple and rarely done: list every third-party script, name the person who wants it, and delete the ones with no name. Most sites we audit are carrying at least two that nobody has looked at in years.

What survives should load after first paint, and heavy widgets should load on interaction — a chat widget that loads when someone clicks the chat button costs nothing until then.

3. Render-blocking CSS and fonts

• Inline the styles needed for the top of the page; load the rest asynchronously
• Serve fonts from your own domain rather than a third party
• Use font-display so text is visible immediately in a fallback face
• Limit weights — three is plenty and each one is a download

Fonts are the sneakiest of these. A page can be fully loaded and still look empty because the text is waiting for a font file, and the metric that measures it is the one search engines care about.

What is usually not worth the money

1. Changing framework for speed. Enormous effort, and the images were the problem.
2. Upgrading hosting first. Worth doing when the server is genuinely slow, which is rarer than vendors suggest.
3. Chasing a perfect score. The last few points cost more than the first thirty and no user notices.
4. Micro-optimising code. Milliseconds, against seconds elsewhere.

Measure what your users experience

Lab tools test on a fast connection from a data centre. Your customers are on a phone on mobile data in a car park.

So we test on a throttled connection on a mid-range device, and where there is enough traffic we look at field data from real visitors. The gap between lab and field is frequently the whole story, and it is always in the same direction.

Frequently asked questions