Critical CSS

Hi, my name is Sergey Labozy, and I'm a software engineer at Focus Reactive. Over the past few years, I've spent a lot of time exploring web performance, and in this talk I want to share with you some insights on a key topic. Critical CSS, a powerful way to enhance user experience. In this talk we'll explore what critical CSS is, when to use it or not, how to implement it effectively, and some common challenges and use cases.

Before we jump into critical CSS, let's start at the very beginning. How a browser renders a page. This involves the critical rendering path, a sequence of steps the browser takes to convert HTML, CSS, and JavaScript into visible content on the screen. Let's break it down briefly. First, browser needs to make a request to get initial HTML. As soon as it receives the first HTML chunk, you start building the DOM, document object model. The browser finds the CSS and starts constructing the CSOM, CSS object model. When the DOM and CSOM are ready, the browser combines them into a render tree, which only includes the visible elements. Finally, the layout and paint steps occur and the content appears on the screen.

The main goal here is to render content as quickly as possible, but browsers have limited resources like time and CPU. Time is crucial, because we want the user to see the content as fast as possible, which is measured by a core vital metric called largest content to paint, or LCP. And given that everything happens in the user's browser, CPU usage is equally important, especially for mobile devices. Add to this varying network speeds and latencies. We also should mention JavaScript here. JavaScript can dynamically modify the DOM and CSOM. Manipulating the DOM and CSOM can be very slow. Not necessarily and not in all cases, but we won't go into that here, we just assume that we don't modify the DOM and CSOM with JavaScript.

With understanding of critical rendering path, let's get closer to why critical CSS matters. We've seen that the render tree needs both the DOM and the CSOM. However, unlike the DOM, the CSOM can't be built incrementally. Why? Because CSS is cascading, meaning the order of CSS rules affects their specificity. The last line of CSS could override all preceding styles. This is why the browser can't partially apply CSS. It must first download, parse, and understand the entire stylesheet to avoid flashes of unstyled content. How to Add CSS to HTML? There are two primary ways to add CSS to your HTML. Inline styles using style tags or external stylesheets using link tags.

Each has its trade-offs. When you use an external stylesheet via link tag, the browser must make an additional request to fetch it. This is often beneficial if you have a large amount of HTML and CSS, because the browser can load them in parallel. While the CSS is being fetched, the browser can keep building the DOM incrementally. However, there is a catch. CSS is render-blocked. The browser needs to wait for the stylesheet to finish loading before it can construct the render tree and display the page. If your stylesheet is large, this delay becomes noticeable.

The images show that HTML, blue, and CSS, purple, are loaded in parallel, but the CSS is blocking render. The rendering event, or the first conceptual paint, or FCP, occurs immediately after the CSS has finished loading. The first conceptual paint is colored green and highlighted with red borders. In this image we can see that reducing the size of the external stylesheet does not speed up rendering. We see that FCP is blocked by CSS and rendering occurs long after the document has fully loaded and parsed. If your CSS is small, the time it takes to send a new request can be comparable to the load time.

The idea behind critical CSS is to align only the styles needed to render the above-default content directly into the head section of your HTML document. This avoids the need for an additional HTTP request and reduces the time to render the first meaningful content. But there is a trade-off too. If you align too much CSS, you increase the size of your head section, which in turn delays the browser's ability to start building the render tree. The goal here is to find a spot where you align just enough CSS to render the visible portion of the page quickly while offloading less critical styles to external stylesheets that can be loaded asynchronously. Here is an example of critical CSS. In this image, we see that rendering occurs while the HTML is loading, and the external stylesheet is loaded in an unblocking manner. Let's summarize why critical CSS is important. With critical CSS, we reduced the size of render-blocking styles. Everything is delivered in one document, no additional stylesheets required. This speeds up initial rendering, also known as FCP, or First Contentful Paint. In some cases, LCP will also be better with critical CSS, if your LCP is text, and for images it depends on the image size. If the image is too big, the LCP will be delayed due to image loading time. And most important, better user experience, especially for mobile users with slow connections. There are several ways to identify critical CSS.

There are several ways to identify critical CSS. We can divide them into two groups, manual and automatic. Manual tools require a lot of copying and pasting. We won't go into these tools too much because of their inefficiency, but in a few words, you can identify critical styles yourself, simply by analyzing the rendered page. Developer tools can help in this. There are also some online tools that can help you extract important styles for a given URL.

Automatic tools, on the other hand, can be easily plugged into your build pipeline. There aren't many automatic tools for extracting critical CSS, and some of them are very old and appear to be abandoned. Critical CSS is not so popular, but we can name a few. Penthouse, Critical, and Besties. Penthouse, an npm package that helps to extract CSS for a given URL address, and CSS lines. There is no webpack support. Critical, an npm package that extracts and aligns critical CSS into HTML files, integrates well with build tools like Gulp and Webpack. Besties, former Critters, an npm package that automatically extracts and aligns critical CSS for your HTML. There is also a webpack plugin. Critical and Penthouse use a headless browser, but not Besties. Later we will see the results obtained using Besties and Critical.

What you need to extract your critical styles. Basically, you want simple HTML that is ready to be sent to the user. This HTML is usually the result of static site generation, or SSG. There is also another type of server rendering where pages are generated for each request. Usually referred to simply as server site rendering, or SSR. In this case, the HTML is usually not stored on the file system. This is not necessarily a problem, but this will increase the complexity and time of processing. Using CSS in JS libraries will also add complexity to critical styles optimization. And finally, hosting or environment limitations. Is the file system API available? Do you only have one server or several? Depending on this, this may also significantly increase the complexity and time required to complete the processing. What are the use cases for critical CSS? Critical CSS for static websites. This is the best used option. Site with statically generated pages.

