让网页展现的更快，官方说法叫做首屏绘制，First Paint 或者简称 FP，直白的说法叫做白屏时间，就是从输入 URL 到真的看到内容（不必可交互，那个叫 TTI, Time to Interactive）之间经历的时间。当然这个时间越短越好。

但这里要注意，和首屏相关的除了 FP 还有两个指标，分别称为 FCP (First Contentful Paint，页面有效内容的绘制) 和 FMP (First Meaningful Paint，页面有意义的内容绘制)。虽然这几个概念可能会让我们绕晕，但我们只需要了解一点：首屏时间 FP 并不要求内容是真实的，有效的，有意义的，可交互的。换言之，随便给用户看点啥都行。

这就是本文标题的玄机了：“看起来”。是的，只是看起来更快，实际上还是那样。所以本文并不讨论性能优化，讨论的是一个投机取巧的小伎俩，但的确能够实实在在的提升体验。打个比方，性能优化是修炼内功，提升你本身的各项机能；而本文接下来要讨论的是一些招式，能让你在第一时间就唬住对手。

这所谓的招式就是我接下来要谈的内容，学名骨架屏，也叫 Skeleton。你可能没听过这个名字，但你不可能没见过它。

骨架屏长什么样

这种应该是最常见的形式，使用各种形状的灰色矩形来模拟图片和文字。有些 APP 也会使用圆形，但重点都是和实际内容结构近似，不能差距太大。

如果追求效果，还可以在色块表面添加动画（如波纹），显示出一种动态的效果，算是致敬 Loading 了。

在图片居多的站点，这将会是一个很好的体验，因为图片通常加载较慢。如上图演示中的占位图片采用了低像素的图片，即大体配色和变化是和实际内容一致的。

如果无法生成这样的低像素图片，稍微降级的方案是通过算法获取图片的主体颜色，使用纯色块占位。

再退一级，还可以使用全站相同的站位图片，或者直接一个统一颜色的色块。虽说效果肯定不如上面两种，但也聊胜于无。

骨架屏完全是自定义的，想做成什么样全凭你的想象。你想做圆形的，三角形的，立体的都可以，但“占位”决定了它的特性：它不能太复杂，必须第一时间，最快展现出来。

骨架屏有哪些优势

大体来说，骨架屏的优势在于：

在页面加载初期预先渲染内容，提升感官上的体验。
一般情况骨架屏和实际内容的结构是类似的，因此之后的切换不会过于突兀。这点和传统的 Loading 动图不同，可以认为是其升级版。
只需要简单的 CSS 支持 (涉及图片懒加载可能还需要 JS )，不要求 HTTPS 协议，没有额外的学习和维护成本。
如果页面采用组件化开发，每个组件可以根据自身状态定义自身的骨架屏及其切换时机，同时维持了组件之间的独立性。

骨架屏能用在哪里

现在的 WEB 站点，大致有两种渲染模式：

前端渲染

由于最近几年 Angular/React/Vue 的相继推出和流行，前端渲染开始占据主导。这种模式的应用也叫单页应用（SPA, Single Page Application）。

前端渲染的模式是服务器（多为静态服务器）返回一个固定的 HTML。通常这个 HTML 包含一个空的容器节点，没有其他内容。之后内部包含的 JS 包含路由管理，页面渲染，页面切换，绑定事件等等逻辑，所以称之为前端渲染。

因为前端要管理的事情很多，所以 JS 通常很大很复杂，执行起来也要花较多的时间。在 JS 渲染出实际内容之前，骨架屏就是一个很好的替补队员。

后端渲染

在这波前端渲染流行之前，早期的传统网站采用的模式叫做后端渲染，即服务器直接返回网站的 HTML 页面，已经包含首页的全部（或绝大部分） DOM 元素。其中包含的 JS 的作用大多是绑定事件，定义用户交互后的行为等。少量会额外添加/修改一些 DOM，但无碍大局。

