Unexpected FOUC after implementing loadCSS

[cagross]

Hello. To my (WordPress) site I've ensured all stylesheets--except one critical stylesheet--are loaded with a rel=preload attribute. This functions as expected in both Chrome and Firefox. In Chrome, all my stylesheets (except one) are loaded asynchronously, with no flash of unstyled content. In Firefox, all stylesheets (except one) are broken--they are not loaded at all. This is of course expected. So to resolve the Firefox issue I've added the loadCSS files to my site, and loaded cssrelpreload.js on mypage. Firefox now asynchronously loads all stylesheets except one, as desired. But there is now a flash of unstyled content at the very start of page load--the page does not wait for my lone critical stylesheet (style.css) to load. Thoughts on that? Might this be related to something loadCSS is doing? I only see the flash of unstyled content when I enable loadCSS.

I'm not seeing the same issue in Chrome. In Chrome there is no flash of unstyled content. Nor did I see the same issue before I added rel=preload links and loadCSS to my site.

My site is here. Here is my full code (PHP).

edit: Actually, I just loaded the page in Chrome, and I think I'm seeing the FOUC there as well. Maybe this is an indication that I have more than one "critical" stylesheet on my page?

[c-vetter]

Hey there, I'm not familiar with WordPress's API, so I cannot say much about that PHP code.

Looking at your site link, however, I can tell you that your "critical" stylesheet is inserted 300 lines later than your non-criticals, while loadCSS is linked a dozen lines after those. That is already bad for your loading because the non-critical stylesheets may actually delay the critical one.

In any case, you're likely to see the FOUC if your network is sufficiently slow – try the throttle feature to check how your stie behaves under sub-optimal circumstances. Both Chrome and Firefox offer that.

You should make sure that the critical stylesheet is the first one on the page. Also, you will have better results with inlining your critical styles – they should not even get loaded separately.

Hope this helps.

[cagross]

@rasenplanscher Thanks very much for the reply. Here are my follow-ups.

Looking at your site link, however, I can tell you that your "critical" stylesheet is inserted 300 lines later than your non-criticals, while loadCSS is linked a dozen lines after those.

Actually, that last part about loadCSS is interesting to know. If I recall, when I implemented loadCSS, I had some confusion as to exactly when I should load the file. I'll have a look into that.

That is already bad for your loading because the non-critical stylesheets may actually delay the critical one.

But if my non-critical stylesheets are loaded asynchronously, would such a delay still occur?

In any case, you're likely to see the FOUC if your network is sufficiently slow – try the throttle feature to check how your stie behaves under sub-optimal circumstances. Both Chrome and Firefox offer that.

I should have maybe mentioned that I tried the throttling in Chrome, and still couldn't see any FOUC.

You should make sure that the critical stylesheet is the first one on the page.

OK. But again though, if all other style sheets are loaded asynchronously, is it a requirement that my critical stylesheet is the first one loaded?

Also, you will have better results with inlining your critical styles – they should not even get loaded separately.

Right O, I'm aware of that, thanks. I'll turn to that if/when I can get fix this asynchronous CSS issue.

[c-vetter]

@rasenplanscher Thanks very much for the reply. Here are my follow-ups.

You're welcome 🙂

Looking at your site link, however, I can tell you that your "critical" stylesheet is inserted 300 lines later than your non-criticals, while loadCSS is linked a dozen lines after those.

Actually, that last part about loadCSS is interesting to know. If I recall, when I implemented loadCSS, I had some confusion as to exactly when I should load the file. I'll have a look into that.

The polyfill is built in such a way that you can include it at any point, but the recommended location is immediately after your style links because that way, it can start loading them right away. If you put it before your style links, there may be a delay. However, I think that's really not a great issue here.

That is already bad for your loading because the non-critical stylesheets may actually delay the critical one.

But if my non-critical stylesheets are loaded asynchronously, would such a delay still occur?

Yes, because any browser will only download a certain number of files at once. That is unless you're using HTTP2, where those files can be delivered on the same connection. But you still cannot rely on that at this point.

In any case, you're likely to see the FOUC if your network is sufficiently slow – try the throttle feature to check how your stie behaves under sub-optimal circumstances. Both Chrome and Firefox offer that.

I should have maybe mentioned that I tried the throttling in Chrome, and still couldn't see any FOUC.

