Does hosting affect website speed? Only in the server's first answer. On my WordPress site a saved copy, not the plan, made it fast; a CDN copy had a trap.

The previous article ended at the server’s door, and only after one check: if the first answer is slow even on a page nobody visits, and the site already keeps a saved copy of its pages, the question goes to the host. This one starts there. A wait has three parts: the road between the visitor and the server, the server’s first answer, and the page’s own files. Hosting decides one of them, how long the server takes to send the first byte of a page. It does not decide how heavy your page is, how many fonts it asks for or what other companies’ scripts cost; those are the same on any host. So “does hosting affect website speed” has a short answer, yes, in one place, and a more useful one: how much of your wait is there, and whether the host or the way your pages are served is to blame.

Two checks before you pay for a bigger plan

1. Measure the server’s part. That is the “Waiting for server response” reading in Chrome, and the previous article shows how to take it without a developer. If it is a small share of the wait, a bigger plan buys you a smaller version of a small number.

2. Ask whether that answer came from a saved copy or was built from scratch. A WordPress page is assembled on every request, code, database and theme, unless something keeps a finished copy. On my WordPress site, kovalweb.com, the server spends about 10 ms when a copy exists and about 145 ms when it builds the page, in the readings below. The copy is usually a cache plugin or a feature the host switched on; in WordPress, Tools → Site Health tells you whether a page cache is in use, and the made-up parameter on the address from that same article gives you the built-from-scratch reading. If there is no copy, that is the first change, before any talk of a bigger plan. If there is one and pages it covers are still slow, the readings below show whether the host or the road is to blame.

What hosting changes, and what it does not

Google’s page on improving server response time sizes the host’s share: shared hosting, it says, is generally slower, and “If you’re running a small personal website that serves mostly static files, this is probably fine”, whereas “if you’re running a larger application with many users that involves personalization, database querying, and other intensive server-side operations, your choice of hosting becomes critical to lower TTFB in the field.” TTFB is the first byte, the server’s first answer. Mine is closer to the first case, and the readings below bear that out for it.

What the host does not decide is everything after that first byte. The WordPress hosting team’s page on performance says it about the saved copy itself: “Full Page Caching stores the HTML output of a request, but all the CSS, JS, images and font files will have to be loaded separately too.” Those files are your page’s own weight; on the two slow sites I measured for it, that was where the wait lived.

The road between the visitor and the server is the one a CDN is for: a service that stands between visitors and your server and can hand out stored copies from a location near them. The same WordPress page on performance warns: “Note, that if you don’t have full page caching on the CDN edges, this might increase the TTFB (time to first byte) because the node must fetch the data from the origin server before serving it to the end user.” In other words, a CDN that does not keep the page still has to fetch it from your server every time. That was my sites’ situation in every earlier reading.

Two days of readings, from one laptop

From 19 to 21 October 2026 a script on my laptop asked for my pages every fifteen minutes: the server’s first answer, and beside it the server’s own work, from a timing note the server sends with each page. One home connection, with a VPN on, mostly through one CDN location, to one server: not a study of hosting, but enough to set the two columns against each other.

The first day’s 99 readings of the home page, built from scratch on every request, split by the hour like this:

The total wait rose by about a tenth of a second from early morning to late afternoon; the server’s work stayed within ten milliseconds. And on kovalseo.com, a site of plain files where the server’s work is about 1 ms, on the first day the total wait drifted the same way, from 167 ms in the early morning to 239 ms in the late afternoon. The drift was never in the server. As far as I can tell it was the road: my connection, my VPN, the network at busy hours. Measure a site at noon and again at dawn and you may be measuring the hour.

That is the pattern to look for in your own readings. If the server’s part is flat and the total moves, moving host is unlikely to fix that movement. If the server’s part itself is large, the question is what the server is doing, and the next section answers it for WordPress.

WordPress: the saved copy on the server

