“My site feels slow” is a symptom, not a diagnosis, and most troubleshooting goes wrong by jumping straight to a guess usually images, since that’s the cause everyone’s heard of without confirming where the time is actually going first. The frustrating part is that a slow site is almost always slow for a specific, findable reason. This is a diagnostic sequence that works through the actual delivery chain in order, rather than guessing at the most commonly cited cause and hoping it’s the right one this time.
Start by measuring, not guessing
Before touching anything, get an actual number. Google PageSpeed Insights, GTmetrix, and Pingdom Tools all give a breakdown of load time by phase rather than just a single overall score, and that breakdown is what tells you which section of this checklist to focus on. A site that’s slow because of Time to First Byte looks completely different in these reports from a site that’s slow because of a 4MB hero image, and troubleshooting the wrong one wastes real time. This step alone eliminates most of the guesswork that turns a fifteen-minute fix into a multi-hour investigation involving several people all pointing at different parts of the stack.
It’s worth knowing what you’re up against structurally, too: the median desktop home page now sits around 2.9 MB and the median mobile home page around 2.6 MB, and mobile page weight specifically has grown substantially over the past decade even as network speeds have improved. Pages have gotten heavier fast enough to cancel out a lot of the infrastructure improvements underneath them, which is part of why “slow” has become such a common complaint even on reasonably modern hosting.
Check server response time first
Time to First Byte how long the server takes to start sending a response is the foundation everything else sits on top of, and it’s worth ruling out before looking at anything in the browser. A slow TTFB usually traces back to one of a handful of causes: an undersized hosting plan struggling under real traffic, a database query that’s missing an index and scanning far more rows than it needs to, an empty or misconfigured cache forcing the server to rebuild a page from scratch on every request, or a plugin or CMS module that started misbehaving after an update. On a database-driven site, a single unindexed query on a large table can be dramatically slower than an indexed equivalent, which is exactly the kind of invisible cause that looks like “the server is just slow” until someone actually checks the query itself.
If TTFB is high and consistent across every page, the cause is almost always server-side hosting capacity, database performance, or caching rather than anything in the frontend code. If TTFB is fine but the page still feels slow, the problem lives further down this list.
Then look at what the page is actually shipping
Once server response time is ruled out, the next place to look is what the browser has to download and render. Oversized, uncompressed images are still the single most common frontend cause, and the fix is usually straightforward: compress existing images with a tool built for it, serve modern formats like WebP or AVIF instead of older formats, ensure images are sized appropriately for where they’re displayed rather than being scaled down in the browser, and lazy-load anything below the initial viewport so it doesn’t compete with content the visitor sees first.
Heavy, unoptimized JavaScript is the second major contributor, and it’s grown as a cause in step with the rise of page builders, heavier CMS themes, and JavaScript-driven frameworks. The practical fixes are minifying scripts, deferring or lazy-loading anything that isn’t needed for the initial render, and auditing whether every script currently loading is actually still in use it’s common for old tracking snippets, unused plugin scripts, or abandoned A/B testing code to keep loading long after anyone remembers adding them.
Don’t skip third-party scripts
This is the cause that gets missed most often, because it’s invisible in your own codebase. Analytics tools, payment processors, chat widgets, cookie consent banners, recommendation engines, and A/B testing platforms all load code from someone else’s server, and any one of them having a bad day can visibly slow down your site without anything in your own code having changed at all. Checking the network waterfall in your browser’s developer tools, or in a tool like GTmetrix, for third-party domains taking unexpectedly long to respond will usually surface this quickly. It’s worth periodically auditing every third-party script still loading on a site, since these tend to accumulate over time and rarely get removed even after the team that added them has moved on.
Check the CMS and plugin layer
For WordPress and similar CMS-driven sites specifically, an accumulation of plugins is a frequent and often underestimated cause, since each one adds its own code, its own database queries, and sometimes its own frontend scripts, whether or not a given page actually needs them. Disabling plugins one at a time and re-testing load time after each is a slow but genuinely reliable way to isolate whether one specific plugin, rather than the theme or hosting, is the actual culprit. Outdated or badly coded themes carry the same risk heavy animation libraries, unused feature bloat, and unoptimized template logic can all add measurable weight without providing any real benefit to most visitors.
Confirm caching is actually working
A page that rebuilds itself from scratch on every single visit, rather than serving a cached version to repeat visitors, is one of the most common and most fixable causes of a slow site. Confirming that browser caching headers are set correctly, that a server-side or plugin-based page cache is actually active and not silently failing, and that a CDN is properly caching static assets rather than passing every request back to the origin server, closes a surprising number of “why is this so slow” tickets on its own. This is worth checking directly rather than assuming it’s configured correctly just because a caching plugin was installed at some point caching configurations silently break more often than people expect, particularly after a theme or plugin update.
Why this matters beyond user annoyance
The business cost of skipping this diagnosis isn’t abstract. In e-commerce specifically, each additional second of load time costs roughly 7% in conversions which means a genuinely slow site isn’t just an inconvenience, it’s a direct and measurable revenue leak, and one that compounds the longer it goes undiagnosed.
The order matters more than the individual fixes
The reason to work through this in sequence measurement, then server response, then frontend assets, then third-party scripts, then CMS layer, then caching rather than jumping straight to whichever cause seems most familiar, is that it prevents the most common troubleshooting mistake: blaming the wrong layer entirely and spending hours optimizing images when the real problem was an unindexed database query the whole time. Working through the chain in order gets you to the actual cause in a fraction of the time that guessing does.
If server response time turns out to be the actual bottleneck rather than anything in the frontend, that’s usually a hosting and configuration issue rather than something more compression or a smaller JavaScript bundle will fix worth ruling out early rather than last, since it’s the one item on this list that makes every fix downstream of it less effective if it’s left unaddressed.
