HTTP/2 server push enables pushing assets to clients which you anticipate they'll need in order to render the page. For example, you can push your CSS/JS/images to the client at the same time as you respond to a request for an HTML page, so they receive those assets sooner.

But how do you avoid wasting bandwidth on clients that already have the assets cached?

Does the server push mechanism handle this situation automatically, and how? Or does my serverside app need to somehow track clients that have already been served a response previously, and avoid server-pushing extra assets to those clients?


Read the spec http://http2.github.io/http2-spec/#PushResources, it notes that cacheable responses will be cached, non-cacheable responses must not be cached.

If something is already in the cache, the client will be able to refuse the duplicate asset by sending a RST_STREAM frame: http://http2.github.io/http2-spec/#RST_STREAM.

See mark Nottingham's blog for more details:


He also indicates that server push will allow the server to proactively invalidate the client's cache, i.e. push a new asset when the server asset has changed, which is a very useful feature.

  • That's interesting. So if the client 'refuses' it, does the server just stop mid-transfer? And doesn't this still waste a lot of bandwidth (depending on how quickly the server receives the refusal frame)? Compared to what we have now (where assets are only transferred the first time a new client visits your site, albeit with a round trip penalty), it sounds like server-pushing assets would be very bandwidth intensive. – callum Apr 9 '15 at 12:50
  • My assumption is that the client will refuse the transfer as soon as it sees the header information with the name/size of the asset. I don't know if how that works in practice is up to the individual client, but I have faith in the ability of the people writing the spec and the client/server software to implement it in a more efficient manner than HTTP/1 with round-trip penalties. – Robert Munn Apr 9 '15 at 22:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.