Why your website is slow, and what actually fixes it

1. Your hosting takes too long to answer

Before a single image or script has started downloading, the server has to begin sending the page. That first response is the floor everything else is built on — every other improvement is stacked on top of it, which is why it is the thing to fix first and the thing most often ignored.

When it is slow, the cause is usually cheap shared hosting, a database query that has grown with the site, or a page being rebuilt from scratch on every single request rather than being cached. On WordPress a full-page caching plugin often halves it in an afternoon, because it stops the site rebuilding the same page for every visitor.

There is a related problem that is almost invisible in testing: hosting that puts a site to sleep when nothing has visited for a while. The first person to arrive after a quiet spell waits for it to wake. Anybody testing the site has just loaded it, so they never see the slow version — but the visitor arriving at seven in the morning does, and so does Google when it crawls at an odd hour.

2. Your images are far bigger than they need to be

This is the most common performance problem on small business websites and by some distance the easiest to fix. A photograph straight from a phone or a stock library is several thousand pixels wide. Displayed in a space eight hundred pixels across, the visitor downloads the whole thing and sees a fraction of it.

The arithmetic is worse than it sounds, because image data grows with the square of the width. An image at twice the width it is displayed at is roughly four times the file size. It is paid for by the person on mobile data, on the connection least able to afford it.

The fix is to resize images to the size they are actually shown at, save them as WebP rather than JPEG or PNG, and let the page reserve their space before they load so the layout does not jump around while they arrive.

3. Scripts and stylesheets block the page from drawing

A browser will not draw a single pixel until certain files have finished downloading. Until then the visitor is looking at nothing at all — not a partial page, nothing. It is worse when one of those files is pulled in by an @import inside another stylesheet, because the second cannot even begin downloading until the first has arrived.

Separately, while scripts are running, the phone cannot do anything else. Taps and scrolls are queued rather than acted on, which does not read to a visitor as the site being slow — it reads as the site being broken. They tap again, nothing happens, and they leave.

4. Third-party widgets you have forgotten are there

Chat widgets, booking systems, review badges, analytics, advertising pixels, font services, cookie banners. Each was added for a reason and each costs loading time, and because they accumulate one at a time nobody ever sees the total.

They are worth auditing precisely because they are invisible in the site's own code — they arrive as a single line of script that pulls in everything else. A chat widget nobody has answered in eight months is pure cost.

What Google actually measures

Google uses three measurements, collectively called Core Web Vitals, and they are worth understanding because they are named after what a visitor experiences rather than what a server does.

Largest Contentful Paint is how long the main thing on the page takes to appear — usually the headline or the main image. Cumulative Layout Shift is how much the page jumps around while it loads, which is what makes somebody tap the wrong thing. Interaction to Next Paint is how quickly the page responds when somebody actually taps something.

Lab tools, including this one, cannot measure Interaction to Next Paint directly, because it needs a real person tapping. They use Total Blocking Time as a stand-in, which measures how long the page was unable to respond during loading. It is a good proxy and it is not the same number, and any tool telling you otherwise is overstating what it knows.

The checks behind this guide

• Server responds promptlyThis is how long your hosting takes to begin sending the page at all — before any images, fonts or scripts have started. Every other speed improvement is stacked on top of this delay, so when it is slow it is the one to fix first.
• Main content appears quickly on a phoneThe largest thing on the page — usually the main image or headline — is what a visitor is waiting for. Until it finishes loading they are looking at a blank or half-built page. This is measured on a mid-range phone on mobile data rather than on a fast desktop connection, because that is the harder case and the one most visitors are actually in.
• Main image is sized for the screenWhen the biggest image on the page is far wider than the space it is shown in, visitors download image data they can never see — and image data grows with the square of the width, so an image at twice the needed width is roughly four times the bytes. It is paid for on the connection least able to afford it.
• Page is light enough for mobile dataSomeone on mobile data pays for every megabyte a page downloads, and waits for them. A heavy page is usually a handful of images that were never resized rather than anything structural, which makes it one of the cheaper speed problems to fix.
• Nothing needless blocks first paintThe browser will not draw a single pixel until certain stylesheets and scripts have finished downloading. On a phone that is dead time the visitor spends looking at nothing. It is worse when one of those files is pulled in by an @import inside another stylesheet, because it cannot even start downloading until the first has arrived.
• Page stays still while loadingContent moves after it first appears, so someone reading or reaching for a button can have it shift under them. This is what causes the mis-taps that make a site feel broken on a phone.