Why cache progressive archive JSON

Progressive loading reduces the amount of archive content included in the first HTML document. The tradeoff is that later batches become separate requests. Caching those requests prevents the same archive work from being repeated for every visitor.

The work behind one batch

When a progressive JSON URL is not cached, the compatible POM Theme flow must:

1. Load WordPress and the active application code;
2. Resolve the post type, locale, archive mode, page number, and items per page;
3. Verify that the URL still matches the current archive configuration;
4. Query the posts for that batch;
5. Render each archive item with its current template;
6. Prepare pagination and next-request data;
7. Encode the complete response as JSON.

That work is necessary for the first valid response. It adds little value when a second anonymous visitor requests exactly the same batch before the underlying content changes.

POM Cache stores the completed response. A later hit can avoid the query and rendering work, and the earliest delivery path can avoid most or all of the WordPress bootstrap.

Why this is separate from page cache

The archive page and its JSON batches have different URLs and different response types:

/products/
/pom-json/archive/product/<context>/page-2-ppp-12.json

The first is HTML. The second is JSON requested by the browser after the page loads. Clearing or disabling only the HTML cache cannot remove a stale JSON batch, and clearing only JSON does not require throwing away a current page shell.

POM Cache therefore maintains two independent stores, two sets of runtime controls, two status summaries, and separate buttons on the settings screen. The administration-bar shortcut can clear both when the whole current site must be refreshed.

Where the largest gains appear

JSON caching is most useful when:

• many visitors traverse the same public archives;
• each batch renders rich cards, prices, images, custom fields, or taxonomy data;
• a progressive archive is split into several taxonomy sections;
• translated archive batches are requested repeatedly;
• the origin has a meaningful WordPress bootstrap or database cost;
• a CDN can reuse the short public response safely.

The gain may be modest on a small, rarely visited archive. It can be substantial on a busy catalog where the same page-two or category batch would otherwise be rendered hundreds of times.

Measure your own workload. POM Cache intentionally does not promise a universal response-time percentage because hosting, templates, query cost, object cache, and CDN behavior all affect the result.

What POM Cache does not cache here

The progressive JSON subsystem is deliberately narrow. It does not:

• cache arbitrary REST API endpoints;
• cache filtered requests that require a dynamic query-string result through the early static path;
• create archive JSON before a real request needs it;
• cache a response that POM Theme marks as non-cacheable;
• accept malformed paths, invalid JSON, empty files, or files above the configured limit;
• replace a CDN, database cache, or general-purpose object cache;
• remove stored files merely because they are old.

This scope lets POM Cache reuse public, deterministic archive batches without pretending every JSON response is safe to share.

The first visitor still matters

The cache is generated on demand:

first eligible request
→ dynamic archive render
→ valid JSON response
→ file written

later matching request
→ stored JSON reused

After a purge, the first visitor to each required batch pays the dynamic generation cost again. There is no built-in JSON preloader. That is why a very broad invalidation can briefly increase origin work on a high-traffic site.

Freshness is an editorial decision

Files do not have an on-disk time-to-live. They remain until an invalidation or manual deletion removes them. You should therefore choose which content events clear JSON:

• post changes for archives whose cards depend on posts or assigned terms;
• term changes for archives whose grouping, labels, or ordering depend on taxonomies;
• translation changes when localized output is stored;
• manual clearing after global display changes not covered by an enabled integration.

This explicit model avoids periodic deletion of perfectly reusable responses. It also makes the site owner responsible for enabling the invalidation paths that match the site's editing workflow.

Practical decision

Enable progressive JSON caching when all of the following are true:

• POM Theme is producing progressive archive URLs;
• the response is public and reusable;
• the cache directory is writable;
• you have a clear invalidation plan;
• you can verify the second request at the origin;
• your CDN policy, if any, is compatible with the JSON Cache-Control policy.

If the site does not use progressive archives, enabling this subsystem provides no benefit. The static HTML cache can continue to operate independently.

Next, follow Enable the progressive JSON cache and then Measure the benefit of JSON caching with a representative archive.