Your homepage scores well in PageSpeed Insights, yet customers say the cart drags and wp-admin crawls every time you add a product. That gap is common on hosts sold as the fastest WordPress hosting, and you can find its cause. WordPress hosting speed doesn’t come from the web server’s brand but from several layers, from the network to the PHP and database work that builds an uncached page. Follow one request from DNS lookup to database and back, with timings measured on N6 Cloud’s own test site, to see which layer spends the time.
What “Fastest” Really Means: Sub-Second Is a Budget, Not a Badge
For a host, fast means a short time to first byte on every page, cached or not, measured from the cities where your visitors live. “Sub-second” is a realistic target for that server response, not for the whole page, which still has to download and appear. The clock comes first, then the budget.
TTFB, LCP, Fully Loaded: Which Clock Should You Trust?
TTFB is the clock the host controls, so judge a host on TTFB and judge your site on LCP. TTFB, or time to first byte, is how long the browser waits before the server’s answer starts to arrive. Largest Contentful Paint (LCP) is the time until the biggest image or text block appears, about when the page feels loaded. “Fully loaded” is when the last file finishes, long after the page is usable.
Google’s Time to First Byte guidance counts 0.8 seconds or less as good and anything above 1.8 seconds as poor. LCP is one of Google’s Core Web Vitals and TTFB isn’t, and a good LCP is 2.5 seconds or less for three visits in four. TTFB starts the LCP clock, so server time comes out of the page’s budget. A 0.8-second TTFB leaves only 1.7 seconds for the rest of the page.
Fully loaded time misleads because it waits for ad networks, chat widgets, and trackers the host never touches. One marketing script can add whole seconds to it. A test that leads with it mostly measures your third-party tags, so read its TTFB and LCP lines.
The 1,000 ms Budget: Where Every Millisecond Goes
A sub-second TTFB is a budget shared by distance, connection setup, and server work, and only some of those stages belong to the host. Before any WordPress code runs, the browser must find the server and open a secure connection. Each step costs at least one round trip: the time it takes for a message to reach the server and return.
Table 1 lists each stage, its approximate time, what sets it, and who controls it.
| Stage | Approximate time | What sets it | Who controls it |
|---|---|---|---|
DNS lookup |
0 ms if already cached; otherwise one round trip to the visitor’s DNS resolver, longer if it has to ask the domain’s DNS servers |
The DNS provider and the visitor’s network |
The DNS provider (often the host) and the visitor’s network |
TCP connection (opening the line to the server) |
1 round trip |
Distance to the data centre |
The host, through where its servers are |
TLS handshake (setting up encryption) |
1 round trip with TLS 1.3 |
Protocol version and distance |
The host |
Server work, cached page |
A few milliseconds |
The server’s page cache |
The host |
Server work, uncached page |
Hundreds of milliseconds, sometimes more than 1 second |
PHP, OPcache (PHP’s code cache), the database, PHP workers (the processes that build pages), and plugins |
The host and your site |
HTML download |
Usually small next to the stages above |
Page size and distance |
Your site and the host |
Render |
Most of LCP’s 2.5-second budget |
Theme, images, fonts, and scripts |
Your site |
Distance is the part no setting can remove. From a server in Vancouver, a round trip takes about 53 ms to Toronto and about 148 ms to Frankfurt (WonderNetwork’s medians over two weeks of hourly pings). A new HTTPS connection needs three round trips before the first byte arrives, about 160 ms from Toronto and 445 ms from Frankfurt, plus whatever time the server spends building the page.
The render row is where the host stops controlling the clock. A heavy page builder, oversized images, or third-party scripts can use up the whole 2.5-second LCP budget, and no hosting plan fixes them. That work belongs to the site, and a separate guide to fixing LCP, INP, and CLS on the site side covers it.
Inside the Stack: The Server Layers Behind a Fast WordPress Site
Once you pick a data centre, the rest depends on the server, where a request meets three layers in order. The network edge opens the connection, the web server answers from its cache or passes the request on, and PHP and the database build the page when nothing is cached. That’s the WordPress server stack.
The Network Edge: DNS, TLS 1.3, and HTTP/3
Modern protocols cut the round trips a new visitor pays. After DNS turns the domain into an IP address (usually cached after the first visit), the browser opens a TCP connection and runs a TLS 1.3 handshake. Those take two round trips, and the request and reply take a third.
QUIC, the newer connection method under HTTP/3, does the connection and encryption in a single round trip, saving about 53 ms from Toronto to British Columbia (BC). A browser usually switches to HTTP/3 only after a response tells it, in a header called alt-svc, that the site offers it, so a first-ever visit usually uses HTTP/2. On a repeat visit, 0-RTT resumption can send the request in the first packet if the server allows it, though an attacker can replay that request, so it’s only safe for requests that change nothing. On the server side, all of this is set up by your host, or by your CDN if you use one, and the browser handles the rest.
HTTP/3 helps most on shaky mobile connections. Over TCP, one lost packet holds up every file behind it (head-of-line blocking), while QUIC keeps the others moving, and a QUIC connection survives a switch from Wi-Fi to mobile data. No primary source gives a reliable percentage gain, so count on one round trip saved, plus steadier loading on poor networks.
LiteSpeed vs NGINX vs Apache: Why the Cache Matters More Than the Brand
On cached pages, most of LiteSpeed’s lead comes from its built-in WordPress cache rather than the server itself. On uncached pages, no reliable public test shows a big gap between a well-tuned LiteSpeed and NGINX server. Apache is the long-time default: flexible, lets each site change settings with .htaccess files, and heavier per connection unless tuned. NGINX is event-driven and light, often in front of PHP-FPM, the process manager that runs PHP. LiteSpeed is a commercial server that reads Apache’s settings and comes with its own WordPress plugin, LiteSpeed Cache (LSCache).
The speed multipliers in hosting ads tend to come from tests that count requests per second for already-cached pages, between two machines a fraction of a millisecond apart. That matters in a spike but says little about a Halifax visitor’s wait for an uncached page. Weigh any multiplier against the test behind it, and check your host’s server in the response headers section below.
The small public tests point in different directions. A short independent test found no uncached difference, a self-published production test credited most of LiteSpeed’s lead to LSCache, and a store test reported second-hand found NGINX faster uncached. Two of the three used OpenLiteSpeed, LiteSpeed’s free edition. Uncached speed comes down to PHP, OPcache, and the database, which the next section follows step by step.
The Uncached Path: PHP, OPcache, Workers, and the Database
When nothing is cached, WordPress rebuilds the page in PHP and asks the database dozens of questions, so PHP, OPcache, workers, and database memory set the time. PHP loads WordPress, runs plugins and the theme, queries the database, and sends the HTML. It repeats this for every uncached visitor.
The WordPress server requirements recommend PHP 8.3 or newer, but 8.3 has received only security fixes since 31 December 2025, so 8.4 or newer is the better choice where your host offers it. PHP OPcache keeps compiled code in memory to skip parsing. From PHP 8.5 it’s built into PHP, though a server setting can still turn it off, so check that it’s active. In an earlier N6 Cloud test, turning OPcache on cut an uncached cart page from about 1.7 seconds to 1.0 second. Switching the PHP handler (the module that connects the web server to PHP) alone changed nothing measurable.
A PHP worker is one process that builds one uncached page at a time. When all workers are busy, extra uncached requests wait in line, adding to TTFB. Stores feel this first, since carts and checkouts are uncached, and the store guide linked below gives typical worker counts.
The database has its own memory cache: MySQL and MariaDB keep frequently read data in the buffer pool. If the pool can hold the data a site uses most, the site rarely reads from disk. Faster storage helps mostly with writes and with reads that miss the pool, and no disk replaces a cache.
Caching Layers: Where a Sub-Second TTFB Is Won
A cache stores a finished answer so the next request skips the uncached path. A cache hit is a request answered from the cache, and a cache miss is one that has to be built. WordPress hosting uses three caches at different distances from the visitor, and Figure 2 shows where each request type stops.
Server-Level Page Cache: LSCache, FastCGI Cache, and Varnish
A server-level page cache returns the finished HTML before PHP starts, which is why it’s usually faster than a cache plugin that runs in PHP on the same server. Many cache plugins still start PHP and load part of WordPress to find their saved copy. A server-level cache answers from the web server, so a hit never touches PHP or the database and takes the server only a few milliseconds. LSCache and NGINX’s FastCGI cache are built into their web servers, while
LSCache takes its orders from a WordPress plugin, which tells it what to clear when you edit content. It tags each cached page by the post, product, or archive it shows. An edit clears that page and related pages that list it, such as the homepage and category archives, rather than the whole cache. A guide with every LiteSpeed Cache setting explained walks through the plugin’s options.
NGINX has its own page cache, FastCGI cache, set up with NGINX’s fastcgi_cache directives, which stores PHP’s output and serves it on the next request. NGINX doesn’t know when a WordPress post changes, though, so clearing the right pages needs a helper plugin and extra server rules. That extra setup, more than raw speed, is where most of LSCache’s advantage comes from.
Redis Object Cache for Logged-In Users and WooCommerce
When the page cache can’t help, as with logged-in users, carts, and wp-admin, a persistent object cache such as Redis stops WordPress from asking the database the same questions on every request. WordPress’s built-in object cache keeps query results only until the request ends, so the next one starts empty. Without a persistent cache, every uncached request runs these two kinds of query from WordPress core, shown here as they appear in the code:
SELECT option_name, option_value FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');
SELECT option_value FROM wp_options
WHERE option_name = '...' LIMIT 1;
The first loads every autoloaded option, the settings read on every page. The second runs for each other option a plugin asks for. Redis is an in-memory store that keeps those answers between requests, so a Redis object cache for WordPress lets the next request read them from memory.
In N6 Cloud’s test, the uncached test post made 35 database queries, 10 of them on the options table, with the Redis object cache off, which is N6 Cloud’s default. With Redis switched on, the same page made one query. Server time fell only from a median of 318 ms to 288 ms, about 10%, because building the page in PHP took most of the time on this small site. The savings usually grow with heavier database work, such as WooCommerce or many plugins.
WordPress’s Site Health screen suggests a persistent object cache once a site passes thresholds such as 1,000 posts, comments, or users, or 500 autoloaded options. It flags a critical issue when autoloaded options pass 800 KB. Many managed WordPress hosting plans include Redis, so enabling it usually means changing settings in the control panel and the cache plugin rather than changing the server.
The CDN Edge Cache, and Why Location Still Matters on a Miss
A CDN serves images, CSS, and scripts from near the visitor, but HTML and every cache miss still travel to the origin, so the data centre’s location still counts. A CDN, or content delivery network, is a set of servers in many cities that keep copies of your files in an edge cache. The origin is the server where WordPress and the database run.
Cloudflare, a widely used CDN, doesn’t cache HTML by default, so a Toronto visitor’s page request goes on to the server in BC. Handshakes happen at the nearby edge, but each page still pays a cross-country round trip plus server work. Logged-in pages and carts can’t be cached at the edge.
In N6 Cloud’s test, Cloudflare passed the cached homepage through as DYNAMIC, back to BC. From Toronto, via Montreal and Chicago edges, the median first byte was 307 ms through Cloudflare and 62 ms direct, with most of the gap in the edge-to-origin fetch. That’s a reason to decide whether Cloudflare should cache your HTML, which you set with its cache rules, not to drop a CDN that still serves static files, absorbs spikes, and shields the origin.
Location still sets the length of every miss. A Canadian data centre keeps it short for Canadian visitors, and Los Angeles, at about 30 ms, is even closer to Vancouver than Toronto. A mostly European audience pays the Frankfurt round trip from the budget section on every miss, before the server does any work.
The Uncached Request Test: Where Fast and Slow Hosts Really Split
Caches make hosts look alike on a homepage, so uncached pages show whether you have fast WordPress hosting or only a fast cache. WooCommerce’s own docs say to keep the Cart, Checkout, and My Account pages out of the page cache, since they show one shopper’s details. Search results, wp-admin, and many REST API calls usually skip it too. For how many PHP workers a store needs, see the guide to what a store asks of the server that a blog doesn’t.
In N6 Cloud’s test, a cache miss cost far more than distance. Table 2 covers one blog post on a LiteSpeed WordPress hosting account in N6 Cloud’s BC data centre. Each figure includes one network round trip (about 55 ms from this Toronto probe, close to the 53 ms median in the budget section, and 1 ms in Vancouver). So a cached page took the server about 3 ms. An uncached copy took about 340 ms of PHP and database work, and the first request after a cache purge took about 360 ms.
Table 2 gives medians in milliseconds, with the range in brackets. Connection setup is the time to open the connection and set up encryption, and the other columns show the wait for the first byte once it’s open. A REST API request is a background data call from a plugin or app.
| City | Connection setup (TCP + TLS) | Warm, cached | Cold, first request after a purge | Uncached post | REST API request |
|---|---|---|---|---|---|
Toronto |
about 120 |
57.5 (56 to 99) |
415 (321 to 418) |
393 (358 to 1,432) |
244 (213 to 302) |
Vancouver |
about 9 |
3 (3 to 4) |
366 (331 to 391) |
344 (325 to 363) |
198 (176 to 234) |
How N6 Cloud tested: a clean WordPress install with the default theme, 30 sample posts, and LiteSpeed Cache on default settings. Globalping’s public probes on data-centre networks in Toronto and Vancouver sent requests straight to the server, 10 runs per cell (5 purge cycles for the cold cell). Requests used HTTPS over TCP, not HTTP/3, and no DNS lookup was timed. Limits: one simple test site, one session, and no concurrent visitors, so a real store will add uncached time.
Every median in Table 2 stays under web.dev’s 0.8-second mark, so a sub-second TTFB held in both cities, cached or not. Even the slowest Toronto median, 415 ms after a purge, comes to about 535 ms with a new connection’s 120 ms added, which leaves room for a DNS lookup. It sits near the top of its range because three of the five runs took 415 to 418 ms, and only one, at 321 ms, was much faster. One uncached Toronto run took 1,432 ms, the first of its series, likely a PHP process starting cold. The median sets it aside, though a visitor then waits the full time.
Under load, uncached speed depends on the CPU, memory, and processes your account gets. On shared servers, CloudLinux resource limits (set by the server operating system many hosts use) give each account its own share, so a busy neighbour can’t use up yours. A VPS reserves a set amount of CPU and memory for your server alone, even on hardware shared with other virtual servers. At a limit, your site’s requests slow down or, at the process limit, get an error page, while other sites carry on. To tell whether your site is hitting them, the guide to what CPU, memory, and process limits do explains each limit and the error it causes.
How to Check Any Host’s Stack Yourself in 10 Minutes
You don’t have to take any host’s word for its stack, N6 Cloud’s included. Three checks show it in about 10 minutes: the headers, a timing test, and your own slow pages. Your browser’s developer tools and curl, a command-line tool built into Windows 10 and 11, macOS, and Linux, are all you need. They work on any host, including one you’re thinking of leaving.
Read the Response Headers: server, x-litespeed-cache, cf-cache-status
Three headers show which web server answered, whether its page cache was hit, and whether a CDN cached the page. In Chrome, Edge, or Firefox, open the developer tools’ Network tab, reload, click the first entry, and open Headers. In Windows PowerShell or Command Prompt, curl.exe -sI https://example.com/ prints them (on macOS or Linux, type curl without .exe). Below are N6 Cloud’s homepage and its test site with a unique query string, trimmed.
HTTP/2 200
x-litespeed-cache: hit
server: cloudflare
cf-cache-status: DYNAMIC
alt-svc: h3=":443"; ma=86400
x-litespeed-cache: miss
server: LiteSpeed
The server: cloudflare line means Cloudflare sits in front, and x-litespeed-cache: hit means LiteSpeed’s page cache answered at the origin. And cf-cache-status: DYNAMIC means Cloudflare passed the HTML through uncached. In the second block, server: LiteSpeed comes straight from the origin, and x-litespeed-cache: miss means this request built and stored the page. The alt-svc: h3 line offers HTTP/3 for the next connection.
A host without a server-level page cache sends no cache header: neither x-litespeed-cache nor the x-cache or x-fastcgi-cache lines that many Varnish and NGINX setups add. The Server line alone proves nothing: it may name Apache, NGINX, LiteSpeed, a CDN, or nothing. To see the protocol, right-click the Network tab’s column headings and turn on Protocol: a repeat visit to an HTTP/3 site shows h3, while a first visit may show h2. WordPress’s Site Health page-cache test looks for x-litespeed-cache and cf-cache-status, among others.
Measure TTFB From Your Visitors’ Cities, the Fair Way
One speed test can lie. It may catch a hit on one host and a miss on another, or be one lucky run from far away. Test the same page several times from your visitors’ cities, cold, warm, and uncached, and use the median, the middle value.
Use three or more runs per case (N6 Cloud’s test above used 10 for most cases and 5 for the test after a purge). Test after a purge (cold), after a visit (warm), and on a URL no cache can answer: a cart, or the page with a new query string each run (?nocache=1, then ?nocache=2). A page cache stores each query-string URL after its first miss, so change the number each run. On Windows, this command prints each stage’s time, in seconds. Type curl.exe, not curl, because in Windows PowerShell plain curl runs a different command. On macOS or Linux, use curl and replace NUL with /dev/null:
curl.exe -o NUL -s -w "dns: %{time_namelookup}\nconnect: %{time_connect}\ntls: %{time_appconnect}\nfirst byte: %{time_starttransfer}\ntotal: %{time_total}\n" "https://example.com/?nocache=1"
dns: 0.005402
connect: 0.007505
tls: 0.037109
first byte: 0.460871
total: 0.466464
This sample ran from a BC server to N6 Cloud’s test site, through Cloudflare, uncached. Each number counts from the start, so connect to tls (about 30 ms here) is the TLS handshake, which happens with Cloudflare’s nearby edge. The gap from tls to first byte (about 0.42 seconds) is the rest: the trip to the edge, Cloudflare’s fetch from the server, and the server building the page. On a site without a CDN in front, that gap is server work plus one round trip, so to time the host alone, test a URL that doesn’t go through a CDN. For other cities, try a free probe network such as Globalping. If the uncached URL’s median stays under web.dev’s 0.8 seconds from your visitors’ cities, the stack is fast enough for them.
Your own slow pages need one more check. In a private window, open a page that should be cached, then log in, add an item to your cart, and open the cart and a wp-admin screen, all with the Network tab open. Click the first document request, open Timing, and note “Waiting for server response” (“Waiting” in Firefox) over a few reloads. If the cached page is slow from a nearby city, the host or the distance to it is the likely cause. If the cached page is quick but the cart or dashboard is slow, the uncached path is the bottleneck: your plugins, theme, and database, or the PHP resources your plan gives you. With LiteSpeed Cache, a missing x-litespeed-cache header means its page cache didn’t serve that page. Some other cache plugins mark a cached page only with a comment at the end of the page source.
What a hosting spec sheet should tell you
Before you compare hosts on speed, check that each spec sheet states these three things in plain numbers or names:
- The page cache that runs on the server, named (LSCache, FastCGI cache, or Varnish), rather than “caching included”
- The PHP versions you can choose, including 8.4 or newer
- How much CPU and memory each account gets, and how many processes it can run
Why Trust N6 Cloud on WordPress Hosting Speed?
N6 Cloud can be checked against those layers too. It’s a Canadian company based in British Columbia, run by a team with more than 20 years in web hosting. Its servers sit in Canadian data centres in British Columbia, which keeps the round trips from the budget above short for visitors across Canada. Table 2 already shows how one of N6 Cloud’s LiteSpeed WordPress accounts behaves.
Each of these layers is listed on N6 Cloud’s product pages. LiteSpeed Web Server with LiteSpeed Cache runs on N6 Cloud’s LiteSpeed WordPress plans and on every Managed WordPress plan, with HTTP/3 on those plans. OPcache is on by default for new WordPress and Managed WordPress accounts, and Redis object caching is included on every Managed WordPress plan. Sites run on SSD SAN storage with RAID 10, the plans work with Cloudflare’s free CDN, and backups run daily. CloudLinux LVE and CageFS keep each account’s resources and files separate, Imunify360 scans for malware, and a 99.9% uptime commitment backs it all.
If you’re choosing WordPress hosting, run the header and timing checks from the previous section on N6 Cloud’s pages, as you would on any other host. The results, not a spec sheet, show which is the fastest WordPress hosting for your visitors. When you’ve seen them, the 24/7 support team can help you match a plan to a blog, a membership site, or a store.
Frequently Asked Questions
What is the fastest WordPress hosting stack?
No single brand makes the fastest stack. It combines a server-level page cache, a persistent object cache, PHP 8.4 or newer with OPcache (WordPress recommends 8.3 or newer), HTTP/3, enough isolated resources, and a nearby data centre. The uncached request test shows whether a host has them.
What is a good TTFB for a WordPress site?
A good TTFB is 0.8 seconds or less, the web.dev threshold from the section on which clock to trust. WordPress Site Health counts a median server response under 600 ms as good, but it measures from the server itself, so the network isn’t included. A cached page on a nearby server should come in far lower.
Is LiteSpeed faster than NGINX for WordPress?
On cached pages, LiteSpeed’s real advantage is how closely LSCache works with WordPress, which keeps a page cache current. On uncached pages, PHP and the database decide the time, and no reliable public test shows a big gap. The LiteSpeed, NGINX, and Apache section above has the detail.
Can a caching plugin make cheap hosting fast?
Only for anonymous visitors, and only on pages it can cache. Carts, checkout, and wp-admin still run on the server’s CPU, memory, and PHP workers, so the plugin hides the host’s limits rather than removing them. The uncached request test is where those limits show up.
How soon will I see speed gains after switching hosts?
Lab TTFB, from a testing tool, changes once the DNS change reaches that tool, usually within the record’s TTL (how long resolvers may keep the old answer), after a short warm-up while caches fill. Field data from real Chrome visitors takes longer, because Google’s Chrome UX Report (CrUX) is a 28-day rolling average. Search Console’s Core Web Vitals validation also runs for 28 days.
Does faster WordPress hosting cost more?
Not because of a “fast” label. You pay for isolated resources, a server-level page cache, and an object cache, so compare those on the spec sheet. A managed plan often adds the object cache and more PHP capacity, and the comparison of what a managed plan changes for speed explains the trade-off.
