If you searched “why is my website so slow,” you probably already have one page in mind – the one you keep checking on your phone over lunch, the one that shows a blank white screen for two seconds before anything appears. Here is the part the plugin ads skip: “slow” is not one problem. It is at least four, they have different causes, and fixing the wrong one is how people lose a fortnight to speed plugins that change nothing.
Work out which kind of slow you have first. Everything after that gets easier.
Your site isn’t slow. One of three things is.
Performance people split “speed” into phases, and each phase has a different owner. The server answers, or it doesn’t. The browser paints the main content. The page responds when someone taps. The layout stays where it’s supposed to. When a reader says a site is slow, they usually mean the last three, but the cause is often the first.
Google bundles the important ones into Core Web Vitals, measured on real Chrome visits rather than a lab machine. The thresholds are worth knowing, because they tell you what “fixed” actually means:
Thresholds per Google’s Core Web Vitals guidance; TTFB is an experimental PageSpeed Insights metric. Google grades at the 75th percentile of real visits, not your best test run.
That last line matters more than it looks. A page can score 100 in a lab and still flunk in the field, because your actual visitors are on mid-range Android phones with patchy signal, and their experience is the one that counts.
Nine causes, in the order I would fix them
1. Your server takes too long to answer
Time to first byte is the floor under everything else. If your server takes 1.2 seconds to send the first byte of HTML, no image trick gets you to a comfortable 2.5-second LCP, because the browser is still waiting for instructions. On cheap shared hosting that wait is a queue: your request sits behind hundreds of others, PHP runs without an opcode cache, and every page view queries the database from scratch.
Check TTFB on a page that isn’t behind a full-page cache. If it’s over 800ms, that’s your problem, and I would fix it before touching a single image. The fixes are unglamorous: a host that runs a real object cache, opcache switched on, HTTP/2 or HTTP/3, and server-level caching for anonymous visitors.
2. Every visitor downloads the same files from the same building
Your logo, fonts, CSS and product photos don’t change between visitors, yet without a CDN every one of them travels from your single server to a phone that might be an ocean away. Distance costs round trips, and round trips cost you hundreds of milliseconds you can actually measure.
A CDN copies your static files to edge locations near your visitors, so the request never crosses the planet. The 2025 Web Almanac found that 71% of third-party content already travels by CDN while only 35% of HTML does, which tells you where the easy win sits. Start with images, CSS, JavaScript and fonts.
3. Your images are ten times bigger than they need to be
Images are still the heaviest thing most pages download, and they’re still mostly the wrong format. HTTP Archive’s 2025 crawl found JPG as the LCP image on 57% of pages and PNG on 26%, with WebP at 11% and AVIF under 2%. A hero photo exported at 4000 pixels wide and displayed at 800 is not a hero; it’s a punishment.
Serve WebP or AVIF – WebP is typically 25–35% smaller than JPEG at the same visual quality – size images to the space they actually occupy, and use srcset so phones don’t download desktop-sized assets.
4. You are shipping JavaScript nobody uses
This is the expensive one, because JavaScript charges you twice: once over the network, once on the CPU. The 2025 Web Almanac puts the median home page at roughly 632 KB of JavaScript, 251 KB of it unused, spread across a median of 72 requests.
Catchpoint’s 2025 SaaS benchmark is a tidy illustration. ClickUp loaded 144 resources, 115 of them scripts, and averaged 9.6 seconds for a full page load; Tableau shipped 19 resources, only 8 of them scripts, and finished in about one second. Same job, very different bill. The fix is boring: defer or async what isn’t critical, delete what nothing uses, and audit tags before adding another one.
5. The page is built in the browser, not on the server
Single-page apps often send a nearly empty HTML shell and let JavaScript assemble the content. That means the hero image and headline only exist after the framework downloads, parses and runs – a request chain that delays the exact element Google measures for LCP. Server-side rendering or pre-rendering the critical pages fixes it. Adding more client-side code does not.
6. You lazy-loaded the one image that should never be lazy-loaded
This is the most self-inflicted wound on the list, and it’s spreading: about 16% of pages still put loading=”lazy” on their hero image. Lazy loading tells the browser to wait, which is exactly wrong for the element above the fold. Keep eager loading with fetchpriority=”high” on the LCP image, preload it, and don’t let JavaScript insert it after the fact.
7. Third parties are writing cheques your main thread can’t cash
Analytics, chat widgets, ad pixels, tag managers, review carousels – each is a small tax you agreed to once and now pay on every page load. Yottaa’s 2025 index, built on more than half a billion shopping visits, attributes 44% of page load time to third-party apps, and HTTP Archive found that more than nine in ten pages include at least one third party.
The answer isn’t “delete analytics.” It’s deciding which scripts genuinely need to run before a user does anything. Load chat and ads after interaction, swap the full widget for a lightweight facade, and check what each tag costs before you approve it.
8. Your cache is a placebo
A caching plugin with a near-zero hit rate is decoration. Static files should carry long max-age headers, HTML should be cached for anonymous visitors, and anything that breaks caching – unique tracking parameters on URLs, cookies on static assets – should be cleaned up. Verify that requests are actually being served from cache rather than trusting the plugin’s dashboard.
9. The database is full of ghosts
On WordPress and similar CMSs, slowness often lives in the database: thousands of post revisions, expired transients, orphaned tables from plugins you deleted, and queries firing on every page view. Stack enough plugins that each add their own assets, and you’ve built a fast server into a slow site. Clean the database, cut plugins you don’t use, and be honest about what each remaining one earns.
What actually moves the needle, and what just feels productive
If I ranked the nine by payoff:
- Server response – fixes a whole class of symptoms at once.
- Images and LCP handling – usually the single biggest LCP gain.
- JavaScript reduction – the difference between “loaded” and “usable.”
- Third-party cleanup – often the cheapest large win.
- Everything else – real, but diminishing.
The common mistake is ordering them by how easy they are to install rather than by what’s actually broken. And the underlying problem is getting worse, not better: despite a decade of advice, the 2025 Web Almanac found the median mobile page’s total blocking time rose 58% year over year to 1,916 milliseconds, meaning the average page spends nearly two seconds unable to respond to a tap.
The uncomfortable part: this is a revenue problem before it’s a ranking problem
A lot of speed content sells itself as an SEO fix. The reality is narrower, and I think the revenue framing is the stronger one.
Core Web Vitals is a confirmed Google ranking signal, but a small and situational one. Google’s documentation says good vitals “align with what our core ranking systems seek to reward,” and John Mueller has been blunt that a perfect score is “not going to make your site’s rankings jump up.” Since 2023, Google has described page experience as a signal other systems read, not a ranking system of its own. In practice the vitals behave like a tiebreaker: when two pages are equally relevant and equally trusted, the faster one tends to edge ahead. When they aren’t equally relevant, a tenth of a second changes nothing.
Where speed pays reliably is the part of the funnel you can watch in analytics. Bounce rates climb sharply past four seconds. Yottaa put the bounce rate for pages loading in over four seconds at 63%, against 45% for pages that loaded within four. Conversions fall, ad revenue falls, and every slow page multiplies the cost across every visitor.
One widely repeated number deserves a warning here. “Every one second of delay cuts conversions by 7%” traces back to an Akamai finding of 100 milliseconds and 7% – not a full second. The garbled version has travelled further than the real one, which should make you sceptical of any load-time statistic you can’t trace to a named report.
When to fix it yourself, and when to hire it out
Some of this is genuinely DIY: compressing images, switching formats, deferring scripts, checking cache headers. Some of it isn’t. Server tuning, server-side rendering, database work and render-blocking JavaScript all need someone comfortable in code and infrastructure.
If two or three items from that list sit outside your comfort zone, that’s the point to bring in a Web Development Company that does performance work, rather than stacking another plugin on top of a problem the plugin can’t see. Ask for field data before and after, not a lab score.
Questions people actually ask
How fast should my website load?
Why is my site slow on mobile but fine on desktop?
Does a slow website hurt SEO?
Will a caching plugin fix my slow website?
How do I test my website speed for free?
A one-hour triage for a slow site
You don’t need to fix everything today. You need to stop fixing things at random.
- Run the home page and one key landing page through PageSpeed Insights, and note TTFB, LCP and INP from the field data.
- If TTFB is over 800ms, that’s the job this week – hosting, caching, server config.
- If LCP is over 2.5s, inspect the LCP element: is it an unoptimised image, a lazy-loaded hero, or blocked by scripts?
- If INP is over 200ms, count JavaScript files and third-party tags before you write another line of code.
- If CLS is over 0.1, set explicit width and height on images and reserve space for ads and embeds.
A slow site is rarely one bug. It’s a stack of small taxes, and the one to pay off first is the one your visitors feel before they see anything at all.