Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Critical CSS? Not So Fast

csswizardry.com

Post reply on HN
Print view View original

21–30 of 90 posts

Re: Critical CSS? Not So Fast

#21

Post by lelandfe »

troysk wrote: post #11

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/ . And the best way to load CSS is with Critical Path CSS + Async CSS as documented at https://web.dev/defer-non-critical-css/ . The easiest way to gen…

> 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 `` closing tag is genuinely a way to really defer your CSS.

> Why would we ever put non-Critical CSS in the 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.

Re: Critical CSS? Not So Fast

#22

Post by dotancohen »

dpacmittal wrote: post #8
ehnto wrote: post #6

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-…

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.

Tell us a bit more about Tailwind. Last I looked at it a few years ago it seemed a conglomeration of antipatterns. Quick googling is not convincing.

Assume that I know _nothing_ about Tailwind, sell it to me. I'd appreciate it. Thanks.

Re: Critical CSS? Not So Fast

#23

Post by pkrumins »

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.

Re: Critical CSS? Not So Fast

#24

Post by toastal »

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.

Re: Critical CSS? Not So Fast

#25

Post by toastal »

dmix wrote: post #9
ehnto wrote: post #6

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-…

> worthwhile to spend all this engineering effort manipulating, culling, tree shaking, modularizing our CSS? You don't have to ever think about this stuff if you use a component-driven frontend framework like Vue w/ Vite (or Webpack). The general design: you use one global .css file for your shared styles (app.css) and then each component has their own inline CSS. Vite will automatically extract each component JS and…

> automatically extract

That's such a tool complexity that most people don't need and probably shouldn't bother with for what is often a microoptimization.

Re: Critical CSS? Not So Fast

#26

Post by deergomoo »

dotancohen wrote: post #22
dpacmittal wrote: post #8

Earlier quoted context omitted.

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.

Tell us a bit more about Tailwind. Last I looked at it a few years ago it seemed a conglomeration of antipatterns. Quick googling is not convincing. Assume that I know _nothing_ about Tailwind, sell it to me. I'd appreciate it. Thanks.

The author of Tailwind wrote a blog post explaining his rationale just after the very first version was released: https://adamwathan.me/css-utility-classes-and-separation-of-...

It may be a longer read than you were looking for, in which case I’d say just try it on a small project next time you get the chance. It looks like it wouldn’t work, but it really does.

Re: Critical CSS? Not So Fast

#27

Post by karlmdavis »

troysk wrote: post #11

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/ . And the best way to load CSS is with Critical Path CSS + Async CSS as documented at https://web.dev/defer-non-critical-css/ . The easiest way to gen…

“It helps build fast rendering sites, sometimes even sub-second renders…”

That has to be a typo, right? Or sarcasm?

I weep for what we’ve all done to the beautiful speed and simplicity of the web.

Re: Critical CSS? Not So Fast

#28

Post by christophilus »

dotancohen wrote: post #22
dpacmittal wrote: post #8

Earlier quoted context omitted.

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.

Tell us a bit more about Tailwind. Last I looked at it a few years ago it seemed a conglomeration of antipatterns. Quick googling is not convincing. Assume that I know _nothing_ about Tailwind, sell it to me. I'd appreciate it. Thanks.

Been developing websites and apps since the days when we are worrying about the y2k bug. Tailwind is my favorite thing. Almost everything that I disliked about CSS is solved by it. Once you really kick the tires, you become way more productive:

Naming is hard. No more naming.

Switching between your markup and your CSS added friction to your flow. No more friction.

Avoiding problems caused by overly aggressive rules / cascade/ whatever is mostly a thing of the past.

I could go on, but if it’s not obvious, I absolutely love it. And the Tailwind UI project is 100% money we’ll spent, too.

Re: Critical CSS? Not So Fast

#29

Post by vehemenz »

dotancohen wrote: post #22
dpacmittal wrote: post #8

Earlier quoted context omitted.

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.

Tell us a bit more about Tailwind. Last I looked at it a few years ago it seemed a conglomeration of antipatterns. Quick googling is not convincing. Assume that I know _nothing_ about Tailwind, sell it to me. I'd appreciate it. Thanks.

Since you use the term "antipattern," what is the respectable pattern (methodology) that Tailwind stands opposed to?

Re: Critical CSS? Not So Fast

#30

Post by youngtaff »

troysk wrote: post #11

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/ . And the best way to load CSS is with Critical Path CSS + Async CSS as documented at https://web.dev/defer-non-critical-css/ . The easiest way to gen…

The process in the article you link to for critical CSS doesn’t work in the real world as it becomes impossible to maintain

This script they use to load the async JS can also be racey and it’s far better to put the link to noncritical styles at the bottom of the page

Post reply on HN