Almost every slow site we are asked to look at is slow for one of four reasons. None of them are exotic, and the order matters, because fixing the fourth while ignoring the first is how people spend a month and gain nothing.
1. Images, by a wide margin
Images are usually most of a page's weight. The common failure is not "we have too many pictures" — it is shipping a 4000px photograph to a phone that will display it at 400px, in a format from 1996.
What actually fixes it: serve modern formats, size images to their display size, and let the browser pick from a set rather than guessing. Lazy-load anything below the fold, but never the main image — that one you want early.
This alone frequently halves load time, and it is the least glamorous work on the list.
2. JavaScript that blocks the first paint
A browser cannot show your page while it is parsing a script that might change it. Every render-blocking script is a queue the user waits in.
The fix is not "use less JavaScript" as a slogan. It is deciding what genuinely needs to run before first paint — usually almost nothing — and deferring the rest. Server-rendered HTML that is readable before any script executes is the difference between a page that appears and a page that assembles itself while you watch.
3. Third-party tags nobody owns
Analytics, chat widgets, heatmaps, ad pixels, a font from one CDN and an icon set from another. Each was added for a reason, usually by a different person, often years apart. Nobody has removed one since.
Third-party scripts are the worst kind of slow because you do not control them. Their outage is your outage. Audit what is actually loading, and delete anything nobody can name a current use for. This is the highest ratio of improvement to effort on the entire list.
4. Hosting and delivery
If your server is in one country and your customers are in another, physics charges you for it. A CDN puts your assets near the person requesting them.
Worth saying plainly: hosting is the last thing to blame, not the first. Moving a badly built site to faster hosting produces a badly built site that is slightly less slow.
Measure the right things
Chase field data, not lab scores. A perfect score on your laptop over office broadband says nothing about a customer on a mid-range Android phone. The metrics that matter are the ones about human experience: how long until something appears, how long until it responds, and whether the layout jumps while they are reading.
Why this is an SEO issue, not just a UX one
Speed is a ranking input, but the larger effect is behavioural. Slow pages get abandoned, abandonment is measurable, and a page nobody stays on does not hold a position for long. You are not optimising for a score. You are optimising for the person who decides within two seconds whether to wait.
Where to start on Monday
- Measure real-user data before changing anything, so you can prove the change worked.
- Fix images. Almost always the biggest single win.
- Remove third-party scripts nobody can justify.
- Defer everything that does not need to run before first paint.
- Only then look at hosting.
