Critical CSS

[ronaldruzicka]

Hey folks! I would like to start a discussion about critical.css and how we are/should use it in our devstack.

For what I know now, there are two possible ways to go:

1. automation: npm module
2. manual: critical css generator

The idea now, as I understand, is to manually create critical.css and use it for the first visit while preloading the main.css.

But I personally like the automated way better, because it's automatic and it puts the the critical.css in inline styles, so it doesn't have to download anything, just preloading the main.css.

So let's start a discussion if we want to use it and if yes, how to use it. Because I think there is no actual project that uses critical.css, if I'm not wrong.

Some articles:

• Understanding Critical CSS
• How and Why You Should Inline Your Critical CSS

[vbulant]

Thanks for opening the discussion.

Both ways to handle the generation are basically the same, the difference is just in manual/automated workflow. The automated one should be the way to go for sure.

But the real issue is that it won’t work that well with dynamically generated websites (ie. CMS based) coz you don’t know the final page contents at the time of critical CSS generation (user can choose multiple components in the CMS).

I think we create mostly this kind of websites so we should address this concern as well. And to be honest I have no idea how to handle it.

[kettanaito]

@vbulant however, automatic CSS generators are often based on analyzing simple html files, which we do have for most of our projects (templates for Sitecore and Kentico are compiled into html in the end).

I understand, that is not the same as the final version, but very close to it. During the html parsing those tools usually collect IDs and class names used on the page (above the fold), and extract their declarations from the main.css into a separate CSS file.

Do you think this will not work for us? My concern is that there is no single approach for us. Our devstack is used for variety of projects, and one approach may work for one projects, and be completely useless for another (i.e. Conrad, where front-end has no control over end-point HTML, everything compiled through Java).

P.S. Also, when implementing critical CSS generation we should take into account that it consists of two parts:

1. Common declarations. Something used throughout the whole website (i.e. typography)
2. Above-the-fold declarations. These are the most crucial, as the whole idea of separating certain parts of CSS into a separate file is for that file to contain only what client needs for fast initial load.

[vbulant]

@kettanaito well it may be close to the final version, but it may still happen that final component order will be different on a final version and thus on the first render it will lack it’s CSS.

You’re right that it differs from project to project. I think good idea might be to try critical CSS in some upcoming project and then create a new critical CSS boilerplate apart from the devstack.

[kettanaito]

Sounds like a good and very important Actum Lab project, @ronaldruzicka :)

[ronaldruzicka]

Well, I can try it on Walmark Line and see, when we finished Homepage, I can try it how it works, and decide if to continue with it or not ;)

Thanks for the input!

[vbulant]

Another possibility to avoid the complex machinery of critical CSS is to use atomic/functional CSS aka Tachyons, BassCSS etc.

In case we’re gonna have the critical CSS boilerplate, this possibility should be listed there as well IMO.

[ronaldruzicka]

Atomic CSS is great, but not for Kentico projects😅

Since Kentico has a lot of code inside it's administration a Backend developer has to change the classes if there are some changes in design. On the other hand it can be easily used with Sitecore or other projects, where source code is inside template files and not directly in CMS administration

[kettanaito]

@ronaldruzicka Atomic approach in CSS should work for any project, if it was designed with Atomic approach in mind. Overall, the pattern of handling the end code as you have described cuts off a lot of CSS optimization techniques.

[ronaldruzicka]

@kettanaito I understand, but if there are changes in design, and you have to change e.g. padding-top on some component, it's more complicated to do it with Atomic CSS inside Kentico.

If you had BEM, it would be just change in CSS:

.component {
    padding-top: 15px; // old
    padding-top: 20px; // new
}

But with Atomic approach, you have to change it in HTML, which means, that you have to modify it in our nunjucks templates first and then wait for Kentico developer to find it inside Kentico and change it there. Because they are using some transformations or sometimes even HTML before and HTML after properties inside the administration, for FE developer it is quite difficult to locate the right location where to change it.

On the other hand e.g. with Sitecore, you can search for the phrase in your editor, locate the right .ascx file and change the class without including a BE developer in the process.

So I would vote for atomic approach on all project except Kentico 😕

[kettanaito]

@ronaldruzicka probably I understand this wrong. Atomic design is just a set of mind that each page consists of smaller parts - components, each component consists of smaller parts - atoms. Parts should be reusable and should not rely on context.

Even BEM can be considered as Atomic approach, since it's aimed at designing small independent reusable modules. The thing you have described looks more like Tachyons, where there is a firm bind between class names and CSS (so in order to change something you would need to add/change/remove class names from a DOMElement). At least this is how I imagine Tachyons.

[vbulant]

It’s true that the word atomic is quite misleading. Let’s use low-level or functional CSS for methodologies like Tachyons.

[ronaldruzicka]

@kettanaito Yeah, it's just a misunderstanding of the terms, for me atomic design is what you mean by reusable components (atoms, components, molecules or whatever...) and atomic CSS is approach which takes utilities like classes, e.g. pt-10, bg-white, like Tachyons. 🙂

[kettanaito]

@ronaldruzicka @vbulant I am sorry, indeed, I understood it wrong. Thanks for explaining :)

[DavidSlavik]

Hello, regarding to commucation in my team I deleted critical css from default layout page. Mostly we don't need this feature. We will solve it ad hoc.