此外，前端渲染的模式存在 SEO 不友好的问题，因为它返回的 HTML 是一个空的容器。如果搜索引擎没有执行 JS 的能力（称为 Deep Render），那它就不知道你的站点究竟是什么内容，自然也就无法把站点排到搜索结果中去。这对于绝大部分站点来说是不可接受的，于是前端框架又相继推出了服务端渲染（简称 SSR, Server Side Rendering）模式。这个模式和传统网站很接近，在于返回的 HTML 也是包含所有的 DOM，而非前端渲染。而前端 JS 除了绑定事件之外，还会多做一个事情叫做“激活”（hydration），这里就不再赘述了。

不论是传统模式还是 SSR，只要是后端渲染，就不需要骨架屏。因为页面的内容直接存在于 HTML，所以并没有骨架屏出场的余地。

骨架屏怎么用

讨论了一波背景，我们来看如何使用。首先先无视具体的实现细节，先看思路。

实现思路

大体分为几个步骤：

往本应为空的容器节点内部注入骨架屏的 HTML。

骨架屏为了尽快展现，要求快速和简单，所以骨架屏多数使用静态的图片。而且把图片编译成 base64 编码格式可以节省网络请求，使得骨架屏更快展现，更加有效。

<html>
    <head>
        <style>
            .skeleton-wrapper {
                // styles
            }
        </style>
        <!-- 声明 meta 或者引入其他 CSS -->
    </head>
    <body>
        <div id="app">
            <div class="skeleton-wrapper">
                <img src="data:image/svg+xml;base64,XXXXXX">
            </div>
        </div>
        <!-- 引用 JS -->
    </body>
</html>

在执行 JS 开始真正内容的渲染之前，清空骨架屏 HTML

以 Vue 为例，即在 mount 之前清空内容即可。

let app = new Vue({...})
let container = document.querySelector('#app')
if (container) {
    container.innerHTML = ''
}
app.$mount(container)

仅此两步，并不牵涉多么复杂的机制和高端的 API，因此非常容易应用，赶快用起来！

示例

我编写了一个示例，用于快速展现骨架屏的效果，代码在此。

index.html

默认包含了骨架屏，并且内联了样式（以 <style> 标签添加在头部）。
render.js

它负责创建 DOM 元素并添加到 <body> 上，渲染页面实际的内容，用来模拟常见的前端渲染模式。
index.css

页面实际内容的样式表，不包含骨架屏的样式。

代码的三个文件各司其职，配合上面的实现思路，应该还是很好理解的。可以在这里查看效果。

因为这个示例的逻辑太过简单，而实际的前端渲染框架复杂得多，包含的功能也不单纯是渲染，还有状态管理，路由管理，虚拟 DOM 等等，所以文件大小和执行时间都更大更长。我们在查看例子的时候，把网络调成 "Fast 3G" 或者 "Slow 3G" 能够稍微真实一些。

但匪夷所思的是，对着这个地址刷新试几次，我也基本看不到骨架屏（骨架屏的内容是一个居中的蓝色方形图片，外加一条白色横线反复侧滑的高亮动画）。是我们的实现思路有问题吗？

浏览器的奥秘：减少重排

为了排除肉眼的遗漏和干扰，我们用 Chrome Dev Tools 的 Performance 工具来记录刚才发生了什么，截图如下：（截图时的网络设置为 "Fast 3G"）

我们可以很明显地看到 3 个时间点：

HTML 加载完成了。浏览器在解析 HTML 的同时，发现了它需要引用的 2 个外部资源 index.js 和 index.css，于是发送网络请求去获取。
获取成功后，执行 JS 并注册 CSS 的规则。
JS 一执行，很自然的渲染出了实际的内容，并应用了样式规则（随机颜色的横条）。

我们的骨架屏呢？按照预想，骨架屏应该出现在 1 和 2 之间，也就是在获取 JS 和 CSS 的同时，就应该渲染骨架屏了。这也是我们当时把骨架屏的 HTML 注入到 index.html，还把 CSS 从 index.css 中分离出来的良苦用心，然而浏览器并不买账。

这其实和浏览器的渲染顺序有关。

相信大家都整理过行李箱。我们在整理行李箱时，会根据每个行李的大小合理安排，大的和小的配合，填满一层再放上面一层。现在突然有人跑来跟你说，你的电脑不用带了，你要多带两件衣服，你不能带那么多瓶矿泉水。除了想打他之外，为了重新整理行李箱，必然需要把整理好的行李拿出来再重新放。在浏览器中这个过程叫做重排 (reflow)，而那个馊主意就是新加载的 CSS。显而易见，重排的开销是很大的。