Have you disabled your cache? I have opened your homepage in Chrome incognito with throttle set to slow 3G and I could see a very visible cascade of repaints. Not a FOUC per se, but that is due to the fact that lots of assets are loaded synchronously and therefore block the rendering completely, so that I saw a blank page until much had been loaded. With more async loading, you'd have the FOUC.

Also, this answer of yours puzzles me in that your initial issue was about seeing a FOUC, including in Chrome as per your edit. How does that fit?

You should make sure that the critical stylesheet is the first one on the page.

OK. But again though, if all other style sheets are loaded asynchronously, is it a requirement that my critical stylesheet is the first one loaded?

Yes and no. Chrome will probably prioritize your critical styles correctly. Browsers using the polyfill, however, probably won't because to them the stylesheet links are just that. They may or may not prioritize based on media query. I haven't tested or researched that, but loading the critical first still makes sense in any case because until the browser encounters the critical style link, it will take care of the others, and at that point, it would need to switch connections which is an unnecessary cost. Look into TCP slow-start for more on that.

Also, you will have better results with inlining your critical styles – they should not even get loaded separately.

Right O, I'm aware of that, thanks. I'll turn to that if/when I can get fix this asynchronous CSS issue.

If you inline all your critical stuff, you can just push your other assets to the end of body if setting up asynchronous loading is problematic to you. Your users will still be better off.

[cagross]

Also, this answer of yours puzzles me in that your initial issue was about seeing a FOUC, including in Chrome as per your edit. How does that fit?

Good catch. Since I first posted my issue here, I've tried to replicate the FOUC in Chrome and I can't at all. So the issue seems to be confined to Firefox and Edge (in Edge, there is also a FOUC, but it is less pronounced). So this is why I think my issue is related to loadCSS. I'm not saying loadCSS has a deficiency--it's more likely that I may be implementing loadCSS incorrectly (or my site has a separate-but-related deficiency).

I have opened your homepage in Chrome incognito with throttle set to slow 3G and I could see a very visible cascade of repaints.

Right. I am indeed aware of those repaints. They are something I'm willing to live with for now. It's the FOUC that I would like to resolve for now. Specifically, I want to improve my page load speed by loading stylesheets asynchronously. And for now, I don't want to implement that until I can resolve this FOUC.

With more async loading, you'd have the FOUC.

But in Chrome, how can there be more async loading? Out of the 16 stylesheets loaded, 14 are loaded asynchronously.

Browsers using the polyfill, however, probably won't because to them the stylesheet links are just that. They may or may not prioritize based on media query. I haven't tested or researched that, but loading the critical first still makes sense in any case because until the browser encounters the critical style link, it will take care of the others, and at that point, it would need to switch connections which is an unnecessary cost.

OK so perhaps if I ensure my critical stylesheet is the first stylesheet loaded, the FOUC issue may clear up on Firefox/Edge? I can look into changing the order in which this particular stylesheet is loaded.

If you inline all your critical stuff, you can just push your other assets to the end of body if setting up asynchronous loading is problematic to you. Your users will still be better off.

OK thanks. I'll keep that in-mind if I can't get async working properly for this site. I believe inlining critcal CSS on a WordPress site is a rather complex process.

[c-vetter]

Since I first posted my issue here, I've tried to replicate the FOUC in Chrome and I can't at all. So the issue seems to be confined to Firefox and Edge (in Edge, there is also a FOUC, but it is less pronounced). So this is why I think my issue is related to loadCSS. I'm not saying loadCSS has a deficiency--it's more likely that I may be implementing loadCSS incorrectly (or my site has a separate-but-related deficiency).

The way the polyfill works is that it turns a rel=preload into a rel=stylesheet media=only x. That means that it becomes a normal stylesheet link with a non-matching media query. That should be asynchronous, but will still be queued before your critical styles are even encountered.

Therefore, the fix stays the same: put the critical stuff first. It is the only way to get the desired result across browsers.

But in Chrome, how can there be more async loading? Out of the 16 stylesheets loaded, 14 are loaded asynchronously.

I have not investigated this, but you might wanna do so: are there blocking scripts? Because they will also prevent the browser from even reaching the critical styles before the scripts have loaded. That is especially likely given all the stuff that happens between your preload-styles and your critical.

OK so perhaps if I ensure my critical stylesheet is the first stylesheet loaded, the FOUC issue may clear up on Firefox/Edge? I can look into changing the order in which this particular stylesheet is loaded.

