11 ms·

Critical CSS? Not So Fast

96 points by karimmaassen 4y ago

chucky123 4y ago
Agree with the author. The gazillion marketing scripts in your webpage is the main performance bottleneck, rather than your css link tag.
- youngtaff 4y ago
  That’s not quite what the author says… He says if you’ve got other blocking scripts / stylesheets in the head then there’s no point using critical CSS
eyelidlessness 4y ago
In my experience “critical styles” are necessary to load fonts efficiently if you load any, and it’s beneficial to load a few color styles at the same time. Other than that it’s better to load them as separate resources.
- laundermaf 4y ago
  I’m not sure you know exactly what “critical CSS” refers to because it’s unrelated to font loading and “color styles.” It has to do with inlining the CSS required for content “above the fold” while loading the rest asynchronously.
  - youngtaff 4y ago
    Not necessarily just for content above the fold there is more than one way to split between critical and non-critical e.g. styles for initial page render vs those used on interaction (for a popup menu for example)
    - lelandfe 4y ago
      https://web.dev/extract-critical-css/ https://web.dev/extract-critical-css/ > Critical CSS is a technique that extracts the CSS for above-the-fold content in order to render content to the user as fast as possible. You can decide to put whatever you want into the style tag, but "critical CSS" explicitly refers to above the fold.
      - youngtaff 4y ago
        > You can decide to put whatever you want into the style tag, but "critical CSS" explicitly refers to above the fold. The Web Dev article might decide to define Critical CSS as about the fold but there are at least three ways of looking at Critical CSS - Styles needed for above the fold - Styles needed to layout a skeleton, and main content to avoid layout shifts - Styles needed to layout the whole page Above the fold is an arbitrary definition because it varies by device with different styles being required for different viewport sizes (at least) The approach of scanning the rendering the page to see what styles are needed then extracting them into inline styles might work for small unchanging sites but it just doesn't scale The only way I've seen sites maintain Critical Styles over time is to have a strong design system / patter library so they know what styles are needed to render the page and then split the styles between those needed for first render, and those needed on user interaction
        lelandfe 4y ago
        Addy Osmani's Critical package > Critical extracts & inlines critical-path (above-the-fold) CSS from HTML https://github.com/addyosmani/critical https://github.com/addyosmani/critical Penthouse, the OG of Critical CSS generators > Penthouse will return the critical CSS needed to perfectly render the above the fold content of the page https://github.com/pocketjoso/penthouse https://github.com/pocketjoso/penthouse > Above the fold is an arbitrary definition because it varies by device I mean, sure. But your critical path of CSS is never going to mean the whole page (unless it's a very short page). And skeleton components is objectively a completely different thing. Having definitions, even if "arbitrary," are important.
        4y ago
forgotmypw17 4y ago
I do this for CSS and most JavaScript, except for the OpenPGP.js module, which is one order of magnitude more LOC than all my other JS templates put together. I have found that keeping my code short and getting it all out in 1-3 HTTP request is the optimal performance strategy.
ehnto 4y ago
First up, agree with the author. Now if I may, a rant. It boggles the mind that we style bikeshed over CSS. Is it honestly, truly, and pragmatically worthwhile to spend all this engineering effort manipulating, culling, tree shaking, modularizing our CSS? Pre-load that, inline this, async-load that, and what have we got for it? A web full of wiggling content, slow CDNs, dozens of requests, and an experience of a mis-timed, slow loading web of bullshit. Deliver less CSS in the first place, be pragmatic, load it as one file when the user hits the website, from the same server they got the HTML from. Bam, lightning fucking fast, like it was before we invented all these new problems. The brief flash of your half-styled website is useless to me. Block rendering until the CSS is done. I don't enjoy looking at half an interlaced video frame, or 100px of a 200px image, just show me the finished product. The content wiggles and asynchronous bullshit is what makes your website -feel- slow, even if you managed to trick Google into thinking it loaded quickly.
- dpacmittal 4y ago
  This is the reason I love tailwind. There's no bloat, no headache of naming conflicts (in fact they completely did away with naming), no orphan css. CSS for a full blown website can be less than 5kb. It takes away the pain of thinking about CSS architecture, naming things, conflicts etc and you can just focus on styling.
  - ehnto 4y ago
    I did not expect to like tailwind, and it still irks my past-self's approach to CSS. But I can't argue that as a wholistic approach to CSS, it is very capable and once you learn the lexicon, very fast to develop with. I really did enjoy it.
    - dmitriid 4y ago
      It's also one of the very few frameworks that cares about accessibility by default in their examples: no buttons-as-links, no divs-as-lists, clear contrast everywhere.
    - speedgoose 4y ago