熟能生巧，箱子理多了，就能想出解决办法。既然每个 CSS 文件加载都可能触发重绘，那我能不能等所有 CSS 加载完了一起渲染呢？正是基于这一点，浏览器会等 HTML 中所有的 CSS 都加载完，注册完，一起应用样式，力求一次排列完成工作，不要反复重排。看起来浏览器的设计者经常出差，因为这是一个很正确的优化思路，但应用在骨架屏上就出了问题。

我们为了尽早展现骨架屏，把骨架屏的样式从 index.css 分离出来。但浏览器不知道，它以为骨架屏的 HTML 还依赖 index.css，所以必须等它加载完。而它加载完之后，render.js 也差不多加载完开始执行了，于是骨架屏的 HTML 又被替换了，自然就看不到了。而且在等待 JS, CSS 加载的时候依然是个白屏，骨架屏的效果大打折扣。

所以我们要做的是告诉浏览器，你放心大胆的先画骨架屏，它和后面的 index.css 是无关的。那怎么告诉它呢？

告诉浏览器先渲染骨架屏

我们在引用 CSS 时，会使用 <link rel="stylesheet" href="xxxx> 这样的语法。但实际上，浏览器还提供了其他一些机制确保（后续）页面的性能，我们称之为 preload，中文叫预加载。具体来说，使用 <link rel="preload" href="xxxx">，提前把后续要使用的资源先声明一下。在浏览器空闲的时候会提前加载并放入缓存。之后再使用就可以节省一个网络请求。

这看似无关的技术，在这里将起到很大的作用，因为 预加载的资源是不会影响当前页面的。

我们可以通过这种方式，告诉浏览器：先不要管 index.css，直接画骨架屏。之后 index.css 加载回来之后，再应用这个样式。具体来说代码如下：

<link rel="preload" href="index.css" as="style" onload="this.rel='stylesheet'">

方法的核心是通过改变 rel 可以让浏览器重新界定 <link> 标签的角色，从预加载变成当页样式。（另外也有文章采用修改 media 的方法，但浏览器支持度较低，这里不作展开了。我把文章列在最后了）这样的话，浏览器在 CSS 尚未获取完成时，会先渲染骨架屏（因为此时的 CSS 还是 preload，也就是后续使用的，并不妨碍当前页面）。而当 CSS 加载完成并修改了自己的 rel 之后，浏览器重新应用样式，目的达成。

不得不考虑的注意点

事实上，并不是把 rel="stylesheet" 改成 rel="preload" 就完事儿了。在真正应用到生产环境之前，我们还有很多事情要考虑。

兼容性考虑

首先，在 <link> 内部我们使用了 onload，也就是使用了 JS。为了应对用户的浏览器没有开启脚本功能的情况，我们需要添加一个 fallback。（不过这点对于单页应用来说可能也无所谓，因为如果没有脚本，那页面实际内容也渲染不出来的）

<noscript><link rel="stylesheet" href="index.css"></noscript>

其次，rel="preload" 并不是没有兼容性问题。对于不支持 preload 的浏览器，我们可以添加一些 polyfill 代码（来使所有浏览器获得一致的效果。

<script>
/*! loadCSS rel=preload polyfill. [c]2017 Filament Group, Inc. MIT License */
(function(){ ... }());
</script>

polyfill 的压缩代码可以参见 Lavas 的 SPA 模板第 29 行。

加载顺序

不同于传统页面，我们的实际 DOM 是通过 render.js 生成的。所以如果 JS 先于 CSS 执行，那将会发生跳动。（因为先渲染了实际内容却没有样式，而后样式加载，页面出现很明显的变化）所以这里我们需要严格控制 CSS 早于渲染。

<link rel="preload" href="index.css" as="style" onload="this.rel='stylesheet';window.STYLE_READY=true;window.mountApp && window.mountApp()">

JS 对外暴露一个 mountApp 方法用于渲染页面（其实是模拟 Vue 的 mount）

// render.js

