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

91–100 of 124 posts

Re: Critical CSS

#91

Post by davidmurdoch »

crazygringo wrote: post #88

I don't really understand the point of this. Most of the CSS that gets used below the fold on a single page on most pages, gets used above it too. Especially when considering it needs to handle large desktop monitors, and responsiveness. And then remaining part (e.g. styling a footer) is tiny. The CSS "bloat" that you might want to delay loading is CSS for the rest of the entire site , including all sorts of legacy s…

It reduces round-trips. The ultimate goal used to be (in the 2010s) to ensure the first tcp packet had everything the browser needed to render the layout without any additional round-trips. Rare to go that extreme these days, of course.

Re: Critical CSS

#93

Post by mediumsmart »

rglover wrote: post #85
dimmke wrote: post #66

Earlier quoted context omitted.

Seriously. When I look at the modern state of front-end development, it's actually fucking bonkers to me. Stuff like Lighthouse has caused people to reach for optimizations that are completely absurd. This might make an arbitrary number go up in test suites, at the cost of massively increasing build complexity and reducing ease of working on the project all for very minimal if any improvement for the hypothetical end…

Yup. Give people a number or stat to obsess over and they'll obsess over it (while ignoring the more meaningful work like stability and fixing real, user-facing bugs). Over-obsession with KPIs/arbitrary numbers is one of the side-effects of managerial culture that badly needs to die.

It’s just a few meaningful numbers like 0 accessibility errors, A+ for the securityheaders, flawless result on webkolls 5july net plus below 1 second loading time on pagespeed mobile. Once that has been achieved obsessing over stabilizing a flaky bloat pudding while patching over bugs aka features that annoy any user will have died.

Re: Critical CSS

#94

Post by todotask2 »

robotfelix wrote: post #45
todotask2 wrote: post #17

