In https://codereview.chromium.org/218363002 we changed the docserver to require clients to always do an http round-trip to revalidate that their cached copy of extension docs content hasn't changed. This isn't that great a strategy - it does possibly save a little bandwidth, but because the ETag is computed based on the content the server would have output, the server needs to do all the normal work to create a response before being able to tell the client that nothing has changed. 

A much more effective strategy would be to do the following:

-Let the client cache everything for some reasonable length of time (1-2 hours perhaps?) without needing to do a network round-trip to revalidate. The docs don't change all that often, and when they do being a little out-of-date isn't the end of the world. This would mean serving header like:

Cache-Control: public, max-age=3600

instead of

Cache-Control: public, max-age=0, no-cache

-Keep some sort of "version number" server-side in a fast-to-read place  (memcache?), and use that to generate the Etag (possibly hash it with the path?). When we find out something has actually changed as we are processing incoming changes from git, we increment the version number.