Yes, I'm certain that will clear the issue.

I believe inlining critcal CSS on a WordPress site is a rather complex process.

Worst case: insert a script-tag that writes a style-tag. That should be simple enough, also make sure it's as early as possible.

[cagross]

OK so perhaps if I ensure my critical stylesheet is the first stylesheet loaded, the FOUC issue may clear up on Firefox/Edge? I can look into changing the order in which this particular stylesheet is loaded. Yes, I'm certain that will clear the issue.

OK. On my page, it looks like my critical style sheet (https://dev.horizonhomes-samui.com/wp-content/themes/horizon-homes/style.css?ver=1553828179) is loaded in line 378, and is the 15th stylesheet loaded (there are 14 stylesheets loaded before it). To be clear, you're saying I should ensure this stylesheet is the first stylesheet loaded--before the others. Is that correct?

I have not investigated this, but you might wanna do so: are there blocking scripts? Because they will also prevent the browser from even reaching the critical styles before the scripts have loaded. That is especially likely given all the stuff that happens between your preload-styles and your critical.

Most JS files are deferred. There are still one or two that are not, but I believe they should not affect initial page render. I want to say they are JS files related to a lightbox that should only appear once a user opens an image. But I can double check on that.

Worst case: insert a script-tag that writes a style-tag. That should be simple enough, also make sure it's as early as possible.

OK interesting. I'll take note of that and look into that after this exercise.

[c-vetter]

OK. On my page, it looks like my critical style sheet (https://dev.horizonhomes-samui.com/wp-content/themes/horizon-homes/style.css?ver=1553828179) is loaded in line 378, and is the 15th stylesheet loaded (there are 14 stylesheets loaded before it). To be clear, you're saying I should ensure this stylesheet is the first stylesheet loaded--before the others. Is that correct?

That is correct.

Most JS files are deferred. There are still one or two that are not, but I believe they should not affect initial page render. I want to say they are JS files related to a lightbox that should only appear once a user opens an image. But I can double check on that.

You should definitely check on that. Even if the lightbox only opens when an image is clicked, loading it will still happen when the browser encounters the related script tag, and that will block render.

Worst case: insert a script-tag that writes a style-tag. That should be simple enough, also make sure it's as early as possible.

OK interesting. I'll take note of that and look into that after this exercise.

You're welcome 🙂

[cagross]

OK understood on all--thanks. Let me try to first move my critical stylesheet up in the loading order. Can we keep this open until I test that out? I may need a few days.

edit: Also, for some reason, I'm back to seeing the same FOUC in Chrome. I think that's a good thing? Perhaps makes it easier to troubleshoot/resolve. It still doesn't happen all the time. But this time I got a screenshot, so at least I know I'm not going crazy.

[c-vetter]

Good luck! 🙂

It still doesn't happen all the time

Yeah, that kind of thing is frustrating, but sadly not unheard of.

[cagross]

OK I was able to add some code to load this critical stylesheet earlier (page here). It now loads 9th out of all 16 stylesheets (instead of 14th as before). And instead of loading on line ~327, it now loads on line 67 of my source code. But, I'm still seeing the FOUC in Firefox. And more importantly, this change has resulted in some fairly big style changes on the front-end of my site (compare it to my live site here). My guess is that in loading the stylesheet earlier, there are now some CSS rules that are overridden by other style rules. That's just a theory--I haven't tested that yet.

What are your thoughts?

[c-vetter]

Your first priority should be inlining those styles because a FOUC means that the styles aren't there, which happens when they are still being downloaded. Getting those styles up in source should be priority two.

Are you on a hosted WP service or running your own instance? If it's your own, I'd go to the template directly and just set the critical style up as the first child of head. In any case, that is far out of scope, and beyond my knowledge of WordPress internals.

Just looking at the fonts used on a piece of text, I can tell you that the change in source order has indeed caused the override you theorized about. In this case there are some inlne styles between the old and the new location. That begs the question how much control you have about the styles that get injected into your page. Depending on that, I may have to retract my recommendation about loading your criticals first – not on principle, but based on practicality.

Some background about critical styles: generally, a critical stylesheet should be a slimmed down version of your overall styles. In the simple case of one main.css containing all relevant styles, you'd have a smaller critical.css that contains just enough styles to prevent a reflow or any nasty styling changes. Many, possibly all, styles found in critical.css would also be found in main.css so that source order would be maintained. My recommendation was based on that strategy.

Right now, it looks like that's not a practical path for your specific setup. If so, you're better off with your overrides coming last, but you would still want them to be inline.

[cagross]

Are you on a hosted WP service or running your own instance? If it's your own, I'd go to the template directly and just set the critical style up as the first child of head. In any case, that is far out of scope, and beyond my knowledge of WordPress internals.

I can indeed edit any and all templates. But just to confirm, are you suggesting that I load this particular stylesheet in my element? I'm fairly sure I can do that. I do this though, will I still encounter the same issues I just encountered? Namely, will I encounter the style changes on the front-end of my site due to the critical stylesheet loading in a different order? I guess there's one way to find out :-)

Just looking at the fonts used on a piece of text, I can tell you that the change in source order has indeed caused the override you theorized about. In this case there are some inlne styles between the old and the new location. That begs the question how much control you have about the styles that get injected into your page. Depending on that, I may have to retract my recommendation about loading your criticals first – not on principle, but based on practicality.

OK got it.

Some background about critical styles: generally, a critical stylesheet should be a slimmed down version of your overall styles. In the simple case of one main.css containing all relevant styles, you'd have a smaller critical.css that contains just enough styles to prevent a reflow or any nasty styling changes. Many, possibly all, styles found in critical.css would also be found in main.css so that source order would be maintained. My recommendation was based on that strategy.

OK got it. I can confirm that in this case, the critical stylesheet is not exactly a slimmed down version of my overall styles. I did not build this website :-/

[c-vetter]

are you suggesting that I load this particular stylesheet in my element?

What do you mean by "my element"?

I can confirm that in this case, the critical stylesheet is not exactly a slimmed down version of my overall styles.

In that case, your best course of action will be to keep the current order and inline the critical sheet.

will I encounter the style changes on the front-end of my site due to the critical stylesheet loading in a different order?

That will always be an issue, because where specificity is equal, source order is the determining factor for which style gets precedence over which.

[cagross]

What do you mean by "my element"?

I meant to write <head> element.

[c-vetter]

What do you mean by "my element"?

I meant to write <head> element.

I see. Generally, yes, styles should be placed in <head>. As far as I can tell, you're already loading all stylesheets in <head>, so no change there unless you are referring to a specific suggestion. In that case, please point that out.

[cagross]

I'm back--so sorry for the delay.

As far as I can tell, you're already loading all stylesheets in <head>

OK yes, you're correct there.

In that case, your best course of action will be to keep the current order and inline the critical sheet.

So how exactly would I do that in my case? Let's say I currently have 20 stylesheets, including my critical stylesheet, all loaded in the <head> element. Inlining the critical stylesheet would require me to move it out of the <head> element, and into the <body> element--correct? If so, how would I inline the critical stylesheet while maintaining the current order? Wouldn't I have to inline all the other stylesheets? Or at least, inline the critical stylesheet and all the stylesheets that come after it in the <head> element?

[c-vetter]

For inlining, the order is unimportant. That is, you can leave everything in its current location.

---

Given a hypothetical stylesheet critical.css with this content:

h1 { color: red }

Inling means turning this:

<link rel="stylesheet" href="critical.css">

into this:

<style>
  h1 { color: red }
</style>

[cagross]

Right O, I do indeed understand that. But I thought you mentioned earlier that I could also "inline" by, "Worst case: insert a script-tag that writes a style-tag." That's how I was hoping to inline my critical stylesheet. Or am I misunderstanding what you wrote?

Inlining my critical CSS by the method you just described would be a bit difficult in my case. At best, it would simply be a bit resource intensive. But at worst, it could cause a lot of style issues. My critical stylesheets are unfortunately several thousand lines long :-/ So moving those style rules from one file to another could conceivably cause a lot of problems. Or it could be fairly seamless--I have to admit I haven't tried yet.

[c-vetter]

Right O, I do indeed understand that. But I thought you mentioned earlier that I could also "inline" by, "Worst case: insert a script-tag that writes a style-tag." That's how I was hoping to inline my critical stylesheet. Or am I misunderstanding what you wrote?

I'm not familiar with the APIs of WordPress. If you cannot insert a style tag, a script tag should be doable. But I think you can disregard this option since you have already said that you have full access. Therefore you should not need to rely on such workarounds.

Inlining my critical CSS by the method you just described would be a bit difficult in my case.

Having full access, you should not have any difficulty in my view. What's the issue?

At best, it would simply be a bit resource intensive.

Given the amount of computation that WordPress is already doing, this should be minor.

But at worst, it could cause a lot of style issues.

Not at all, your styles don't change.

My critical stylesheets are unfortunately several thousand lines long :-/

First, you should minify. Secondly, seriously think about slimming it down content-wise.

So moving those style rules from one file to another could conceivably cause a lot of problems. Or it could be fairly seamless--I have to admit I haven't tried yet.

You don't even need to do that, nor should you. Read the file with PHP and just print it into a style tag. The exact calls are up to you and way out of scope here.

You seem to think this more complicated than it really is. Think simple.

[cagross]

Inlining my critical CSS by the method you just described would be a bit difficult in my case. Having full access, you should not have any difficulty in my view. What's the issue?

Well in my case, since this is a WordPress site, there are essentially two critical stylesheets. And WordPress takes care of inserting a <link> tag for each. So I have to be careful about how to first ensure that WP does not insert these <link> tags, then take care to properly inline all of the CSS. Anyway, that's an exercise for me to research--everything should still be viable.

At best, it would simply be a bit resource intensive. Given the amount of computation that WordPress is already doing, this should be minor.

Sorry, my mistake. I wasn't trying to say it would require more computational resources. I was trying to say it would require a fair bit of my time :-) But I can chip away at it, especially since I'm working on a private dev site.

But at worst, it could cause a lot of style issues. Not at all, your styles don't change.

Right, the style rules/selectors/syntax themselves don't change. But if I inline my CSS, will the order of the rules change? I know the order of the CSS rules in my critical stylesheet will not change. But will my critical CSS rules be loaded in a different order than the other ~15 non-critical stylesheets loaded by the page? That's what I'm trying to wrap my head around. It sounds like you're saying no, the order will not change ("For inlining, the order is unimportant.").

My critical stylesheets are unfortunately several thousand lines long :-/ First, you should minify.

The stylesheets are indeed minified, by Cloudflare, which is active on our live production site. But if remove these two critical stylesheets, and inline all the CSS (into my <head> element), the CSS will no longer be minified. Is that correct? That may not be a huge issue, but I'm mainly asking just so I understand the process.

Secondly, seriously think about slimming it down content-wise.

Yes indeed. I can say that I did not build this particular site, so most of the CSS came from the previous developer. Additionally, we are thinking about changing WordPress themes soon, which should also slim down our content.

Read the file with PHP and just print it into a style tag. The exact calls are up to you and way out of scope here.

Actually, just as a quick-and-dirty test, I was going to simply copy-and-paste everything from my critical stylesheet into a style tag. If that works and does what I hope/expect, then I can come up with a more efficient/robust method (e.g. the PHP read-and-print-to-style-tag method that you suggested).

You seem to think this more complicated than it really is. Think simple.

Right O. I'll try to keep that in-mind. Thanks for being patient. The ball is now in my court I guess--I need to inline everything properly and see how it goes.

[c-vetter]

Inlining my critical CSS by the method you just described would be a bit difficult in my case. Having full access, you should not have any difficulty in my view. What's the issue?

Well in my case, since this is a WordPress site, there are essentially two critical stylesheets. And WordPress takes care of inserting a <link> tag for each. So I have to be careful about how to first ensure that WP does not insert these <link> tags, then take care to properly inline all of the CSS. Anyway, that's an exercise for me to research--everything should still be viable.

Good luck 👍

At best, it would simply be a bit resource intensive. Given the amount of computation that WordPress is already doing, this should be minor.

Sorry, my mistake. I wasn't trying to say it would require more computational resources. I was trying to say it would require a fair bit of my time :-) But I can chip away at it, especially since I'm working on a private dev site.

But at worst, it could cause a lot of style issues. Not at all, your styles don't change.

Right, the style rules/selectors/syntax themselves don't change. But if I inline my CSS, will the order of the rules change? I know the order of the CSS rules in my critical stylesheet will not change. But will my critical CSS rules be loaded in a different order than the other ~15 non-critical stylesheets loaded by the page? That's what I'm trying to wrap my head around. It sounds like you're saying no, the order will not change ("For inlining, the order is unimportant.").

The order in which the rules are applied depends on the order in which their stylesheets are linked. That is independent of when those stylesheets become available. Inline stylesheets are just available immediately.

For example, given these stylesheets:

// style1.css
body { color: red; background: black; }

// style2.css
body { color: blue; background: white; }

and this markup:

<link rel="stylesheet" href="style1.css">
<style>body { color: green }</style>
<link rel="stylesheet" href="style2.css">

While style1.css and style2.css are loading, you'll have green text on a white background. When style2.css loads, you'll have blue on white. If style1.css loads before style2.css, which is not guaranteed, you'll have red on black in the meantime.

Hopefully, this clears the confusion.

My critical stylesheets are unfortunately several thousand lines long :-/ First, you should minify.

The stylesheets are indeed minified, by Cloudflare, which is active on our live production site. But if remove these two critical stylesheets, and inline all the CSS (into my <head> element), the CSS will no longer be minified. Is that correct? That may not be a huge issue, but I'm mainly asking just so I understand the process.

I have no deep knowledge of CloudFlare, but they are likely compressing assets for transport, so yeah, probably not a huge issue.

Question is: do they minify on the fly, or do they store a minified file that you can read at runtime. In the latter case, you should be good – just inline the minified file.

Secondly, seriously think about slimming it down content-wise.

Yes indeed. I can say that I did not build this particular site, so most of the CSS came from the previous developer. Additionally, we are thinking about changing WordPress themes soon, which should also slim down our content.

👍

Read the file with PHP and just print it into a style tag. The exact calls are up to you and way out of scope here.

Actually, just as a quick-and-dirty test, I was going to simply copy-and-paste everything from my critical stylesheet into a style tag. If that works and does what I hope/expect, then I can come up with a more efficient/robust method (e.g. the PHP read-and-print-to-style-tag method that you suggested).

👍

You seem to think this more complicated than it really is. Think simple.

Right O. I'll try to keep that in-mind. Thanks for being patient. The ball is now in my court I guess--I need to inline everything properly and see how it goes.

👍

[cagross]

While style1.css and style2.css are loading, you'll have green text on a white background. When style2.css loads, you'll have blue on white. If style1.css loads before style2.css, which is not guaranteed, you'll have red on black in the meantime. Hopefully, this clears the confusion.

Yes, that helps a lot, thanks. But what if the markup was instead:

<link rel="stylesheet" href="style1.css">
<link rel="stylesheet" href="style2.css">
<style>body { color: green }</style>

When the page fully loads, will the text be blue or green? I think green, based on your statement, "The order in which the rules are applied depends on the order in which their stylesheets are linked. That is independent of when those stylesheets become available. Inline stylesheets are just available immediately." I guess I can also of course test this all myself, using Codepen or something like that.

Question is: do they minify on the fly, or do they store a minified file that you can read at runtime. In the latter case, you should be good – just inline the minified file.

Not sure. I will be sure to look into that. I think it's still a net gain if I can load stylesheets async, yet have to unminify my critical CSS in the process.

[futtta]

Maybe have a look at how Autoptimize (WordPress plugin which I maintain) does it when the "inline & defer"-option is on for inspiration?

[c-vetter]

Sounds like @futtta's plugin would be a good idea to include in your WordPress setup, @cagross

[cagross]

Hi guys. Sorry for the delay.

The Autoptimize plugin has actually been on my radar for a few months now--I learned about it when I first started researching my defer/inline CSS options. I will certainly keep that in-mind as an option, if I cannot implement these fixes on my own.

This particular task is not a critical one. It is just a task I am casually working on, as part of a pet project. I'm mainly doing this task so in the future, if a client asks me to optimize stylesheet loading, I'll (hopefully) know of a proper way to do so.

I still need a few more days to complete my own testing. Maybe even a week or two :-/ Thanks for the assistance so far though--I've learned a lot.

[cagross]

@rasenplanscher OK I gave it a shot. Here is what I did.

First, I ran my site through PageSpeed Insights, and confirmed that both of my critical stylesheets are listed in the "Eliminate render-blocking resources section."

Then, for one of my critical stylesheets, I ensured it was no longer loaded via the usual tag. As a test, I loaded my page in the browser and confirmed that the style rules in that stylesheet were no longer applied.

I then moved all of the style rules in that stylesheet to a