Caching concepts

This chapter explains the decisions POM Cache makes before you configure a server rule or troubleshoot a page. Read it when you need to understand why a request was reused, rendered normally, or deliberately excluded.

POM Cache maintains two independent origin stores:

• Static HTML cache: complete public pages stored as index.html.
• Progressive JSON cache: data files generated for compatible POM Theme progressive archives.

The static HTML cache is the subject of most examples in this chapter. JSON has its own eligibility, storage, delivery, and invalidation controls; enabling one store does not enable the other.

The three places a response can come from

For a public page, the browser may receive a response from:

1. A CDN edge: an upstream service reuses an edge copy before the request reaches the origin.
2. An origin cache hit: Apache or POM Cache finds the page’s existing index.html.
3. WordPress: PHP, WordPress, the theme, and the active plugins render the request.

These layers are cumulative, not interchangeable. A successful CDN hit says nothing about whether the POM Cache file exists at the origin. Likewise, a POM Cache hit does not mean that WordPress’s object cache was involved.

The central safety rule

A static file is shared output. POM Cache may only reuse it when the response is suitable for every anonymous visitor represented by the same host and URL path.

That means the following are intentionally poor candidates:

• administration and login routes;
• authenticated or password-protected views;
• cart, checkout, and account state;
• previews and Customizer requests;
• query-string searches and other content-changing query strings;
• REST, feed, robots, redirect, and non-HTML responses;
• state-changing request methods.

A bypass is not a cache failure. It is often the correct outcome.

How an HTML file is created and reused

Eligible public request
        │
        ├── matching index.html exists
        │       ├── Apache serves it directly, or
        │       └── the early PHP drop-in serves it
        │
        └── no usable file
                └── WordPress renders the page
                        ├── response fails final checks → return only
                        └── response passes final checks → write index.html

The first eligible request is normally slower because WordPress must render it. Later matching requests can reuse the file. POM Cache does not assign an age-based expiry to HTML files, so content changes must be paired with the appropriate purge strategy.

Choose the concept you need

• How POM Cache handles a page request follows one request from the web server to the final write.
• Static HTML cache and WordPress object cache are different explains why the two technologies solve different costs.
• Apache delivery and PHP delivery compared shows what each origin path can and cannot inspect.
• Understand cache hits and misses gives precise language for verification and troubleshooting.
• Why some requests must never be cached describes the privacy and correctness boundary.
• How cache files stay isolated by host and site explains the file key and canonical-host implications.
• How POM Cache works on WordPress multisite covers shared infrastructure and site-specific settings.

When these concepts are clear, continue to Static page caching for the operational workflow.