Monitor JSON cache size

The progressive JSON cache grows on demand. Each requested combination of site, locale, archive context, taxonomy section, batch number, and items per page can create another file.

POM Cache does not remove JSON merely because it is old, so storage monitoring belongs in the production maintenance plan.

Read the built-in summary

Open Settings → POM Cache → General → Progressive JSON tools and find Progressive JSON Cache Contents.

The summary calculates for the current site:

• the number of non-empty .json files;
• their combined file size.

The scan is refreshed when the settings page builds the summary and after the JSON delete action. It is a current-site storage report, not an analytics dashboard: it does not show hits, misses, ages, or the largest individual file.

HTML files are counted separately under Cache tools → Cache Contents.

What makes the tree grow

One archive can create several dimensions:

locales
× archive contexts
× term sections
× requested pages
× posts-per-page variants

Not every theoretical combination is generated. Only a real or deliberate request writes a cacheable batch.

Growth is usually driven by:

• visitors reaching deeper archive pages;
• more public languages;
• split-by-term archives with many groups;
• changes to progressive archive settings that create a new context hash;
• a changed items-per-page value;
• old slugs or routes no longer receiving traffic;
• automatic invalidation switches being left disabled during frequent structural changes.

Maximum file size is a per-entry guard

Maximum JSON file size defaults to:

1048576

That is 1 MiB in bytes. POM Cache enforces at least 1024 bytes as the configured limit and uses the limit for both reads and writes.

The setting does not cap the whole cache directory. A 1 MiB limit still permits thousands of smaller files.

Do not reduce the value below real response sizes without testing. An oversized dynamic response still reaches the visitor, but POM Cache will neither store it nor reuse an existing file above the limit.

Estimate a storage budget

Use measured values:

expected files × average JSON file size = approximate active storage

For example, 2,000 files averaging 45 KiB require roughly 88 MiB before filesystem overhead. The real distribution may be uneven, so inspect representative small and large archive modes.

Also reserve temporary headroom for:

• a new context being generated before old files are cleared;
• several locales warming at once;
• bulk content activity;
• backup or deployment tooling that copies the cache directory.

Generated cache should normally be excluded from backups and release artifacts according to your hosting policy, because it can be regenerated.

Establish a maintenance routine

1. Record Progressive JSON Cache Contents after normal warm-up;
2. Record it again after a typical week or editorial cycle;
3. Relate growth to new locales, contexts, or deep archive traffic;
4. Clear JSON after structural template or batch-size changes;
5. Confirm the count falls to zero for the current site;
6. Let normal traffic rebuild the active working set;
7. Compare the new steady-state count and size.

A large count is not automatically a problem. Continuous growth after routes are retired or configurations change is a signal to review invalidation.

Bulk operations

During a large import or translation batch, an enabled automatic purge can remove the current-site JSON tree repeatedly. Leaving purges off can preserve stale files. Choose a controlled workflow:

1. Decide whether editors can tolerate stale progressive batches during the operation;
2. Run the bulk change;
3. Perform one manual JSON clear at completion;
4. Verify important archives regenerate;
5. Invalidate related CDN paths if the edge cached them.

This avoids repeated origin churn while ending with a known-fresh cache.

Multisite accounting

The settings summary shows the current site's namespace, not a network-wide total. Repeat the check on each relevant site when the network shares one physical Cache Location.

For subsite-specific clearing, open that site's frontend or dashboard and use the current-site controls described in Clear one site safely on a multisite network.

When size looks wrong

If the count remains zero, test JSON generation and write permissions. If the count is plausible but the size is unexpectedly high, inspect actual batch response sizes and look for:

• unusually large rendered item markup;
• excessive items per batch;
• many obsolete context hashes;
• locale or taxonomy fan-out;
• a maximum size chosen without measuring the payload.

Clear and regenerate before treating old abandoned contexts as current demand. For no-hit or no-write symptoms, continue with Troubleshoot progressive JSON caching.