function mountApp() {
    // 方法内部就是把实际内容添加到 <body> 上面
}

// 本来直接调用方法完成渲染
// mountApp()

// 改成挂到 window 由 CSS 来调用
window.mountApp = mountApp()
// 如果 JS 晚于 CSS 加载完成，那直接执行渲染。
if (window.STYLE_READY) {
    mountApp()
}

如果 CSS 更快加载完成，那么通过设置 window.STYLE_READY 允许 JS 加载完成后直接执行；而如果 JS 更快，则先不自己执行，而是把机会留给 CSS 的 onload。

清空 onload

loadCSS 的开发者提出，某些浏览器会在 rel 改变时重新出发 onload，导致后面的逻辑走了两次。为了消除这个影响，我们再在 onload 里面添加一句 this.onload=null。

最终的 CSS 引用方式

<link rel="preload" href="index.css" as="style" onload="this.onload=null;this.rel='stylesheet';window.STYLE_READY=true;window.mountApp && window.mountApp()">

<!-- 为了方便阅读，折行重复一遍 -->
<!-- this.onload=null -->
<!-- this.rel='stylesheet' -->
<!-- window.STYLE_READY=true -->
<!-- window.mountApp && window.mountApp() -->

修改后的效果

修改后的代码在这里，访问地址在这里。（为了简便，我省去了处理兼容性的代码，即 <noscript> 和 preload polyfill）

Performance 截图如下：（依然采用了 "Fast 3G" 的网络设置）

这次在 render.js 和 index.css 还在加载的时候页面已经呈现出骨架屏的内容，实际肉眼也可以观测到。在截图的情况下，骨架屏的展现大约持续了 300ms，占据整个网络请求的大约一半时间。

至于说为什么不是 HTML 加载完成立马展现骨架屏，而是还要等大约 300ms 才展现，从图上看是浏览器 ParseHTML 所花费的时间，可能在 Dev Tools 打开的情况下计算资源有限，不过可优化空间已经不大。（可能简化骨架屏的结构能起一些作用吧）

多骨架屏的支持

一般来说一个站点的所有页面不太可能是同一种展示类型。例如说首页和内部页面就展示风格而言会很有区别，另外例如列表页和搜索页比较接近（可能都有列表展示），但和详情页（可能是商品，服务，个人信息，博客文章等等）就会很不相同。但单页应用的 index.html 只有一个，所有的变化都源自前端渲染框架在容器节点内部进行改变。所以直接将骨架屏注入到 index.html 中会导致所有的页面都用同一个骨架屏，那就很难达成“和实际内容结构类似”的目标了，骨架屏就退化为 Loading 了。

为了要支持多种骨架屏，我们需要在 index.html 里面进行判断逻辑（独立于主体 JS 之外），具体来说：

把所有种类的骨架屏的 HTML 和样式全部写入 index.html
在 index.html 底下新增内联的脚本 <script>，根据当前路由判断应该展示哪一个骨架屏

这样会导致 index.html 体积变大一点，但整体感觉依然是收益大于付出，我认为是值得的。

后记

这个优化点最早由我的前同事 xiaop 同学在开发 Lavas 的 SPA 模板中发现并完成的，Issue 记录在此。我在他的基础上，做了一个分离 Lavas 和 Vue 环境并且更直白的例子，让截图也尽可能易于理解，方便阅读。在此非常感谢他的工作！

另外骨架屏的编写我全部采用的是纯粹的手写 HTML 和 CSS，不止展现逻辑，包括开发流程也是独立于单页应用其他常规页面的。当然这可能给开发者带来一点不便，所以这时候需要推出 xiaop 同学的利器：vue-skeleton-webpack-plugin。它的作用是把骨架屏本身也当成一个 Vue 组件，配上单独的路由规则来统一在 Vue 项目中的开发体验，最后使用 webpack 在打包构建的时候加以区分并注入，对于使用 Vue + webpack 开发的同学来说可以一试。

参考文章

让骨架屏更快渲染 - xiaop 同学原作
Loading CSS without blocking render - 使用修改 media 的方式达成目的。
filamentgroup/loadCSS - 同样使用修改 rel 的方式，并提供了 preload polyfill