Measure the benefit of JSON caching

Measure progressive JSON caching with the same public URL under controlled cold and warm conditions. A general page-speed score cannot isolate the database, rendering, and bootstrap work saved by this subsystem.

Define the question

Useful questions include:

• How much faster is the second origin request than the first?
• How much server processing does PHP early delivery avoid compared with the WordPress fallback?
• Does direct Apache delivery provide a meaningful additional gain?
• How often do visitors request batches that have already been generated?
• Does an automatic full-site purge create an unacceptable temporary burst?

Choose one question per test. Otherwise CDN hits, browser reuse, and origin behavior can be confused.

Select representative routes

Test more than the smallest archive. Include:

• a common standard archive batch;
• a deeper batch with rich item templates;
• a split-by-term batch, if used;
• one translated route;
• a route close to the largest normal JSON response;
• a high-traffic route that matters operationally.

Always preserve the exact URL between cold and warm requests. Changing the context hash, locale prefix, page number, or items-per-page creates a different cache entry.

Establish the cold baseline

1. Open POM Cache → General → Progressive JSON tools.
2. Select Delete Progressive JSON Cache.
3. Ensure the CDN is bypassed through an approved origin-testing method;
4. Use a logged-out session with no cart or password cookie;
5. Request the chosen clean .json URL once;
6. Record status, response size, server timing, and total response time;
7. Confirm X-POM-Progressive-Archive-Cache: generated-cacheable;
8. Confirm the JSON file count increases.

This is the on-demand generation cost. If the response reports generated-dynamic, it is not a valid candidate for this comparison.

Measure a PHP early hit

Keep:

• Progressive JSON cache enabled;
• PHP early static serving enabled;
• the optional Apache JSON rule disabled for this phase.

Request the identical URL several times and confirm:

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

Record median and slower-tail timings rather than choosing only the fastest request. The difference from the cold request represents saved WordPress, query, template, and encoding work plus any change in filesystem cost.

Measure the WordPress fallback

For a controlled comparison:

1. Disable PHP early static serving;

2. Keep WordPress read fallback enabled;

3. Request the same stored file;

4. Confirm:

   X-POM-Progressive-Archive-Cache: hit

5. Record timings;

6. Re-enable PHP early serving after the test.

The fallback should save archive generation but still pay for the WordPress request. It is normal for it to be slower than an early PHP hit.

Measure Apache separately

After the PHP baseline is stable, install the reviewed Apache JSON block and repeat the origin test. Confirm Apache actually served the file; the missing PHP header alone is insufficient evidence.

Compare:

This comparison reveals whether the extra operational complexity of a server rule is justified on your origin.

Keep CDN results separate

A CDN hit measures the edge, not POM Cache. Run it as a second experiment:

1. Verify the current origin response first;
2. Request the public viewer URL;
3. Record the CDN cache-status and age headers;
4. Repeat after the configured s-maxage;
5. Clear origin JSON and observe whether the edge still has an older copy;
6. Test the documented CDN invalidation procedure.

Do not infer origin freshness from a fast edge hit.

Watch regeneration after a purge

For a high-traffic archive, measure the short period after clearing:

• how many distinct JSON paths regenerate;
• how long the working set takes to warm naturally;
• whether concurrent first requests increase PHP or database load;
• whether full-site automatic invalidation fires more frequently than the content workflow needs.

POM Cache has no built-in preloader. The first request to each path after a clear is dynamic.

Report the result honestly

Document:

• date and environment;
• route and archive mode;
• response byte size;
• active runtime switches;
• whether Apache or CDN was bypassed;
• cookie and authentication state;
• cold and warm sample counts;
• median and tail latency;
• database or PHP observations available from your approved monitoring;
• the invalidation frequency expected in production.

Avoid a universal claim such as “JSON caching makes every archive 90% faster.” A defensible result is tied to the tested route and delivery layer.

If the warm request does not reach the intended layer, resolve that with How a JSON cache request is served before using the numbers.