Progressive JSON cache

POM Cache has a dedicated cache for the JSON batches used by POM Theme progressive archives. It is independent of the static HTML cache: you can enable, inspect, or clear either store without doing the same to the other.

This chapter is for site owners who use progressive archive loading and for technical teams responsible for the origin server. It explains the complete path from the first dynamic response to later static delivery.

What the JSON cache accelerates

A progressive archive initially renders a page shell and then requests additional items as the visitor scrolls or selects Load more. POM Theme exposes those batches as public JSON URLs, normally below:

/pom-json/archive/...

The response contains the rendered archive items and the information the browser needs to request the next batch. Without a cached file, WordPress must resolve the archive context, query its posts, render the item templates, and encode the response for every request. POM Cache can save an eligible response once and reuse it.

This subsystem does not turn every WordPress REST response into a static file. It only participates in the compatible progressive-archive flow.

The four runtime controls

Open Settings → POM Cache → General, then find Progressive JSON runtime. On multisite, use Network Admin → Settings → POM Cache → General.

The four switches have deliberately separate jobs:

The child switches do nothing while Progressive JSON cache is disabled. After enabling the master switch, keeping all three child controls enabled gives the normal layered behavior: write on the first eligible request, serve early when possible, and retain a WordPress fallback.

The JSON master switch is not tied to Caching, the static HTML master switch. This is useful when progressive JSON is beneficial even though HTML is cached elsewhere.

Choose the delivery layer

POM Cache can use three progressively later delivery paths:

1. Apache direct delivery can return the file before PHP starts, when you have installed the optional generated rules.
2. PHP early static serving can return the file from the cache drop-in before the normal WordPress request completes.
3. WordPress read fallback lets the compatible theme router read the same file when neither earlier path served it.

The first available valid hit wins. A miss continues to the next layer and eventually reaches dynamic generation. Read How a JSON cache request is served before deciding which layers your hosting environment should use.

Configure freshness separately

The runtime section also contains three opt-in invalidation switches:

• Purge JSON on post changes
• Purge JSON on term changes
• Purge JSON on translation changes

All three default to Disabled. When enabled, each relevant event removes the current site's complete progressive JSON tree. This broad invalidation favors correctness because one post, term, or translation can appear in many archive contexts.

The HTTP JSON Cache-Control header is a different kind of freshness control. It tells browsers and shared caches how to reuse a response; it does not expire the file on disk. POM Cache has no age-based JSON garbage collector.

Recommended reading path

Start with these guides in order:

1. Why cache progressive archive JSON
2. Enable the progressive JSON cache
3. How JSON cache entries are generated
4. How a JSON cache request is served
5. Understand JSON cache response headers
6. Clear the JSON cache manually

Then use the delivery guide for your stack:

• Serve JSON cache files directly with Apache
• Serve JSON cache files early from PHP
• Use the WordPress JSON fallback

For ongoing operation:

• learn where progressive JSON files are stored;
• measure their size and control growth;
• evaluate the performance benefits with representative requests;
• configure post, term, and translation invalidation;
• use Troubleshoot progressive JSON caching when generation, reuse, or freshness does not behave as expected.

Safe production baseline

For a conventional Apache or PHP deployment, a cautious first rollout is:

1. Keep the optional Apache rules out of the first test;
2. Enable the master switch, PHP early serving, WordPress fallback, and writes;
3. Leave the maximum size at 1048576 bytes unless a real response is larger;
4. Keep the default short Cache-Control policy;
5. Enable the invalidation switches that match the content you edit;
6. Request one progressive batch twice and verify generation followed by a hit;
7. Add direct Apache delivery only after the PHP path works;
8. Coordinate origin clearing with any CDN that caches the JSON URLs.

This sequence provides an observable fallback while you validate the cache. It also keeps HTML and JSON decisions independent.

What success looks like

A healthy JSON cache has these characteristics:

• an eligible first request is generated dynamically and creates one valid .json file;
• a repeated clean request reuses that file;
• authenticated or commerce-session requests are not served by the early static paths;
• edits clear the current site's JSON when the matching purge switch is enabled;
• Progressive JSON Cache Contents reports a plausible file count and size;
• a manual JSON clear leaves the static HTML count unchanged;
• visitors receive current content from both the origin and any CDN.

If a repeated request remains dynamic, work through the troubleshooting guide rather than increasing cache lifetimes or adding broad server rules.