More or less supported by all tools. There is one nuance with revalidation. Not all tools can be integrated into Webpack and support revalidation. Critical CSS for static website with CSS in JS. No tools have the full support of CSS in JS. We need to add some extra steps to optimize it. This depends on the tool we use, but usually it involves connecting the inline styles into a single external stylesheet.

Dynamic websites. By dynamic websites we mean sites that generate pages for each user request or simply sites with SSR. It may be difficult to integrate critical CSS on this site. Moreover, after adding optimization, you can realize that this optimization slows down your site. The extraction of critical CSS takes some noticeable time and increases the load on your server. We also need a mechanism to apply critical styles at runtime or fall back to default styles for unoptimized pages. Beasties or Critters, for example, is supported by Next.js as an experimental feature.

How to check the effect of critical CSS? To understand how performance changes, we must measure before and after we apply critical CSS. What to measure? We expect better initial rendering or FCP. In some cases, LCP may be better. Where to measure? The Lighthouse in the Chrome browser is always at hand and is most famous. It also has a cloud version at PageSpeed WebDev. But sometimes the results can vary. Chrome Performance tab is better for testing. You can change network and CPU conditions, change viewport, etc. The results are more stable compared to the Lighthouse. WebPageTest.org is another option. It has more detailed results. Can be selected from several network options, screen and locations. One important note here. Results should only be compared with results from the same tool. In this table, we can compare the results. We used two tools to extract critical CSS for the same page.

Criticals and BISTIs. The page contains only external stylesheets. The total size of the styles is about 240 kilobytes.

In the first column, we have auto inline. It is a feature that automatically inlines critical styles into the head section. Both tools have this feature.

Second column is processing time. It is the time it takes to process one page. We see a huge difference. 330 milliseconds versus 17 seconds.

Third column is critical size. It is the size of the extracted critical styles. Both tools extract styles of the same size. This is an interesting result, as we would expect the styles extracted for BISTIs to be larger.

Next column is needs additional steps or config. Here we see that critical do not need additional actions, but BISTIs do. I'll comment on the asterisks a bit later.

And the final column is defer non-critical styles. Critical has this feature, but BISTIs doesn't seem to.

FCP and LCP correspond to the same element on this page, a text node. If all styles are loaded via external stylesheet, then the initial time is about 2 seconds. If all styles are inlined in the head tag, the initial time will be roughly 1 second. The time after optimization is 820 milliseconds.

Let's comment on asterisks. What additional steps or settings might be required for BISTIs? Potential issue with fonts. Font styles are not fully extracted and embedded, therefore this might cause an additional late LCP event when loading the full stylesheet. Even though nothing has changed from the user's perspective, additional work would be required to correct this problem. Also, BISTIs don't seem to defer non-critical styles. This sounds like a problem, but we can solve it by adding some additional logic to modify the HTML. Also, it seems that if we combine both approaches, inline critical CSS and loading full styles as external stylesheets, external stylesheets will not block rendering.

Instead, the first rendering will occur when external stylesheets are loaded. So, it shouldn't be that much of a problem anyway.

Now that you see the timings, we can draw some conclusions. We compared two of the best working tools. And, while BISTIs may require some extra handling for some edge cases, it makes up for it with better performance.

This time, for processing one page, you can calculate and find out how long it will take to process all of your pages. This time will be added to your built pipeline. If you have a revalidation or SSR, then this time is taken from your server time. This can interfere with the normal operation of the server. And instead of improving performance, you can get a deterioration in performance.

For example, for critical. We simply specify the path of the HTML and all involved CSS files and the size of the viewport. For example, for BISTIs. It's pretty much the same. One important difference is that we don't specify viewport, which means we extract critical styles for the entire page.

What problems can arise with critical styles? Over-inlining too much CSS. While in some cases inlining full CSS will provide some performance gains, this is not always the case. A large number of styles in the head will delay rendering, and this will happen all the time. While external styles can be cached. And only the first visit may be slower. Subsequent visits will have much faster rendering.

Critical CSS will give you a bigger performance boost. Forgetting to load the first styles. This is an essential part of critical CSS. Split the source styles into two parts critical and non-critical. Then load the critical ones with the highest priority and non-critical ones synchronously. Style order is wrong. Specificity issue. The problem may occur if you do not preserve the order of styles. Runtime optimization impacts performance.

Sometimes optimization can take too much server time and therefore degrade performance. Style extraction must be performed on every render. This is important. You can't extract critical styles just once and reuse them for subsequent renders. Something might change. Some elements that were previously hidden might become visible. And you won't hope this. You won't have these styles on your critical CSS.

In that case, you might have a flush performance style content. You need to extract styles for each render. You can detect a new version of a page by the e-tag header. Or by checking the page hash. Client-side rendering. Critical CSS optimization only applies to the server side. If you have both server rendering and client rendering, and those renders are different, you cannot safely use this optimization.

So, to sum up, critical CSS is all about finding a balance. It's about understanding the critical rendering path, the role of CSS, and the trade-offs between inline and external styles. By inlining critical CSS, you can reduce rendering times and enhance the user experience. Especially on slower networks or low-power devices. But critical CSS comes with a cost. While critical CSS is useful in almost all cases, it is not always easy to implement. Processing also takes time. Although it is possible to process pages at run time, it is recommended to avoid this and perform most optimization at build time. Thank you for listening. I hope this gave you some insights on how browsers render pages, the role of CSS, and when to consider implementing critical CSS.