Due to complexity, missing features, and browser bugs, I don't think I'd recommend HTTP/2-push to anyone unless they'd exhausted all other optimisations (including link[rel=preload]), and have a large expert team to deal with the fallout.https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/ …
-
Show this thread
-
Replying to @jaffathecake
This sort of thing, to make it in general use, needs to be workable by one person/role. Not to require hardcore backend people and deep knowledge front end people working together.
1 reply 0 retweets 0 likes -
Replying to @MattWilcox
This is why I like link[rel=preload]. Easier to set up, easier to debug, and fails in a more predictable way.
1 reply 0 retweets 7 likes -
Replying to @jaffathecake @MattWilcox
I wish all browsers supported it for fetch.
1 reply 0 retweets 2 likes -
Replying to @wycats @MattWilcox
Yeah, I want to get a feel for "best use of H2 push" vs "best use of preload".
1 reply 0 retweets 0 likes -
Replying to @jaffathecake @MattWilcox
I currently think of H2 push as being ~appcache. It has all these interactions with the rest of the spec that you can completely avoid by doing something like SW + WebSockets. It just feels like a pretty big thing when we have really good primitives now.
2 replies 0 retweets 2 likes -
Replying to @wycats @MattWilcox
Hmm, I think of H2 push as being really low level. Eg you have to understand when the browser will use multiple connections to the same origin etc etc.
1 reply 0 retweets 0 likes
But it also interoperates with a whole bunch of nonobvious spec things (leading to questions like multi-conn that you wouldn't predict). On the web, I think it's not obvious that there are major wins from shimming the spec's normal HTTP this way.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.