Every time someone loads your WordPress site, a small journey happens behind the scenes. If you have ever wondered why a CDN makes pages feel instant, or why your cache hit rate matters more than your plugin count, it helps to trace one request from a browser all the way to your origin server and back. Understanding that path makes every caching setting you touch, from LiteSpeed Cache to Cloudflare, make a lot more sense.
Step One: The Browser Asks a Question
A visitor types your domain or clicks a link. Their browser resolves DNS and, if you are running Cloudflare in front of your site, that DNS lookup does not point to your actual server. It points to Cloudflare’s anycast network. Anycast means the same IP address is announced from hundreds of locations around the world, and internet routing automatically sends the request to whichever announcement is topologically closest to the visitor. This is the mechanism that gets a shopper in Singapore routed to a nearby point of presence (PoP) instead of a server in Virginia.
This is also why keeping your origin IP unpublished matters. If your real server address is exposed through old DNS records, a misconfigured subdomain, or a leaky plugin, an attacker can bypass the edge entirely and hit your origin directly, defeating the DDoS protection and WAF that the CDN provides.
Step Two: Arriving at an Edge City
A modern CDN operates from a large number of PoPs, often described loosely as edge cities, spread across continents. Each PoP is a cluster of servers whose job is to answer requests as close to the visitor as possible. When the request lands here, the edge server checks its local cache. If it has a fresh copy of the page, it serves it immediately over HTTP/3, and the visitor gets the whole response without a single packet reaching your origin server. That is the best-case outcome, and for pages that do not change often, it is achievable most of the time.
Cache Hit or Cache Miss
If the edge does not have the content, or the content has expired, you get a cache miss. This is where a lot of site owners misunderstand CDNs. A miss does not mean the system failed. It means this particular edge city has not been asked for this particular page recently, so it has nothing cached. What happens next depends on whether the CDN uses a flat cache model or a tiered one.
Flat Caching
In a flat model, every edge PoP that misses reaches all the way back to your origin server to fetch the content. This works, but if you have 300 edge cities and a page suddenly goes viral, dozens of them can end up hitting your origin nearly simultaneously, each looking for its own fresh copy.
Tiered Caching and Origin Shields
Tiered caching solves this by inserting a middle layer. Instead of every edge PoP calling home directly, misses are routed to a smaller set of regional caching nodes, sometimes called an origin shield. That shield fetches the content from your origin once, caches it, and then serves every downstream edge PoP that asks. Your origin server sees one request instead of dozens. This is one of the most underappreciated pieces of CDN architecture: it is not just about being close to visitors, it is about protecting the origin from redundant work.
What Actually Gets Cached at the Edge
Edge caching is excellent at static and semi-static assets: images, CSS, JavaScript, and full HTML pages that do not depend on a logged-in session. It is not designed to cache things like a shopping cart total or an admin dashboard. Cache rules typically respect standard HTTP caching headers, along with CDN-specific page rules that let you set explicit behavior per URL pattern.
This is where WordPress-specific caching complements CDN edge caching rather than replacing it. LiteSpeed Cache, running on a LiteSpeed or OpenLiteSpeed server, handles full-page caching at the server level and is aware of WordPress internals: it can bypass the cache correctly for logged-in users, WooCommerce carts, or dynamic widgets. Underneath that, Redis or Memcached provide a persistent object cache through a drop-in, so database query results and computed objects survive across requests instead of being rebuilt every time PHP runs. Layered together, you get edge caching for anonymous visitors at the CDN, full-page caching at the server for anything the edge does not handle, and object caching for the dynamic parts that still need PHP and MySQL to do real work.
The Security Layer Riding Along
The same edge infrastructure that accelerates your pages is also your first line of defense. A web application firewall (WAF) inspects requests at the edge and blocks common attack patterns before they ever reach WordPress. Bot mitigation filters out scraper and credential-stuffing traffic. DDoS protection absorbs volumetric attacks across the distributed network instead of letting them concentrate on one server. Universal SSL terminates encryption at the edge so visitors get HTTPS by default. None of this requires configuration on your origin server, but it does require that your origin IP stay hidden, so traffic cannot route around the protection.
Why the Journey Matters for Core Web Vitals
All of this architecture has a direct, measurable payoff. Largest Contentful Paint (LCP) improves when the largest visible element loads from a nearby edge cache instead of crossing an ocean to your origin. Interaction to Next Paint (INP) benefits when server response times are fast and consistent, which object caching and OPcache (paired well with PHP 8.3 on current WordPress installs) help deliver. Cumulative Layout Shift (CLS) is more about front-end discipline than caching, but a CDN that serves assets quickly reduces the temptation to let render-blocking resources straggle in late and shift your layout. The targets are well established: LCP at 2.5 seconds or under, INP at 200 milliseconds or under, and CLS at 0.1 or under.
Checking the Journey Yourself
You do not need to guess whether a request hit the edge cache or traveled all the way to origin. Most CDNs return a cache status header you can inspect directly:
curl -I https://example.com/ | grep -i cacheLook for a header indicating hit, miss, or dynamic, along with the PoP or colo that served it. If you manage WordPress from the command line, wp-cli remains the standard tool for clearing object caches, flushing rewrite rules, or checking active plugins when you are trying to figure out why a page is not caching the way you expect.
A managed WordPress host like ServerBorn wires the LiteSpeed and Redis layers together with Cloudflare’s edge network so this whole pipeline works out of the box, without you having to hand-configure cache hierarchies yourself.
The Takeaway
A page load is not one hop, it is a relay: anycast routing to the nearest edge city, a cache hit or a miss, an optional origin shield absorbing redundant requests, and layered caching back at your server that protects the database from unnecessary work. Knowing where each layer sits makes it much easier to diagnose slow pages, tune cache rules with confidence, and understand exactly what a CDN is doing for you every time someone loads your site.