I wanted to figure out the fastest way to load non-critical CSS so that the impact on initial page drawing is minimal.
TL;DR: Here's the solution I ended up with: https://github.com/filamentgroup/loadCSS/
For async JavaScript file requests, we have the async
attribute to make this easy, but CSS file requests have no similar standard mechanism (at least, none that will still apply the CSS after loading - here are some async CSS loading conditions that do apply when CSS is inapplicable to media: https://gist.github.com/igrigorik/2935269#file-notes-md ).
Seems there are a couple ways to load and apply a CSS file in a non-blocking manner:
- A) Use an ordinary
link
element to reference the stylesheet, and place it at the end of the HTML document, after all the content. (This is what Google recommends here https://developers.google.com/speed/docs/insights/PrioritizeVisibleContent ) - B) Fetch it asynchronously with some inline JavaScript from the
head
of the page, by appending alink
element to page dynamically. (To ensure it's async, I'm setting thelink
's media to a non-applicable media query, then toggling it back after the request goes out).
I suspected B
would initiate the request sooner, since A
would be dependent on the size of the content in the document - parsing it in entireity before kicking off the request.
In this case, sooner would be ideal to reduce impact on our page load process, since there could be minor reflows that are triggered by the styles in the non-critical CSS file (ideally, the critical CSS would have all reflow-triggering styles in it, but that so far, that's been hard to pull off across the breakpoints of a responsive design, and given that the initial inlined CSS should be kept very small to fit into the first round trip from the server).
I made some test pages, and they do seem to confirm that B will load the CSS sooner (B
requests the css file after around 60-70ms
whereas A
usually requests it around 130-200ms
). It's consistently about twice as fast.
- Demo A (static
link
at end of page): http://scottjehl.com/test/loadingcss/fromhtml.html - Demo B (dynamically loaded
link
): http://scottjehl.com/test/loadingcss/fromscript.html
B comes with the additional benefits of qualifying the request based on whatever conditions we care to test too, which is nice.
- Update noted here: https://gist.github.com/scottjehl/87176715419617ae6994#comment-1243423
- Another note: @adactio helpfully pointed out that the approach would be a bit better if the non-critical CSS still loaded for non-JS environments. Wrapping a
link
to that file in anoscript
tag and placing it at the end of the page would be a nice way to address that. - Update: loadCSS has its own home now! https://github.com/filamentgroup/loadCSS/
@woeldiche, @shshaw All our projects use a very modular, component based Sass structure, from which we are able to build a critical.css file (inlined in the head), a base.css file (global styles) and then, if required, the styles for particular page types.
For example, we do a lot of ecommerce sites - if we know that a specific component is only used on Product Pages then it goes in product-page.css.
Yes this adds one more http request, but the files are loaded asynchronously and once the browser has that file it's cached. Plus this also massively reduces redundancy - I tested one of our, non-optimised sites the other day and 85% of the styles in main.css weren't being used.
Of course these CSS loading techniques aren't the only facet involved in optimising the critical rendering path, but we've seen our optimised sites conversion rates shoot up after implementation - making for very happy clients! :)