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

71–80 of 90 posts

Re: Critical CSS? Not So Fast

#71

Post by ehnto »

e12e wrote: post #58
ehnto wrote: post #43

Earlier 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?

I would say that'd be a Tailwind anti-pattern, since Tailwind exceeds by trying to do away with cascading, and BEM is an attempt to componentize CSS but retain some cascading.

Also, if you handed me a project with that approach, I would run for the hills! How would you decide when to use BEM styling and when to use the tailwind classes? It'd be a nightmare.

Re: Critical CSS? Not So Fast

#72

Post by ehnto »

cantSpellSober wrote: post #59
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-…

> Is it [...] pragmatically worthwhile YES! It affects e-commerce conversion rates measurably. Great point by the author: "make sure it’s the right thing to focus on." Hobby site? Don't care about FOUC. E-commerce? It's a game-changer. > The brief flash of your half-styled website is useless to me Not to the rest our users though! Are you on a 3G connection in a third-world country? If not your experience may be not…

I am confused, are you for or against FOUC? Or for optimizing against it?

My core industry is e-commerce, have been doing it for over a decade. Our fastest sites are the fully cached, single CSS file sites. You get sent a small amount of CSS and HTML, and you are off to the races. Javascript comes later, and is not necessary to operate the site until checkout.

What kills a sites speed for us is usually shitty CDNs and bloated assets, we don't have those. There isn't a single e-commerce platform popular today that I feel does this well, but that is because they are all enterprise platforms full of enterprise features.

Re: Critical CSS? Not So Fast

#73

Post by omnimus »

e12e wrote: post #64
omnimus wrote: post #63

Earlier quoted context omitted.

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

Typical basic example where tailwind fails is styling text and i don't mean styling html generated from user markdown. (that is given - impossible to do with tw)

When you have any text on page like a heading - tailwind approach is for you to set ".text-xl .leading-tight .tracking-tight" ok fine. Your designer is then like. "Yeah on mobile the fontsize must be much smaller and thus tracking+leading bigger" (because these 3 are tightly related) then he will also want the heading even bigger on big screens (and decrease tracking+leading). Suddenly you are juggling 9 classes that also have some fixed value. So you look into Figma and see that on mobile the leading of this style of heading is 1.27. On laptops its 1.14 and on big screen it's 1.035. So what now - will you change the design or will you add new utility classes specifically for this heading?

So you realize the best approach is to create one class .text-heading-1 and use css - that solves all the issues and it's super easy to change moving forward when you need some fine grained responsive adjustment.

The great thing about TW is that it's very fine grained in html but on the other hand it's bad at being explicit and precise like css is. I think the reason people like TW so much is that huge chunk of web work is layouting. Flex here, justify there and add gap. No more pain to target/name element just because you need to add margin and flex.

Theming is OK to some point (like making dark version) but if you need to make broader changes between multiple themes it just crumbles.

Re: Critical CSS? Not So Fast

#74

Post by omnimus »

ehnto wrote: post #71
e12e wrote: post #58

Earlier 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?

I would say that'd be a Tailwind anti-pattern, since Tailwind exceeds by trying to do away with cascading, and BEM is an attempt to componentize CSS but retain some cascading. Also, if you handed me a project with that approach, I would run for the hills! How would you decide when to use BEM styling and when to use the tailwind classes? It'd be a nightmare.

Use tailwind as much as possible until you feel like you need a class then use BEM for the naming/organisation. It's actually pretty practical system - with headwind the non TW classes sort to the front so you can immediately see if there is something more in css.

The resulting css you end up with is usually super light only with special things, edge cases, hover groups and stuff TW just doesn't handle.

Re: Critical CSS? Not So Fast

#75

Post by troysk »

cercatrova wrote: post #54
troysk wrote: post #13

Earlier quoted context omitted.

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.

I see you haven't used these libraries in at least a few years, because they all have frameworks that work with SEO by server side rendering content. React has NextJS while Vue has NuxtJS.

I have from its days of bleeding edge. They still can't match the speed unless you have huge caching budgets; in my experience.

Re: Critical CSS? Not So Fast

#76

Post by troysk »

lelandfe wrote: post #55
troysk wrote: post #49

Earlier quoted context omitted.

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…

> the author mentions JavaScript preventing rendering which isn't the case for anybody who is looking to optimize their site for speed Rewriting your JS to be async-ready can be a huge lift. Not every site pursuing frontend performance is ready to do that, much less has done it. I think this article certainly has an audience. > I have not run into layout janks when I have used critical path CSS Call me a skeptic :) i…

> Rewriting your JS to be async-ready can be a huge lift. Not every site pursuing frontend performance is ready to do that, much less has done it. I think this article certainly has an audience.

CSSWizardry targets performance engineers which is why I pointed it out. I would never post that for some Next.js or other new hotness blogpost which isn't focussed on frontend performance.

> Call me a skeptic :) if a user is able to scroll beyond the fold before the CSS loads, you've introduced CLS. Spoiler: they will always be able to.

I can't speak on code I haven't worked on or predict how users will react on UIs without looking into data. But I read this as excuses from providing the best UX to the end user.

