CSS 加载新方式（css3有哪些新特性）-睿象云平台

Chrome 浏览器有意改变的加载方式，当其出现在中时，这一变化将更加明显。笔者决定在本文中进行详细说明这种改变可能带来影响与好处。

CSS 会阻碍渲染，因此在all-of-my-styles.css全部加载完之前，用户就只能面对一片空白的屏幕。

通常，我们将某个站点的所有 CSS 样式合并为一到两个资源，这意味着用户会下载一堆当前页面根本就用不上的规则。这是因为网站可能包含许多不同类型的页面，每个页面都有自己的「组件」；而在组件级别传递 CSS 的话，会降低 HTTP/1 的性能。

然而，对 SPDY 和 HTTP/2 来说，事实却并非如此。在这些协议中，许多小资源只需要很小的代价就能完成递送，并且被独立缓存。

这样一来就解决了冗余问题，但也意味着你需要知道输出时页面将包含的内容，从而防止 streaming。与此同时，浏览器还是只能等待所有 CSS 样式加载完毕，才能开始渲染。如果加载 /site-footer.css的速度不够快，就会耽误所有页面的渲染。

这个方法受到性能专家的推崇,他们认为这是快速完成初始渲染的好方法，并且经过实地测量确实在加载的时候快了不少。

这是由 WebKit 的实现方式造成的。一旦页面中添加了，即使样式表是由 JavaScript 加载的，WebKit 还是会在加载完成之前阻碍渲染。

在 Firefox 和 IE/Edge 浏览器中，通过 JS 加载样式表是完全异步进行的。稳定版本的 Chrome 浏览器是通过 WebKit 的方式加载的，但在 Canary 版本中，仍然是使用 Firefox/Edge 加载方式。

在上述模式中，内联的 CSS 通过display:none隐藏了没有加载完样式的内容，直到异步加载完剩余的 CSS 样式。如果你将这些样式分派到两个或多个 CSS 文件中，这些文件有可能不按照顺序加载，导致加载过程中出现内容错乱：

既然有两个加载阶段，你就必须决定渲染的先后顺序。你当然会想首先渲染「位置显要」的内容。但是，所谓的「位置」是根据窗口大小来决定的。因此，问题来了，你得找出一把「万能」钥匙。

…

计划是这样的：针对每个，加载样式表时我们阻止渲染它的后续内容，但是允许渲染它之前的内容。样式表是并行加载的，但是按照一定的顺序显示。这使得的效用与相近。

假设网站 header、正文和 footer 的 CSS 已经加载完毕，但其余内容仍在等待，那么页面会是这样的：

Header：已渲染正文：已渲染评论部分：未渲染，它前面的 CSS 还未被加载（/comment.css）。关于本站：未渲染。它前面的 CSS 还未被加载（/comment.css）。Footer：未渲染。尽管它本身的 CSS 已加载完成，但它前面的 CSS 还未被加载（/comment.css）。

这是一个按顺序渲染的页面。你不需要决定哪部分内容在「显要位置」，只要在页面组件第一次实例化之前引入该组件的 CSS 即可。它完全兼容 Streaming，因为除非你需要，否则不必要输出。

当使用内容决定布局的布局系统时（例如表格和 flexbox），要注意避免加载时出现内容错位。这不是什么新问题了，但是分步渲染会使得它出现得更为频繁。你可以通过 hack flexbox 来解决，但对整体页面布局来说，使用 CSS grid 工具效果更佳（不过对小一些的组件来说，flexbox 还是很棒的）。

Chrome和Safari：一旦发现就停止渲染，并且在已发现的样式表全部完成加载之前不会开始渲染。这会导致前未被渲染的内容也被阻塞。Firefox：head中的会阻塞渲染，直至所有已发现的样式表加载完毕，body中的并不阻塞任何渲染，除非某个 head 中的样式表已经阻塞了渲染，这会导致无样式的内容出现闪烁（FOUC）。IE/Edge：阻塞解析器直到样式表加载完毕，但是允许渲染之前的内容。

在 Chrome 团队，我们喜欢 IE/Edge 的方式，所以打算跟它看齐。这就允许上文描述的渐进式 CSS 渲染方式。我们正在努力把它变成标准，从允许中的开始。

目前 Chrome/Safari 采用的方式是向下兼容的，带来的问题是阻塞渲染的时间比实际需要的长。Firefox 的方式稍微复杂一些，但有个解决的方法：

因为 Firefox 并不总是为了中的阻塞渲染，我们得为这个多花点功夫来避免 FOUC。谢天谢地这很容易，因为

…