It's mostly a trade-off of what's more important to you: round-trip or bytes. The client might have a cached-copy, but it must (in most cases) revalidate it by

It's mostly a trade-off of what's more important to you: round-trip or bytes. The client might have a cached-copy, but it must (in most cases) revalidate it by requesting with cache-headers and getting back that empty 304 response. The round-trip cost depends of the actual scenarios, but the fact is that some resources, like css in <head> will block rendering. So you might have some better results by speculatively pushing the critical rendering path. You can also speculatively push 304 responses btw, which would have the same effect in your described scenario minus the round trip. How you figure out if the client has fresh cached resources, that's still an unsolved problem. You can program it yourself in some servers. H2O server has its own mechanism for that. There's also an RFC for Cache Digest Assets frame that might extend HTTP2: https://tools.ietf.org/html/draft-ietf-httpbis-cache-digest-00 https://tools.ietf.org/html/draft-ietf-httpbis-cache-digest-...