Almost every site we are asked to speed up is slow for one of four reasons. Not ten, not fifty. Four. The difficulty is that performance tools report dozens of symptoms at once, all colour-coded red, with no indication of which one is actually costing you anything.
So before you buy a caching plugin or a bigger server, work through these in order. The order matters: fixing the fourth while the first is still true will not move your score.
1. Images that were never resized
This is the single most common cause, and it is usually the least interesting to fix, which is why it gets skipped. Someone uploads a photograph straight off a phone or a stock library at 4000 pixels wide, the theme displays it in a 400 pixel box, and the browser downloads all four thousand pixels anyway.
A page with six of those is downloading perhaps fifteen megabytes to show something that should weigh under one. On a good office connection you might not notice. On a phone on mobile data, which is where a growing share of your visitors are, it is the difference between a site that loads and a site that gets abandoned.
What to do: resize images to roughly twice the size they display at, then convert to a modern format. WebP is supported everywhere that matters now, and AVIF in most places. The conversion alone typically cuts file size by half to two thirds with no visible difference.
Be careful of one trap. Setting a smaller display size in your page builder does not change the file that gets downloaded. WordPress generates multiple sizes and offers them through a srcset, but if the largest candidate is still in that list the browser may well pick it. Format is the reliable lever, not dimensions.
2. Fonts loaded from somewhere else
A typical site pulls two or three typefaces from a third-party font service. Each one is a separate connection to a separate domain, and the browser will not paint your text until it has them. That is a render-blocking request sitting directly between your visitor and your headline.
Self-hosting the fonts removes the connection entirely. You download the font files once, serve them from your own domain alongside everything else, and the browser reuses the connection it already has. It also removes a third party from your privacy position, which is worth something separately.
Two details people miss. First, only host the weights you actually use: shipping nine weights of a family when the design uses three is a straight waste. Second, set font-display: swap so text renders in a fallback face immediately rather than sitting invisible while the font arrives.
3. Plugins doing work on every single page
A contact form plugin that loads its JavaScript on all forty pages, when you have one contact page. A slider library on a site with no sliders any more. An analytics tag, a chat widget, a cookie banner, a review widget, each adding a script and a connection.
Open your browser developer tools, go to the network tab, reload, and sort by size. You will usually find two or three things you had forgotten were installed. The fix is either removing them or loading them conditionally, only on the pages that need them.
This is also where the honest conversation about tracking happens. Every marketing tag has a cost, paid by your visitors in load time. That can be worth it. It should be a decision rather than an accumulation.
4. The server, and only then the server
Hosting is where most people start and it should usually be last. A slow server shows up as a long wait before anything at all appears, measured as time to first byte. If that number is high while everything else is lean, the host is genuinely your problem.
But if you are serving fifteen megabytes of unresized images, moving to a faster server just delivers those fifteen megabytes slightly sooner. The bottleneck is not where you are paying attention.
What a realistic result looks like
Two things worth setting expectations on. First, performance scores vary between runs on the same unchanged site, sometimes by several points, because they depend on network conditions and how busy the testing machine is. Judge a change by the trend across several runs, not by one number.
Second, mobile scores are always well below desktop, and on a content-heavy site they are genuinely hard to lift. The same page can score in the nineties on desktop and the fifties on mobile. That is not a bug in the test. It reflects a slower processor on a slower connection, which is what a real visitor has.
The goal is not a perfect score. It is a site that feels immediate to the person using it, which is mostly about the first thing they see appearing quickly, and about the page not jumping around while it loads.
Where to start today
Run one page through a performance test. Ignore the overall score and read the opportunities list. If images are at the top, you have your answer and you can stop reading reports. If it is scripts, work out which plugin owns each one.
If you would rather someone worked through it properly, our maintenance and troubleshooting work starts with exactly this kind of audit, and business website builds have it designed in rather than bolted on afterwards.