The same series, before any copy at the CDN, gives the WordPress numbers side by side. The home page served from the cache plugin’s copy on the server: first answer 225 ms, of which the server’s own work was 9.6 ms. The same page built from scratch: 340 ms, of which 144.5 ms was the server’s. Nothing about the plan changed between the two; only whether a copy existed.

That is why “upgrade hosting” is usually the wrong first move on a WordPress site with no saved copy. A faster server builds the page in less than 145 ms. A saved copy makes the building not happen. The copy is a cache plugin, or a page cache the host runs; whoever set up the site knows which one you have.

A copy at the CDN, and the wrong page on the wrong device

The copy on the server still costs a trip to the server. A copy at the CDN is handed out from the location nearest the visitor. On the second day of the series, with the CDN keeping the home page, the median first answer fell from 225 ms to 128 ms; 88 of 96 readings came from the stored copy. The page built from scratch, a new address every time so the CDN never had a copy, stayed at 339 ms. More than forty percent of the wait, gone.

My CDN is Cloudflare, and Cloudflare keeps no copy of a site’s pages unless someone told it to: with a Cache Rule set to “Eligible for cache”, with the older “Cache Everything” setting, or by switching on its WordPress add-on. Without such a rule Cloudflare cannot spring the trap below; if you are not sure, ask whoever set up the account.

I first turned that copy on in September, in the week the article on AI bots describes. Later I turned it off again, and this is the reason. kovalweb.com builds its style files separately for desktop and for mobile, and part of the HTML differs too, so a phone and a computer asking for the same address get different pages. With the CDN copy on, desktop visitors were shown the mobile version. Not at once; by the next day. I switched the rule off and kept the copy on the server only.

On 20 October I reproduced it, with the rule set as it had been in September. The desktop page is 81,231 bytes and asks for seven fonts up front; the phone page is 65,423 bytes and asks for three. Every device test was a script on my laptop. It sent the name each device’s browser gives, which is how the CDN and the plugin tell devices apart. A fresh address is one nobody had asked for yet, so no copy of it existed. The script asked for a fresh address as a desktop browser first, then as an iPhone: the iPhone received the desktop page, byte for byte, seven fonts and all. On another fresh address it asked as the iPhone first: the desktop then received the mobile page. The CDN kept one copy per address and handed it to whoever came next.

My cache plugin’s own documentation says this can happen. Its page on the mobile cache warns: “If you are using an additional layer of cache, such as Varnish, NGINX, Cloudflare’s Cache Everything, etc., that is not configured to distinguish between mobile and desktop visitors, then you may run into these problems”, and the first problem it lists is “Wrong display for mobile, tablet or desktop”. Its page on Cloudflare’s cache-everything setting is blunter:

WP Rocket’s page on Cloudflare’s cache-everything setting

Cloudflare cache everything is not able to cache by device type. It will cache the first request of the page and keep serving it to all following visits.

Cloudflare’s own blog post of 22 September 2026 is about “Vary”, the note a server can add to say a page changes with who is asking, and it puts the general rule in one line: “Without Vary, whichever response enters the cache first can be served to both clients.” Why it took a day to show in September is my inference, not something any of these pages states: the CDN refills its copy after the copies are cleared or after the two hours my rule keeps it, and its page on purging says the refill happens “within the specific Cloudflare data center that served the request”. So at each location the first visitor after each expiry decided which version everyone else got.

Cloudflare can keep one copy per device type, and the setting is on every plan, the free one included. The cache plugin’s page, dated October 2025, says device caching needs Cloudflare’s paid WordPress add-on or its top plan; Cloudflare’s own page on cache keys, updated September 2026, lists “Cache by device type” in Cache Rules on every plan and says the device-type field “classifies a request as mobile, desktop, or tablet based on the User Agent”. Cloudflare’s example rule lists “Setting: Cache key” and under it “Cache by device type: On”. Within the hour I turned that setting on, cleared the copies and tried four orders, with desktop, iPhone, Android and iPad each going first once on a fresh address, then the real home page and a post three times from each. No device got another’s page. iPhone and Android share one mobile copy; iPad gets its own, and on pages served from the plugin’s copy it is the desktop version, as far as I can tell the site’s own choice. A day later, with real visitors in between, sixty more requests, five pages as four device types, three times each: no wrong versions. Tablets are their own group, and Cloudflare’s idea of a phone and the plugin’s may not agree on every device; on another site the same switch needs the same test before anyone relies on it.

