How to Actually Speed Up a Website
Site speed advice is usually a list of thirty tweaks. In practice four things account for nearly all of it, and images alone are typically half.
Four things account for most page speed problems: oversized images, slow server response, third-party scripts, and render-blocking CSS and fonts. Fixing images alone typically recovers more than every other optimisation combined, because images are usually the largest thing on the page by a wide margin.
Why Sites Are Slow
Almost no site is slow because of one dramatic problem. Sites are slow because of accumulation — an unoptimised image here, a tracking script there, a font nobody removed — each individually defensible and collectively fatal.
This matters for how you approach it. Looking for the single cause usually fails, because there isn't one. Measuring what the page actually loads, sorting by size and time, and working down that list is the method that works, because it addresses the accumulation in order of cost.
It also explains why sites get slower over time without anyone changing anything structural. Each new campaign adds a pixel, each new feature adds a script, and nothing is ever removed. A speed audit is as much about deletion as optimisation.
The commercial case is straightforward and does not depend on rankings. Slower pages convert worse, and the effect is sharpest on mobile connections — which is most of your traffic, and where the paid traffic you are buying arrives.
The Order That Recovers the Most
Work these in sequence. Each is roughly ordered by how much time it typically recovers per hour of effort, which is not the order most speed guides use.
- 01
Images — usually half the problem on its own
Serve images at the size they are actually displayed rather than full resolution scaled down in the browser. Use a modern format. Compress properly. Lazy-load everything below the fold, and never lazy-load the hero. A page shipping a 3MB photograph into a 400px slot is extremely common and fixed in minutes.
- 02
Server response time
If the first byte takes over half a second, everything downstream inherits the delay. Pre-render pages that do not need to be dynamic and serve them from a CDN edge cache. This converts a variable server cost into a near-zero constant, and it is the single biggest structural improvement available.
- 03
Third-party scripts
Analytics, pixels, chat widgets, heatmaps, consent banners, embedded videos. Audit what is actually loading — most sites carry scripts for tools nobody uses any more. Remove what you can, defer the rest, and load nothing in the head that does not have to be there.
- 04
Render-blocking CSS and fonts
Stylesheets and font files block the first paint. Inline the styles needed for the first screen, defer the rest, preload the fonts that appear immediately, and set a font-display strategy that shows fallback text rather than nothing.
- 05
JavaScript bundle size
Split code so a page loads only what it needs, and ship interactivity only where it is used. This is the hardest item and usually the smallest win for a content site — which is why it is last, not first.
Getting Images Right
Since this is typically the largest single win, it is worth being precise about what correct looks like.
Right dimensions, not just compressed
Compression on a 4000px image displayed at 400px still ships far too much data. Resize first, compress second. This ordering matters more than the compression settings.
Modern formats with fallbacks
WebP and AVIF are substantially smaller than JPEG at equivalent quality and are widely supported. Serve them with a fallback and the saving is free.
Responsive sources
Serve a smaller file to phones than to desktops using srcset and sizes. Without this every visitor downloads the desktop image, including the ones on the slowest connections.
Always set dimensions
Width and height attributes or an aspect ratio let the browser reserve space, which prevents layout shift. Costs nothing, fixes a whole metric.
Lazy-load below the fold only
Everything not visible on load should be deferred. The hero image should never be, because it is usually the element LCP measures — lazy-loading it delays exactly the thing being scored.
Why Caching Plugins Aren't the Answer
The usual first response to a slow site is a speed plugin. These genuinely help, and they help with a narrower slice of the problem than their marketing suggests — which is why sites often install one and remain slow.
Caching plugins mainly address server response time by storing generated pages and serving them again. That is real and worth having. It does nothing about a 3MB hero image, a dozen third-party scripts or a render-blocking font, because none of those are server-generation costs.
The minification and combination features can also introduce problems. Aggressive settings break layouts and functionality in ways that appear intermittently and are unpleasant to debug, which is why so many sites end up with a plugin installed and most of its features disabled.
Treat a caching plugin as one item on the list rather than as the list. If the site is still slow after installing one, the remaining problem is in the page itself, and that is where the measurement should point you.
Common Questions
What people ask when a site is slow.
What load time should I aim for?
Under 2.5 seconds for the main content to appear, measured on a mid-range phone on mobile data rather than on your own machine. Your desktop on office broadband is the least representative test available and consistently produces false confidence.
Will faster hosting fix it?
It fixes server response time, which is one of four causes. If your images are oversized and you load fifteen scripts, better hosting produces a marginal improvement on a slow page. Measure first — hosting is the right answer sometimes and an expensive non-answer often.
How much does speed affect rankings?
Modestly and as a tiebreaker. Its reliable effect is on conversion, where slower pages lose visitors measurably. Optimise for the visitors and take the ranking effect as a bonus rather than the goal.
Do I need to remove all third-party scripts?
No — remove the ones nobody uses, and defer the rest so they load after the page is usable. Most sites carry at least one script from a tool abandoned a year ago, still loading on every page view for nobody.