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.
> yet I find this post misleading. The examples shown are ways NOT to do frontend performance
Is advice different than what you prefer "misleading?"
Anyway, he doesn't actually weigh in on marking JS with `defer` or `async`. And the article is directly contesting preloading the styles, given his note on race conditions with `media` switching. Moving the CSS before the `</body>` closing tag is genuinely a way to really defer your CSS.
> Why would we ever put non-Critical CSS in the <head> in the first place?!
To this point from Harry, I find myself skeptical that anyone's really going to want to do that. Getting layout jank / cumulative layout shift fixed when the main stylesheet is applied is a sisyphean task.
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 other tools/settings while extracting the critical path CSS if this would happen to me.
> 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 :) 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.
Critical CSS and 0 CLS happens only when you create skeleton placeholder components for everything below the fold as well. There are no "tool/settings" that will do this automatically.
> 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.
I don't think it's a typo - a sub-second render on a modern website with all the bells and whistles that users now expect...that probably puts you in the 99th percentile, maybe even higher.
Not disagreeing with you though - it's amazing how much bloat we've added. Nobody seems to get just how fucking fast the web actually is. Take a look at Figma or Linear if you want to see products that truly care about performance.
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 Cloudflare so has CDN support and does sub second render on first load even though its image heavy.
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 mean a higher TTFB.
> If you are lazy loading images
> sub second render on first load even though its image heavy
Images are not render blocking, and so won't be a part of this discussion. (Nor would I consider 1MB of mostly SVGs to be "image heavy")
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).
> 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.
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.
It is easy with a little automation :). In the build process, adding a step to calculate critical path css helps. This should probably be the last step and run on production post deploy. The calculated CSS is stored in redis which will be appended in the head for subsequent requests. This tool had inspired me to build this process at multiple orgs I have worked with https://github.com/pocketjoso/penthouse.
Agree on the async JS part but I guess browser makers will solve it soon.
Is advice different than what you prefer "misleading?"
Anyway, he doesn't actually weigh in on marking JS with `defer` or `async`. And the article is directly contesting preloading the styles, given his note on race conditions with `media` switching. Moving the CSS before the `</body>` closing tag is genuinely a way to really defer your CSS.
> Why would we ever put non-Critical CSS in the <head> in the first place?!
To this point from Harry, I find myself skeptical that anyone's really going to want to do that. Getting layout jank / cumulative layout shift fixed when the main stylesheet is applied is a sisyphean task.