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.

The process in the article you link to for critical CSS doesn’t work in the real world as it becomes impossible to maintain

This script they use to load the async JS can also be racey and it’s far better to put the link to noncritical styles at the bottom of the page

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.