Interesting. You have this as one of your points: "- https2 server push is anti-pattern. Doesn’t consult browser cache." This is an odd claim, as server push

Interesting. You have this as one of your points: "- https2 server push is anti-pattern. Doesn’t consult browser cache." This is an odd claim, as server push is built to respect the browser cache and can even be used to populate it. In usual cases the server can know whether to push the dependencies of a requested resource based on the ETag header, working under the true-enough assumption that if a resource is in cache, its dependencies are also likely to be. I can think of a thornier case where two resources have a shared dependency, and the server pro-actively pushes the shared dependency in response to a request for the second resource, oblivious to the fact that it's already in cache from a request for the first resource. I don't believe this case is enough to call server push an anti-pattern, though: the browser can cancel the push midstream if it already has it in cache. Although the server probably has already sent all of the dependency at that point. Used appropriately, server push interacts nicely with caching and can even improve cacheability: I think servers can push 304 responses, for instance.