A 304 response is a validation result. Judge freshness by the reused representation and its validator, not by the absence of a response body.
Capture the first complete response
Load a public test document and record its content marker, ETag or Last-Modified header, and status. Then reload normally with the Network panel open. A conditional request may ask whether the stored representation still matches. Note the request headers beside the response. The first load and subsequent validation answer different questions and should not be merged into one measurement.
Check the validator after a controlled edit
Change the marker on staging and request the page through the same delivery path. Compare a normal reload with a fresh browser session. If the new session receives new HTML but the older session keeps the previous marker after validation, capture the exact validator pair. Do not conclude that every 304 is broken: the representation may genuinely be unchanged.
Avoid mixing requests with different variants
Keep locale, authentication, query parameters and content encoding consistent during comparison. Record the final URL after redirects. A validator belongs to a particular representation; comparing unrelated variants can produce misleading results. Also identify whether the CDN or origin supplied the response. A stored edge representation and a browser’s stored copy can have different ages.
Separate transfer savings from application correctness
A successful validation can save transferring a full body while still involving a network round trip. It does not establish that an HTML page was served directly from an edge cache or that WordPress avoided execution. Use the layer-specific status indicators for those questions. Conversely, a full 200 response can be perfectly fresh without a conditional exchange.
Prepare useful evidence for the owner
Send the host or component maintainer the test URL, old and new markers, edit time, conditional request headers and response headers. Strip account cookies before sharing. Include the fresh-session comparison and the result of a targeted purge. Restore the test content once recorded. A reproducible mismatch is more useful than a general report that reloads sometimes look old.
Symptom-to-cause worksheet
| What you observe | What to investigate | Next check |
|---|---|---|
| 304 and content unchanged | Normal conditional reuse | Compare against the expected representation |
| Fresh session updates but old session does not | Validator or intermediary mismatch | Capture request and response validator values |
| Every reload transfers a full body | No validator or non-reusable policy | Inspect policy before adding caching |
Worked investigation scenario
This is an illustrative case, not a measured Velonic result. Imagine an existing browser continues showing a previous excerpt while a clean profile sees the corrected excerpt. Preserve the older request’s conditional headers and compare its validator with a full new response. If the stored marker is outdated despite successful validation, provide that exact pair to the delivery owner. Do not disable all conditional requests as the first remedy. A correct fix makes the earlier session update while retaining valid reuse for unchanged content.
Put it into practice
- Record a first 200 response before testing reloads.
- Keep session and representation conditions consistent.
- Use a visible staging marker to verify freshness.
AI-assisted educational content prepared for the Velonic resource library. How these guides are prepared.