Perspective 1

I understand how external CSS style sheets can affect page performance, but there was a reason why CSS mostly became an external file. This entire article failed to address that important reason, which was to provide the logistic power to alter styling to a large number of posts or pages by changing one or a few CSS files.

That was one of the main reasons to place CSS into an external style sheet, so we would not have to manually change hundreds of pages/posts. This important element in styling web pages should never be ignored.

Baseline: external CSS is very helpful when it comes to developer experience.

Perspective 2

I’ve seen people use a dozen elements to do what could be easily accomplished with a single properly styled element. So their css file becomes an unmaintainable mess and blows up. You do things correctly, your case file will be small and there will not be any issues.

So many of the problems in the modern computing age are just problems caused by doing something in a dumb way and then trying to fix the resulting mess by doing more things. It never occurs to people to look at why they ran into issues in the first place. Fix the problem, don’t implement a solution to fix the problem.

Baseline: with good coding practice, size of css file can be reduced.

Perspective 3

There are a lot of things that can be optimized in a web page before going to such depth, like minifying resources, placing non-critical scripts at the bottom of the page etc. Also don’t forget the server end of things. I recently moved my business website to a hosting service that is the best in the market. It has very fast SSD and the page speed of my site has increased dramatically. So for page performance there are a lot of parts to address to ensure you have the best performance possible.

Baseline : apart from CSS, several other optimizations can be done to get better performance.

Perspective 4

Software development is all about tradeoffs. In the pursuit of better performance, we need to determine what tradeoff we’re willing to make. We eliminated a network request (which is good) but we just transferred those kilobytes to the HTML file and made it bigger (which is bad).

There is some balance to be made in accepting the overhead of having a larger HTML file in order to eliminate a synchronous network request, but at some point, if you put too many styles into the head, your performance metrics will actually suffer.

The observation to make here is that inlining CSS makes things more performant for metrics such as first contentful paint when we only inline critical CSS in the document head (the key word being critical).

Perspective 5

Let’s be honest: the idea of inlining critical CSS and preloading the rest seems fairly straightforward if your project consists of a page or two. But if you have hundreds of different pages and a whole team of developers working on different parts then keeping track of critical and non-critical styles can be cumbersome, if not impossible. We would be greatly helped by some tooling here :)

Further resources:

Front-End Performance Checklist 2020 – Setting Realistic Goals