wonnage 4y ago
Nowadays it's probably better to just prompt the browser to preload CSS early with a link preload header. Any page complicated enough to need critical CSS extraction is probably also going to take 50-100ms to render and transfer to the user. Just send the headers before you render and the client will probably have finished downloading them by the time you're done. If clients are on a crappy network, critical css is even worse of an idea because they'll scroll down and get a broken page for 5 seconds
- laundermaf 4y ago
  I don’t find the HTTP headers approach useful. Headers only appear a few bytes before the HTML so if you keep the regular link tag right at the top of the file you’re good to go; no need to mess with headers. Every HTML file should start with: doctype, html tag, head tag, charset meta tag, title, stylesheet link tag. A couple of those tags are even optional.
  - porker 4y ago
    Once HTTP 103 is better supported this will improve.
    - youngtaff 4y ago
      Only if there’s a gap between the 103 response and the head content arriving
  - wonnage 4y ago
    The header approach is easier to graft on to an existing system where the entire html document is generated in one go. Otherwise you have to deal with generating the response in chunks which can be nontrivial.
troysk 4y ago
I am a fan of CSSWizardry and yet I find this post misleading. The examples shown are ways NOT to do frontend performance engineering. The current best performant way to load JS is asynchronously as documented at https://web.dev/efficiently-load-third-party-javascript/ https://web.dev/efficiently-load-third-party-javascript/. And the best way to load CSS is with Critical Path CSS + Async CSS as documented at https://web.dev/defer-non-critical-css/ https://web.dev/defer-non-critical-css/. The easiest way to generate Critical CSS is https://github.com/addyosmani/critical https://github.com/addyosmani/critical where you may suggest multiple resolutions. I have found https://github.com/addyosmani/critical-path-css-tools https://github.com/addyosmani/critical-path-css-tools to be a great resource to master critical path CSS which improves page render speeds. It helps build fast rendering sites, sometimes even sub-second renders given you have a low latency backend.
- lelandfe 4y ago
  > yet I find this post misleading. The examples shown are ways NOT to do frontend performance Is advice different than what you prefer "misleading?" Anyway, he doesn't actually weigh in on marking JS with `defer` or `async`. And the article is directly contesting preloading the styles, given his note on race conditions with `media` switching. Moving the CSS before the `</body>` closing tag is genuinely a way to really defer your CSS. > Why would we ever put non-Critical CSS in the <head> in the first place?! To this point from Harry, I find myself skeptical that anyone's really going to want to do that. Getting layout jank / cumulative layout shift fixed when the main stylesheet is applied is a sisyphean task.
  - troysk 4y ago
    I said misleading as the author mentions JavaScript preventing rendering which isn't the case for anybody who is looking to optimize their site for speed. There are other such assumptions. Performance engineer is most times going against the default way and standards which the author is aware which is why I am surprised with this post. I have not run into layout janks when I have used critical path CSS. I'd look into other tools/settings while extracting the critical path CSS if this would happen to me.