The rule I now follow: cache the page at the CDN freely only if the site serves one version to every device. If it serves different pages to phones and computers, turn on device-type caching, or do not cache the page there at all. The gain is real, about a tenth of a second on my site; so is the trap.

Not sure which your site does? Ask whoever built it; and if the site runs WP Rocket, treat it as one that does: WP Rocket’s page on the Cache tab’s removal says its Mobile Cache, with separate cache files for mobile devices, is active by default, and only if the plugin’s Tools tab offers to enable Mobile Cache is it off.

Who is my web hosting provider?

If you did not set up the site, you will need this before you can ask your host anything. Three things get mixed up. The company the domain name is registered with is the registrar, and ICANN’s FAQ for domain owners notes that “Some registrants do not know that the domain name registrar can be different from the entity providing web-hosting/email services.” The registrar you can find in a minute with ICANN’s lookup; it shows the registrar and the nameservers, not the host.

The host is whoever runs the server the pages come from, and the public way to look is by numeric address: a registry records which organisation holds each address, and ARIN’s page on its lookup gives the one step, a search box at search.arin.net/rdap/ that covers addresses held by the other regional registries too.

But with a CDN in front, the address the site’s name resolves to is the CDN’s. Cloudflare’s page on proxy status explains why: “When a record is Proxied, Cloudflare sits between your visitors and your server — optimizing, caching, and protecting traffic along the way.” On the three sites of mine I checked, every public method, the address, the nameservers and the “server” line the pages send back, named the CDN, and none named the host. The “server” line in general names software, not a company, and some sites send none.

If you have the Cloudflare account, there is a route that works: DNS, then Records; the A record’s Content column shows your server’s numeric address. Paste it into ARIN’s search and it names the organisation that holds it, often your host or the data-centre company it rents from. Otherwise the surest answer is the dull one: the invoice, the account you log into to manage files and backups, the welcome email, or whoever built the site.

When moving host is worth it

Google’s page on improving server response time, quoted above, gives the test: “if you start to observe long TTFB values even in dedicated hosting providers, it may be a sign that you might need to re-evaluate your current hosting provider’s capabilities so that you can deliver the best possible user experience.” Read that with the saved copy in mind: a long first answer on pages served from a copy points at the host, or the road to it; a long one only on pages built from scratch is the building itself: first make sure the copy covers those pages, then it is a question for the host. Chrome’s guide to its server-response check offers WordPress owners one step up: “Consider upgrading your hosting to managed or dedicated service.” I would take that step after the copy, not instead of it.

A second reason to move has nothing to do with speed. WordPress’s requirements page recommends PHP 8.3 or greater and MariaDB 10.11 or MySQL 8.0 or greater, with HTTPS; of older versions it says “these versions have reached their official End Of Life and may expose your site to security vulnerabilities.” A host that cannot offer the current versions is a reason to move whatever the first answer says; in WordPress, Site Health → Info → Server shows the PHP version you are on.

Does changing hosting affect SEO? For speed, only through the first answer, provided the move itself goes cleanly; what speed does and does not do for ranking is in the article on PageSpeed’s score.

The next day, look at the page

Whatever you change, the saved copy, the CDN copy or the host, take the same reading as before the change, on the same page, and once more at a different hour so the road is not mistaken for the server. If you turned on a copy at the CDN, open the site the next day from a phone and from a computer and look at the page, not the numbers. My readings said 128 ms; it was the next-day check, asking as four device types, that said it was the right page.

Written by Oleh Koval at Specia1ne, who reads these reports for a living.