A slow website and a website that collapses the day the newsletter goes out are not two degrees of the same problem: they are two different problems, with two different causes and two different repairs. The first comes from a site that is too heavy or poorly served, the second from a resource ceiling that has been hit. The most common reflex, installing one more caching plugin, fixes neither. Here is the diagnostic method we follow, layer by layer, from the server down to the browser.
Slow, or saturated? Two different problems
Constant slowness is reproducible: the site takes four seconds to appear at 3 in the morning just as it does at noon. Saturation is a threshold effect: everything is fine until the number of simultaneous visitors exceeds what the plan allows, and then everything goes down at once.
Three observations settle it in a minute. Run a speed test at a quiet hour, then a second one during a peak: if the gap is small, you have a weight problem, not a capacity problem. Next, look at whether the errors arrive in waves, with visitors served normally in between, which is the signature of a saturated queue. Finally, open the hosting contract and look for the number of simultaneous processes allowed: that figure, not the advertised power, is what decides how much the site can take.
| What you observe | Constant slowness | Saturation |
|---|---|---|
| Timing | The same day and night | Only at peaks |
| Symptom | Pages slow to appear | 503 or 508 errors in waves |
| Dominant cause | Page weight, no cache | Process or memory ceiling |
| First repair | Cache, images, database | Edge cache, then capacity |
Reading the errors the server sends back
The codes your visitors see are a free diagnosis, provided you know how to read them (the HTTP response status code reference on MDN, in its French edition).
503, service unavailable
The server refuses to answer because it is busy or has deliberately been put into maintenance. Nine times out of ten on WordPress, the PHP process queue is full: every request the cache does not serve ties up a process, and once they are all taken, the next ones are turned away. A security plugin or upstream filtering can produce the same code.
504, gateway timeout
One link in the chain waited too long for another, typically PHP waiting on the database. Look for a slow query, an import in progress, a heavy scheduled task or a call to an external API with no timeout set. A 504 almost always points to one specific operation, not to a general shortfall.
508, resource limit reached
This message is specific to shared hosting: the account has gone over its quota of memory, processes or input/output. It is not an outage, it is a contractual ceiling. A useful detail to know: in the HTTP standard, code 508 means something else entirely; this usage is a hosting convention. In other words, the server is fine, it is your share of the server that is full.
429 and upstream blocks
Too many requests in too little time. The usual culprit is not a visitor but a bot: a badly configured crawler, a content scraper, or a low-intensity attack that is not trying to bring the site down but manages it as a side effect. The server’s access logs give the IP address and the pattern in a few lines.
The measurement chain, from server to browser
Four tiers, four indicators and, above all, four different owners.
- Server response time, or TTFB, measures the delay before the first byte. A good benchmark is under 0.8 seconds. This is the tier of hosting, server cache and database.
- LCP measures when the largest visible element is displayed; the target is 2.5 seconds or less. This is the tier of images, fonts and the critical path.
- INP measures responsiveness to interactions; the target is 200 milliseconds or less. It replaced FID in March 2024, and a good many French-language articles still quote the old metric. This is the JavaScript tier.
- CLS measures visual stability; the target is 0.1 or less. This is the tier of image dimensions and banners inserted after the fact.
These thresholds are judged at the 75th percentile of real visits, mobile and desktop combined (Core Web Vitals on web.dev). Above all, remember the triage rule: a bad server response time is never fixed by optimizing images. If the TTFB is at two seconds, compressing the photos will change nothing, because nothing has even started to display by the time those two seconds are up.
The seven causes that come up almost every time
- Undersized shared hosting, or a noisy neighbor. Symptom: slow spells at certain times of day that bear no relation to your traffic. Check: compare your visitor curve with the slowness curve. If they do not overlap, the problem is not on your side.
- No page cache, or a cache that has been neutralized. Symptom: the TTFB is the same on the first visit and on the second. Check: look at the response headers. A plugin that forces personalization onto every page switches the cache off without saying so.
- A database that has never been maintained. Post revisions by the hundred, expired transients never purged, options loaded on every page. Check: the volume of autoloaded options; beyond one megabyte, every page picks up the bill.
- Images neither compressed nor resized. Symptom: a 3 MB photo displayed in a 400 pixel frame. Check: the total page weight in the browser’s network tab. This is the most rewarding item, and the simplest.
- A page builder that stacks containers and scripts. Symptom: a brochure page that loads thirty files to display three paragraphs. Check: the number of requests and the weight of the JavaScript.
- Third-party scripts. Ad trackers, social widgets, chat bubbles, assorted banners: each one adds a connection to a domain you do not control. Check: sort the requests by domain and look at what is not yours.
- A slow query caused by a badly written plugin. This is the real culprit on many online stores: a product search filter, a stock calculation or a loyalty module that queries the database on every page view. Check: a query profiler, or a read through the database’s slow query log.
Fixing things in the right order
The order is decided by the ratio of effort to gain, never by technical enthusiasm.
First, what is free and immediate. Switch on a page cache with correct exclusions for the cart, the checkout and the customer account. Compress and resize the images, serve modern formats, declare dimensions in the code to remove layout shifts. Purge the revisions and the transients. In half a day, an ordinary site often gains back half of its display time.
Next, what needs sorting through. Go through the plugins one by one and remove those whose purpose nobody can name. Challenge every third-party script with the only question worth asking: what happens if I take it out? Move scheduled tasks outside traffic hours. One high-yield detail on busy sites: by default, WordPress fires its scheduled tasks on the back of visits, which makes a random visitor pay the cost of a backup or a newsletter send. Switching that trigger to a system task on the server removes that element of chance.
Finally, what costs money. Moving up in infrastructure, or rebuilding the site’s front end. Going from shared hosting to a dedicated server before doing the first two steps amounts to paying every month to mask a defect in the code: the site will be a little faster, it will still be heavy, and the bill, for its part, will be permanent.
Where we stand: when changing host becomes the right decision
We would rather lighten a site than overfeed it. But there are cases where migration is the right answer, and they can be identified without a sales pitch:
- Saturation persists even though the site has been lightened and the cache is working.
- You cannot choose your PHP version, which condemns you to stay on a release that no longer receives fixes.
- The hosting offers neither server cache nor object cache, so nothing to absorb the peaks.
- There is no staging environment, so no way to test without risk.
- Your peaks are predictable: campaigns, seasonality, press coverage. In that case, putting an edge cache in front of the site absorbs most of the load at a cost that bears no comparison with an oversized server.
The choice of plan matters more than the name of the host: we set out the criteria in how to choose web hosting. And if your slowdowns turn into complete outages, it is no longer a performance question: follow the protocol for the first sixty minutes. For a measured assessment, we offer a performance audit and intervention that always begins with measurement, never with a recommendation to buy.
A site that goes down at peak times almost always lacks dedicated resources: that is what our managed cloud hosting in Pau, in south west France, puts right.
Conclusion
Speed is not a setting, it is a consequence. A lean site, well hosted and maintained, is fast without effort; a heavy site will stay slow whatever power you buy, and will simply cost more to host. That is exactly the logic of sustainable web design, building a light, fast site: fewer resources consumed, less energy spent, and a faster site for everyone. Start by measuring your TTFB: that one figure will tell you whether the problem comes from the server or from the page.
Also worth reading: page speed, SEO and the impact on your conversions
Have my site’s performance audited Talk hosting and infrastructure
