This article demonstrates a technique that downloads style sheets asynchronously to prevent their download from blocking the rendering of the page as much as possible Let visitors get information quickly.

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 (direct crash 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 team 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 will also work ). 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.

<link rel="stylesheet" href="css.css" media="none">

Once the style sheet 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:

<link rel="stylesheet" href="css.css" media="none" onload="if(media!='all')media='all'">

This method of loading CSS will deliver useful information to your 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 technology 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 first draw performance of fonts is an issue, they are blocking resources and will make the text they are applied to invisible while the font is 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 surface:

<link rel="stylesheet" href="main.css"><link rel="stylesheet" href="font.css" media="none" onload="if(media!='all')media='all'">

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. Here is the declaration for the font:

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

While the font is being downloaded, the first matching fallback font (in this case, Lucida Grande) is used to render the content of the page. . Once the font stylesheet is applied, Merriweather will be 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 graph as shown below; note that DOMContentLoaded is triggered 450ms earlier, and the resources are downloaded faster after using non-blocking technology:

Graphic of simulated 3G network. Blocked font is shown at the top. The bottom shows non-blocking fonts.

Deploying it to a test server and running the webpagetest construct on a 3G connection produced 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 decoupling JavaScript-enhanced styles from core CSS.

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 .

This article address: http://www.oschina.net/translate/loading-css-without-blocking-render

Original address: http://keithclark .co.uk/articles/loading-css-without-blocking-render/