Stop fooling around with deferred CSS

I was happily testing my latest little contact form page for my own fresh new company, that I couldn't resist testing on this Google page speed tool.
There's basically only one point missing in there, which is the following:

Eliminate render-blocking JavaScript and CSS in above-the-fold content
Your page has 1 blocking CSS resources. This causes a delay in rendering your page.

Deferred main CSS is an Anti-Pattern

Not only since this tool came out, everyone decided to write any sort of JavaScript based solution, making JS mandatory for those that maybe blocked JS but still would like to see the page as it should be ... apparently, nobody ever questioned this practice on real-world scenarios, so here a quick recap:

• it's a very bad User eXperience when you can already surf a page that keeps moving under your eyes/fingers because deferred CSS changed every-bloody-box on the page ... style changing everything under our eyes is simply disorienting, period!
• it cannot compete with native applications, those that might take a little longer to load the first screen, but FFS you gonna see them the way their designers meant, and not the uncontrolled way some random browser decided to show the naked page
• it's against W3C standards where it's clearly stated the following:

link should be used where metadata content is expected

The definition of Metadata content is content that sets up the presentation or behavior of the rest of the content.
The list of element that should be placed inside the head one is deadly simple: base, link, meta, noscript, script, style, template, title.
Please note that script is indeed also an element that just should be on the header, specially to inform ASAP the browser that some JS related logic might be involved.
Here again we shouldn't fool ourselves with broken-prone patterns like async, when the page cannot as example possibly even work without JS, but while script gained the right to support defer and async, the link is still "the dangerous tag to avoid for CSS on the head", which is simply ridiculous if you ask me.

And yet not a reliable analysis

Guess how big is the CSS I am talking about, after minification and served as compressed content? 1.3KB ... and this is how the graph looks like when you reach the page:

As Summary

For a page that triggers a DOMContentLoaded in less than 400ms and with all stylesheets in, I would expect something more than "you shuold defer through JS your CSS or put them inline" ... no, I have 4 pages based on the same CSS, why would i even think about wasting time to do something worst?
And please, despite my disappointed tone, don't get me wrong, I love tools like this because there's always something to learn and improve (as example, I completely forgot about pngquant so thanks a lot for pointing that out!)

---

My take on this little story is: don't ever take for correct, right, or absolutely a good practice, anything without before understanding the prooblem and why the eventual solution might work, or not, as it has been in my case.
Thank You for reading, and apologies for not linking such page, it's just not the point to show you a contact form, the rest is ;-)