A website is slow when the server takes too long to prepare the page or the browser takes too long to download and draw it, and in most cases the culprit is a cache that isn't working, heavy resources, third-party scripts or a server under load. To work out which of these is yours, the useful question is slow for whom, where and since when: each answer rules out half the causes.
Put like that, it sounds obvious.
Yet the usual reaction is different: you open the site, it seems slow, you install a caching plugin or ask for a quote to move hosting. Sometimes it works. Often it doesn't, because you've treated the wrong symptom.
The mistakes we see most often are three:
- testing while logged in to the WordPress dashboard, which means judging a version of the site visitors never see;
- moving hosting when the slowdown comes from a plugin, or rewriting the theme when the problem lies with the provider;
- compressing images while the server answers thousands of bot requests that never show up in Google Analytics.
Our projects keep reminding us. The online shop of Scovaventi, an Italian food producer, was getting visits but not selling: slow pages, a CMS that worked poorly on smartphones, a checkout that made people abandon their baskets. Once the store was rebuilt on Shopify, it generated €77,000 in sales in twelve months with an average basket of €190.
Bosatta, which makes spare parts for Vespa scooters and Piaggio group motorcycles, had a similar bottleneck on an outdated CMS: after the new purchase journey it sold €240,000 in a year across four markets.
And what does that have to do with speed?
In both cases the slowness wasn't going to be fixed by compressing photos: the problem was the platform. It was the diagnosis that decided the fix, not a list of tips.
Here you'll find:
- what the eight UK page-one guides for "why is my website slow" cover, and what they all skip;
- a symptom, cause, first check table to use before you touch anything;
- our test of visilay.com's response time with and without the login cookie;
- the numbers on AI crawler traffic, which none of those UK guides mentions;
- what to look at when only the admin area is slow.
Let's start.
What the UK guides to "why is my website slow" cover (and the five cases they skip)
On 10 October 2026 we read the results Google UK shows on mobile for "why is my website slow", leaving out the AI Overview, forums and "People also ask". There were eight organic results, all readable. For each one we noted whether it deals with five situations in which a site is slow only for some people or only at certain times.
| Guide | Logged-in user | Bots and AI crawlers | Admin area only | Suddenly slow | Mobile only |
|---|---|---|---|---|---|
| wowvisible.com | no | no | no | mention | yes |
| hostiserver.com | mention | no | no | mention | yes |
| seo.com | no | no | no | mention | mention |
| castus.co.uk | mention | no | no | no | mention |
| everbluedigital.com | no | no | mention | yes | mention |
| virtualstacks.com | no | no | no | no | yes |
| znetlive.com | no | no | no | no | no |
| servebolt.com | no | no | no | no | mention |
| Total | 0 out of 8 (2 mentions) | 0 out of 8 | 0 out of 8 (1 mention) | 1 out of 8 (3 mentions) | 3 out of 8 (4 mentions) |
All eight list more or less the same causes: cheap hosting, heavy images, render-blocking code, too many plugins, no caching. It's also what the AI Overview above the results repeats. They're real causes, but they assume a site that is slow all the time and for everyone, which is only one of the possible cases.
In Google's US results for the same query the picture is similar, with one exception: the Calibre guide by Karolina Szczur, dated May 2026, has a section on aggressive bot and AI crawler traffic. None of the eight UK pages has done the same.
The symptom tells you where to look (the first-ten-minutes table)
Slowness nearly always has a "where" and a "when". This is the table we use before opening any testing tool.
| Symptom | Most likely cause | First check |
|---|---|---|
| Slow only for you, fast in incognito or on another phone | Login session that bypasses the cache, browser extensions, network | Same page in an incognito window and on mobile data |
| Suddenly slow, from one day to the next | Plugin or theme update, new script, provider fault | What changed in the last 48 hours; another site on the same hosting |
| Slow in waves, with high CPU or bandwidth but normal visits in Analytics | Bots and AI crawlers | Server access logs grouped by user agent |
| Only the WordPress dashboard is slow | Autoloaded options, Heartbeat, heavy back-end plugins | Tools > Site Health; the Query Monitor plugin |
| Slow only on mobile | JavaScript tying up the phone's processor | INP in Search Console's Core Web Vitals report |
| Only some pages are slow | Filters, site search, URL parameters the cache doesn't serve | Same page with and without parameters |
| Always slow, for everyone | Loading: server, discovery and weight of resources | LCP breakdown in PageSpeed Insights |
The sections that follow take the rows one at a time.
Slow only for you? Log out of WordPress first (our test)
When you're logged in to the WordPress admin, the browser sends a login cookie with every page and caching systems treat that visit as personal: the ready-made copy of the page, the one visitors get, isn't served to you. The server rebuilds it, or uses a private cache just for you.
How much difference does it make in practice?
We measured it on visilay.com.
| Page | Visitor without login (median) | With login cookie (median) | Ratio |
|---|---|---|---|
| Homepage | 77 ms | 318 ms | 4.1 times |
| Blog article | 49 ms | 308 ms | 6.3 times |
| Service page | 45 ms | 286 ms | 6.4 times |
With the cookie the response is four to six times slower, and in the worst case it hit 2.2 seconds, against a maximum of 151 ms for the homepage served from cache.
For visitors, the site was the same throughout.
Some plugins soften the effect. LiteSpeed Cache, for example, has a Cache Logged-in Users option switched on by default, which keeps a private copy for each user: from the second visit things improve, but it's still a different cache from the public one.
The rule that comes out of it is simple: judge speed in an incognito window, or better still on a phone using mobile data. If the site is fast there, the problem isn't the site.
The same goes for your connection. If other sites slow down too, the bottleneck is the network or the browser, and extensions that block or add scripts are a classic. The Ofcom figures we quote in our page speed guide show that in the UK mobile bandwidth is rarely the limit; the office Wi-Fi sometimes is.
Suddenly slow? Look for what changed (including outside your site)
A site that worked yesterday and doesn't today nearly always has a cause with a date on it: an automatic plugin or theme update, a script added for a campaign, a change to the server configuration, sometimes an intrusion (the warning signs are in our guide to website security). The first question is what happened in the last 48 hours and who has access to the site.
Sometimes, though, nothing on the site has changed.
In November 2025 a B2B manufacturer we work with wrote to us: the site had suddenly become slow. Suspicion fell on the page builder, which was stuck on an old version. Backup, update, no improvement. In the WordPress tools a precise error showed up, cURL error 28: Operation timed out after 10001 milliseconds: the server couldn't complete outgoing connections within 10 seconds.
The check that settled the diagnosis took a minute: we opened another client's site hosted by the same provider. That one was slow too. The fault lay with the hosting company, and no work on plugins or code would have fixed it.
Since then, faced with "the site's been slow since this morning", the first step is always that: another site on the same hosting and the provider's status page, before touching the theme or plugins.
There's an SEO reason not to let it slide, too. In its guide to managing crawl budget, updated in July 2026, Google writes that when a site slows down or responds with 5xx and 429 errors, its crawl capacity limit goes down and Googlebot crawls less. A server that struggles for days also slows down how quickly new pages get into the index: the mechanism is explained in our guide to crawling.
The traffic Analytics doesn't see: bots and AI crawlers (and what they cost a server)
AI crawlers are the programs OpenAI, Anthropic, Perplexity and others use to download web pages to train their models or build their answers. Hardly any of them run JavaScript, so they don't appear in Google Analytics: to the server they're real visits, to your reports they don't exist.
The available figures come from networks and sites with global traffic:
- On the Vercel network, in one month at the end of 2024, GPTBot made 569 million requests and Claude's crawler 370 million, together about 20% of Googlebot's volume. 34.8% of ChatGPT's requests ended up on 404 pages, against 8.2% for Googlebot.
- Read the Docs, which hosts documentation for thousands of open source projects, saw a single crawler download 73 TB of files in May 2024, almost 10 TB in one day, running up over $5,000 in bandwidth costs. Once crawlers were blocked, download traffic fell by 75%, from about 800 to 200 GB a day (Eric Holscher, Read the Docs).
- The Wikimedia Foundation calculated that bots generate about 35% of page views but at least 65% of the most expensive traffic to serve, and that bandwidth for multimedia files has grown by 50% since January 2024.
- According to Cloudflare, in the twelve months to July 2025, 80% of AI crawling was for model training. In July 2025 Anthropic made about 38,000 crawls for every visit it referred back to a site, OpenAI about 1,100.
And on a small business site? We counted the bots on ours: between 31 August and 27 September 2026, across about 199,000 lines of visilay.com logs (a site whose audience is mostly Italian), OpenAI's bots made 4,773 requests, more than three times Googlebot's 1,355. The method is explained in the article on AI crawlers linked below.
The 404 detail is what weighs most on a small site. A page that doesn't exist often isn't cached, so every old or made-up URL a crawler requests is processed from scratch by PHP and the database.
The Calibre guide describes the signal to look for well: CPU or bandwidth spikes with no matching rise in visits in Analytics. At that point you need the server's access logs grouped by user agent, and a few minutes are usually enough to see who's asking for what.
So should I block them all?
Not necessarily. Blocking GPTBot or ClaudeBot in robots.txt cuts the load, but it removes your content from the sources AI tools build their answers from: for a company that wants to appear in ChatGPT, that's a cost. The sensible route usually lies in between: rate-limit requests with the CDN firewall, serve pages from cache to bots as well, and shut out only the crawlers that bring nothing. How to recognise them is explained in our article on AI crawlers.
Is your server working for visitors you can't see?
You've just seen how a single crawler can download more in a day than a site serves to real customers in months. We read your server logs, separate people, Googlebot and AI crawlers, and tell you what to limit without disappearing from ChatGPT's and Google's answers.
Book a strategy consultationOnly the WordPress dashboard is slow: the problem is behind the scenes (autoload and Heartbeat)
If the public site is fast but the admin area isn't, page loading has little to do with it. According to W3Techs, in October 2026 WordPress is used by 40.1% of all websites and by 58.6% of those with an identifiable CMS: it's the case we come across most often.
There are two things to check first.
1. The settings loaded on every request
On every request WordPress loads into memory a group of settings marked "autoload", and uninstalled plugins often leave some behind. Since version 6.6, released in July 2024, options larger than 150 KB are no longer loaded automatically, and the Tools > Site Health page warns you when the total goes over 800 KB (technical note by Paul Bearne and Joe McGill on the core blog). If you see that warning, you've found a suspect.
2. The requests the dashboard makes on its own
The Heartbeat API keeps the dashboard up to date (autosaves, locking posts being edited, notifications) by sending a request to the server at intervals of between 15 and 120 seconds, according to the developer documentation. Ten editor tabs open across three people make dozens of requests a minute that no cache can serve, and on shared hosting you feel it.
To find out which plugin slows down a screen you need Query Monitor, which shows the time taken by each database call and what made it. Many of these problems start when the CMS and theme are chosen, long before anyone complains.
Slow only on mobile or only on some pages (here the server is innocent)
When the site is slow only on smartphones, the bottleneck is nearly always the phone's processor, kept busy by JavaScript from themes, chat widgets, pixels and tracking tools. It's measured by INP, the responsiveness metric in Core Web Vitals: in our page speed guide we show how the gap between desktop and mobile is concentrated right there. It was also the case with Scovaventi, where the old CMS made the shop awkward to use on a smartphone.
When only some pages are slow, look at the URL. Online shop filters, sorting and site search add parameters, and many cache set-ups treat each combination as a new page to generate.
In the first round of our test on visilay.com, the same page with a random parameter added to the URL responded in 253-269 ms, against 70-85 ms for the version served from cache: the same jump as with the login cookie. On a catalogue with thousands of filter combinations, and crawlers following all of them, the bill grows quickly.
The other pages that are slow by design are those with embedded videos, maps and third-party forms: each one brings files from external domains you don't control.
Always slow, for everyone: then it's loading (and you work in phases)
If the site is slow in incognito, on mobile and on desktop, at any time of day, you're in the last row of the table. Here the causes in the page-one guides are the right ones, but the order matters more than the list.
Google considers a time to first byte of up to 0.8 seconds good (web.dev): if you're above that, the work starts with the server and the cache, not the images. If the server responds quickly but the main content appears late, the problem is how the browser discovers and downloads resources. The full procedure, phase by phase, is in our guide on how to speed up a website, and for photos there's the one on image optimisation.
Sometimes the cause is more mundane than it looks. On a group of B2B sites we look after, the largest element on the page as far as Google was concerned was the cookie banner: once it was made smaller from the consent platform's console, the LCP warnings cleared. No change of hosting, no theme rewrite.
These checks are part of the technical SEO we handle in our SEO consultancy projects. And when the problem is the platform, as with Scovaventi and Bosatta, speed is decided before the site goes live, in our website development projects.
Frequently asked questions about slow websites
It depends: speed is one of the page experience signals, but Google says that good results in its reports don't guarantee rankings and that the most relevant content can win even with poor page experience. The more direct effect is another one: a server that is slow or responds with 5xx errors reduces how much Googlebot crawls and slows down the indexing of new pages.
It depends: it helps if time to first byte stays high even with caching on, or if the provider has recurring faults. It doesn't help if the slowness comes from scripts, images or plugins: a more powerful server just generates the same heavy page a little faster.
No, if it's fast in incognito and on another device. When you're logged in, the login cookie bypasses the public cache: in our test on visilay.com the response was 4 to 6 times slower. That's what you see, not what your customers see.
Yes, if they're the ones overloading the server: Read the Docs cut its download traffic by 75% by blocking them. The cost is disappearing from the sources ChatGPT, Claude and Perplexity use to answer, so it's better to rate-limit requests first and block only those that bring no visits.
No. It serves the ready-made page to anonymous visitors, but it doesn't help the admin area, pages with URL parameters, logged-in users or JavaScript slowing the phone down. It's the first fix for response time, not the only one.
Summary in five lines (and who is really visiting your site)
Slow for whom: test in incognito, never while logged in.
Slow since when: look for the date, including outside the site.
Slow with normal visits: look at the logs, not Analytics.
Slow only in the dashboard: autoload, Heartbeat and back-end plugins.
Always slow: server, cache and images, in that order.
Ten years ago the question "why is my website slow" had an answer that was only about people. Today some of the visitors to your site aren't people, and deciding how many of them to serve, with what priority and in exchange for what is a marketing decision before it's a technical one. If you leave it to your hosting's default settings, you're still making it, just without knowing.
If you want to work out which row of the table is yours, we can look at it together in a consultation, starting from your server and Search Console data. See you next time!
