Benchmark POM Cache responsibly
A useful cache benchmark compares the same public request before and after reuse. It does not compare unrelated pages, an administration screen with a public page, or one lucky response with one unusually slow response.
Define the question
Decide which layer you want to measure:
- HTML generation versus a POM Cache HTML hit;
- dynamic progressive JSON versus a JSON hit;
- PHP cache delivery versus direct Apache delivery;
- origin performance versus CDN edge delivery.
Measure one transition at a time. If the CDN, browser cache, and origin change simultaneously, the result cannot identify which component produced the improvement.
Build a representative route set
Include a small set of routes that reflects real use:
- the home page;
- a normal singular page or post;
- an archive;
- a progressive archive JSON request, when used;
- a deliberately dynamic or personalized route as a safety control.
Do not include WordPress administration requests in a public page-cache comparison.
Record the test conditions
For every run, note:
- environment, date, URL, and route type;
- anonymous or authenticated state;
- HTTP method and query string;
- origin or CDN hostname;
- whether Apache direct delivery is active;
- response status, content type, and size;
- compression reported on the wire;
- the header or server evidence that identifies the delivery path.
Keep network location and client tooling consistent.
Measure cold and warm behavior
- Clear only the store being tested.
- Request the route once. Treat this as the cold generation request.
- Confirm that the expected file was created.
- Request the identical route several times.
- Verify the hit path rather than assuming that later requests are cached.
- Report the median warm result and a slower-tail value, not just the fastest sample.
- Repeat the complete sequence enough times to reduce noise.
Time to first byte is useful for server work, while total time also includes transfer. Report both when payload sizes vary. POM Cache may add generation comments to stored HTML, but those comments are not a replacement for an external timing measurement.
Test origin and edge separately
Benchmark the origin first. Once its content and invalidation are correct, test the CDN using the same path and document the edge hit evidence. A warm CDN response can hide an origin regression; an edge miss can hide a healthy POM Cache hit.
Compression also belongs to the delivery layer. POM Cache stores reusable content but does not need to create precompressed Brotli files when CloudFront or another CDN negotiates and compresses the response.
Include correctness gates
Reject a performance result if any of these checks fails:
- the warm response differs unexpectedly from the cold public response;
- a logged-in or personalized request receives shared content;
- an edit remains stale after its documented invalidation;
- a redirect, error, REST response, or meaningful query is cached incorrectly;
- the test compares different URLs or payloads.
The goal is the fastest response that preserves public correctness. A larger percentage improvement is not valuable if the benchmark bypasses the site's real safety conditions.