sccxy 4y ago
So many over optimize their sites for Google PageSpeed. Most annoying is fancy "loading" screen before page load. Skip that fancy loading screen/spinner page and your site is already faster.
austinpena 4y ago
I find critters[0] quite easy to work with and well worth implementing on my nextjs or Astro projects. I build a lot of landing pages so there are very few multi page visits. [0] https://github.com/GoogleChromeLabs/critters https://github.com/GoogleChromeLabs/critters
pkrumins 4y ago
I recently converted several of my projects into critical CSS and now I’m outranking my competitors who still use old CSS. Say what you want but Google loves fast loading sites and gives a good rankings boost. You can whine about critical CSS or get it done and win.
- lelandfe 4y ago
  > Say what you want but Google loves fast loading sites and gives a good rankings boost If you're passing your Core Web Vitals scores, there is no further ranking signal. Transcribed from a 2021 Q&A with Google engineers > beyond that point [of a good threshold for all Core Web Vital metrics], you don't get additional boost for reaching it even better. Like if you have your LCP at two seconds and you get it all the way down to one second, um, we've kind of publicly stated that that will not increase your ranking https://youtu.be/HWm6WNkHs90?t=1676 https://youtu.be/HWm6WNkHs90?t=1676
toastal 4y ago
Inline styles make CSP go from trivial to pain if you gotta create nonces without adding much value—to the point where I have the Lighthouse test ignored. I've never seen this sort of optimization being worthwhile and I'm happy the article starts off with how to show it's not a bottleneck.
pg_bot 4y ago
I'm astounded that we still don't have proper lazy loading of stylesheets in 2022. We have async and defer for scripts but nothing for css. There are a bunch of hacks that exist, but none of them work if you want to use a strict CSP. Even if you use it then you have to worry about a FOUT instead of automatically loading the stylesheet from the browser's cache. Inlining critical CSS is madness for any project that is above a certain scale. Maybe you can do it for a single page, but in my experience the results are not worth the effort. You can make your site exceptionally fast without it.
pwython 4y ago
Wait, what's wrong with just using "ModPagespeedEnableFilters prioritize_critical_css"?

96 points by karimmaassen 4y ago

Agree with the author. The gazillion marketing scripts in your webpage is the main performance bottleneck, rather than your css link tag.

youngtaff 4y ago
That’s not quite what the author says… He says if you’ve got other blocking scripts / stylesheets in the head then there’s no point using critical CSS

eyelidlessness 4y ago

In my experience “critical styles” are necessary to load fonts efficiently if you load any, and it’s beneficial to load a few color styles at the same time. Other than that it’s better to load them as separate resources.

laundermaf 4y ago
I’m not sure you know exactly what “critical CSS” refers to because it’s unrelated to font loading and “color styles.” It has to do with inlining the CSS required for content “above the fold” while loading the rest asynchronously.
- youngtaff 4y ago
  Not necessarily just for content above the fold there is more than one way to split between critical and non-critical e.g. styles for initial page render vs those used on interaction (for a popup menu for example)
  - lelandfe 4y ago
    https://web.dev/extract-critical-css/ https://web.dev/extract-critical-css/ > Critical CSS is a technique that extracts the CSS for above-the-fold content in order to render content to the user as fast as possible. You can decide to put whatever you want into the style tag, but "critical CSS" explicitly refers to above the fold.
    - youngtaff 4y ago
      > You can decide to put whatever you want into the style tag, but "critical CSS" explicitly refers to above the fold. The Web Dev article might decide to define Critical CSS as about the fold but there are at least three ways of looking at Critical CSS - Styles needed for above the fold - Styles needed to layout a skeleton, and main content to avoid layout shifts - Styles needed to layout the whole page Above the fold is an arbitrary definition because it varies by device with different styles being required for different viewport sizes (at least) The approach of scanning the rendering the page to see what styles are needed then extracting them into inline styles might work for small unchanging sites but it just doesn't scale The only way I've seen sites maintain Critical Styles over time is to have a strong design system / patter library so they know what styles are needed to render the page and then split the styles between those needed for first render, and those needed on user interaction
      - lelandfe 4y ago
        Addy Osmani's Critical package > Critical extracts & inlines critical-path (above-the-fold) CSS from HTML https://github.com/addyosmani/critical https://github.com/addyosmani/critical Penthouse, the OG of Critical CSS generators > Penthouse will return the critical CSS needed to perfectly render the above the fold content of the page https://github.com/pocketjoso/penthouse https://github.com/pocketjoso/penthouse > Above the fold is an arbitrary definition because it varies by device I mean, sure. But your critical path of CSS is never going to mean the whole page (unless it's a very short page). And skeleton components is objectively a completely different thing. Having definitions, even if "arbitrary," are important.
        4y ago

