2

Google PageSpeed suggests adding Critical CSS in a <style> tag in the head, and deferring external CSS to the end of the HTML.

This goes against Web Standards by inlining CSS in HTML (which should be separated), as well as creating FOUC when the CSS does load. Visibility can be styled to show the whole page in one go once CSS has loaded, but this creates FOUC of the whole page which doesn't look good either.

There is no real time difference between loading CSS correctly using a <link> in the head and deferring it until later, so there's no real need to defer the loading of the stylesheet. It still takes the same amount of time to load the page. Why would you serve the user with a half-styled page, when it's better to just display the styled page.

My question is this: Why does a Web giant Google suggest such ridiculous practices which are not Standards compliant and create load-time issues like FOUC? It's like the people that come up with these ideas have no concept of Standards.

nick-roberts91
  • 49
  • 2

1 Answers1

1

Here are some points to help understand the concept better.

This goes against Web Standards by inlining CSS in HTML (which should be separated)

Putting css rules inside the document's head in <style> tags is perfectly fine and acceptable if it serves a specific purpose as in the case you are describing. In a world where we work with things like styled-components and css-in-js, there is no room for this kind of generalization (referring to "such ridiculous practices")

as well as creating FOUC when the CSS does load

If you have prepared your critical css right, then all above-the-fold rules for every breakpoint should be there and no above-the-fold FOUC will occur. At the rest of the page, if you have a well optimized page most probably nobody will manage to actually see the FOUC happening. It will happen very fast and below the visible content.

There is no real time difference between loading CSS correctly using a in the head and deferring it until later, so there's no real need to defer the loading of the stylesheet.

In large projects the css files do not consist of 10 css rules and a 2kb size. You may have some bundled css (or multiple css files) with style rules for hundreds of components, templates and pages while you may only need a handful of rules for your above-the-fold content. When the browsers stumbles across a linked css file, it immediately stop the page rendering, it sends a request for the specific asset, and it does not continue the rendering process until it finishes getting the stylesheet and parsing its content. This time matters. It is the time before the first pixel on your screen is painted. With the aforementioned technique, you can let your browser start painting as soon as it gets the document, without having the css blocking its way (unless you have other blocking resources)

It still takes the same amount of time to load the page.

  1. It does not always take the same amount.
  2. Performance optimization is not only on how long it takes to actually finish loading every bit of the page/resources etc. It is also on how fast you can serve the user with useful content (or any content), and many more...

Why does a Web giant Google suggest such ridiculous practices which are not Standards compliant and create load-time issues like FOUC? It's like the people that come up with these ideas have no concept of Standards.

The things that I already mentioned should answer the question already, so I just want to give you a piece of advice here. This type of companies have lots of really talented and experienced people (that even contribute in writing the web standards and tools etc). If you don't understand something in the first glance, have a further research, ask (as you did :-)), and try to understand the reasoning behind the things that you find wrong. Most of the cases someone will find out that the reason he thought of some things as "ridiculous" and "against the standards" was his incomplete understanding and not them having "no concept of Standards".

Alekos Dordas
  • 802
  • 7
  • 20
  • ` – nick-roberts91 Nov 21 '19 at 21:57
  • I understand the concept of the idea, and it can speed up load times, but it's the way it's implemented (at least by our new hire anyway) that I don't like. It just makes the page look broken as only the header gets styled initially and the rest of the page is blank for a couple of seconds. – nick-roberts91 Nov 21 '19 at 21:59
  • Styling only the header will definitely lead to above-the-fold FOUC. In most cases, rules for above-the-fold content is not SO MUCH of css. And in every case, these rules don't add extra weight because they are removed from the css file. They just change place. So it ends up the the case here was an improper implementation which led to wrong assumptions about the whole practice. – Alekos Dordas Nov 21 '19 at 22:25
  • So, per-se, what would you include in above-the-fold CSS? I see it as being far too much of the page to include inline. They do add extra weight to the HTML/PHP file, so the initial load of the content is heavier IMO. I'd prefer to keep all CSS external in this case, if Critical CSS is only being used for the header, as you say, improper implementation, so the page actually gets styled correctly. New hire won't listen, and keeps pushing back with 'Google say so..'. I wouldn't be so bothered if it was implemented correctly and there was no white screen except header on load. – nick-roberts91 Nov 21 '19 at 22:42
  • " Here are some points to help understand the concept better. This goes against Web Standards by inlining CSS in HTML (which should be separated) Putting css rules inside the document's head in – albert Nov 24 '19 at 04:53