Defer unused CSS @ Google's Lighthouse

Defer unused CSS @ Google's Lighthouse

The biggest challenge under the former PageSpeed Insights test has been completely annulled as the PageSpeed Insights uses the Lighthouse engine nowadays.

At the beginning of 2018, webshop and website owners had to deal with a sudden change in their pagespeed-score in Google’s PageSpeed Insight. The change emphasised even more the importance of the First Contentful Paint, where code that is responsible for styling below the fold is loaded asynchronously. This method prevents that the browser will have to wait before “painting” the screen of a potential client.

The new situation

Since Google started using the Lighthouse engine for their PageSpeed scoring , this factor has been completely lapsed. The score still takes into account the asynchronous loading of CSS, or as it is also called: "Defer unused CSS". That this denominator can be confusing, is illustrated by a github issue that has been submitted within the Lighthouse project.

Beside of this test, Google recommends that everything "Above the Fold" has to be properly painted through CSS styling. Using this method, the user will experience a faster responding website. By using techniques that optimizes performance, websites and booking systems can experience a dramatic increase in their conversion, resulting in possible millions more revenue.

Unstyled page

However, this “Defer unused CSS” criterium does not take into account the latter. In other words: you can present the page primarily in a style-free manner, with which it looks as if the website is completely 'broken'. Then you can load all styling asynchronously, at which point the styling will be applied. This creates a flickering effect in styling, but is not punished by Google.

Deferred demo

As an illustration, I created a demo page, where the styling kicks in with a delay of one second. This way, an unstyled page is presented initially. While this provides no issues within the Lighthouse-test, this is off course un undesired effect which you do not want to serve to your potential customers.

> Deferred demo

Defer techniques

One technique that our LightBolt CMS used to apply was the asynchronous loading of the entire style sheet. Everything "Above the fold" was already drawn in advance. This technique would only be applied to the first page hit within a session. After that moment the technique of painting above the fold in advance, would work counterproductively, as the stylesheet has been cached already (this would increase the content-download and advantage of caching would be cancelled).

I have set up a demo for this. The main CSS has already been loaded. The buttons are deliberately unstyled. After a second delay, they will be completely styled using CSS. Making use of this technique is recommended for content that is below the fold, not yet visible by users within the first second(s).

> Critical CSS Demo

Unfortunately, the Lighthouse performance analysis would yield you a percentage point deduction for this technique. That is because the Lighthouse-test doesn't treat itself as first time pagehit within a session. As a result, the use of this technique is not discovered by Lighthouse. Nevertheless it still works, once cached, it provides a quick page. This can be experienced when one would navigate to the “undeferred” demo page:

> Undeferred demo

Defer solution for Lighthouse

In order to continue taking advantage of caching and limit the time it takes for content download, we have chosen to continue using this technique. Although it is primarily a shortcoming of the Lighthouse analysis, we have found a work-around for this.

We have been able to provide our LightBolt CMS with a subtle feature in which both the Lighthouse analysis and the visitor interests are met. On this website you can already see the feature in action. During a subsequent page visit within a session, the entire style sheet is loaded asynchronously. This results in a white page. To work around this, we used an implementation that is also used by Google's AMP.

Invisible to visible

The entire web page is primarily served completely transparent, via the CSS opacity property. As soon as the stylesheet kicks in, this transparency is cancelled using CSS animation. Because the stylesheet was already cached during the first visit, no-one will notice a delay, only experiencing the animation. The animation from 100% transparency (invisible) to 0% transparency (visible) takes place over a period of 0.1 seconds. The web page is thus smoothly visualized and therefore continues to feel fast.

> Opacity demo

In this demo we intentionally increased the animation duration to 0.5 seconds, to be able to illustrate the effect.

More about opacity:

Summary: Defer unused CSS

All demo pages will achieve the 100% performance score. Therefore, we can state that this technique does not influence the Lighthouse performance score. The main purpose to use this technique is to provide a sense of speed and reaction time for your visitors.

If you are the owner of a more extensive website, which involves more styling, repeatedly inlining (demo) of CSS is not a recommended best practice. This will result in an increase in kilobytes, data traffic and even load time, which would be an undesired effect.

Undeferred CSS (demo) can be practical for subsequent visits, but will be penalized by Lighthouse performance analysis in the case of larger websites. Deferred CSS (demo)without primary styling is also not a solution, as it will result in an unstyled webpage.

By playing with visibility / CSS opacity (demo), you can satisfy both visitors and the Lighthouse analysis. Ideally however, I would like to see that the Lighthouse-analysis will adept to handle first time-visit within a session and subsequent visits, so that the undeferred solution can be deployed without penalties.