CSS asynchronous loading technology does not affect page rendering_html/css_WEB-ITnose

This article demonstrates a technique that downloads style sheets asynchronously to prevent their download from blocking the rendering of the page, thereby allowing visitors to obtain information content as quickly as possible.

Warning! I post this with good intentions, but it is not responsible for making people who read it aware of the problems that will be encountered below. The community quickly gave me a lot of feedback (some feedback I'm grateful), and it became increasingly obvious that the technology wasn't as stable as I'd hoped. Rather than having as much success testing and exploiting it as I had, many developers were experiencing it in both IE and Firefox. issues (crash outright in FF beta) while others report success in Chrome and Safari. My advice right now: don't use it for products. I plan to address this feedback and update this article with any relevant information.

The principles behind these techniques are not new. For example, the Filament technical group has published a lot of content about loading CSS and fonts. I wrote this article to record my thoughts and opinions on loading non-blocking resources.

The trick to trigger asynchronous style downloading is to use a element and set an unavailable value for the media attribute (I used media="none", but any other value is also acceptable ). When a media query evaluates to false, the browser will still download the style sheet, but will not wait for the style sheet resources to be available before rendering the page.

Once the stylesheet is downloaded, the media attribute must be set to a usable value , so that the style rules can be applied to the html document, the onload event can be used to switch the media attribute to all:

This method of loading CSS will deliver useful information to visitors much faster than the standard method. Crucial CSS can still be loaded in the usual blocking way (or you can handle it inline for ultimate performance), while non-critical styles can be slowly downloaded and rendered during the parsing/rendering process. It will be applied at a later stage.

This technique uses JavaScript, but you can also encapsulate an equivalent blocking element in a

This technique has a side effect. When a non-blocking style sheet finishes loading, the document is redrawn to reflect any new style rules it defines. Injecting new styles into the page will trigger content reflow, but this will only be a problem during the first load of the page without historical cache. As with anything related to performance, you're going to want to make the necessary adjustments when the need to control the cost of a reflow outweighs the potential speed advantage.

Use non-blocking CSS to load fonts

The performance of the first draw of fonts is an issue, they are blocking resources and will make the text they are applied to The font is not visible when downloaded. Using the non-blocking link in the above example, it is possible to download the stylesheet containing the font data behind the scenes without blocking the rendering of the pressed surface:

font.css Contains a base64-encoded WOFF version of the Merriweather font.

@font-face { font-family: Merriweather; font-style: normal; font-weight: 400; src: local('Merriweather'), url('data:application/x-font-woff ;charset=utf-8;base64,...')}

main.css contains all the style rules that need to be applied to the site. The following is the declaration of the font:

body { font-family: Merriweather, "Lucida Grande", ...;}

When the font is being downloaded, the first matching backup response The back font (in this case Lucida Grande) is used to render the content of the page. Once the font stylesheet is applied, Merriweather is used. I try to ensure that the fallback font shares similar layout characteristics to the preferred font, so that the inevitable reflow is as subtle as possible.

I tested blocking versus non-blocking using my Google Analytics Debugger site in Chrome over a simulated 3G network connection. The local test produced the network diagram shown below; note that DOMContentLoaded is triggered 450ms earlier, and the resource downloads faster after using non-blocking technology:

Graphics that simulate 3G networks. Blocked font is shown at the top. The bottom shows non-blocking fonts.

Deploy it to a test server and run it on a 3G connection. The webpagetest construct produces the following timeline:

3G timeline. Blocking fonts are displayed at the top and non-blocking fonts are displayed at the bottom.

Both methods took 2.8 seconds to completely render the page, but the non-blocking method drew 1 second earlier than the normal blocking method. Running the same test with the main stylesheet inline shows a 0.7 second time advantage when non-blocking CSS is applied to handle fonts:

3G timeline of main CSS content . Displays blocking fonts at the top and non-blocking fonts at the bottom.

This technique works really well for fonts, but I also recommend keeping an eye on the new CSS font loading module, which will give us more control over font loading.

Summary

Loading fonts is an example of applying non-blocking techniques, but it can also be used for other purposes, such as separating JavaScript from core CSS Enhanced styling.

I've started to experiment with the idea of ​​splitting styles into frames (core layout) and presentation (everything else), which would allow important page layouts to block page rendering, while visible style data is delayed for a while .