In a recent article on Medium, JP DeVries wrote about “Unfolding Critical CSS“.
Are you building a single web page that users will visit once never to return to or are you building a multi–page website that most users click around on for a while?
If you inline an average of ~20kB of critical CSS on each page and a user visits 10 pages that make use of those same styles you’ve served them 180kb of avoidable weight. That’s ~20kB of the same uncacheable non–blocking styles being downloaded 10 times (once for each page) vs ~20kB of blocking styles being downloaded once as part of a common stylesheet. The number of average page views per user should be taken into consideration when architecting your CSS delivery method.
CriticalCSS is something that I’ve been HUGELY in favour of since it was first suggested through the Filament Group (citation needed). Since then I’ve showed clients many times how much faster we can make their website appear by loading the Critical CSS in the head…. although I leave off the how and just show them the results.
The point about the 20kb of additional critical CSS of subsequent page requests is a really good argument, that can really add up over many visits. I will say though that the idea is to get the first part of the “fold” within the first 14kb of the entire HTML document, so we’re not really talking about 20kb of additional content (although the argument still holds fast just with less kb).
The better approach is to send the critical CSS in the head through on the first visit, download the full CSS file, set a cookie, and then include the tag back in the head to replace the critical CSS.
This does require some configuration on what the server is generating and might not be as straight forward for some sites, and it can have additional complications around CDN’s and caching URI’s as well…. but then the web is just getting more and more complicated these days.
2 comments