When I tested mine, I got the following: Built on Astro web framework HTML: 27.52KB uncompressed (6.10KB compressed) JS: Critical CSS: 57KB uncompressed (7KB compressed) — tested using this site for performance analysis. In comparison, many similar sites range from 100KB (uncompressed) to as much as 1MB. The thing is, I can build clean HTML with no inline CSS or JavaScript. I also added resource hints (not Early Hint…

It's worth noting that including Critical CSS in every page load isn't the only way to use it. A lot of unnecessary bloat can be avoided by only including it when it looks like a user is visiting for the first time (and likely hasn't got the CSS files cached already) or only using the Critical CSS technique for pages that commonly come at the start of a session.

> A lot of unnecessary bloat can be avoided by only including it when it looks like a user is visiting for the first time (and likely hasn't got the CSS files cached already

I’ve thought about that before but couldn’t figure out the ideal approach. Using a unique session cookie for non-logged in users isn’t feasible, as it could lead to memory or storage issues if a malicious actor attempts a DDoS attack.

I believe this approach also doesn’t work well for static pages, which are likely already hosted close to users.

One useful trick to keep in mind is that CSS content-visibility only applies in certain scenarios. One agency I came across using for every section is a bad idea.

So my conclusion is mobile-first CSS is generally more practical and use PWA which I'm building now for site that has lots of listings.

Re: Critical CSS

#95

Post by youngtaff »

lelandfe wrote: post #84
youngtaff wrote: post #81

Earlier quoted context omitted.

I wouldn’t use the JS hack to load CSS… When the stylesheet loads and is applied to the CSSOM it’s going to trigger layout and style calculations for the elements it’s applied to maybe even the whole page Browsers are pretty eager at fetching stylesheets even those at the bottom of the page

That stylesheet application was going to happen anyway, the difference now is that FCP will occur before it. > Browsers are pretty eager at fetching stylesheets even those at the bottom of the page Browsers begin fetching resources as they discover them. For a big enough document, that will mean low placed resources will suffer.

Sure that work is going to happen but often what you see is multiple stylesheets loaded using the async hack which results in multiple style and layout calculations as the browser can coalesce them because it doesn’t know that they’re stylesheets or when they will arrive

The whole philosophy of critical styles philosophy being those about the fold is a mistake in my view

Far better to adopt approaches like those recommended by Andy Bell that dramatically reduces stylesheet size

And do critical styles “correctly” i.e. load those that are needed to render the initial page and load the ones that rely on interactions separately

Re: Critical CSS

#97

Post by defied »

We created this as a free tool a while back on TestingBot: https://testingbot.com/free-online-tools/critical-css-genera....

It uses a remote browser to start a Puppeteer session and runs JavaScript code to extract the critical CSS needed for above-the-fold content. We chose Puppeteer because it’s fast to instrument the browser and works well even on JavaScript-heavy sites.

Re: Critical CSS

#98

Post by crazygringo »

davidmurdoch wrote: post #91
crazygringo wrote: post #88

I don't really understand the point of this. Most of the CSS that gets used below the fold on a single page on most pages, gets used above it too. Especially when considering it needs to handle large desktop monitors, and responsiveness. And then remaining part (e.g. styling a footer) is tiny. The CSS "bloat" that you might want to delay loading is CSS for the rest of the entire site , including all sorts of legacy s…

It reduces round-trips. The ultimate goal used to be (in the 2010s) to ensure the first tcp packet had everything the browser needed to render the layout without any additional round-trips. Rare to go that extreme these days, of course.

But it increases overall bandwidth, because you're adding a bunch of CSS to every page that can't be cached.

That's a terrible tradeoff.

And if a site has a single CSS file, there's only ever a CSS round-trip on the first page. There aren't any round-trips afterwards.

Re: Critical CSS

#99

Post by davidmurdoch »

crazygringo wrote: post #98
davidmurdoch wrote: post #91

Earlier quoted context omitted.

It reduces round-trips. The ultimate goal used to be (in the 2010s) to ensure the first tcp packet had everything the browser needed to render the layout without any additional round-trips. Rare to go that extreme these days, of course.

But it increases overall bandwidth, because you're adding a bunch of CSS to every page that can't be cached . That's a terrible tradeoff. And if a site has a single CSS file, there's only ever a CSS round-trip on the first page . There aren't any round-trips afterwards.

Well, yes, but also no. It really depends on your website. SPAs can benefit, especially ones that utilize server-side rendering, as they don't have multiple pages anyway. And not all MPAs need to optimize for multi-page navigation either; sometimes websites aren't intended to be heavily navigated, or if they are, common navigation can make use of preloads.

This technique is usually combined with preloads so the parser can identify assets that should be prefetched while the remaining packets are still being downloaded.

If your "Critical CSS" is small enough (i.e., it fit well within the client's CWND), it is very possible it doesn't increase the total number of roundtrips at all.

As a web developer, if you are optimizing for above-the-fold CSS, you are already optimizing in lots of other ways, and should be fully cognizant of the potential trades for the optimization solutions that are available to you.

Re: Critical CSS

#100

Post by crazygringo »

davidmurdoch wrote: post #99
crazygringo wrote: post #98

Earlier quoted context omitted.

But it increases overall bandwidth, because you're adding a bunch of CSS to every page that can't be cached . That's a terrible tradeoff. And if a site has a single CSS file, there's only ever a CSS round-trip on the first page . There aren't any round-trips afterwards.

Well, yes, but also no. It really depends on your website. SPAs can benefit, especially ones that utilize server-side rendering, as they don't have multiple pages anyway. And not all MPAs need to optimize for multi-page navigation either; sometimes websites aren't intended to be heavily navigated, or if they are, common navigation can make use of preloads. This technique is usually combined with preloads so the parse…

I really continue to disagree. SPA's seem like the least likely to benefit of anything at all -- they often don't even have a concept of "below the fold", as they have a workspace-like environment, not a scrolling-document one. And not only is loading time generally less important for them (unlike news articles), but they're used constantly, so the CSS is almost always cached anyways.

There are lots of ways to optimize CSS. I continue to think this particular one is not a good idea under any circumstance, because it's anti-caching and eliminating a since round-trip once is just not ever going to be worth it.

Post reply on HN