“My website is slow” is a symptom, not a diagnosis. Before you buy faster hosting or install another caching plugin, it is worth finding out which of the four common causes you actually have, because the fixes are completely different and three of them are free.
Step one: separate the two kinds of slow
There are two distinct problems people describe with the same word.
Slow to start means you click a link and stare at a blank screen. The server is taking too long to respond. This is a hosting or backend problem.
Slow to finish means content appears quickly but the page keeps loading, jumping, or ignoring your taps for several seconds. This is a frontend problem: too many resources, or too much JavaScript.
To tell them apart, run your homepage through PageSpeed Insights and look at Time to First Byte. Under roughly 0.8 seconds is healthy. If TTFB is high, you have a slow-to-start problem and no amount of image compression will help. If TTFB is fine but the page still feels heavy, your problem is everything that loads afterwards.
Cause one: your server is slow to respond
Symptoms: high TTFB, the whole site feels sluggish including the admin area, and it gets worse when more people visit at once.
The usual reasons, in the order we find them:
Cheap shared hosting
On shared hosting your site competes for resources with many others on the same machine. It is fine for low traffic and becomes a real constraint as you grow. If your admin dashboard is slow even when the public site is cached, hosting is a strong suspect.
No page caching
Without caching, WordPress rebuilds every page from the database on every single visit. Page caching stores the finished result and serves that instead. This is usually the single largest improvement available on an unoptimised WordPress site, and it is free.
A bloated database
Post revisions, expired transients, orphaned metadata and spam comments accumulate silently for years. A database carrying tens of thousands of unnecessary rows makes every query slower. Cleaning it is routine maintenance that most sites never receive.
An outdated PHP version
Newer PHP versions are meaningfully faster than older ones. Running an end-of-life version is both a performance cost and a security risk, and upgrading is often a single click in your hosting panel. Take a backup first.
Cause two: your images are too big
This remains the most common frontend problem, and the most fixable.
A photo straight off a phone or a stock library can be 4000 pixels wide and several megabytes. Displayed in a 800-pixel-wide slot, the browser still downloads the entire original and then scales it down. The visitor pays the full cost for none of the benefit.
What to do:
- Resize before uploading. Nothing on a typical site needs to exceed about 2000 pixels wide.
- Use modern formats. WebP typically achieves substantially smaller files than JPEG at equivalent quality.
- Compress. Most photographs look identical at 80% quality and weigh far less.
- Lazy load below-the-fold images so they download only when the visitor scrolls near them.
- Always set width and height attributes. This costs nothing and prevents layout shift.
One important exception: do not lazy load your hero image. It is usually the element that determines your Largest Contentful Paint, and deferring it makes that metric worse rather than better.
Cause three: too much JavaScript
Symptoms: the page looks ready but does not respond to taps, menus lag, and forms feel sticky. This is what fails Interaction to Next Paint.
JavaScript is expensive in a way images are not. An image downloads and displays. A script downloads, then parses, then executes, and while it executes the browser cannot respond to anything the visitor does.
The usual sources:
Plugins you no longer use
Deactivating a plugin is not the same as removing its effect on pages built while it was active. Audit honestly: if you cannot name what a plugin does for you, it is a candidate for removal.
Third-party scripts
Chat widgets, heat mapping, multiple analytics tools, social embeds and advertising pixels each add weight, and you control none of their performance. A single chat widget can add several hundred kilobytes. Keep the ones that earn their place and remove the rest.
Page builder overhead
Builders load supporting JavaScript and CSS across the site regardless of whether a specific page uses those features. This is the price of visual editing. It is often a reasonable trade, but it should be a conscious one.
Cause four: too many requests and no compression
Every separate file is a round trip. Sites that load thirty stylesheets and forty scripts spend much of their time simply asking for things.
Standard fixes, all of which are configuration rather than redesign:
- Enable GZIP or Brotli compression on the server. Text files typically compress dramatically.
- Minify CSS and JavaScript to strip whitespace and comments.
- Set browser caching headers so returning visitors do not re-download unchanged assets.
- Use a CDN to serve static files from a location near the visitor.
- Limit web fonts. Each family and weight is another download. Two families is usually plenty.
A diagnostic order that saves time
- Check TTFB. High means fix hosting, caching, database and PHP version before anything else.
- Check your largest downloads in the browser network tab. If images dominate, fix images.
- Check whether the page responds while loading. If not, you have a JavaScript problem.
- Count your requests. If you are loading dozens of files, enable compression, minification and caching.
- Re-measure after each change, one at a time, so you know what actually worked.
What not to do
Do not install five optimisation plugins. They conflict, and each adds its own overhead. One well-configured caching and optimisation plugin is correct.
Do not chase a perfect score. A score of 100 in a lab test is not the goal. Real visitors on real devices are the goal, and the two are not the same thing.
Do not buy faster hosting first. It is the most expensive fix and, unless TTFB is genuinely poor, often the least effective. Establish the diagnosis before spending money.
What to take away
Slowness has four common causes: a slow server, oversized images, excessive JavaScript, and too many uncompressed requests. Time to First Byte tells you which half of the problem you have. Images and configuration fixes are cheap and usually deliver the largest immediate gain. JavaScript problems are the hardest, and the honest fix is usually to ship less of it rather than to add another tool.
If you want the diagnosis done for you, performance work is part of how we handle modern website development and every maintenance plan. It also helps to know what the numbers mean first, which we cover in our guide to Core Web Vitals.
