Most speed advice is a list of thirty things, which is useless because you will do four of them and they will be the wrong four. This is the order we work in, and how to find out which step your site is stuck on before spending money.
The fastest route to a faster site is usually: compress and correctly size images, remove unused third-party scripts, enable caching and a CDN, then fix render-blocking CSS and fonts. On most business sites those four account for the large majority of the load time. Anything deeper is worth doing only after they are done.
First, find out what is actually slow
Guessing costs more than measuring. Open your slowest important page in Chrome DevTools, run the Network tab with cache disabled, and sort by size. Then run the same URL through PageSpeed Insights and read the diagnostics rather than the score.
You are looking for two things: the single largest file, and the number of requests to domains you do not own. Those two answers usually determine the whole plan.
The order we work in
| Step | Typical gain | Effort |
|---|---|---|
| Compress and resize images | Large | Low |
| Remove unused third-party scripts | Large | Low |
| Caching and a CDN | Medium to large | Low |
| Fix render-blocking CSS and fonts | Medium | Medium |
| Defer or split JavaScript | Medium | Medium |
| Upgrade hosting | Medium | Low cost, low effort |
| Rebuild the front end | Large | High |
Work top down and stop when you hit your target. Teams that start at the bottom spend the most and often finish slower than teams that did the first three properly.
Images are almost always the problem
On the sites we audit, images are the largest single cause of slow loading more often than everything else combined. The usual pattern is a photograph uploaded straight from a phone at 4000 pixels wide, displayed at 800.
- Serve modern formats. WebP or AVIF typically cut file size by half or more against JPEG at the same visual quality.
- Size images to their display size, and provide multiple sizes so phones do not download the desktop version.
- Lazy load anything below the fold, but never the hero, since lazy loading your LCP element makes the metric worse.
- Set explicit width and height so the layout does not jump.
Third-party scripts are the hidden tax
Every tag you add runs on your visitors' devices. A typical business site we inherit is loading analytics, a tag manager, a chat widget, a heatmap tool, two ad pixels and a review widget, several of which nobody has looked at in a year.
Audit them honestly. For each one ask who reads the data and what decision it informs. If there is no answer, remove it. This is usually the highest return per hour of any speed work, and it costs nothing.
Caching, CDNs and hosting
Caching means the server stops rebuilding the same page for every visitor. A CDN means the files come from somewhere near your visitor rather than one origin server. Both are cheap and both help almost every site.
Hosting matters more than people expect. If your server takes 800 milliseconds to send the first byte, no amount of front-end optimisation will rescue the page. Time to First Byte under 200 milliseconds is a reasonable target, and cheap shared hosting frequently cannot reach it.
When speed is not your problem
Occasionally we audit a site, find it loads in 1.4 seconds, and the real issue is that the homepage does not say what the company sells. Speed work is measurable and satisfying, which makes it a comfortable place to spend a budget that a messaging or structure problem would have used better.
If your bounce rate is high and your site is fast, stop optimising and start reading session recordings.
Frequently asked questions
What is a good page load time?
Aim for Largest Contentful Paint under 2.5 seconds on mobile, measured on real visitor data. Total load time is a less useful target because it includes things that happen after the page is usable. If you want one number to watch, use LCP.
Will a caching plugin fix my slow site?
It will help, and it will not fix an oversized image problem or a page loading twelve third-party scripts. Caching reduces server work. It does nothing about what the browser has to download and execute once the page arrives.
Is it worth paying for faster hosting?
If your Time to First Byte is above roughly 600 milliseconds, yes, and it is usually the cheapest meaningful improvement available. If TTFB is already low, better hosting will change very little and the problem is on the front end.
Do I need to rebuild the site to make it fast?
Rarely. Most sites reach acceptable numbers through images, script removal, caching and font loading. A rebuild is justified when the page weight comes from the theme or page builder itself, which is common on sites built with heavy visual builders.
How fast is fast enough?
Fast enough that speed stops being the reason people leave. Chasing a perfect score has diminishing returns quickly. We aim to pass Core Web Vitals with headroom, then spend the remaining budget on things that change conversion more directly.