Chrome打算改变 的加载方式，当 link 出现在
中时，就变得非常明显了。在blink-dev的文章中，它的影响和性能尚不明确，所以我想在这里深入讲讲。<head> <link rel="stylesheet" href="/all-of-my-styles.css"></head><body> …content…</body>
CSS会阻塞渲染，用户需要等待 all-of-my-styles.css 整个加载完，否则屏幕一直是白色的。
一个网站的CSS样式分成一个两个文件存放是非常正常的，也就是说用户必须额外加载一大堆的并不会应用于当前页面的样式规则。因为网站会包含很多类型的页面，其中包含的“组件”也非常多，在组件级别整理CSS文件的话，对于HTTP/1协议会影响性能。
对于SPDY和HTTP/2来说则并非如此，许多小规模的资源可以以较小的开销生成，以及独立缓存。
<head> <link rel="stylesheet" href="/site-header.css"> <link rel="stylesheet" href="/article.css"> <link rel="stylesheet" href="/comment.css"> <link rel="stylesheet" href="/about-me.css"> <link rel="stylesheet" href="/site-footer.css"></head><body> …content…</body>
这解决了冗余加载的问题，但意味着你需要先知道：当你输出
时，页面将包含什么内容，可以防止streaming。另外，浏览器在渲染页面内容之前，还是需要先下载所有的CSS文件。一个 loading /site-footer.css 文件的缓慢加载，就可以导致页面所有内容的渲染延迟。查看DEMO
<head> <script> // https://github.com/filamentgroup/loadCSS !function(e){"use strict" var n=function(n,t,o){function i(e){return f.body?e():void setTimeout(function(){i(e)})}var d,r,a,l,f=e.document,s=f.createElement("link"),u=o||"all" return t?d=t:(r=(f.body||f.getElementsByTagName("head")[0]).childNodes,d=r[r.length-1]),a=f.styleSheets,s.rel="stylesheet",s.href=n,s.media="only x",i(function(){d.parentNode.insertBefore(s,t?d:d.nextSibling)}),l=function(e){for(var n=s.href,t=a.length;t--;)if(a[t].href===n)return e() setTimeout(function(){l(e)})},s.addEventListener&&s.addEventListener("load",function(){this.media=u}),s.onloadcssdefined=l,l(function(){s.media!==u&&(s.media=u)}),s} "undefined"!=typeof exports?exports.loadCSS=n:e.loadCSS=n}("undefined"!=typeof global?global:this) </script> <style> /* The styles for the site header, plus: */ .main-article, .comments, .about-me, footer { display: none; } </style> <script> loadCSS("/the-rest-of-the-styles.css"); </script></head><body></body>上面的代码中，有一些内联样式使得我们可以进行快速的初始渲染，然后隐藏我们还没有加载样式的内容，接着使用JavaScript异步加载剩下的CSS。剩下加载的CSS会重写 .main-article 中的 display: none 。
这种方法是 性能方面 的 专家 建议 的，以获得快速的初始渲染，也不无道理：
查看DEMO
在现实世界中，我做了这个 wiki-offline ，是有效果的 ：
在3g网络中，初始渲染快了0.6秒。完整的结果 前 对比结果 后 对比。
但也有一些不足：
不幸的是，这是由于WebKit的实现情况。一旦页面加了 ，WebKit会阻塞渲染，直到样式表加载完成，即使是通过JavaScript加载样式表。
在Firefox和IE/Edge中，通过JS加载样式表是完全异步的。稳定版的Chrome目前还是WebKit的方式，但在Chrome的Canary版本中，我们切换成了和Firefox/Edge一样的方式。
在上面的模式中，内联CSS使用 display:none 隐藏没有样式的内容，然后异步加载CSS来解决。如果你的CSS文件多于两个或者更多，它们可能不会按照顺序加载，这会导致加载过程中内容错乱：
查看DEMO
内容错乱，还带有 弹出式广告 ，是非常糟糕的用户体验。
因为你被限制了只能在两个阶段加载，你必须选择第一次渲染加载什么，然后再加载什么。你当然希望“显眼”的内容被快速渲染，但是“页面排版”是依赖于窗口的。相当艰难，你必须选择一个适合所有情况的解决方案。
更新：如果你想要让事情变得复杂，你可以使用CSS自定义属性建立一个类似渲染依赖树的东西，这里有一篇使用自定义属性控制CSS加载的 文章 。
<head></head><body> <!-- HTTP/2 push this resource, or inline it, whichever's faster --> <link rel="stylesheet" href="/site-header.css"> <header>…</header> <link rel="stylesheet" href="/article.css"> <main>…</main> <link rel="stylesheet" href="/comment.css"> <section class="comments">…</section> <link rel="stylesheet" href="/about-me.css"> <section class="about-me">…</section> <link rel="stylesheet" href="/site-footer.css"> <footer>…</footer></body>
这个方法是，对于每个 ，加载样式表时，阻塞渲染其后续内容，但允许在它之前的内容先渲染。样式表是并行加载的，但是按照顺序应用。这样 也变得和 有点像了。
我们来看看如果上面这个网站的标题header，正文内容article和footer，这些内容的CSS先加载，然后其它的挂起，页面结果会如何：
这是一个顺序渲染的页面。你不需要决定什么内容是“明显位置”，只需要在页面组件实例化之前引入该组件的CSS即可。它完全兼容streaming，因为你不需要输出 ，直到你需要它。
当使用内容决定布局的布局系统（如表格和flexbox）时，你需要注意避免加载过程中内容错位。这并不是新出现的问题，但渐进式渲染会导致这个问题更频繁地暴露。你可以hack flexbox来解决，但是CSS grid对于整体页面布局是 更好的系统 （flexbox对于较小组件依旧是非常棒的）。
HTML规范 没有包含页面被CSS阻塞时如何渲染，它不鼓励在 body 中写 ，但是所有的浏览器都允许这一写法。当然，浏览器都有自己解决 body 中的 link 的方式。
在Chrome，我们也喜欢IE/Edge的行为，所以我们将向它看齐。也就是上面描述的CSS渐进式渲染的模式。我们正努力把它变为标准，从允许
中加入 开始。目前，Chrome/Safari的行为是向下兼容，它只会阻塞它需要的渲染时间更长。Firefox的行为稍微复杂，但有一个解决方法...
因为Firefox并不经常因为 body 中的 link 阻塞渲染，我们需要解决它以避免FOUC。值得庆幸的是，这并不难，因为
