search

csswizardry / ama

Ask me anything!
57 stars 4 forks source link

What is your perspective on critical CSS for large sites? #40

Closed bassplayer7 closed 5 years ago

bassplayer7 commented 7 years ago

I primarily work on sites that run Magento - a shopping cart that ships a ~70KB stylesheet (minified). One option we have considered to attempt to speed it up is to use a critical CSS technique to reduce the time to first paint. By asynchronously loading non-essential styles, the page can start to render as soon as the HTML response has returned.

In working with critical CSS for other projects, however, I'm come across a few questions:

Each of those can certainly be solved if the benefit of including the critical CSS in the initial response is there. I believe Google recommends this approach, and there are tools to help with the first item, in particular. If done manually, critical CSS introduces more maintenance overhead, but again, if the benefit is there, that can certainly be worth it.

As one that has worked on large sites and performance, what is your perspective on the practicality of using critical CSS on a reasonably large site?

UsmanArshad87 commented 5 years ago

One of the best question, any answer?

nmercky commented 5 years ago

I'm working on large websites too, and I keep asking myself these questions

csswizardry commented 5 years ago

Dang! I’m so sorry I missed this. It is a great question.

The first thing I would say is that Critical CSS is hard, so don’t worry if it feels impossible.

Secondly, and perhaps quite controversially, Critical CSS is error-prone, difficult to implement, and difficult to automate. You may well have bigger opportunities for optimisation that you can tackle more cheaply before you look to implement Critical CSS. You need to be sure it will repay the investment.

Where is the "the fold"?

Problem numero one. You immediately have to define what the fold is, and your safest bet is to settle on something mobile. This means that pretty much all larger-screened devices will fetch a lot of redundant code. I’d mine your analytics and attempt to get a realistic idea of what a sensible lower threshold might be.

If the total HTML initial response is greater than what can be sent in the first packet […] is there any benefit at all to using critical CSS?

Your first round trip can carry 10 TCP segments/packets, which equals about 14.6KB. You don’t need to worry about getting all of your HTML into that payload, but you definitely want to get your <head> tags and the critical CSS <style> blocks in there. To help make this more effective, you can flush your <head>. In PHP, which Magento is written in:

<head>
  ...
</head>
<?php flush(); ?>

This will output the page-so-far to the buffer and send it down the wire ahead of the rest of the payload.

How is the cascade managed because the external stylesheet will have a different source order?

You just gotta hope it all works out for you. Generally, you should be okay. Specificity doesn’t change so most styles should still be applied as expected.

What happens when the source order of components on the page changes and ones that didn't previously display above the fold now do?

You’d need to regenerate your critical styles any time someone makes significant changes to the HTML, unfortunately.

What about the loss of the ability to cache the CSS on subsequent requests?

We’ll still be caching the lion’s share of our CSS, so I wouldn’t worry too much about taking the small hit for your critical payload. That said, if you want to really score extra points, @scottjehl has you covered: Inlining or Caching? Both Please!

Just a few closing words: Critical CSS is great when you get it working, but I often worry that the cost of implementing it can be uneconomical when it truly does only benefit very first-time users. If you can’t get it working, don’t stress. Just focus on writing good quality CSS and trim as much away as possible.

Good luck!