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

11–20 of 90 posts

Re: Critical CSS? Not So Fast

#11

Post by troysk »

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 generate Critical CSS is https://github.com/addyosmani/critical where you may suggest multiple resolutions.

I have found 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.

Re: Critical CSS? Not So Fast

#12

Post by dmitriid »

ehnto wrote: post #10
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.

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.

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.

Re: Critical CSS? Not So Fast

#13

Post by troysk »

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…

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.

Re: Critical CSS? Not So Fast

#14

Post by speedgoose »

ehnto wrote: post #10
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.

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.

Tailwind goes against all old CSS best practices, so I was strongly against it. But I eventually tried it after reading everyone recommending it and it’s great.

Re: Critical CSS? Not So Fast

#15

Post by laundermaf »

eyelidlessness wrote: post #3

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.

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.

Re: Critical CSS? Not So Fast

#16

Post by laundermaf »

wonnage wrote: post #7

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

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.

Re: Critical CSS? Not So Fast

#17

Post by dspillett »

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 what makes your website -feel- slow, even if you managed to trick Google into thinking it loaded quickly.*

I assume this is why a lot of pages do it: SEO over UX. If they cared that much about user experience the ads and tracking would be gone before worrying about CSS in this way.

Re: Critical CSS? Not So Fast

#18

Post by porker »

laundermaf wrote: post #16
wonnage wrote: post #7

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

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.

Once HTTP 103 is better supported this will improve.

Re: Critical CSS? Not So Fast

#19

Post by sccxy »

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.

Post reply on HN