Does inlining Critical CSS worth?

Question

Google Pagespeed complains when you have blocking CSS in an external file. In HTTP/1 this probably makes sense, but what about now with HTTP/2 ?

If you inline critical CSS (above the fold), that bytes still need to download, parse and everything else, all before the document renders.

With HTTP/2, there is no need to make another connection since the same can be reused, so that is not an overhead. Plus, with server push you can even push the CSS file before it's being requested.

So... is inlining critical CSS still a recommended thing?

---

I agree that in heavy sites, you probably don't want to download all CSS. For example if you are visiting the gallery, you would only need gallery.css, not profile.css, not forum.css, etc. But that is manageable with chunks and other techniques (and still using external css files, no need to inline them)

Inlining also makes CSS not cacheable.

I am missing something?

---

This has nothing to do with the possible duplicate question. Whoever marked this as duplicated has no idea about what critical CSS is or probably didn't even have read this question.

Shannon

This question is either too broad, opinion based or requires discussion and so is off-topic for Stack Overflow. If you have a specific, answerable, programming issue, please provide full details. – Mystify

Its not really about to download all files, its about how long it takes to download this files. – Terresaterrestrial

I'm asking if inlining critical CSS is still worth it when using HTTP2. That question doesn't require discussion at all, someone could answer it without being opinion-based. – Beetle

Yes inlining still makes sense. The CSS file can only start to download after the at least the head is downloaded and parsed. – Champion

Possible duplicate of What's so bad about in-line CSS? – Taught

@Taught this is about critical-path, not about why inline css is bad. – Beetle

What about generating the critical css with a tool like sitelocity.com and inline it into the head tag ? The generated code is usually only a few kb so there won't be any overhead. – Opec

Answer 1

Yes it can still help. A lot.

When you download the HTML you still need to wait for that to download, then process it, and then make another request for the CSS file(s) and wait for those to download.

While downloading additional resources is quicker under HTTP/2, and there is not as much of a bottleneck when you have a lot of additional resources to download when using it, the CSS file still can't be requested until the HTML file has downloaded and been processed. Additionally the CSS file is usually prioritised by the browser, since it's render blocking, so usually will be one of the first resources requested meaning the avoidance of head of line blocking for HTTP/2 is not as beneficial for CSS resources.

When HTTP/2 Push becomes more common place it may not have as much impact as requests for the HTML page can also push the CSS file needed for that, but that's added complexity and there's still some questions as to how that will work (e.g. if the browser already has the CSS file then server should somehow know not to push it).

I wrote a blog post on this topic if you want more detail on this (and this is on a HTTP/2 site): https://www.tunetheweb.com/blog/inlining-css-is-not-for-me/ . I'm still not a big fan of this process as I explain in that post...

Nephelinite

Answer 2

Don't inline it if it doesn't make sense. I guess inlining ten lines of css won't kill you, but inlining the equivalent of 18 kb of gzip-compressed CSS is just madness.

Just use HTTP/2 Push to be sure the browser gets the CSS as early as possible.

Worst case HTTP/2 Push will push the resource multiple times, but browsers reset pushed streams which they consider are fresh in cache (use etags). So worst case HTTP/2 Push is still slightly better than inlining.

The cache issue with HTTP/2 Push is largely attenuated using a cache digests polyfill (until the real thing be available in browsers):

• https://www.shimmercat.com/en/blog/articles/cache-digests/
• For a quick video introduction to cache digests: https://www.youtube.com/watch?v=Zq1YF3ri98k

We use it in production and we are very satisfied.

As a general note, take automatic optimization recommendations with a grain of salt until they complete their transitions to HTTP/2.

Conspicuous

Answer 3

I am missing something?

You're right in general, for the modern browsers and http 2. For the mobile and old browsers, for gprs or other slow high latency connections - not exactly. In some cases, you can get an advantage of fewer documents downloaded and improving browser parsing speed by inlining .css. Additionally, if you're dynamically adding the .css and something goes wrong, the inlined .css still works, the same is right for any resources could be inlined in html.

Wendalyn

Answer 4

Its not really about to download all files, its about how long it takes to download this files.

If you are using critical CSS the CSS(Design) is directly shown, so its really faster then first downloading the CSS Files because the CSS is directly in the <head> of your Page so the Page is shown directly without blocking Resources ( e.g download the big CSS File ).

If you have the CSS File which is for Example 5MB big, the Browser first has to download this file until the Design is shown.

Terresaterrestrial

The same bytes needs to be downloaded with either method. With normal method (not inlining critical path), you can still have critical.css and main.css. And you can block while loading critical.css inside <head> (same bytes have to download against the inlining method) and defer main.css to load async using js. So inlining is not offering any benefit. Same bytes to download. Inline = no cache. No inline with http2 = no new connections anyway + server push – Beetle

As i said its not about the Download its about how the rendering is blocked by downloading the CSS with its extra Request. If i have inline CSS with for example with 100 bytes for the necessary CSS properties to show the view, this does not block the Browser Rendering. Therefore the view is shown faster. The CSS has to be downloaded extra of course, but in these times the site is already shown because the inline CSS and the Browser not have to wait until the extra CSS File is downloaded. – Terresaterrestrial