Read cache statistics
The two statistics panels show how much reusable content POM Cache currently stores for the site being administered. HTML and progressive JSON are measured separately because they have different generation, delivery, and invalidation paths.
Find the counters
Open Settings → POM Cache → General. On multisite, open the equivalent screen in Network Admin.
- Cache Contents reports static HTML.
- Progressive JSON Cache Contents reports progressive archive JSON.
Each panel displays a file count and an aggregate size. Opening or refreshing the settings screen recalculates those values by scanning the current site's cache directory. The saved numbers are therefore a recent inventory, not a live counter that changes in the browser as visitors navigate the site.
What is counted
The HTML count includes non-empty files whose path ends in index.html below the current site's HTML cache tree. The protective file at the cache root is not treated as a cached page.
The JSON count includes non-empty .json files below the current site's progressive JSON tree. A JSON route can create several artifacts for different languages, post types, filters, pages, or progressive-rendering contexts.
Zero-byte files do not count as usable cache entries. The reported size is the sum of the files that qualify for that store.
Interpret common results
Zero files immediately after activation is normal. POM Cache generates content from eligible public requests; it does not preload the whole site.
Zero HTML files after two anonymous visits to the same page means that the request may be ineligible, the cache runtime may be disabled, WordPress may not be loading the drop-in, or storage may not be writable. Test a clean GET request without a query string or login cookies.
HTML files exist but JSON remains at zero can be correct if the site is not using a supported progressive archive request, JSON writes are disabled, or the tested response is not cacheable.
The count rises after URL or language changes is expected when those variations have different public representations. Unexpected continuous growth deserves investigation; see Monitor storage usage.
The count drops after editing content can indicate that automatic invalidation removed the current site's store. The next eligible visit should repopulate the required file.
What the counters do not prove
A file count does not prove that:
- a visitor received a cache hit;
- an Apache rule served the file before PHP;
- the file contains current or correct content;
- a CDN has refreshed its own copy;
- personalized output was excluded;
- the cache improves response time.
The settings page also does not provide per-URL age, hit/miss history, a hit ratio, or automatic expiry information. POM Cache does not remove files merely because they have reached an age threshold.
A reliable check
- Record both counts.
- In a private browser window, request one eligible public URL twice.
- Refresh the settings screen.
- Confirm that the relevant counter changed or remained stable for a previously generated route.
- Use the response evidence in Verify a cache hit.
- Confirm that a logged-in request does not receive public cached content.
On multisite, repeat the check while administering the intended site. Statistics are scoped to that site's cache tree; they are not a network-wide total.