Free tools Windows power users keep installed
One-click scans. No signup required.
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.
The reliable way to enable caching is to let your host handle page caching if it already does; otherwise install one maintained WordPress page-cache plugin, turn on its page cache, exclude private or personalized pages, and verify the response headers while logged out. After publishing or changing templates, styles, menus, or settings, purge the cache layers that may still hold the old response.
Caching does not mean one switch controls everything. A WordPress site can have a server page cache, a reverse proxy such as Varnish, a browser cache for static files, an object cache, and a content-delivery network (CDN). Each stores different data and has its own purge rules. The sections below show how to identify those layers, configure them without conflicts, and prove that visitors are receiving cached responses.
What WordPress caching changes
Without a page cache, a request for a public post can invoke PHP, load WordPress, run plugins and the theme, query the database, assemble the page, and send the resulting HTML. A page cache stores that generated HTML as a static response. Later visitors can receive the stored file without rebuilding the page through the full WordPress stack. This lowers repeated PHP and database work, particularly for pages whose content changes infrequently.
WordPress documentation describes caching as a major performance optimization and says it can improve performance “several hundred times over” for fairly static pages. That is documentation language, not a controlled benchmark or a guarantee for every site. The actual result depends on hosting, theme and plugin code, database load, traffic, network distance, and whether requests are cacheable.
#1 Best Overall
Know which cache layer you are configuring
Before installing anything, map the layers already present. A host may provide full-page caching or Varnish, while a plugin adds another page cache and a CDN caches responses at the edge. Running independent layers without a clear purge and header strategy is a common cause of stale pages and confusing test results.
| Layer | Where it runs | What it stores | How it is purged or refreshed | Important boundary |
|---|---|---|---|---|
| Page cache | WordPress plugin or the web server | Generated HTML for public URLs | Plugin controls, host dashboard, or automatic invalidation | Must bypass logged-in, personalized, and transactional responses |
| Reverse proxy | In front of the web server, commonly a host-managed Varnish layer | HTTP responses, often complete HTML pages | Host or proxy purge endpoint and rules | Can serve stale content even after a plugin cache is cleared |
| Browser cache | Each visitor’s device | Images, CSS, JavaScript, fonts, and other reusable files | Expiration, validation, a new URL, or a user’s browser controls | Does not replace server-side page caching |
| Object cache | Server-side memory or a cache service | Database query results and other WordPress objects | Host or object-cache controls, often after content changes | Speeds generation but does not itself serve a complete HTML page |
| PHP bytecode cache | PHP runtime on the server | Compiled PHP opcodes | PHP/runtime restart or host controls | Reduces compilation work; it is separate from page and browser caches |
Ask your host whether full-page caching, a reverse proxy, a CDN, or object caching is active. Check the hosting dashboard, server documentation, or support response before changing WordPress settings. If the host already owns full-page caching, use its purge controls and compatibility guidance instead of creating a second independent page-cache authority.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsPrepare the site before turning on a page cache
Make a short list of public and private URLs
List representative public pages such as the home page, a category archive, a typical post, and a page with images or embedded media. Separately list URLs that must be generated for each visitor: cart and checkout pages, account areas, personalized dashboards, previews, forms that display user-specific results, and any page whose output changes according to a cookie or session.
Record a baseline
Open a representative page in a private browser window and note its load behavior and response headers in the browser’s Network panel. A first request may be uncached, so do not treat that single request as proof that caching is unavailable. This baseline gives you something to compare after configuration.
Check for existing rewrite and header rules
Look at the host’s cache settings and the web server configuration if you manage it. A plugin that rewrites rules or adds cache headers can conflict with host rules. Plan for one component to own public page caching and purging; document which component that is before enabling another.
Enable page caching step by step
- Confirm the host’s position. Ask whether full-page HTML caching or Varnish is enabled, which URLs are excluded, and how to purge it. Also ask whether the host recommends a particular plugin or supplies automatic purging when WordPress content changes.
- Choose one maintained page-cache plugin when the host does not provide the feature. Install it from the WordPress plugin directory, review its compatibility notes, and avoid activating a second plugin whose primary job is also full-page HTML caching. WordPress’s administration handbook identifies W3 Total Cache, WP Super Cache, and Cache Enabler as plugins that can turn posts and pages into static files.
- Enable the plugin’s page cache. With WP Super Cache, open Settings → WP Super Cache, select the option to enable caching, and save the setting. The plugin generates static files in the site’s cache directory. Other plugins use different labels, so look for a setting described as page cache, disk cache, or static HTML cache rather than enabling every optimization switch at once.
- Generate a first cache. Log out, open the public URLs you listed, and allow each page to load once. The first request may build the static response; subsequent requests should be eligible to reuse it. WP Super Cache provides controls to inspect generated files and clear the cache.
- Clear the cache after changes. Purge the page-cache plugin whenever you publish or edit content, change menus, update templates or styles, alter plugin settings, or deploy code that changes output. If the host, CDN, or reverse proxy has its own cache, purge that layer as well.
- Configure exclusions before opening the site to logged-in users. Exclude cart, checkout, account, dashboard, preview, and other user-specific URLs. Exclude responses that vary by login, session, commenter identity, location, or a private cookie unless your cache system explicitly supports that variation.
- Coordinate any proxy or CDN. If the host uses Varnish or another reverse proxy, follow its purge and cookie rules. A plugin purge cannot remove a copy held by a separate proxy unless integration is configured. Likewise, a CDN may continue serving an old object after the origin cache is clear.
Configure browser caching for static files
Browser caching is separate from page caching. It controls how long a visitor can reuse an image, stylesheet, script, font, or other static asset without downloading it again. Configure response headers for those files through your host, web server, CDN, or caching plugin.
Cache-Control: use a suitablemax-ageso browsers know how long an asset may be reused. A positivemax-ageis also one of the cache indicators recognized by WordPress Site Health.Expires: supplies an expiration time for clients that use this older HTTP mechanism.- Entity tags (ETag): let a browser validate whether a stored file is unchanged. If it is unchanged, the server can return a 304 Not Modified response without retransmitting the full file.
Long browser lifetimes work best when asset URLs change whenever the file changes, for example through a version query string or renamed file. Otherwise a visitor can retain an old stylesheet or script even after the server page cache has been purged. Do not apply a long public lifetime to responses containing private or user-specific data.
Keep private and dynamic responses out of shared page caches
A shared page cache may deliver one stored HTML response to many visitors. That is appropriate for a public article but dangerous for a page containing account details, a shopping cart, a one-time form result, or another user’s information. Logged-in users and commenters often receive cookies that indicate their session or identity; those responses should normally bypass the public page cache.
WordPress provides nocache_headers() for responses that must not be cached. Use it, together with your cache layer’s exclusion rules, when custom code generates private output. Exclusion rules must match the actual URLs, cookies, query parameters, and headers used by the site. One documented Batcache implementation skips cookies beginning with wp, wordpress, or comment_author; that is an example of one implementation, not a universal rule you can copy to every host.
Test both anonymous and authenticated states. A cache hit for an anonymous post and an intentional bypass for a logged-in account page are both correct outcomes. The goal is not to cache every response; it is to cache safe, reusable responses and preserve correct personalization.
Verify that caching is working
Use the browser Network panel
- Open a private or incognito window so existing browser data is less likely to affect the result.
- Make a GET request for a public URL while logged out.
- Inspect the document request’s response headers. Look for a positive
Cache-Control: max-age=..., an indicator added by your plugin or host, or a reverse-proxy header such asX-Varnish. - Reload or request the same URL again. Compare the headers and timing with the first request. The exact header names and hit/miss values vary by host and plugin, so use the host’s documentation to interpret them.
- Repeat the test while logged in. A deliberate cache bypass, a private response, or a no-cache header on the authenticated request is expected when the page is personalized.
WordPress documentation recommends checking a GET request when evaluating cached responses. Site Health recognizes cache evidence such as a positive Cache-Control max-age and X-Varnish patterns, but the absence of one particular header does not prove that no cache exists; some systems use different headers or hide them.
Check content freshness deliberately
Publish a harmless, recognizable change to a public test post, purge the relevant layers, and request the page while logged out. Confirm that the new text appears. Then inspect a static asset after changing it and verify that its URL versioning or cache headers do not leave the old file in the browser. Remove the test text when finished.
Why visitors still see an old version
| Symptom | Likely location of the old response | Corrective action |
|---|---|---|
| The origin shows new text, but remote visitors see old HTML | Host page cache, reverse proxy, or CDN | Purge each upstream layer and confirm its invalidation completed |
| HTML is new, but styling is old | Browser or CDN cache for CSS | Change the asset version or filename and review Cache-Control and Expires |
| Only logged-in users report stale or inconsistent output | Intentional bypass, cookie variation, or a misconfigured exclusion | Compare headers in logged-out and logged-in sessions; adjust exclusions rather than forcing a shared cache |
| Clearing the plugin cache changes nothing | Host-managed cache or proxy still contains the response | Use the host or proxy purge control and identify the single cache authority |
| A cart or account page shows another state | Private URL was cached publicly | Immediately purge the affected layers, add URL and cookie exclusions, and send no-cache headers for that response |
When content changes, purge in a known order: the WordPress page cache, the host or reverse proxy, the CDN, and finally your own browser data if you are testing locally. Purging only one layer can leave an older copy upstream or downstream. Avoid repeatedly pressing refresh as a substitute for identifying which layer supplied the response.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Common setup mistakes and recovery steps
Two page-cache systems are active
Symptoms include contradictory headers, cache files that never update, repeated purges that do not work, or intermittent old and new versions. Disable one page-cache authority, restore the host’s recommended rules, purge all layers, and retest from a private window. Keep one documented owner for HTML caching, headers, and invalidation.
The cache is enabled but no files are generated
Check that the plugin setting was saved, the cache directory is writable, and the URL is publicly accessible without a login or exclusion cookie. Visit the page while logged out to trigger generation, then use the plugin’s generated-file check. A host-level cache may also mean the plugin does not create files because the request is being handled earlier in the stack.
Changes appear only after a long delay
Find the longest cache lifetime among the plugin, host, CDN, and browser. Add automatic purge hooks for publishing and theme or plugin updates where supported. For static assets, use versioned URLs so changed files are distinguishable from old ones. Do not simply reduce every lifetime without understanding the resulting load and invalidation behavior.
Personalized content leaks into a public response
Treat this as a configuration incident. Purge all copies, identify the cookie, URL, query parameter, or code path that varies the response, and exclude it at every cache layer. Add nocache_headers() in custom responses that must never be stored, then test with two separate sessions before re-enabling caching.
Maintenance checklist
- Keep exactly one clearly identified owner for public HTML page caching.
- Document host, proxy, CDN, plugin, and browser purge steps.
- After publishing, editing menus, changing CSS, updating templates, or changing plugin settings, purge the layers that can contain the affected response.
- Review exclusions whenever you add a membership feature, cart, account area, personalization, or new cookie.
- Test a representative public URL logged out and a private URL logged in after major changes.
- Inspect response headers periodically instead of assuming the cache state from a plugin status screen alone.
- Watch for stale assets caused by browser lifetimes and use URL versioning when files change.
What result should you expect?
Page caching removes repeated WordPress generation work for cacheable public requests; browser caching reduces repeat downloads of unchanged static assets; object caching reduces repeated database or object retrieval. They solve different parts of the request path and can be combined when their ownership and purge behavior are understood.
Recommended Free Tools
There is no universal speed percentage to promise. The WordPress handbook’s “several hundred times over” wording is a qualitative statement about fairly static pages, not an independently validated result for a particular host, theme, device, or traffic pattern. Verify your own site with repeat requests, response headers, and measurements taken before and after the change.
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.
