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

Critical CSS

critical-css-extractor.kigo.studio

Post reply on HN
Print view View original

71–80 of 124 posts

Re: Critical CSS

#71

Post by lxe »

zaphodias wrote: post #65
lxe wrote: post #64

This is a footgun. You'll get a very consistent flash of unstyled content. It's not just an aesthetics issue -- when layout shifts in the middle of a page load, as your "non-critical" styles are applied, and user is interacting with something, it will kill your usability.

isn't the whole point avoiding FOUC, while also avoiding to block the rendering for CSS network requests?

Unless you're sure that your the "non-critical" css doesn't cause layout shifts (aka, it doesn't overload any "critical" styles), you're gonna see layout shifts even on fast connections if you load some styles at the top of the document and then do a link rel at the bottom.

Re: Critical CSS

#72

Post by rtsil »

lxe wrote: post #71
zaphodias wrote: post #65

Earlier quoted context omitted.

isn't the whole point avoiding FOUC, while also avoiding to block the rendering for CSS network requests?

Unless you're sure that your the "non-critical" css doesn't cause layout shifts (aka, it doesn't overload any "critical" styles), you're gonna see layout shifts even on fast connections if you load some styles at the top of the document and then do a link rel at the bottom.

The critical css should cover everything above the fold to avoid that visible reflow.

Re: Critical CSS

#73

Post by acjohnson55 »

oneeyedpigeon wrote: post #32

Feels like premature optimisation to me. Are there really cases where the CSS is so complex or the page loads so many resources that this effort is worthwhile? Maybe with the most complex web apps, I guess, but for almost all cases, I would have thought writing clean CSS, HTML, and JavaScript would render this unnecessary or even counterproductive.

For many sites, this probably is a premature optimization. But for sites that live off of click-through, like news/media, getting the text on screen is critical. Bounce rate starts to go up and ad revenue drops as soon as page loads are less than "immediate", which is about 1 second. The full page can actually be quite heavy once all the ads, scripts, and media load.

We were doing this optimization more than a decade ago when I worked at HuffPost.

Re: Critical CSS

#74

Post by lxe »

rtsil wrote: post #72
lxe wrote: post #71

Earlier quoted context omitted.

Unless you're sure that your the "non-critical" css doesn't cause layout shifts (aka, it doesn't overload any "critical" styles), you're gonna see layout shifts even on fast connections if you load some styles at the top of the document and then do a link rel at the bottom.

The critical css should cover everything above the fold to avoid that visible reflow.

Then what does the "non-critical" css do?

Re: Critical CSS

#75

Post by bawolff »

oneeyedpigeon wrote: post #32

Feels like premature optimisation to me. Are there really cases where the CSS is so complex or the page loads so many resources that this effort is worthwhile? Maybe with the most complex web apps, I guess, but for almost all cases, I would have thought writing clean CSS, HTML, and JavaScript would render this unnecessary or even counterproductive.

> Are there really cases where the CSS is so complex or the page loads so many resources that this effort is worthwhile?

On the contrary, the more complex the css is or the more resources loaded, the less this would be worthwhile.

The thing i think they are trying to optimize is latency due to RTT. When you first request the html file, the browser needs to read it before knowing the next thing to request. This requires a round trip to the server, which has latency (pesky speed of light). The larger your (critical) css, the more expensive this optimisation is so the less likely it is a net benefit.

Re: Critical CSS

#76

Post by bawolff »

lxe wrote: post #74
rtsil wrote: post #72

Earlier quoted context omitted.

The critical css should cover everything above the fold to avoid that visible reflow.

Then what does the "non-critical" css do?

The non-critical things?

I mean, i agree with you that this is insanely easy to screw up. However in most websites there is obviously css which doesn't cause reflows and is not needed for first paint. Actually separating that out correctly seems easy to mess up, but it obviously exists.

Re: Critical CSS

#77

Post by bigbuppo »

a_gray wrote: post #42
Brajeshwar wrote: post #5

I’ve been away for quite a while, so just a loud thinking. With tools such as PostCSS, and servers serving zipped styles across CDN, maintaining a single request to the styles; does it really benefit from breaking up the styles these days? Also, I’m going to assume, besides the core styles that run a website, anything that is loaded later can come in with its specific styles as part of the HTML/JS. For the critical C…

> serving zipped styles across CDN CDNs haven't been cached across domains for years. I.e. using a CDN is no faster than a server serving it itself (usually slower because of DNS lookups, but sometimes slightly faster if the geolocation is closer if the DNS was already looked up).

The performance impact of CDNs are definitely a complicated matter and always have been. They aren't a magic solution to any problems unless you're exceeding the origin's available bandwidth, or are serving up something that should be cacheable but somehow can't live without whatever it is that Elementor does that makes it worth every request taking 75 seconds to complete.

Re: Critical CSS

#78

Post by bawolff »

austin-cheney wrote: post #28

When I was doing performance examinations from localhost I found that CSS was mostly inconsequential if written at least vaguely efficiently and requested as early as possible from the HTML. By completely removing CSS I might be able to save up to 7ms of load time, but that was extremely hard to tell because that was well within the variance between test intervals. https://github.com/prettydiff/wisdom/blob/master/per…

Obviously trying to do an optimization designed to reduce the impact of latency between client server is going to have no impact if you are testing on localhost where latency is already effectively zero.

That's not to say i think this optimization is neccesarily worth it, just that testing on localhost is not a good test of this.

Re: Critical CSS

#80

Post by bawolff »

pjc50 wrote: post #27
sublinear wrote: post #12

Non-starter for all but hobby websites since it's incompatible with any content security policy disallowing inline style tags. Edit regarding replies to this comment: I'm sure many will get a kick out of your workarounds and they're all worth posting in the spirit of HN, however I am talking about CSPs that disallow shenanigans. Carry on though :^)

> content security policy disallowing inline style tags Wait, why on earth is this a thing?

The threats solved by restricting CSS with CSP are pretty minor, but generally its to prevent injection attacks that do the following:

- injecting css to restyle the page as part of a social engineering attack or to otherwise trick the user into doing something stupid

- using css to load an image or something to track users viewing the page or capture their IP address

- leak the values of attributes on the page (you can do complex things with ^= and ~= selectors to leak attribute values). Sometimes page text contents can also be leaked using tricks with fonts and scrollbars (not sure if that still works on modern browsers).

On the whole though, the surface area is small compared to javascript. I often see people restrict css before js (or doing the js restrictions incorrectly) because restricting css is much easier, but that is really silly as an attacker will always reach for javascript first if its available.

Post reply on HN