http2-push-manifest

In 2016, the Chromium team at Google produced a document [1] that examines usecases for HTTP/2 Push, talks about deployment models, and analyzes whether it's worth it. In this particular case, you'd push static content because you know it will be needed later, and this way the information arrives in the HTTP header instead of in the payload's content body, so by the time 'main.css' is needed, the UA's HTTP cache may already be populated with the file. That being said, I fail to see how in the general case, setting static headers in the server software's config for Push is useful [2][3], and wish that more implementations converged on a common way of describing what to push [4], so that tools could be built around discovering dependencies, and around interpreting that manifest to execute push. [1] https://docs.google.com/document/d/1K0NykT

As more software is adding support for HTTP/2 server push, I hope they'll start supporting a higher-level, implementation-agnostic, declarative way of specifying resources to push, which operates at a layer higher than server config directives. Google has a dead-simple JSON format [1] for this from 2015. [1] https://github.com/GoogleChromeLabs/http2-push-manifest

For those interested in HTTP/2 Push, check out Eric Bidelman's Push Manifest format[1], which is a JSON format describing the dependencies to push for any request URL. You can generate the manifest by hand or with tools, and then there are servers that can read the manifest and push the right resources.[2] In Polymer we're most of the way done with support for automatically generating push manifests from a dependency analysis of your project[3] and have push manifest support in our dev server and soon a small production server, so you can `polymer deploy` and get a push-enabled site. [1]: https://github.com/GoogleChrome/http2-push-manifest [2]: https://github.com/GoogleChrome/http2push-gae [3]: https://github.com/Polymer/polymer-build/pull/172

It's true that the mechanics of triggering HTTP/2 Push are done with the Link rel=preload directive (defined by the W3C [1]), the advice to hardcode HTTP headers on outgoing responses that point to file references is simplistic at best -- which shows that this whole thing (still) isn't yet thought out too well. Most of the content of my earlier post on this topic [2] still stands; since then, Caddy has implemented rule-based ways of specifying what to push [3][4] (although not via Google's push manifest [5], despite being asked to). It'd be far more productive if the community coalesced around one clear declarative way of specifying what to push -- Google's push manifest does this well enough -- which could be ingested by server software and applied as needed. If this were done, the problem space is moved to somehow generating that manife

They usually don't, because server push is a micro-optimization, proper use of which requires a lot of effort from the server (and perhaps the client), as evident from Google's research on the matter [1]. Google has coded their App Engine to read a 'push manifest' generated by a tool they publish [2]. Akamai gives you a GUI [3]. Cloudflare wants you to manually set headers [4] defined by the brand-new W3C draft 'preload' [5]. Last year, the Caddy devs blogged that HTTP/2 Push is essentially a big exercise for the reader/implementer [6]. I'm currently unaware of any web application framework which exposes idiomatic hooks to use HTTP/2 to push additional resources to the server. There are some generic server push addons or plugins that use older techniques from the websocket or pre-websocket days. [1] https://news.ycombinator.com/item?id=12