forgotmypw17 4y ago

I do this for CSS and most JavaScript, except for the OpenPGP.js module, which is one order of magnitude more LOC than all my other JS templates put together. I have found that keeping my code short and getting it all out in 1-3 HTTP request is the optimal performance strategy.

ehnto 4y ago

First up, agree with the author. Now if I may, a rant. It boggles the mind that we style bikeshed over CSS. Is it honestly, truly, and pragmatically worthwhile to spend all this engineering effort manipulating, culling, tree shaking, modularizing our CSS? Pre-load that, inline this, async-load that, and what have we got for it? A web full of wiggling content, slow CDNs, dozens of requests, and an experience of a mis-timed, slow loading web of bullshit. Deliver less CSS in the first place, be pragmatic, load it as one file when the user hits the website, from the same server they got the HTML from. Bam, lightning fucking fast, like it was before we invented all these new problems. The brief flash of your half-styled website is useless to me. Block rendering until the CSS is done. I don't enjoy looking at half an interlaced video frame, or 100px of a 200px image, just show me the finished product. The content wiggles and asynchronous bullshit is what makes your website -feel- slow, even if you managed to trick Google into thinking it loaded quickly.

dpacmittal 4y ago
This is the reason I love tailwind. There's no bloat, no headache of naming conflicts (in fact they completely did away with naming), no orphan css. CSS for a full blown website can be less than 5kb. It takes away the pain of thinking about CSS architecture, naming things, conflicts etc and you can just focus on styling.
- ehnto 4y ago
  I did not expect to like tailwind, and it still irks my past-self's approach to CSS. But I can't argue that as a wholistic approach to CSS, it is very capable and once you learn the lexicon, very fast to develop with. I really did enjoy it.
  - dmitriid 4y ago
    It's also one of the very few frameworks that cares about accessibility by default in their examples: no buttons-as-links, no divs-as-lists, clear contrast everywhere.
  - speedgoose 4y ago

wonnage 4y ago

Nowadays it's probably better to just prompt the browser to preload CSS early with a link preload header. Any page complicated enough to need critical CSS extraction is probably also going to take 50-100ms to render and transfer to the user. Just send the headers before you render and the client will probably have finished downloading them by the time you're done. If clients are on a crappy network, critical css is even worse of an idea because they'll scroll down and get a broken page for 5 seconds

laundermaf 4y ago
I don’t find the HTTP headers approach useful. Headers only appear a few bytes before the HTML so if you keep the regular link tag right at the top of the file you’re good to go; no need to mess with headers. Every HTML file should start with: doctype, html tag, head tag, charset meta tag, title, stylesheet link tag. A couple of those tags are even optional.
- porker 4y ago
  Once HTTP 103 is better supported this will improve.
  - youngtaff 4y ago
    Only if there’s a gap between the 103 response and the head content arriving
- wonnage 4y ago
  The header approach is easier to graft on to an existing system where the entire html document is generated in one go. Otherwise you have to deal with generating the response in chunks which can be nontrivial.

troysk 4y ago

