“Fast hosting” gets thrown around a lot, but speed is not one thing. It is a stack of decisions: what kind of disk your database sits on, what web server answers the request, whether repeated database queries get cached in memory, what PHP version runs your code, and what happens to the request before it even reaches your server. Understanding each layer means you can diagnose slowness instead of guessing, and ask sharper questions when you are evaluating a host.
The Disk Layer: Why NVMe Matters
Every WordPress request touches disk, whether it is PHP files being read, the database reading and writing rows, or media files being served. Traditional spinning hard drives and even older SATA SSDs introduce latency that compounds under load. NVMe drives connect directly over PCIe and handle far more input/output operations per second with lower latency, which matters most under concurrency: many visitors hitting the database at once, or a plugin doing heavy read/write cycles.
You will not “feel” NVMe on a single page load in isolation. Where it shows up is consistency: a site on NVMe tends to stay fast during traffic spikes, cron jobs, and admin-side operations like search-and-replace or large imports, where slower storage would start to bottleneck.
The Web Server: LiteSpeed and Full-Page Caching
The web server is what actually answers HTTP requests. LiteSpeed (or its open-source sibling, OpenLiteSpeed) is a server built with performance and efficient concurrency handling in mind, and it pairs with the free LiteSpeed Cache plugin to do full-page caching at the server level.
Full-page caching means that instead of WordPress rebuilding a page from scratch, on every request (loading PHP, running theme code, querying the database), the server can serve a pre-built HTML snapshot directly. For anonymous visitors browsing static-ish content (most pages, most of the time), this is the single biggest performance lever available, often mattering more than any other single optimization.
To confirm full-page caching is actually working, check response headers:
curl -I https://example.com/Look for a header like x-litespeed-cache: hit on a second request to the same URL. If you only see a miss every time, the cache may be misconfigured, or something (a logged-in cookie, a query string, a plugin) is preventing cache from being stored.
The Object Cache: Redis or Memcached
Full-page caching helps anonymous visitors, but it does not help logged-in users, WooCommerce carts, or any dynamic request that must run through PHP and the database. That is where persistent object caching comes in. Redis or Memcached sit in memory and store the results of expensive, repeated database queries so WordPress does not have to hit MySQL for the same data over and over.
This requires an object-cache.php drop-in file in wp-content/, usually installed by a Redis or Memcached plugin, or provided by the host directly. You can confirm it is present with:
ls -la wp-content/object-cache.phpIf the file exists and is not empty, persistent object caching is active. Without it, WordPress falls back to a non-persistent cache that resets on every request, which means every dynamic page load re-runs the same queries. For sites with logged-in users, WooCommerce, memberships, or heavy custom queries, object caching is often the difference between a snappy backend and a sluggish one.
PHP Version and OPcache
PHP is the language WordPress and its plugins run on, and newer versions are consistently faster, not just more secure. PHP 8.1 through 8.3 are the current mainstream versions, and PHP 8.3 with OPcache enabled is a solid default choice for most sites in this era.
OPcache stores compiled PHP bytecode in memory so the server does not have to re-parse and re-compile PHP files on every single request. It is one of the highest-leverage, lowest-risk performance settings available, and it should be on by default on any competent host.
Check your running PHP version with:
wp cli infoIf you are still on an old PHP version, ask your host for a supported upgrade path, and test plugin compatibility on a staging copy first. Most reputable plugins keep pace with mainstream PHP versions, but abandoned or poorly maintained ones sometimes lag behind.
The Edge: What Cloudflare Actually Does
Everything above lives on your origin server. Cloudflare (or a similar edge network) sits in front of that server and intercepts traffic before it arrives. It provides several distinct things at once: edge caching of static assets closer to the visitor, a web application firewall (WAF) that filters malicious requests, bot mitigation, DDoS protection, Universal SSL, and HTTP/3 support for faster connection handling.
One detail that matters more than people expect: DDoS resilience depends partly on your origin server’s IP address staying unpublished. If an attacker can bypass Cloudflare and hit your server’s real IP directly, the edge protection is worth much less. Hosts that run everything through a properly configured edge setup, keeping the origin IP out of DNS records and headers, give that protection real teeth.
ServerBorn’s stack runs NVMe, LiteSpeed, Redis, and a Cloudflare-backed edge together by default, which is one honest example of what a fully integrated version of this looks like end to end.
Putting It Together: Measuring What Matters
All of this infrastructure exists to hit Core Web Vitals thresholds that reflect real user experience: Largest Contentful Paint (LCP) at or under 2.5 seconds, Interaction to Next Paint (INP) at or under 200 milliseconds, and Cumulative Layout Shift (CLS) at or under 0.1.
Measure with PageSpeed Insights or Lighthouse, but always distinguish lab data from field data. Lab data is a single simulated test run, useful for diagnosing specific issues. Field data (the Chrome User Experience Report, shown in PageSpeed Insights as “real user” data) reflects what actual visitors on actual devices and networks experienced. A site can look great in a lab test and still underperform in the field if, say, most of your traffic comes from slower mobile connections. Trust field data for the real verdict, and lab data for figuring out why.
Questions to Ask Any Host
- What storage does the database and file system run on, and is it NVMe?
- Is the web server LiteSpeed, OpenLiteSpeed, or something else, and does it support server-level full-page caching?
- Is Redis or Memcached available, and is the object-cache.php drop-in provided or something you must install yourself?
- What PHP versions are supported, and is OPcache enabled by default?
- Is there an edge network (Cloudflare or similar) in front of the origin, and is the origin IP kept unpublished?
- Are backups automated, off-site, and actually tested for restoration, not just scheduled?
Takeaway
Speed is not a single toggle, it is a stack. NVMe removes disk bottlenecks, LiteSpeed and full-page caching skip PHP entirely for anonymous visitors, Redis or Memcached speeds up everything dynamic, a current PHP version with OPcache makes the code itself run faster, and an edge network protects and accelerates the whole thing before requests even arrive. Understanding what each layer contributes means you can ask better questions of any host, and diagnose exactly which layer is failing when something feels slow.