Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Edge caching stores a copy of an eligible WordPress response at CDN data centers close to visitors. Static files such as images, CSS, and JavaScript are normally cacheable automatically. Full HTML pages are different: they can contain account, cart, preview, or other private state, so a CDN must be explicitly told which responses are safe to share. A correct setup can serve public pages from the edge while sending logged-in, administrative, transactional, and personalized requests to WordPress.
What edge caching means for WordPress
A conventional WordPress request travels from a visitor to your origin server, where PHP, WordPress, plugins, and the database generate a response. An edge cache places a copy of that response in a CDN point of presence. A later visitor whose request matches the same cache key can receive the copy from a nearby data center instead of making the full trip to the origin.
CDNs generally cache static content by default. Cloudflare describes its service as caching content across globally distributed data centers, but its default behavior does not automatically make dynamic WordPress HTML public. Images, stylesheets, scripts, and other static assets are usually eligible; HTML requires a cache policy or a WordPress-aware product.
The important safety boundary is shared public HTML versus personalized or transactional responses. A home page or published article may be identical for anonymous visitors. A dashboard, preview, shopping cart, account page, or response containing a user-specific cookie is not. If private HTML enters a shared cache, another visitor could receive it.
#1 Best Overall
How a cached WordPress request is evaluated
1. The CDN receives the request
The visitor connects to the CDN hostname. The CDN examines the HTTP method, path, query string, request headers, cookies, and its cache rules before deciding whether the request can use shared cache.
2. Eligibility is checked before lookup
A request can be rejected before the CDN even searches its cache. Typical reasons include a method other than GET or HEAD, an excluded path, a bypass cookie, a request asking for no-cache, a development mode setting, or a rule that marks the response dynamic. This produces a DYNAMIC result rather than a cache miss.
3. The cache key identifies the object
For eligible traffic, the CDN builds a cache key from the hostname, path, and any query-string or header components configured by the policy. Two URLs that differ in a meaningful query parameter should not share an object unless you have deliberately normalized that parameter. Conversely, including unnecessary parameters can create many nearly identical objects and reduce the hit rate.
4. A hit, miss, or bypass is returned
- HIT: the edge served an object already stored for the matching key.
- MISS: the request was eligible, but that edge did not have a fresh object. The CDN fetched the origin response and normally stored it for subsequent requests.
- BYPASS: a request, response, cookie, header, or rule instructed the CDN not to use shared content.
- DYNAMIC: the request was considered ineligible before cache lookup, often because of method, path, development mode, or an explicit rule.
These labels describe cache behavior, not a performance grade. A miss immediately after publishing or purging is normal. A hit on a page that contains user-specific information is a configuration defect.
What WordPress content should and should not be cached
| Content or request | Typical policy | Reason |
|---|---|---|
| Images, CSS, JavaScript, fonts | Cache by default; set an appropriate asset TTL | These files are normally identical for many visitors. |
| Published posts and pages for anonymous visitors | Cache at the edge when the response is a 200 HTML GET or HEAD | Public HTML can be shared if cookies and other personalization are absent. |
/wp-admin/ and login or authentication flows |
Bypass | Administration and sign-in responses are private and state-changing. |
| Cart, checkout, account, and order pages | Bypass | Commerce state belongs to the individual visitor. |
| Preview and draft URLs | Bypass | Preview content can be private, temporary, or different from the published page. |
| Search results, feeds, cron, and API endpoints | Usually bypass unless you have a specific, tested policy | These responses often vary by query, authentication, or request state. |
| Requests with logged-in, session, comment, or commerce cookies | Bypass | Cookies can make the HTML user-specific. |
Responses with Set-Cookie |
Do not store as shared cache by default | Cloudflare’s default behavior does not cache responses that include Set-Cookie. |
The table describes a safe starting point, not a substitute for inspecting your plugins. A membership, multilingual, personalization, or commerce plugin may add its own cookies or headers. Add those signals to your bypass policy before enabling HTML caching.
Two ways to cache WordPress HTML at the edge
Managed WordPress optimization
Cloudflare Automatic Platform Optimization (APO) is the WordPress-aware approach. Its plugin connects publishing events to the edge and applies eligibility and bypass logic for WordPress. APO can cache HTML at the edge, bypass logged-in and administrator users, and update or purge edge content when changes are published. You continue managing content in WordPress rather than manually purging every edited URL.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11APO still depends on a correctly proxied hostname, compatible responses, and exclusions for private or stateful paths. Treat its automatic behavior as a managed policy to verify, not as permission to cache every response.
Manual Cache Rules
Manual rules provide more explicit control. In the CDN dashboard, create a Cache Rule that selects the WordPress hostname and only the paths and responses you have determined are public. Mark eligible GET and HEAD HTML responses for edge caching, then set an Edge TTL. Cloudflare defines Edge TTL as the maximum time an asset remains fresh or available from edge cache.
Manual rules are useful when you need custom cache keys, different TTLs for sections of a site, or visibility into exactly why a request is bypassed. They require more maintenance: every new plugin route, cookie, query parameter, or personalization feature must be assessed.
| Decision factor | Managed APO | Manual Cache Rules |
|---|---|---|
| Initial setup | Lower effort after the WordPress plugin and CDN connection are configured | Higher effort because paths, cookies, methods, and response conditions must be defined |
| WordPress publish handling | Plugin can send update and purge events | You must configure a purge integration or purge affected objects yourself |
| Cache-key control | Provider-managed behavior; inspect the documented limits | Explicit control over query strings, headers, and other key components |
| TTL control | Managed defaults plus available provider settings | Per-rule Edge TTL and, separately, Browser Cache TTL where supported |
| Bypass-cookie support | WordPress-aware bypasses for logged-in and administrator traffic, subject to documented eligibility | You define and maintain every relevant cookie and path condition |
| Debugging | Fewer policy decisions to inspect, but less granular customization | More visibility into matching rules and exceptions, with more possible misconfigurations |
| Plan and feature requirements | Depends on the provider and current APO availability | Depends on the provider plan and the Cache Rules, purge, and cache-key features included in it |
A team already operating on AWS may instead use Amazon CloudFront, a global edge distribution service. WordPress plugins can add CloudFront support, but you still need the same method, cookie, path, query-string, TTL, and purge safeguards. Changing CDN vendors does not remove the privacy problem.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Safe setup sequence for Cloudflare or another CDN
1. Proxy the correct WordPress hostname
- In the CDN DNS or distribution settings, put the public WordPress hostname behind the CDN proxy.
- Confirm that the origin server remains reachable by the CDN and that TLS, the origin certificate, and the Host header are valid.
- Open the site anonymously and while logged in to verify that the hostname, redirects, cookies, and administrative access still work before changing HTML cache behavior.
Do not begin by caching the entire domain indiscriminately. Establish that the CDN can reach the origin and that the current site works through the proxy.
2. Keep static assets on the provider defaults initially
Leave images, CSS, JavaScript, and fonts under the CDN’s normal static caching behavior unless you have a reason to change it. Asset versioning or filename changes should be used when deploying new files so a long-lived object cannot hide an update.
3. Choose APO or a manual HTML rule
For APO, install and connect the provider’s WordPress plugin, complete the site authorization, and confirm that the plugin can send purge or update events. For manual configuration, open the CDN’s Cache Rules area and create a rule that targets only the intended hostname and public URL pattern.
Require the response conditions documented for HTML caching: GET or HEAD, a 200 response with an HTML content type, a permitting cf-edge-cache header where applicable, no bypass cookie, no excluded path, no risky request header, and a supported query-string pattern. If your provider uses different header names, use its equivalent eligibility controls rather than copying a Cloudflare-specific header blindly.
4. Set an Edge TTL deliberately
Choose how long an object may remain fresh at the edge. A short TTL limits staleness but increases origin requests. A long TTL reduces origin work but makes purge reliability and publishing integration more important. Edge TTL is separate from Browser Cache TTL: the former governs the CDN’s stored object, while the latter governs how long a visitor’s browser may reuse its copy.
Do not use a long TTL to compensate for an untested purge process. First prove that a publication or manual purge removes the old object, then select a TTL that matches how often your site changes and how harmful stale content would be.
5. Add bypass rules before enabling HTML caching
Create bypass conditions before the cache rule is active. At minimum, exclude:
/wp-admin/, login, authentication, and password-reset paths;- cart, checkout, account, order, and other commerce routes;
- preview, draft, and editor URLs;
- feeds, cron endpoints, search, XML or JSON APIs, and webhook routes unless each has a tested public-cache design;
- requests containing logged-in, session, comment, or commerce cookies;
- responses or requests with
Set-Cookie,Cache-Control: private,no-store, or an explicit no-cache instruction; - requests with authorization or other headers that identify a user or alter the response.
Place bypass logic ahead of the broad “cache public HTML” rule. A broad cache rule that matches first can defeat a later exception, depending on the provider’s rule evaluation order.
Recommended Free Tools
6. Connect publishing to purge
A purge removes cached objects. The next request in each data center fetches the current origin response and returns MISS; later requests can return HIT. With APO, the WordPress plugin can send update events when content is published. With manual rules, configure the provider’s purge API, plugin integration, or an operational step for purging affected URLs.
Decide whether a change requires a single-URL purge, a related archive purge, or a full-site purge. Purging everything is simple but can send a large burst of requests to the origin; purging too little leaves old archives, feeds, or navigation fragments visible.
7. Test before production rollout
- Use a private browser window with no WordPress cookies and request a public post twice. Inspect the response headers and confirm that the first eligible request can be a
MISSand a later request can become aHIT. - Publish a small, safe edit. Confirm that the changed page and any configured related objects are purged, then request them again and observe the expected repopulation sequence.
- Sign in as a normal user and request the same public URL. Confirm that the response is bypassed or dynamic and that it contains the correct user state.
- Test an administrator session,
/wp-admin/, login, preview, search, API, account, cart, and checkout paths. - Inspect
Set-Cookie,Cache-Control, content type, query strings, and thecf-cache-statusheader (or your CDN’s equivalent) for every test.
How to diagnose HIT, MISS, BYPASS, and DYNAMIC
DYNAMIC
DYNAMIC means the request was ineligible before cache lookup. Check whether it used POST or another non-GET/HEAD method, matched a bypass rule, hit an excluded path, included a disqualifying header or cookie, or was affected by Development Mode. This status does not mean the origin is broken.
BYPASS
BYPASS means the request or response told the CDN not to serve shared content. Inspect cookies, Set-Cookie, Cache-Control, authorization headers, and the rule that matched the request. A plugin that sets a session cookie on every page can prevent public HTML from being cached until you adjust the plugin or explicitly account for that cookie.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →MISS
A miss after a purge is expected. The edge has no current object yet, so it retrieves the origin response and repopulates its cache. Different data centers may show misses at different times because each must obtain its own copy.
HIT
A hit confirms that the edge served a stored object for that cache key. It does not prove that the object is fresh, correct for every visitor, or safe. If a logged-in request, cart page, preview, or other personalized response is a hit, stop increasing TTLs and tighten the bypass conditions immediately. Purge the affected objects after correcting the rule.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Staleness, purging, and cache-key decisions
TTL policy
Use the site’s publishing pattern to choose Edge TTL. Frequently edited news or campaign pages need a short freshness window or dependable event-driven purge. Stable documentation can tolerate a longer window if updates reliably trigger purge. Keep browser caching in mind: a visitor may still see an older browser-held response after the edge object has been replaced if Browser Cache TTL is longer.
Query strings
Decide which query parameters change the response. Tracking parameters that do not affect HTML can be excluded from the cache key to avoid duplicate objects. Search terms, preview tokens, language selectors, and other response-changing parameters must either remain in the key or be bypassed. Never normalize a parameter merely because most of its values are harmless.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteCookies and headers
Cookie-based bypass is safer than trying to cache around unknown user state. Maintain an inventory of cookies added by WordPress, membership, comment, analytics, experimentation, and commerce plugins. Likewise, treat authorization, no-cache, and private-cache headers as signals to bypass unless you have verified an equivalent safe policy.
Purge scope
Publishing a post may affect its canonical URL, category or tag archives, home page, RSS feed, XML sitemap, and navigation blocks. Your purge integration should cover the objects that actually display the changed data. A full purge is a recovery tool, not a substitute for understanding dependencies.
Common failure modes and fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| Every public page remains DYNAMIC | No HTML cache rule, Development Mode, unsupported method, or an always-present bypass signal | Check the matching rule, method, mode, cookies, and response headers; verify that the response is a 200 HTML GET or HEAD. |
| Pages remain BYPASS | Set-Cookie, private or no-store cache control, session cookies, authorization, or an exclusion |
Inspect the exact response and remove only the state signal that is genuinely unnecessary; otherwise keep the bypass. |
| A page is stale after publishing | Purge event did not fire, purge scope was too narrow, or browser cache still holds the old copy | Check the plugin or purge integration, purge related objects, compare edge and browser TTLs, and retest in a private window. |
| Old content appears in one location but not another | Each data center repopulates independently, or cache keys differ by query string | Allow each edge to receive the new object and inspect the full URL and key-affecting parameters. |
| Logged-in content appears to be cached | Missing cookie or path bypass, an overly broad rule, or a cache key that ignores user state | Stop the rule, purge affected objects, add the relevant cookie/header/path exclusions, and retest authenticated and anonymous sessions. |
| Checkout or account pages break | Transactional paths or commerce cookies were included in shared caching | Bypass the complete commerce flow and its state cookies; do not cache only the first page in a stateful sequence without testing the entire flow. |
Operational checklist
- The public hostname is proxied and the origin remains reachable.
- Static assets work under the provider’s normal cache policy.
- Only tested GET and HEAD 200 HTML responses are eligible for shared caching.
- Administrative, authentication, preview, search, feed, API, cron, account, cart, checkout, and order paths bypass.
- Logged-in, session, comment, commerce, authorization, no-cache, private, and no-store signals bypass.
- Edge TTL and Browser Cache TTL are documented separately.
- Publishing events purge the affected URLs and related archives.
- Anonymous tests produce the expected MISS-then-HIT behavior.
- Authenticated and transactional tests remain BYPASS or DYNAMIC.
- Response headers and cookies are checked after plugin, theme, and CDN-rule changes.
When edge caching is the right choice
Edge caching is most valuable when many visitors request the same public HTML and the origin spends significant time generating it. It is less suitable for pages whose output is inherently unique per visitor unless you can separate a public shell from private data or bypass the personalized route. The CDN reduces repeated origin work; it does not make database queries, PHP code, or uncached API calls intrinsically faster.
Choose managed APO when you want WordPress-aware publish handling and a lower-maintenance starting point. Choose manual Cache Rules when your team needs precise cache keys, TTLs, path policies, and debugging control and can maintain the bypass inventory. CloudFront is a reasonable architectural alternative for teams already standardized on AWS, but its implementation still requires the same privacy and purge discipline.
Final rollout sequence
- Map every public, authenticated, administrative, and transactional route.
- Inventory cookies, response headers, query parameters, and plugin-generated endpoints.
- Proxy the hostname and verify origin connectivity.
- Enable static caching without changing application behavior.
- Deploy APO or a narrowly scoped manual HTML rule with bypasses already in place.
- Set an Edge TTL that matches publishing frequency and confirm Browser Cache TTL separately.
- Connect publish events to targeted purge.
- Test anonymous, logged-in, administrator, preview, search, API, and commerce requests.
- Monitor cache-status headers after every theme, plugin, cookie, or rule change.
The safe outcome is not “everything is a HIT.” It is public HTML served from nearby edges while every response containing private or changing user state reliably avoids shared cache.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
