It looks like the unzipped index files (module-search-index.js, package-search-index.js, type-search-index.js, member-search-index.js and tag-search-index.js) are loaded by the browser along with their zipped versions. If this is true, then it is a double whammy and defeats the purpose of the mechanism. This should be investigated (my suspicion is that there's a race).

The proposal is as follows. We should first try to load the zipped versions. If this fails, fall back to the unzipped versions. Ideally, the zipped version should be loaded without using HTTP compression (read "Accept-Encoding: gzip, deflate"), while the unzipped version should be *attempted* (an HTTP server is not obliged to use any compression) to load using HTTP compression.

This way, neither the server nor the client would experience any unnecessary strain in the best case scenario and the transfer size will be optimal. However, the client will have to unzip the stream in any case.