Obsolete with HTTP/2?

[malchata]

I guess this is more of a question than an issue, but I'm curious to know what the viability of this is in an HTTP/2 world with server push? Has there been any research done that anyone can point to? I'd be particularly interested to see what @scottjehl thinks.

[scottjehl]

In our testing so far, yes, the inlining of critical css is no longer a good pattern when server push is in play. But you still would gain from server-pushing the critical css that this tool extracts, and linking to it externally from head, rather than inlining it. (And loading the rest of the css in another non-blocking request)

Also, the current http1 workflow would still be useful for any client that doesn't have http2 support (like IE10). We're currently testing a server proxy that lets us branch logic based on the protocol in play, and the main difference is whether we inline the css in the html, or link to it and set link preload headers to cause the server to push it instead.

[malchata]

Awesome. I wrote a chapter on critical CSS for an upcoming book, but realized too late that HTTP/2 may already solve the problem. If you have time, I might want to pick your brain on how I should approach this "problem."

[strarsis]

Though this only really ceases as optimization practice when Google PageSpeed Insights removes it from their todo list.

[Stefany93]

So we don't have to write Critical CSS anymore, correct? That makes me so happy!

[Stefany93]

@strarsis Google is not the boss of the internet.

[scottjehl]

@Stefany93 h2 or not, we find it's often noticeably/measurably faster to load only the critical portion of the CSS in parallel with the HTML (either using h2 server push or just inlining the styles in the HTML). And then loading the rest of the CSS in another non-blocking request. In other words, h2 doesn't change or improve the way a browser will wait for link-referenced CSS to load before rendering the page. But it does give us a more cache-friendly alternative to inlining css.

[strarsis]

The pagespeed extensions can do this in most cases automatically, I find this approach much better, new optimizations can be easily enabled or disabled and they are transparent.

[strarsis]

@Stefany93: The reason why I try to fulfill all points on pagespeed checklist are Google ranking improvements.

[scottjehl]

@Stefany93 okay! 👍

[Stefany93]

@scottjehl So do you still recommend we use inline CSS? What happens when the inline CSS is loaded and then the server pushes the style-sheet file? I.e. does that mean we don't have to "extract" inline css from the stylesheet since the browser will know it is already included (sorry I don't think I am expressing myself clearly)

[Stefany93]

@strarsis I didn't know you get Google ranking bump from fulfilling their PageSpeed checklist. Although people are saying now Lighthouse is the "new" PageSpeed - so I am really confused.