Somebody has said your website is slow. Possibly a customer, possibly your own team, possibly a report with a red score on it. Before spending anything, two questions are worth answering, because they change what the problem even is.
Slow for whom, and on what? A site can be quick on a laptop in your office and genuinely painful on a phone on a weak connection, which is where a large share of your visitors actually are. It can be fast for you because your browser has already stored everything and slow for the first-time visitor who matters most. And it can be perfectly fast everywhere except your office, in which case the problem is your office.
Test on a phone, on mobile data, away from your own network, in a private window. If it is fine there, you have learned something valuable for nothing.
Why a website is slow: the usual culprits, ranked
Roughly this order, in our experience of being sent slow sites. The ranking matters, because people tend to start at the bottom of this list where the work is most expensive.
- Images. Far and away the most common, and the most boring. Photographs uploaded straight from a camera or a phone at several megabytes, resized in the browser rather than before upload, in old formats, all loading at once whether or not anyone scrolls to them. One page can easily be carrying twenty times more image weight than it needs.
- Third-party scripts. Analytics, chat widgets, heat maps, review badges, advertising pixels, cookie tools. Each one added by somebody reasonable for a reasonable purpose, none ever removed. They load from other people's servers, so their bad day becomes your bad day.
- Too many plugins or add-ons. Common on platform sites. Each adds its own styles and scripts to every page, including the pages that do not use it. Twelve plugins to add six features is a familiar pattern.
- Hosting. Cheap shared hosting where hundreds of sites share a machine. The tell is that the very first response takes a long time before anything at all appears, and it is worse at busy times of day.
- Fonts. Several families, several weights, loaded from elsewhere, with text invisible until they arrive. Easy to fix and frequently overlooked.
- The code itself. Doing work on every request that could be done once, querying the database inefficiently, rendering things nobody sees. Genuinely the cause sometimes, and much rarer than the five above.
The useful thing about that order is that the first three cost hours and the last three cost weeks. Most slow sites are fixed in the first three.
The speed scores, in plain words
Google measures three things about real visits, and the jargon obscures how simple they are.
| The measurement | In plain words | Usually caused by |
|---|---|---|
| Largest contentful paint | How long until the main thing on the screen appears. Usually the hero image or the headline. | A huge hero image, slow hosting, or fonts blocking the text from showing. |
| Interaction to next paint | When someone taps something, how long before anything happens. This is the one people describe as the site feeling sluggish. | Too much script running, usually third-party, keeping the browser busy so it cannot respond. |
| Cumulative layout shift | How much the page jumps about while loading. The reason you tap the wrong thing because a banner appeared. | Images and adverts with no space reserved, or fonts swapping and resizing the text. |
These are measured from real visits over time, not from a single test, so a fix takes a few weeks to show up in the reported figures even though your visitors feel it immediately.
One caveat worth having. A score out of one hundred from a testing tool is a diagnostic, not a target. Chasing the last few points is a well-known way to spend a lot of money on something no human being will ever perceive. Fix what a visitor would actually notice and stop.
Cheap fixes and structural ones
| Fix | Effort | Typical effect |
|---|---|---|
| Resize and compress images, modern formats | An afternoon | Often the single largest improvement available. Start here, always. |
| Load below-the-fold images only when needed | An hour | Faster first view, especially on long pages. |
| Audit and remove third-party scripts | A day, mostly meetings | Large. The hard part is agreeing what to delete, not deleting it. |
| Reserve space for images and banners | A few hours | Removes the jumping about, which people notice more than raw speed. |
| Host fonts yourself, limit weights | A few hours | Text appears sooner, and the page stops reflowing. |
| Put a content network in front | A day | Helps visitors far from your server, and absorbs busy periods. |
| Move to better hosting | A day or two | Fixes a slow first response. Does nothing for heavy pages. |
| Remove and replace overlapping plugins | Days | Meaningful on platform sites, and it needs care not to break things. |
| Rework how pages are built and cached | Weeks | Large, and it is real engineering. Not the first thing to try. |
| Rebuild the site | Months | Only when the structure is the problem. See below. |
The third-party script problem
This one deserves its own section because it is the most political and therefore the least often fixed.
Every script was added by someone with a good reason. Marketing wants the heat map. Sales wants the chat widget. Someone wants the review badge. Legal requires the consent tool. Individually each is defensible and each costs a little. Together they can easily be most of what the browser is doing, and unlike your own code they load from servers you do not control, so you inherit their outages and their slow days.
The fix is not technical. Get the list of what loads on every page in front of the people who asked for each one, and ask what would break if it went. Half will turn out to belong to a campaign that ended, or a person who has left, or a tool nobody logs into any more. That conversation is worth more than any amount of optimisation.
Who is actually waiting, and for what
Before spending on any of the fixes above, it is worth knowing which visitors are affected, because the answer changes what is worth doing.
- First-time visitors carry the whole weight. Everyone returning has most of the page already stored by their browser. If you only ever test as a regular visitor, you are testing the easy case and missing the one that matters commercially.
- Phones on mobile data are the real benchmark. A significant share of visitors arrive that way, on a device with less processing power and a connection that varies by the minute. A page that is comfortable on a laptop can be genuinely unpleasant there.
- Distance from your server is a real cost. If your hosting is in one country and a meaningful number of visitors are in another, every request pays for the round trip. This is what a content network fixes, and it is why the same site can feel fine locally and sluggish abroad.
- Your busiest hour is not your average hour. Cheap shared hosting behaves differently at four in the afternoon than at nine in the evening. Test when your customers are actually there.
- The page they land on is rarely the home page. Most visitors arrive on an article or a product page from a search, and those are frequently heavier than the home page nobody has optimised them.
A practical consequence: measure the page that receives the most search traffic, on a phone, as a first-time visitor. That single number is worth more than a site-wide average, and it is the one that corresponds to money.
When speed genuinely needs a rebuild
- Every page is assembled from scratch on every request and nothing can be reused, because the way it is built makes caching impossible.
- A page cannot show anything until a large amount of script has downloaded and run, which is a choice made early in a build and is expensive to reverse.
- The platform is being fought. Fifteen plugins, three of them overlapping, and every fix breaks something else.
- Nobody can change anything safely, so the cheap fixes are not actually available to you at any price.
If two or more of those apply, optimisation is money spent slowing the rate of decline, and a redesign is the honest conversation. If none apply, do not let anyone sell you one on the basis of a speed score.
How to measure it yourself, for nothing
- Open your site on your own phone, on mobile data, in a private window, and count. This is the only test that matches what a real visitor experiences, and it costs nothing.
- Run a free speed test from one of the well-known tools. Read the opportunities list, not the score.
- Sort the page contents by size. Every browser has a network view. Sorting by size takes ten seconds and usually names the culprit outright.
- Check the first response time separately from everything else. Long here means hosting; short here means the page is heavy.
- Test the same page twice, once fresh and once returning, so you can tell what a first-time visitor gets.
- Test a competitor. Useful perspective, and occasionally reassuring.
If nobody would notice the site being down for an hour, you also have a monitoring gap rather than only a speed one, and our monitoring and continuous improvement work exists for the sites that need attention rather than surgery.
Not for you if
The reason to work through this in order is straightforward. Compressing images costs an afternoon. Rebuilding costs months. The two are frequently proposed for the same symptom, and the difference between them is whether anybody actually looked first.