What actually makes a website slow
Most speed advice targets the wrong half of the problem. Here is how to tell whether your site is slow because of the server or because of the browser, and why that distinction decides everything you do next.
Almost every conversation about a slow website starts with a score from a testing tool and ends with somebody installing a caching plugin. Sometimes that works. Frequently it hides the problem well enough that nobody investigates it for another year, at which point it's worse.
There's a more useful first question, and it takes about thirty seconds to answer.
Server time or browser time?
A page load has two distinct phases. First the server receives the request and builds the page. Then the browser receives what it built and draws it. Nothing that fixes one phase does anything at all for the other, which is why so much performance work produces no result: it was aimed at the wrong half.
The measurement that separates them is time to first byte: how long the browser waits before it receives anything at all. Every browser's developer tools show it, as do most testing services.
One caveat, because it sends people down the wrong path more than anything else here. Time to first byte isn't purely server time. It also contains the redirect chain, the DNS lookup, and connection and TLS setup. A single unnecessary redirect or a distant origin can add several hundred milliseconds with the application doing nothing at all, so check those timings before you go looking at PHP.
| What you see | Where the problem is | What to look at |
|---|---|---|
| High time to first byte, page renders quickly once it arrives | Before the first byte | Redirect chains, DNS and TLS setup first; then PHP execution, database queries, plugin overhead, missing caching, undersized hosting |
| Fast first byte, then a long wait before anything appears | The browser | Render-blocking CSS and JavaScript, web fonts, third party scripts |
| Content appears then jumps around | Layout stability | Images and embeds without reserved space, late-loading fonts, injected banners |
| Fast for you, slow for customers | Caching or geography | Logged-in versus logged-out behavior, cache misses, distance from the server |
Interpreting time to first byte
When the server is slow
Database queries
The most common cause on established WordPress and WooCommerce sites, and the hardest to see from outside. Typically a query running once per item inside a loop, a table nobody indexed, or an options table where years of plugin leftovers are set to load on every single request. On that last one the number that matters is how much is autoloaded, not how large the table is.
A profiler that shows queries per page and time per query will usually identify the responsible plugin within minutes. Guessing won't.
Plugin overhead
Every active plugin runs on every page load unless it has been written not to. A plugin that adds a few hundred milliseconds is invisible on its own, and there are usually several of them.
Hosting capacity
Shared hosting typically allows a small number of concurrent PHP processes. Once they're all busy, further requests queue, and the site becomes dramatically slower at exactly the moment traffic increases. No amount of application optimization fixes an undersized machine, and no amount of hardware fixes a query running a thousand times.
When the browser is slow
Images
Still the largest single win on most websites. The usual pattern is a photograph uploaded at camera resolution, served at full size to a phone, in a format from the 1990s, with no lazy loading.
Correctly sized, modern format, lazy loaded below the fold, with width and height attributes so nothing shifts. That combination is undramatic and it routinely removes more weight than every other change on this list combined.
Render-blocking resources
A stylesheet or a script the browser won't draw the page without, sitting in front of content that was ready two seconds ago. Frequently the file being waited on styles a section the visitor hasn't scrolled to yet.
Third party scripts
Chat widgets, tag managers, analytics, heatmaps, review widgets, advertising pixels and hosted fonts. Each one is a connection to somebody else's server, and each one can block your page while it responds.
This is worth auditing rather than optimizing. In our experience a meaningful share of the third party scripts on a typical business site are for tools nobody uses any more, and removing them is free.
Web fonts
Three families in five weights is a large download and a rendering delay. Two weights of one family, self-hosted, with a metric-matched fallback, is nearly always enough and is noticeably faster.
The measurement trap
Testing tools give you a score. Scores are useful diagnostics and terrible goals, because it's entirely possible to optimize for the test rather than for the visitor.
What matters is field data: how the page performs for real people, on real devices, on real connections, in the places your customers actually are. A perfect score from a test server on a fiber connection tells you very little about somebody loading your site on cellular in a parking lot.
A sensible order of work
- Measure time to first byte and decide which half you're fixing.
- Fix images. It's nearly always the largest single win and it's cheap.
- Audit third party scripts and remove what nobody uses.
- Profile the application if the server half is slow, and fix the specific queries or plugins responsible.
- Set up caching correctly, with cart, checkout and account pages excluded.
- Reassess hosting only after the application is behaving, unless the machine is obviously undersized.
- Measure again on the same test, and write down what changed.
The unglamorous conclusion is that most performance work is subtraction. Fewer scripts, fewer plugins, fewer fonts, smaller images. That's less satisfying than a configuration change and it lasts considerably longer.
