Performance
ETag
ETag is a fingerprint the server attaches to a response so the browser can ask later whether the file changed. If it did not, the server answers 304 with no body.
How it is measured
The browser sends the stored value back in `If-None-Match`. A match returns a 304 and a few hundred bytes of headers. A mismatch returns 200 and the full file. Check both in the Network panel.
A strong ETag means byte-identical. A weak one, prefixed with `W/`, means equivalent content. Some servers derive ETags from inode and modification time, which can differ across machines behind a load balancer.
Worked example
A marketing site serves a 148 KB `main.css` with an ETag and no max-age. Each repeat visit sends a conditional request that costs 52 ms for a 304 on desktop and 340 ms on a slow phone. The body is saved, but the round trip is not.
Two origin servers behind a load balancer generate different ETags for the same file. Visitors get a full 200 half the time, and the 304 rate is 49 percent instead of 98.
How it differs
An ETag validates a stored copy. Cache-Control decides whether the browser needs to ask at all. HTTP 304 is the response that says it is still valid. ETag saves bytes but not the round trip, while a long max-age saves both.
Common errors
Relying on ETag alone for static assets and paying a round trip every time. Using server-specific ETags behind a load balancer. Sending both a strong and weak variant inconsistently. Disabling compression and then breaking weak ETag matching. Expecting an ETag to expire a file earlier.
In practice
Use fingerprinted filenames with a long max-age for assets, and keep ETags for HTML and API responses where revalidation makes sense. If you run multiple origins, make the ETag content-based so they agree.