See the entire conversation

The more I dig into HTTP/2 push, the more troublesome I find it. Lots of gotchas and race conditions across browsers 😕
48 replies and sub-replies as of May 30 2017

The law of inverse effort-to-views dictates that no one is going to read this blog post.
what blog post?
Not quite done yet. It's on HTTP/2 push.
One of the modern Web topics I'm most interested in, so I'm there.
Those of us that do appreciate it all the more to compensate!!
I'd most definitely will
so it's not just me who gets hit with this then! I have to stop myself getting really frustrated :P
*follows thread to read blog post*
I look forward to reading that post! 🙂
Wish i could sign up for notifications once specific blog posts etc. like this one are published. "Notify me when this happens"-button
Yes, especially if you throw CriticalCSS (with a cookie) and Service Worker caching into the mix. ;)
I tried it with a small payload <16kb for HTML + CSS + JS. It would send files twice. 😬
Yes. Especially when I use <link rel="import" href="some-web-component.html" defer (or async)> it messes up the load order
Do I smell a blog post in the works?
the stench of blogging is palpable
IIRC, it doesn't even improve on first render compared to critical inline <style>, right? Only so much TCP at once
The ideal would be having the benefits of inline, but without sending it if it's already cached. But that's not the case yet.
Can be achieved today, but not trivial and benefits vary. Cache Digests would make it easier and more accurate.
I don't think any browser aborts the stream if it's already cached.
True, but even if they did, it's often to late. Need to use alternative mechanisms
I've always worried about the browser evicting cached CSS before its cookie expires
Just today @patrickhamann gave a nice talk about it. I guess the best we can do so far is push the critical CSS, but Link:preload the rest
Agreed. I get depressed every time I tinker with it.
😬 That's not good. Is it a problem with the spec? Or just early days and browsers haven't worked out the bugs yet?
A little of both. I'm going to write up my thoughts.
Agreed. On the spec side, Cache Digests can't come soon enough for my money.
Sounds like great quiz content!
We've had such a hard time making it a reality on Polymer. We're considering a big test framework for digging into these issues
+1 — There are quite a few tripping points. I'm not sure I'd recommend using without a SW too.
*adds you to blog post proof read list*
, I'd love to get on that proofread list, too. My outlook based on our Polymer work is a bit brighter than @justinfagnani 's...
You'd already been volunteered by @mattsmcnulty 😀
Only time I've seen it be a net-win is if you have slow server response time for the HTML and you can push the content you'd normally inline
Soooo much risk for duplicate requests with mismatched content types, crossorigin, etc though.
That's my conclusion too. Once bugs are ironed out & support is increased, link rel=preload is far easier to understand & less risky.
If we had full control over when pushes happened in regard to the parent stream… that might be interesting.
Technically you do..if you implement it in the server, not with something off the shelf though. Could do lots of cool things in H2 on server
Feels a lot like Itanium VLIW vs x64 CISC though where the added flexibility at compile time loses to simple and usually faster by default
Exactly. Need a nice & easy way to say "Don't bother sending any <body> until the CSS is pushed".
Need better H2 support on frontend servers. And in node for that matter.
I always imagined Webpack would eventually morph into a manifest generator for h2 push rather than a bundler
Is this something that will improve with 103 Early Hints (expect the wait)? And are there specific server solutions in the making?
I wasn't aware of this. Interesting!
there's an ongoing discussion about this, and will be a topic at @http_workshop.
I think one of the big problems is that you don't know the state of the UA's cache when you set up your push