Inicio - Documentación - POM Cache - 02 Concepts - Understand cache hits and misses

Understand cache hits and misses

“Hit” and “miss” describe a lookup, not whether a page looks fast. Precise language helps you identify the layer that answered and whether the result was expected.

Four outcomes, not two

POM Cache testing should distinguish these cases:

Outcome Meaning Does WordPress render? Can a new HTML file appear?
Hit A reusable index.html was found and served No for Apache/early PHP No
Cacheable miss No usable file existed, but the final response qualified Yes Yes
Bypass The request was not allowed to read or write shared HTML Yes No
Rejected response The request began normally, but final output failed storage checks Yes No

A missing file is therefore not enough to predict what happens next. A public page may create it; a query-string search, preview, logged-in view, redirect, or incomplete response should not.

Identify an origin hit

Use a signed-out browser with a clean cookie jar and request the exact same canonical URL twice.

For an early PHP hit, inspect the second response for:

X-POM-Cache: Served static cache from PHP; phase=early

For Apache delivery, that header is absent because PHP never runs. After the cache file has been generated:

  1. request the URL again and view the HTML source;
  2. find the Cached page generated by POM-Cache comment;
  3. record its timestamp;
  4. reload without purging;
  5. confirm the timestamp is unchanged.

You can also review POM Cache → General → Cache tools → Cache Contents. A stable file count plus an unchanged page timestamp supports reuse, although the count alone does not prove which URL was served.

Recognize a cacheable miss

Immediately after Delete Cache, the first suitable request should:

  • take the normal WordPress rendering path;
  • return the correct page to the visitor;
  • create a host-and-path directory ending in index.html;
  • add a POM Cache generation comment to the stored copy.

The first response is not retroactively a hit. The file only becomes available after WordPress finishes and the atomic rename succeeds.

Recognize a bypass

Change one request property while keeping the path constant:

  • log in to WordPress;
  • add an item to a WooCommerce cart;
  • add a meaningful query parameter;
  • request a preview;
  • send an Accept: application/json header.

The existing anonymous file can remain on disk, but the changed request should not reuse it. That is a successful safety test.

Separate origin and CDN evidence

A CDN may return its own HIT, Age, or vendor-specific header. That proves an edge lookup, not a POM Cache lookup.

When diagnosing:

Browser → CDN cache → Apache/PHP POM Cache → WordPress render

Test one boundary at a time. First prove that the origin generates and reuses the correct file. Then enable or validate edge caching. After an origin purge, an old edge object can remain visible until the CDN is invalidated.

Why a “fast miss” is possible

WordPress might render quickly because of:

  • a warm persistent object cache;
  • PHP opcode caching;
  • optimized database queries;
  • a lightweight template;
  • a nearby origin.

Speed alone is not cache evidence. Use the file, source timestamp, response headers, and controlled purge/reload sequence.

A repeatable hit test

  1. Choose a normal published page with no visitor-specific output.
  2. Open it while signed out and confirm the content is correct.
  3. Delete the current site’s HTML cache.
  4. Request the page once and verify that its file count appears.
  5. Request it again and prove reuse by header or unchanged generation timestamp.
  6. Open the page while authenticated and prove bypass.
  7. If a CDN is present, repeat the edge test only after the origin result is known.

If the expected outcome differs, use Pages are not cached rather than weakening the request guards.

What POM Cache deliberately does not do
Anterior
Why some requests must never be cached
Siguiente