相比于早些年前后端代码紧密耦合、后端工程师还得写前端代码的时代，如今已发展到前后端分离，这种开发方式大大提升了前后端项目的可维护性与开发效率，让前后端工程师关注于自己的主业。然而在带来便利的同时，也带来了一些弊端，比如首屏渲染时间(FCP)因为首屏需要请求更多内容，比原来多了更多HTTP的往返时间(RTT)，这造成了白屏，如果白屏时间过长，用户体验会大打折扣，如果用户网速差，则FCP会更长。
由此引申出一系列的优化方法，骨架屏也因此被提出。
1. FCP优化
在 Google 提出的以用户为中心的四个页面性能衡量指标中，FP/FCP可能是开发者们最熟悉的了：
为了优化首屏渲染时间这个指标，减少白屏时间，前端仔们想了很多办法：
加速或减少HTTP请求损耗 ：使用CDN加载公用库，使用强缓存和协商缓存，使用域名收敛，小图片使用Base64代替，使用Get请求代替Post请求，设置 Access-Control-Max-Age 减少预检请求，页面内跳转其他域名或请求其他域名的资源时使用浏览器prefetch预解析等；
延迟加载 ：非重要的库、非首屏图片延迟加载，SPA的组件懒加载等；
减少请求内容的体积 ：开启服务器Gzip压缩，JS、CSS文件压缩合并，减少cookies大小，SSR直接输出渲染后的HTML等；
浏览器渲染原理 ：优化，尽可能减少阻塞渲染的JS、CSS；
优化用户等待体验 ：白屏使用加载进度条、菊花图、骨架屏代替等；
这里要介绍的就是优化用户等待体验的骨架屏，它可以被视为是原来加载菊花图的一种升级版，结合传统的首屏优化方法对应用进行优化可以达到不错的效果。
2. 骨架屏
骨架屏可以理解为是 ，一个简单的关键渲染路径。可以看一下下面Facebook的骨架屏实现，可以看到在页面完全渲染完成之前，用户会看到一个样式简单，描绘了当前页面的大致框架的骨架屏页面，然后骨架屏中各个占位部分被实际资源完全替换，这个过程中用户会觉得内容正在逐渐加载即将呈现，降低了用户的焦躁情绪，使得加载过程主观上变得流畅。
可以看一下下面的示例图，第一个为骨架屏，第二个为菊花图，第三个为无优化，可以看到相比于传统的菊花图会在感官上觉得内容出现的流畅而不突兀，体验更加优良。
如今这项技术已经在Facebook、Google、支付宝、饿了么、简书、新浪微博、知乎、美团、领英等公司的产品中被广泛的使用。在论坛和社区也都有不少文章讨论骨架屏的实现和使用场景等。
3. 生成骨架屏的方法
生成骨架屏的方式主要有：
手写HTML、CSS的方式为目标页定制骨架屏 做法可以参考 <Vue页面骨架屏注入实践> ，主要思路就是使用vue-server-renderer 这个本来用于服务端渲染的插件，用来把我们写的 .vue 文件处理为 HTML ，插入到页面模板的挂载点中，完成骨架屏的注入。这种方式不甚文明，如果页面样式改变了，还得改一遍骨架屏，增加了维护成本。 骨架屏的样式实现参考CodePen
使用图片作为骨架屏； 简单暴力，让UI同学花点功夫吧哈哈；小米商城的移动端页面采用的就是这个方法，它是使用了一个Base64的图片来作为骨架屏。
自动生成并自动插入静态骨架屏 这种方法跟第一种方法类似，不过是自动生成骨架屏，可以关注下饿了么开源的插件page-skeleton-webpack-plugin ，它根据项目中不同的路由页面生成相应的骨架屏页面，并将骨架屏页面通过 webpack 打包到对应的静态路由页面中，不过要注意的是这个插件目前只支持history方式的路由，不支持hash方式，且目前只支持首页的骨架屏，并没有组件级的局部骨架屏实现，作者说以后会有计划实现 (issue9) 。