How to use this ETag strategy guide
Enter the request count, body size, 304 response size and the share that ends unchanged, and the transfer saved by conditional requests appears. Pick an ETag value and type, and the flow from the 200 response through If-None-Match to the 304 is shown ready to paste.
How the numbers are derived
Transfer is the 304 count times the 304 size plus the remaining count times the body size. The flow and the strong versus weak comparison rules follow the HTTP conditional request standard (RFC 9110), checked October 2026. A 304 size has no authoritative default because header sets differ, so you enter it.
Limits and cautions
Only body bytes are counted; TLS and TCP overhead is out of scope. No hit rate is predicted, and the share you enter is used as given. Assembling directives such as max-age belongs to the Cache-Control generator.
Frequently asked questions
Last-Modified has one-second resolution, so two changes within the same second go unnoticed. An ETag built from the content is more precise, and both can be sent together.
When the bytes differ but the content is considered the same, such as a change of encoding. Note that a weak ETag cannot be used for Range requests.
No. The round trip still happens and only the body is dropped. To remove the request itself, give the response a freshness lifetime with max-age.