Wait, what's wrong with just using "ModPagespeedEnableFilters prioritize_critical_css"?
Critical CSS? Not So Fast
61–70 of 90 posts
Re: Critical CSS? Not So Fast
#62First 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.
Any system using PurgeCSS (like Tailwind) would have the same bloat removed right? (minus the bloat Tailwind adds to your HTML)
Is there a replacement for CSS Modules' "composes" keyword? Tailwind has @apply, but that defeats the purpose of a utility framework somewhat.
Re: Critical CSS? Not So Fast
#63Earlier quoted context omitted.
They might mean a system like BEM, where they are semantic in that they represent concepts tightly coupled to the HTML and what it's used for. ...etc BEM is a good example of what Tailwind is a counterpoint to.
Nothing stops you from layering BEM on top of tailwind via @apply - although I'm not sure if that's a good idea. Maybe if creating a full, custom, design-system using tailwind?
Although the Tailwind author hates @apply and says they shouldn't have put it in the tailwind in the first place (mainly because it's a hard feature to develop - i wouldn't be surprised it would be removed). I think going tailwind only is bad too because you loose many of the nice functions of CSS like theming/cascade.
So i think using utility classes/tailwind for base/layout and still using named classes where it makes sense (like common reusable components, hover hiearchies, transitions/animations) is most practical approach. And using BEM as convention for the named classes is not a bad idea - certainly better than no system.
Re: Critical CSS? Not So Fast
#64Earlier quoted context omitted.
Nothing stops you from layering BEM on top of tailwind via @apply - although I'm not sure if that's a good idea. Maybe if creating a full, custom, design-system using tailwind?
Although the Tailwind author hates @apply and says they shouldn't have put it in the tailwind in the first place (mainly because it's a hard feature to develop - i wouldn't be surprised it would be removed). I think going tailwind only is bad too because you loose many of the nice functions of CSS like theming/cascade. So i think using utility classes/tailwind for base/layout and still using named classes where it ma…
> Although the Tailwind author hates @apply and says they shouldn't have put it in the tailwind in the first place (mainly because it's a hard feature to develop - i wouldn't be surprised it would be removed). I think going tailwind only is bad too because you loose many of the nice functions of CSS like theming/cascade.
I'd say that dropping the cascade, along with namespacing "classes" (through the build-step) is the main feature of tailwind. It's a departure from CSS - I don't think I'd recommend to mix and match.
I like CSS, but I also see how it's a complex tool that's often used poorly, even by experienced developers.
As for themeing - I'd say that is well supported within tailwind.
Re: Critical CSS? Not So Fast
#65Re: Critical CSS? Not So Fast
#66Earlier 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.
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.
We have to have Tailwind because we got CSS instead of DSSSL.
Re: Critical CSS? Not So Fast
#67First 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-…
>The brief flash of your half-styled website is useless to me. Block rendering until the CSS is done. I have good news for you: https://web.dev/critical-rendering-path-render-blocking-css CSS is already a render blocker.
Which I think is the correct way to handle a CSS file, but it's not render blocking if you dynamically load it in with JS. That is what Critical path CSS is combatting against, the "FUIC" or flash of unstyled content, which of course is because people are loading in CSS asynchronously. A problem we created for ourselves.
A lot of new approaches atomically separate the CSS and JS into dozens of smaller files that load in as the parts of the website that need them load in. Critial CSS is likely also a response to the issues that this approach creates.
As the article alludes to, they're ideas that makes total sense clinically, but falls short really quickly in practice.
Re: Critical CSS? Not So Fast
#68First 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-…
The more CSS you load the slower some rendering becomes. Even when the styles aren't used. If you use a static page this isn't as relevant. It can become significant for single page apps, especially if you dynamically load CSS.
An SPA has all the tools in their tooling chain necessary to minimize delivered CSS, yet they're often still slower than a static page web application with a 5000 line CSS file. The issue isn't the CSS rendering, it's in the timing of the resources and their delivery. If you load CSS in 12 different files, especially if you're doing it as the user interacts with the site, then the browser has to combine, reprocess and repaint every line of CSS it has been given so far, each time it gets new CSS. That's after waiting for the network request.
I know I'm talking against industry opinion, but I don't believe browsers are the right platform to be loading things on the fly as the user needs them. It's 50-300+ms absolute best case, plus processing time. It's going to feel bad.
Re: Critical CSS? Not So Fast
#69Earlier quoted context omitted.
> 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.
How is it a micro-optimization to only load content that you need?
Like I said for large SaaS products you might never see 50% of the components on random settings and other less used pages. Some users only load a few index pages the first few times they visit so making it load faster is always a win.
Frameworks handle way more complex stuff that this. It's not overhead.
Re: Critical CSS? Not So Fast
#70Earlier quoted context omitted.
> 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…
The way SPAs work is very performant but are also poor for indexing. Critical Path CSS is mostly used in user facing sites which one wants to get indexed by Google. As page speed is one of the factors considered in SEO, and rightly, one tries to optimize that. Vue, React, etc. are poor at SEO as they do not even try to do solve the problem as they are used to build apps and not sites.
No one is using non-SSR SPAs for content that needs to be SEO'd? That doesn't stop them from using much of the same toolset.