Re: Critical CSS? Not So Fast

#77

Post by troysk »

lelandfe wrote: post #57
troysk wrote: post #50

Earlier quoted context omitted.

Your location decides the latency of the request. If you are close to server you can do less than 200ms time to first byte. Getting a server near your users help. After that you have 500ms to render your webpage. If you are lazy loading images, and most assets below the fold, thats a lot of time to get a page rendered. You may take a look at my personal website ( https://www.troysk.com/ ) which is hosted via Cloudfla…

You have less CSS than HN, and hardly any JS. This doesn't add anything to the discussion of if this is easy or hard to do – your site will always have a fast FCP, even if you weren't serving with a CDN. Note also that the parent commenter mentioned being logged in to HN. You're serving a static page, which will always be fast. There are many aspects of HN's site that cannot be cached for logged in users, which will…

> You have less CSS than HN, and hardly any JS. This doesn't add anything to the discussion of if this is easy or hard to do – your site will always have a fast FCP, even if you weren't serving with a CDN.

Your observations reeks of incompetence. Are you seriously comparing a few bytes difference? The site loads more CSS from https://www.troysk.com/stylesheets/style.css

And hardly any JS? Can you even read code?

Many sites use static caching and then load dynamic parts asynchronously. The goal is to provide the end user a usable UI real fast. There is also Fastly and other new caching solutions if you are interested to know more.

> Your site actually has room for improvement on performance. You could likely cut your overall page weight in half (not that it would do much, being default fast).

How does it benefit? Have users reaction rates become faster than 1s on the web? This is a site not a game.

Re: Critical CSS? Not So Fast

#78

Post by [deleted] »

troysk wrote: post #77
lelandfe wrote: post #57

Earlier quoted context omitted.

You have less CSS than HN, and hardly any JS. This doesn't add anything to the discussion of if this is easy or hard to do – your site will always have a fast FCP, even if you weren't serving with a CDN. Note also that the parent commenter mentioned being logged in to HN. You're serving a static page, which will always be fast. There are many aspects of HN's site that cannot be cached for logged in users, which will…

> You have less CSS than HN, and hardly any JS. This doesn't add anything to the discussion of if this is easy or hard to do – your site will always have a fast FCP, even if you weren't serving with a CDN. Your observations reeks of incompetence. Are you seriously comparing a few bytes difference? The site loads more CSS from https://www.troysk.com/stylesheets/style.css And hardly any JS? Can you even read code? Many…

[deleted]

Re: Critical CSS? Not So Fast

#79

Post by lelandfe »

troysk wrote: post #77
lelandfe wrote: post #57

Earlier quoted context omitted.

You have less CSS than HN, and hardly any JS. This doesn't add anything to the discussion of if this is easy or hard to do – your site will always have a fast FCP, even if you weren't serving with a CDN. Note also that the parent commenter mentioned being logged in to HN. You're serving a static page, which will always be fast. There are many aspects of HN's site that cannot be cached for logged in users, which will…

> You have less CSS than HN, and hardly any JS. This doesn't add anything to the discussion of if this is easy or hard to do – your site will always have a fast FCP, even if you weren't serving with a CDN. Your observations reeks of incompetence. Are you seriously comparing a few bytes difference? The site loads more CSS from https://www.troysk.com/stylesheets/style.css And hardly any JS? Can you even read code? Many…

> Are you seriously comparing a few bytes difference? The site loads more CSS from https://www.troysk.com/stylesheets/style.css

Setting aside that you're wrong (your style.css is 1.7kB, HN is 2.2kB), that small difference is kind of my point. Discussions of if a quick FCP is easy or not should be based on a typical site. Tiny, static portfolio sites ain't that.

> And hardly any JS? Can you even read code?

Your site's entire JS weight is below 50kB.

> How does it benefit? Have users reaction rates become faster than 1s on the web?

Right. That's why I said, "not that it would do much, being default fast"

Re: Critical CSS? Not So Fast

#80

Post by e12e »

omnimus wrote: post #73
e12e wrote: post #64

Earlier quoted context omitted.

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

Typical basic example where tailwind fails is styling text and i don't mean styling html generated from user markdown. (that is given - impossible to do with tw) When you have any text on page like a heading - tailwind approach is for you to set ".text-xl .leading-tight .tracking-tight" ok fine. Your designer is then like. "Yeah on mobile the fontsize must be much smaller and thus tracking+leading bigger" (because th…

> Suddenly you are juggling 9 classes that also have some fixed value

In my experience, devs using tailwind will happily wait until there are 20+ classes before refactoring - on the surface this seems insane - but if all you're editing is single, re-usable components (eg: "text on a page" is in a custom "article" component) - it's no longer quite as crazy.

> Theming is OK to some point (like making dark version) but if you need to make broader changes between multiple themes it just crumbles.

You wouldn't make css zen garden with tailwind - you would make such sweeping themes at component level, where you can change style, behavior (js) and markup all together.

Again - tailwind isn't for document styling, but for building applications - that happen to feature html and css as implementation details.

Post reply on HN