Static page caching

Static page caching turns the final HTML of an eligible public page into a reusable file. It is most effective for anonymous traffic because a hit can avoid template rendering, database queries, and—in the Apache path—PHP itself.

POM Cache stores one file named index.html for each qualified hostname and URL path. It does not create compressed copies, user-specific variants, or files with an age-based expiry.

What you need before enabling it

Confirm these conditions:

• the site uses working pretty permalinks;
• normal public pages render correctly without caching;
• PHP can write below Cache Location;
• WP_CACHE is true;
• POM_CACHE_HOME points to the installed POM Cache directory;
• wp-content/advanced-cache.php is the expected POM Cache drop-in;
• you know which editorial changes will trigger an automatic or manual purge;
• any CDN can be bypassed or invalidated during origin verification.

POM Cache reports the three WordPress bootstrap checks under POM Cache → Advanced → WordPress configuration. The report is read-only.

Recommended setup order

1. Enable the static HTML cache and save the current site’s runtime choice.
2. Install and verify the advanced-cache drop-in.
3. Generate one simple public page and inspect the cache file layout.
4. Learn which pages can be cached and which requests are excluded.
5. Test logged-in behavior and cookies, query strings, and methods.
6. Review errors and 404 responses and response headers.
7. Add direct Apache delivery only after the PHP path is correct.

This order keeps application behavior observable before the web server begins bypassing PHP.

To understand the two PHP stages in detail, read Phase one: early static delivery and Phase two: validate and store the rendered response. These articles explain why a later hit contains the stored cache marker even though the first visitor receives the original WordPress response.

Generation and delivery are separate

POM Cache needs WordPress to build a missing file:

First eligible request
→ WordPress renders
→ POM Cache checks the complete response
→ temporary file is written
→ temporary file becomes index.html

Later requests may reuse it:

Repeat request
→ Apache direct hit, or
→ early PHP hit through advanced-cache.php, or
→ WordPress renders because the request bypasses or misses

The Caching setting controls PHP generation and static delivery for the current site. Previously copied Apache rules operate before that PHP setting can be read; if you disable caching as an emergency measure, also remove or disable the direct rewrite and purge existing HTML files.

Decide how pages become current again

HTML files remain until they are deleted or replaced. Under General → Runtime, POM Cache offers opt-in purges for:

• public post changes;
• taxonomy term changes.

Both switches clear the current site’s HTML tree when their relevant event occurs. They are intentionally broad because one content change may affect homepages, archives, menus, related-content blocks, or several URLs.

If you leave a switch disabled, make manual purge part of the publishing workflow. Clearing POM Cache does not invalidate an upstream CDN automatically.

Production acceptance criteria

Before rollout, prove all of the following:

• a signed-out canonical page creates one index.html;
• a repeat view reuses the stored response;
• login, password, comment-author, and WooCommerce state bypasses it;
• meaningful query strings and non-HTML requests stay dynamic;
• previews, redirects, ordinary 404 pages, and incomplete output are not stored;
• a post or term change follows the chosen invalidation policy;
• host and subsite boundaries remain distinct;
• Apache/CDN behavior matches the PHP safety contract.

Start with Enable the static HTML cache. Use Caching concepts first if “hit,” “miss,” and “bypass” are not yet clear.