I am a fan of CSSWizardry and yet I find this post misleading. The examples shown are ways NOT to do frontend performance engineering. The current best performant way to load JS is asynchronously as documented at https://web.dev/efficiently-load-third-party-javascript/ https://web.dev/efficiently-load-third-party-javascript/. And the best way to load CSS is with Critical Path CSS + Async CSS as documented at https://web.dev/defer-non-critical-css/ https://web.dev/defer-non-critical-css/. The easiest way to generate Critical CSS is https://github.com/addyosmani/critical https://github.com/addyosmani/critical where you may suggest multiple resolutions. I have found https://github.com/addyosmani/critical-path-css-tools https://github.com/addyosmani/critical-path-css-tools to be a great resource to master critical path CSS which improves page render speeds. It helps build fast rendering sites, sometimes even sub-second renders given you have a low latency backend.

lelandfe 4y ago
> yet I find this post misleading. The examples shown are ways NOT to do frontend performance Is advice different than what you prefer "misleading?" Anyway, he doesn't actually weigh in on marking JS with `defer` or `async`. And the article is directly contesting preloading the styles, given his note on race conditions with `media` switching. Moving the CSS before the `</body>` closing tag is genuinely a way to really defer your CSS. > Why would we ever put non-Critical CSS in the <head> in the first place?! To this point from Harry, I find myself skeptical that anyone's really going to want to do that. Getting layout jank / cumulative layout shift fixed when the main stylesheet is applied is a sisyphean task.
- troysk 4y ago
  I said misleading as the author mentions JavaScript preventing rendering which isn't the case for anybody who is looking to optimize their site for speed. There are other such assumptions. Performance engineer is most times going against the default way and standards which the author is aware which is why I am surprised with this post. I have not run into layout janks when I have used critical path CSS. I'd look into other tools/settings while extracting the critical path CSS if this would happen to me.

sccxy 4y ago

So many over optimize their sites for Google PageSpeed. Most annoying is fancy "loading" screen before page load. Skip that fancy loading screen/spinner page and your site is already faster.

austinpena 4y ago

I find critters[0] quite easy to work with and well worth implementing on my nextjs or Astro projects. I build a lot of landing pages so there are very few multi page visits. [0] https://github.com/GoogleChromeLabs/critters https://github.com/GoogleChromeLabs/critters

pkrumins 4y ago

I recently converted several of my projects into critical CSS and now I’m outranking my competitors who still use old CSS. Say what you want but Google loves fast loading sites and gives a good rankings boost. You can whine about critical CSS or get it done and win.

lelandfe 4y ago
> Say what you want but Google loves fast loading sites and gives a good rankings boost If you're passing your Core Web Vitals scores, there is no further ranking signal. Transcribed from a 2021 Q&A with Google engineers > beyond that point [of a good threshold for all Core Web Vital metrics], you don't get additional boost for reaching it even better. Like if you have your LCP at two seconds and you get it all the way down to one second, um, we've kind of publicly stated that that will not increase your ranking https://youtu.be/HWm6WNkHs90?t=1676 https://youtu.be/HWm6WNkHs90?t=1676

toastal 4y ago

Inline styles make CSP go from trivial to pain if you gotta create nonces without adding much value—to the point where I have the Lighthouse test ignored. I've never seen this sort of optimization being worthwhile and I'm happy the article starts off with how to show it's not a bottleneck.

pg_bot 4y ago

I'm astounded that we still don't have proper lazy loading of stylesheets in 2022. We have async and defer for scripts but nothing for css. There are a bunch of hacks that exist, but none of them work if you want to use a strict CSP. Even if you use it then you have to worry about a FOUT instead of automatically loading the stylesheet from the browser's cache. Inlining critical CSS is madness for any project that is above a certain scale. Maybe you can do it for a single page, but in my experience the results are not worth the effort. You can make your site exceptionally fast without it.

pwython 4y ago

Wait, what's wrong with just using "ModPagespeedEnableFilters prioritize_critical_css"?