Part 6 built out your DNS record structure inside Cloudflare: A records, CNAMEs, MX, TXT, the whole configuration layer that makes your domain actually function. That foundation matters because everything in this part sits on top of it. You can't cache content at the edge if your traffic isn't routing through the edge. You can't write redirect rules that fire before your server touches a request if Cloudflare isn't in the path at all.
This part is about what Cloudflare does once it's in that path. Not security, not Zero Trust, not tunnels. Just the front door: how your content gets distributed globally, what gets cached and what absolutely must not, how you write rules that give you precise control over both, and how redirects work when they fire at the network edge instead of inside your web server. These are the features most people enable without fully understanding, which means they either under-configure them and leave performance on the table, or over-configure them and spend an afternoon wondering why logged-in users keep seeing each other's data.
Neither outcome is acceptable. So here's how it actually works.
Cloudflare as Your Front Door: What This Actually Means
When people say Cloudflare "protects" or "accelerates" their site, they're describing a consequence without explaining the mechanism. The mechanism is simpler than the marketing makes it sound. Cloudflare inserts itself between every user and your origin server. That's it. That insertion point is what makes everything else possible.
The Request Journey: Browser to Edge to Origin
When a visitor types your domain into their browser, the first thing that happens is a DNS lookup. Without Cloudflare proxying, that lookup returns your server's actual IP address. The browser connects directly to your server. Your server handles everything.
With Cloudflare proxying enabled (the orange cloud in your DNS dashboard), that DNS lookup returns a Cloudflare edge IP instead. Your real server IP stays hidden. The browser connects to Cloudflare's nearest edge node, not your machine in a data center somewhere.
From that edge node, Cloudflare decides what to do with the request. If the content is cached, it responds immediately without touching your origin at all. If it's not cached, it fetches the content from your origin, stores a copy, and delivers it to the user. That round trip to your origin only happens when it has to.
The contrast with DNS-only mode (the gray cloud) is worth understanding clearly. In gray cloud mode, Cloudflare serves DNS but does not proxy traffic. Requests go straight to your origin. No caching, no edge delivery, no redirect rules firing at the network layer. Gray cloud is appropriate for records that should never be proxied, like mail server entries or certain infrastructure subdomains. For anything user-facing, you almost always want the orange cloud.
Why the Edge Changes Everything
Cloudflare operates a global network of edge nodes distributed across hundreds of cities. When a user in Tokyo requests your site hosted in Virginia, without edge delivery, that request travels across the planet and back. With edge delivery, a cached response comes from a node in Tokyo or somewhere close to it. The physics of that difference shows up directly in your time-to-first-byte numbers.
CDN delivery, cache rules, browser TTL settings, redirect rules: all of them execute at the edge. None of them require your origin server to be involved. That's the mental model to carry into every section that follows.
CDN Basics: How Cloudflare Distributes Your Content Globally
A CDN solves a simple problem. Your server is in one place. Your users are everywhere. The further a user is from your server, the slower their experience. A CDN fixes that by keeping copies of your content in many locations simultaneously, so users get served from wherever is closest to them.
What a CDN Actually Does (Without the Jargon)
The first time a user requests a file, Cloudflare fetches it from your origin and stores a cached copy at the edge node that handled the request. Every subsequent request for that file from users near that edge node gets the cached copy. Your origin server never sees those requests. The file travels a short distance instead of a long one, and your server handles a fraction of the load it would otherwise carry.
Static content benefits most from this model. HTML files, CSS stylesheets, JavaScript bundles, images, fonts, PDFs: all of these can be cached at the edge and served without touching your origin. A static site with good cache configuration can serve thousands of simultaneous visitors from Cloudflare's edge while your origin server sits essentially idle.
Cloudflare's Network: Scale and Reach
The scale here is not abstract.
That second number is the one worth sitting with. One in five requests on the internet passes through Cloudflare's infrastructure. The network effect of that scale means their edge nodes are already geographically close to nearly every user on earth.
CDN vs Traditional Hosting: A Side-by-Side View
Traditional hosting puts your content on one server or a small cluster in one region. Every request, regardless of where it originates, eventually reaches that server. During traffic spikes, that server absorbs the full load. During a regional outage, your site goes down.
Cloudflare operates as both a CDN and a reverse proxy simultaneously. The CDN layer distributes cached content globally. The reverse proxy layer means all traffic flows through Cloudflare first, giving you a single control plane for caching, redirects, security rules, and rate limiting. Traditional CDNs and traditional reverse proxies are separate products. Cloudflare collapses them into one.
For a static site, this combination is particularly powerful. Deploy your HTML, CSS, JS, and images once. Cloudflare handles global distribution automatically. Users in São Paulo, Stockholm, and Singapore all get fast responses without you spinning up infrastructure in any of those places.
What Should (and Should Not) Be Cached
Caching the wrong content is worse than not caching at all. A misconfigured cache can serve one user's session data to a different user, strip out personalization, or lock a checkout page into a stale state. Getting this right isn't optional.
Cache-Friendly Content: The Safe List
These file types are safe to cache aggressively. They don't change per user, they don't contain session data, and serving a slightly stale version rarely causes a problem worth worrying about.
Images (JPG, PNG, WebP, SVG, GIF), web fonts (WOFF, WOFF2), CSS stylesheets, JavaScript files, static HTML pages that don't vary by user, PDFs, video files, and downloadable assets all belong in this category. If a file is the same for every visitor regardless of who they are or whether they're logged in, it can be cached.
Content That Should Never Be Cached
This list is shorter but more important.
Never Cache These
API endpoints that return user-specific data, checkout and cart pages, admin dashboards, session-dependent pages, authentication endpoints, and any response that includes a Set-Cookie header with session identifiers. Caching any of these is a data exposure risk, not just a functionality bug.
The API route example makes this concrete. A /api/user/profile endpoint returns different data for every authenticated user. If Cloudflare caches the first response and serves it to the next person who hits that endpoint, you've just served someone else's profile data to a stranger. That's not a hypothetical. It happens when cache rules aren't written carefully.
The Gray Area: Authenticated Pages and Dynamic Content
WordPress sites are the most common source of cache misconfiguration. The homepage is cacheable. A blog post is cacheable. The admin dashboard at /wp-admin/ is absolutely not. The cart page is not. Any page rendered differently for a logged-in user is not.
"The rule is simple: if the page would look different for two different users, it must not be served from cache."
WordPress sets cookies like wordpress_logged_in_* and woocommerce_cart_hash that signal the request is user-specific. Cloudflare can read these cookies and bypass cache when they're present, but only if you configure it to do so. Out of the box, it won't know to look for them.
Query strings add another layer of complexity. Cloudflare's default behavior treats URLs with different query strings as different cache keys. /products?sort=price and /products?sort=name are cached separately. That's usually correct, but it can fragment your cache if you're not careful about how query parameters are used. Cache-Control headers from your origin also interact with Cloudflare's behavior. A Cache-Control: no-store header from your origin tells Cloudflare not to cache that response, regardless of what your cache rules say. Understanding that interaction is essential before you start writing rules.
Cache Rules: Taking Fine-Grained Control
Default Cloudflare caching behavior is conservative. It caches based on file extension and respects origin headers, but it doesn't make aggressive decisions on your behalf. Cache Rules are how you override that default behavior with precision.
Understanding Cache Rules in the Cloudflare Dashboard
Cache Rules live under Rules > Cache Rules in the Cloudflare dashboard. The interface follows the same pattern as other Cloudflare rule types: you define a match condition, then specify an action to take when that condition is met. Rules are evaluated in order, and the first matching rule wins.
A rule has two parts. The match condition can target URL paths, hostnames, file extensions, cookie names, request headers, or combinations of all of these. The action determines what Cloudflare does with matching requests: cache them, bypass cache, or set specific TTL values.
Setting Cache Level and Edge TTL
Edge TTL is how long Cloudflare's edge nodes hold a cached copy before checking your origin for a fresh version. Origin TTL is what your server sends via Cache-Control headers. These are independent settings. You can tell Cloudflare to cache something for a week at the edge even if your origin sends a shorter Cache-Control value, and vice versa.
The Cache Everything option is worth understanding separately. By default, Cloudflare only caches content it recognizes as static based on file extension. Cache Everything overrides that and caches any response, including HTML, regardless of extension. This is appropriate for fully static sites where no page is user-specific. It is not appropriate for WordPress or any site with dynamic, user-dependent content unless you've also written bypass rules for the exceptions.
Practical Example: WordPress Site Cache Rules
A reasonable WordPress cache rule set looks like this. First, a bypass rule that matches any request where the cookie name contains wordpress_logged_in or woocommerce_cart_hash. Set the action to bypass cache. This ensures logged-in users and active cart sessions never get served cached pages.
Second, a bypass rule matching the URL path /wp-admin/*. No part of the admin interface should ever be cached.
Third, a caching rule for static assets matching file extensions like .css, .js, .jpg, .png, .woff2. Set edge TTL to one week. These files don't change without a deployment, so long TTLs are safe.
Rule Order Matters
Bypass rules should always appear before caching rules in your rule list. If a caching rule matches first, the bypass rule below it won't fire. Cloudflare evaluates rules top to bottom and stops at the first match.
Practical Example: Static Site Cache Rules
A static site is simpler. One rule: match all requests on the hostname, set cache level to Cache Everything, set edge TTL to one week or longer. No bypass rules needed because there are no authenticated users, no cart sessions, no admin dashboards. The entire site can live at the edge indefinitely, with your origin only getting hit when the TTL expires or you manually purge the cache after a deployment.
Browser Cache TTL: Controlling the Last Mile
Edge caching controls what Cloudflare stores on its servers. Browser cache TTL controls what the user's own machine stores. These are two separate layers, and confusing them leads to configurations that don't behave the way you expect.
What Browser Cache TTL Does and Does Not Control
When Cloudflare delivers a response to a browser, it can include cache headers that tell the browser how long to keep that file locally. If the browser has a valid cached copy, it won't make a network request at all, not even to Cloudflare's edge. That's faster than any CDN delivery because there's no network round trip whatsoever.
Browser Cache TTL in Cloudflare is configured under Caching > Configuration in the dashboard. The setting either respects whatever Cache-Control header your origin sends, or overrides it with a value you specify. If your origin sends Cache-Control: max-age=3600 and you set Cloudflare's Browser Cache TTL to one week, Cloudflare's setting wins for traffic passing through its proxy.
Recommended TTL Values by Content Type
Images and fonts that don't change without a filename change: one year. CSS and JavaScript files that use versioned filenames or cache-busting query strings: one year. HTML files: no-cache or a very short TTL, because HTML is what changes when you publish new content, and a stale HTML file means users see an outdated page even after you've deployed an update.
Overriding Origin Cache-Control Headers
The important warning here applies to files that change frequently without versioning. If you set a long browser TTL on a CSS file that you edit directly without changing its filename, users will keep loading the old version until their browser cache expires. The fix is cache busting: either append a version number to the filename (styles.v2.css) or use a build tool that appends a content hash automatically (styles.a3f9b2.css). With that pattern in place, long browser TTLs are safe because a changed file gets a new URL, which the browser treats as a completely different resource.
Redirect Rules: Routing Traffic Without Touching Your Server
Every redirect that fires inside your web server costs something. Apache reads .htaccess. Nginx evaluates a rewrite rule. PHP executes. The server sends a response. That chain takes time and consumes server resources, even for a request that's just going to bounce somewhere else immediately.
Why Redirects at the Edge Are Faster
Redirect rules in Cloudflare fire at the edge, before the request ever reaches your origin. No .htaccess file involved. No PHP execution. No server load. The edge node reads the incoming URL, matches it against your rule, and returns a redirect response directly. The round trip to your origin never happens.
For high-traffic sites running large-scale migrations, this isn't a minor optimization. It's the difference between your server handling redirect overhead for millions of requests and your server not seeing those requests at all.
Building a Redirect Rule in Cloudflare
Redirect Rules live under Rules > Redirect Rules in the dashboard. The anatomy is the same as Cache Rules: a match condition and an action. The action for a redirect specifies the destination URL and the HTTP status code, either 301 (permanent) or 302 (temporary).
Use 301 when the move is permanent and you want search engines to transfer link equity to the new URL. Use 302 when the redirect is temporary and you want search engines to keep indexing the original URL. Getting this wrong during a site migration costs you SEO value that takes months to recover.
Practical Example: Redirecting Old URLs After a Site Migration
The single-URL case is straightforward. Match on URL path equals `/blog/old-post
Page Rules vs the New Rules Engine: What Changed and Why It Matters
Cloudflare's original approach to customizing how your site behaves at the edge was a single system called Page Rules. One rule could cache everything, redirect a URL, set security levels, and adjust performance settings simultaneously. That flexibility was also the problem. Everything lived in one place, rule order mattered in unpredictable ways, and the system didn't scale cleanly as Cloudflare's product surface expanded. So they replaced it. Not all at once, but deliberately, with a set of purpose-built rule types that each do one job well.
What Page Rules Were Built For
Page Rules were designed as a catch-all configuration layer. Match a URL pattern, apply a pile of settings. For years, that was enough. A rule like "cache everything on /static/*" took one rule slot and handled it. The problem is that catch-all systems accumulate technical debt fast. Rules conflicted. Evaluation order became a debugging puzzle. New Cloudflare features didn't fit cleanly into the old model, so the system got bolted onto instead of rebuilt.
Page Rules still work. They're not gone yet. But Cloudflare has placed them on a deprecation roadmap, and new projects have no good reason to use them.
Page Rules Are Deprecated
Cloudflare has officially flagged Page Rules as a legacy system. They'll continue to function for existing configurations, but the platform is not investing in new features for them. New projects should start with the modern rules engine from day one.
The Modern Rules Engine: Cache Rules, Redirect Rules, Transform Rules
The replacement isn't one system. It's four focused ones. Cache Rules control what gets cached, for how long, and under what conditions. Redirect Rules handle URL forwarding at the edge, replacing the "forwarding URL" action in Page Rules. Transform Rules let you rewrite URLs, modify request headers, and modify response headers without touching your origin. Configuration Rules let you apply Cloudflare settings like SSL mode or security level to specific URL patterns.
Each type has its own free tier allocation. Redirect Rules give you 10 on free plans. Cache Rules give you 10. Transform Rules give you 10. That's more usable capacity than the 3 Page Rules slots free accounts ever had.
Migration Path: Should You Move Away from Page Rules?
Yes, eventually. Not urgently, but deliberately. A Page Rule that cached everything on /static/* translates directly to a Cache Rule with a hostname-and-path match on /static/*, cache level set to Cache Everything, and an edge TTL of your choosing. The logic is identical. The interface is cleaner and the behavior is more predictable.
Existing Page Rules won't break tomorrow. But every new rule you write should go into the modern engine. Migrate old rules when you're already in that section of the dashboard, not as a dedicated project. One at a time, the old system empties out.
Speed and Reliability Benefits: What You Actually Gain
Proxying your domain through Cloudflare isn't just about security. The performance benefits are measurable, documented, and visible in your server logs almost immediately after you flip the orange cloud on.
Latency Reduction: The Numbers
That number comes from Cloudflare's own network performance data, and it holds up in practice. The reason is geography. When a visitor in Frankfurt hits your site, Cloudflare's edge in Frankfurt responds. Your origin server in Virginia never gets involved for cached content. The round-trip shrinks from transatlantic to local.
Origin Offload: Fewer Requests Hitting Your Server
Every request that Cloudflare serves from cache is a request your origin never sees. No PHP execution. No database query. No bandwidth consumed on your hosting plan. For a static site with aggressive caching configured, origin traffic can drop by 80 percent or more during normal operation. That translates directly to lower CPU load, lower egress costs, and a server that has headroom left when actual dynamic requests arrive.
Auto Minify contributes here too. Cloudflare can strip whitespace and comments from HTML, CSS, and JavaScript at the edge before delivery, shaving bytes off every response without touching your source files. It's a small win per request that compounds across millions of page loads.
Reliability Under Traffic Spikes
A traffic spike that would saturate your origin gets absorbed at the edge. Cloudflare's network handles the flood. Your server sees a fraction of the actual load. This isn't just a performance feature. It's effective HTTP-layer DDoS mitigation. Volumetric attacks that target your site with repeated page requests hit Cloudflare's infrastructure, not yours.
Cloudflare's Always Online Feature
Always Online is the reliability safety net. If your origin server goes down entirely, Cloudflare serves a cached version of your pages to visitors. It's not a perfect substitute for a live site, but it's the difference between a maintenance page and a functioning read-only experience during an outage. Enable it under Caching configuration and let it run quietly in the background.
For teams that need more than the default routing, Argo Smart Routing is a paid upgrade that routes requests across Cloudflare's backbone using real-time congestion data rather than standard BGP paths. Measurable latency improvements, especially for origins in regions with inconsistent peering. Worth evaluating once you've extracted everything from the free tier.
Putting It All Together: Three Real-World Configurations
Theory lands differently when you can see it applied to a site that looks like yours. Three configurations follow. Each one makes different tradeoffs based on what the site actually serves.
Configuration 1: Static Site (JAMstack or Hugo/Jekyll)
A static site is the easy case. Every page is the same for every visitor. There's no session, no cart, no user-specific content. Cache everything, cache it aggressively, and don't second-guess it.
DNS: Orange cloud on for all A and CNAME records. Cache Rule: Match the entire hostname, set cache level to Cache Everything, set edge TTL to 30 days, set browser cache TTL to 24 hours. No bypass rules needed because there's nothing to bypass. Redirect Rules handle any old URLs from a previous site structure, forwarding them permanently to the correct new paths at the edge before the request ever touches your origin.
Configuration 2: WordPress Site
WordPress is where caching gets complicated. The site has publicly cacheable pages, but it also has admin interfaces, shopping cart states, and logged-in sessions that must never be served from cache to the wrong user.
Cache Rule 1: Bypass cache for any request matching /wp-admin/*, /cart, /checkout, or any request carrying the wordpress_logged_in_* cookie. This rule runs first. Cache Rule 2: Cache static assets at /wp-content/uploads/*, /wp-content/themes/*, and /wp-content/plugins/* with a long edge TTL. Redirect Rules: Forward any old post slugs that changed during a site migration. WordPress has no native edge redirect system, so Cloudflare handles this cleanly without a plugin.
"The rule for WordPress caching is simple: if the request proves the visitor is logged in or mid-transaction, Cloudflare gets out of the way."
Use Cache Rules here, not Page Rules. The conditional logic around cookies is cleaner in the new engine, and the rule order is explicit.
Configuration 3: API Backend with No Caching
An API backend that returns user-specific or session-specific data should not be cached at all. The risk isn't a performance problem. It's serving one user's data to a different user.
Cache Rule: Match /api/*, set cache level to Bypass. Done. Belt-and-suspenders approach: configure your origin to send Cache-Control: no-store on all API responses. If the Cache Rule ever gets misconfigured, the origin header is the fallback.
No Redirect Rules needed for a pure API. The decision tree for any new URL you're configuring is one question: does this content change per user or per session? If yes, bypass cache without hesitation.
Common Mistakes and How to Avoid Them
Most Cloudflare caching problems fall into a small number of categories. Knowing them in advance is faster than debugging them after the fact.
Caching Pages That Should Not Be Cached
The most consequential mistake is caching a page that contains user-specific data and serving it from cache to a different user. Checkout pages, account dashboards, order confirmations. If Cloudflare caches a checkout page while User A's cart data is in the response, User B might see it.
This Is a Data Exposure Risk
Caching authenticated or session-specific pages isn't just a functional bug. It's a potential privacy incident. Audit your bypass rules before you touch edge TTL settings on any page that could contain personal or transactional data.
The fix is a Cache Rule that bypasses cache for any request carrying a session cookie, or for specific paths you know are user-specific. Write that rule before you write anything else.
Forgetting to Purge Cache After Deployments
You deploy a new version of your site. Visitors keep seeing the old one. Cloudflare is serving a cached copy from before your deployment. This is expected behavior, not a bug, but it catches people off guard repeatedly.
Purge options: single URL, cache tag (requires paid plan for tag-based purging), or purge everything. The dashboard makes all three accessible under Caching > Cache Purge. The API makes it scriptable. Add a purge step to your deployment pipeline and stop thinking about it manually.
Conflicting Rules and Rule Order
Cloudflare evaluates rules in the order they appear in your dashboard. A Cache Rule that caches /static/* placed below a rule that bypasses everything will never fire for those paths because the bypass rule wins first. The interface lets you drag rules to reorder them. Use that. Specific rules should sit above general ones. Bypass rules for sensitive paths should sit at the top of the list.
Browser Cache TTL deserves a mention here too. Setting it to 30 days on a JavaScript bundle that you update frequently means visitors run old code until their local cache expires. The fix is filename versioning on your assets, not a shorter TTL. Versioned filenames get cached forever and replaced when they change. Unversioned filenames need short TTLs and suffer for it.
If Cloudflare features aren't working at all, check the DNS tab first. A gray cloud means DNS-only. No proxy, no caching, no rules. The orange cloud has to be on.
Your Part 7 Action Checklist: Activate Cloudflare's Performance Layer
Ten steps. Work through them in order and your site's performance layer will be properly configured before you close the dashboard tab.
Part 6 covered how Cloudflare handles DNS at the record level and what the orange cloud actually does when you enable it. This part built on that foundation by showing what happens once traffic flows through the proxy. Part 8 moves into Cloudflare Workers: edge compute that runs your own JavaScript at Cloudflare's network layer, between the visitor and your origin, with response times that don't depend on where your server lives.
