10 comments

[ 2.6 ms ] story [ 45.3 ms ] thread
The significant (and only) feature addition being HTTP/2 server push support:

> Feature: HTTP/2 server push support; the "http2_push" and "http2_push_preload" directives.

What about caching? If the assets I want to push to browser are already cached in the browser would Nginx be smart enough to not to push?
In their intro to push they say to not push objects that are already cached so I'd wager no
I'm not sure if I never understood this right, but it seemed server push was not an ideal overall solution. It seemed it was targeted to push needed css/js/image in the stream of the page result. But most assets that one would want loaded are coming via an external CDN so doing a push of that does not make sense. Yeah, I guess if you are proxying your whole site via the CDN. Am I missing something here?
My view on this is that it doesn't just work for "http page preloads assets to get", and more like "http request preloads other http requests" ... the difference is, in the case of a CDN, they could basically download a JS file for, say, a JS framework, but also send you jQuery, etc because they know it's dependent.

All this is to get away from a lot of our current hacky workflows (like file concatenation).

I saw a talk on this from someone at Fastly where they talked about protocol changes that would allow CDNs like theirs to do push from the edge
I don't see a lot of external CDN script (like cdnjs) use in the real-world anymore. That's sort of dated compared to bundling and using something like S3. Ideally, these days you'd still minify, but your *.html files could plainly include scripts, and the server would read the resources to be sent, and send them all over the same stream, rather than forcing a client to open multiple connections.