本文主要介绍“关键渲染路径”与“网络”两个方面的性能优化并提供demo&＃xff0c;篇幅较长建议电脑观看。

前端优化的方面太多&＃xff0c;本文介绍的仅仅是其中的一部分&＃xff0c;力求涵盖“关键渲染路径”的方方面面&＃xff0c;及一些不常被提到的“网络优化”部分。

测试环境如无特殊说明均为Chrome 57

渲染页面过程

浏览器从打开一个URL到渲染完页面共有&＃xff1a;

• 下载HTML文档

• 下载HTML文档中的css

• 下载Js文件

• 执行js脚本

• 下载其他资源

• 通过HTML文档构建DOM&＃xff08;Parse HTML&＃xff09;

• 通过CSS文件构建CSSOM&＃xff08;Parse CSS&＃xff09;

• 通过DOM与CSSOM计算render tree

• 根据render tree进行绘制&＃xff0c;计算各个元素位置与大小&＃xff08;Layout&＃xff09;

• 对页面进行上色&＃xff0c;渲染为最终显示的像素&＃xff08;Paint&＃xff09;

第一次完成Paint称为“初次渲染”&＃xff0c;这时候用户就能看到render tree里面的东西了。而完成初次渲染的过程称为“关键渲染路径”&＃xff0c;关键渲染路径上需要加载的资源叫做“关键资源”

这个过程很多很复杂&＃xff0c;其中的依赖关系也很复杂&＃xff0c;笔者尝试画图来表示&＃xff0c;但是实在是没画出来&＃xff0c;所以还是用文字来表述吧&＃xff1a;

• 引入的资源&＃xff0c;哪怕被阻塞&＃xff08;比如被js脚本阻塞后续link标签&＃xff09;&＃xff0c;浏览器依旧会智能的预先加载它们&＃xff08;但是不执行&＃xff09;

• “CSS文件的加载”会阻塞“Js文件执行”。若CSS引用在Js文件之前&＃xff0c;“加载CSS文件”会阻塞“Js文件执行”。即CSS文件未加载解析完成前&＃xff0c;js文件不会得到执行。因为js有可能会修改CSSOM。带有async和defer属性的script不受限制。

• Parse HTML的解析是增量的&＃xff0c;因此浏览器可以边下载HTML边构建DOM树

• “CSS文件的加载”会阻塞“Layout”。若页面有正在加载的CSS文件&＃xff0c;在CSS文件加载完之前&＃xff0c;浏览器不会对页面进行Layout&＃xff0c;这是为了防止样式突变带来的抖动

• “加载Js文件”会阻塞“Parse HTML”&＃xff0c;这个估计大家都知道了&＃xff0c;因为js可以通过document.write修改HTML文档流

• “Js文件执行”会几乎会阻塞所有东西&＃xff0c;包括Layout

比较有意思的是&＃xff0c;字体的加载会阻塞局部的渲染。若某一段文本的字体使用了一个尚未加载完的字体&＃xff0c;这段文本则先不会被Paint&＃xff0c;直到字体加载完或者超过某个时间&＃xff08;通常是3秒&＃xff09;文本才会突然显示。

浏览器为了避免FOUT(Flash Of Unstyled Text)&＃xff0c;会尽量等待字体加载完成后&＃xff0c;再显示应用了该字体的内容。只有当字体超过一段时间仍未加载成功时&＃xff0c;浏览器才会降级使用系统字体。每个浏览器都规定了自己的超时时间&＃xff08;Chrome是3秒&＃xff09;。但这也带来了FOIT(Flash Of Invisible Text)问题。内容无法尽快地被展示&＃xff0c;导致空白

一些Demo来解释浏览器渲染流程

CSS会阻塞Layout&＃xff1a;Demo

Hello

World

CSS会阻塞Js执行&＃xff1a;Demo

Hello

World

Js执行会阻塞关键渲染路径&＃xff0c;哪怕是defer还是async&＃xff1a;Demo

Hello

World

Foot会阻塞局部渲染&＃xff0c;但是智能的浏览器会给他设定一个上限&＃xff0c;一般是3秒钟&＃xff1a;Demo

Hello

World

CSS篇优化策略

优化核心概念是&＃xff1a;将初次渲染不需要的CSS想办法剥离出关键渲染路径

如果仅仅是为了提前初次渲染时间而进行优化&＃xff0c;将页面必备的CSS剥离关键渲染路径而造成样式突变导致页面抖动&＃xff0c;则得不偿失了

使用link/style的media属性

对某些媒体查询条件触发后才使用的css&＃xff0c;可以在link标签中加入media属性&＃xff0c;如下&＃xff1a;

此样式表仍会加载。当浏览器环境不匹配媒体查询条件时&＃xff0c;该样式表不会阻塞渲染。我们可针对不同媒体环境拆分CSS文件&＃xff0c;并为link标签添加媒体查询&＃xff0c;避免为了加载非关键CSS资源&＃xff0c;而阻塞初次渲染

使用DOM API添加CSS

可以使用js代码来添加css

var style &＃61; document.createElement(&＃39;link&＃39;);
style.rel &＃61; &＃39;stylesheet&＃39;;
style.href &＃61; &＃39;index.css&＃39;;
document.head.appendChild(style);

使用resoure hint规范的preload

将link标签的rel属性设置为preload&＃xff0c;浏览器遇到遇到标记为preload的link时&＃xff0c;会开始加载它&＃xff0c;但是由于rel不是stylesheet&＃xff0c;因此不会阻塞渲染。

然后在适当的时候&＃xff0c;在rel改为stylesheet&＃xff0c;即可应用此样式。

但是这个属性兼容性比较差&＃xff0c;详细可以参考这里。不过有一个polyfill可以用loadCSS&＃xff0c;原理是通过DOM API插入样式资源。

这个属性的使用情景有些偏&＃xff0c;也可能是我理解问题&＃xff1a;

当使用preload引入css文件时&＃xff0c;实际上证明这个页面根本不需要这个css&＃xff0c;它有可能是打印样式&＃xff0c;或者是响应式网站的另一套css代码。但是&＃xff0c;使用preload属性&＃xff0c;浏览器反而会预先加载它&＃xff0c;也就是说&＃xff0c;在window.onload之前&＃xff0c;用户将耗费了网络资源在加载一个暂时不需要的样式。网络资源不可能是无限的&＃xff0c;也就是说这个css会占用页面其他资源比如图片的网络资源。

询问瓜瓜老师本人后&＃xff0c;瓜瓜老师说&＃xff1a;

举个例子。第三屏有个广告版&＃xff0c;它的样式

这样确实这个css的紧急程度就介于关键渲染路径的css与页面图片之间了&＃xff0c;不过貌似这个情景很受限。

JS篇优化策略

使用defer延迟脚本执行

当script标签拥有defer属性时&＃xff0c;该脚本会被推迟到整个HTML文档解析完后&＃xff0c;再开始执行。因此将脚本放在head中&＃xff0c;可以提早浏览器对脚本文件的加载&＃xff0c;但是却不会阻塞parse HTML。

注意&＃xff0c;defer的脚本不会被css阻塞&＃xff0c;parse HTML完成后立即执行&＃xff0c;但是有可能会阻塞关键渲染路径。为什么说有可能呢&＃xff0c;假如脚本文件在render tree生成前加载完毕&＃xff0c;则会开始执行&＃xff0c;执行过程中会阻塞关键渲染路径。请参考这个Demo

被defer的脚本&＃xff0c;在执行时会严格按照在HTML文档中出现的顺序执行&＃xff0c;但是实际上貌似不是这样&＃xff0c;js文件前后文件若有依赖需慎重使用。

使用async延迟脚本执行

和defer类似&＃xff0c;只是当js加载完后马上执行&＃xff0c;而不在乎parse HTML是否完成&＃xff0c;因此假如脚本比css先加载完&＃xff0c;也会阻塞关键渲染路径。

使用DOM API

据笔者所知&＃xff0c;这是唯一一种100%不会阻塞关键渲染路径的js脚本加载方式。通过DOM API引入的js脚本会等到页面Layout和Paint后再开始执行&＃xff0c;不论你将载入js文件的代码放在head中还是body后面亦是如此。

其他的优化

使用Web Font Loader加载字体

若不想让字体阻塞局部渲染&＃xff0c;可使用Web Font Loader

网络优化篇

网络优化和CSS优化策略相同&＃xff0c;尽可能让关键资源提前加载完&＃xff0c;所以优化时尽量将以下指标压缩到最低&＃xff1a;

• 关键资源数

• 关键资源体积

• 关键资源网络来回数

当然&＃xff0c;如果你的项目使用了先进的SPDY或HTTP/2&＃xff0c;下面的方法可能并不适用。

优化关键资源数

RFC2616规定同域名同时只能有 2 个连接&＃xff08;RFC7230 中无限制&＃xff09;&＃xff0c;而​​​​​​​现代浏览器一般允许同域6个并发连接。因此&＃xff0c;当页面中有许多需要外链的资源&＃xff08;script、link等&＃xff09;&＃xff0c;浏览器最多在每个域同时并发下载6个。

每一个请求&＃xff0c;若使用域名&＃xff0c;则需要额外增加一次DNS查询时间&＃xff08;若缓存未过期会命中缓存&＃xff09;&＃xff0c;因此一个网站过多的使用不同域名的资源会额外增加DNS查询开销&＃xff0c;这点在移动端非常明显。

当然&＃xff0c;每个请求建立根据TCP协议规定&＃xff0c;还需要先进行3次捂手才可以建立链接。

合并请求

尽可能的合并请求&＃xff0c;减少网络请求数。这一点可能在其他性能优化文章都说烂了&＃xff1a;

• 小图片转base64

• 合并打包CSS、JS文件

现在的比较流行的webpack就非常擅长做这种事情

适度使用内联CSS和Js

使用内联的CSS和JS固然可以减少请求&＃xff0c;但是使用内联也意味着你的CSS和JS将不会再被浏览器缓存&＃xff0c;因此要适度的使用内联&＃xff0c;内联不是万能的。

从HTTP协议下手

最佳方案肯定是过渡到HTTP/2无疑&＃xff0c;但是现在HTTP/2的支持并不算太好&＃xff0c;而且各大浏览器仅支持TLS下实现的HTTP/2&＃xff08;说白了就是HTTPS&＃xff09;&＃xff0c;使得HTTP/2的使用存在许些限制。

如果没有HTTP/2&＃xff0c;或许可以&＃xff1a;

• 使用Keep-Alive可以规避TCP三次握手的时间

• 使用Transfer-Encoding:chunked分块输出文件&＃xff0c;还记得parse HTML的过程是增量的吗&＃xff1f;若浏览器可以边下载HTML文件边解析&＃xff0c;岂不美哉&＃xff1f;

• 减少重定向&＃xff0c;这个看上去理所当然但是实际上却很容易被忽略

适度使用域名散列

浏览器同域并行下载数量有限&＃xff0c;所以只要多建立几个二级域名就好了&＃xff0c;然后合理的分配各个资源就好了。

假如由于某些不可抗拒原因&＃xff0c;关键资源数是12个&＃xff0c;那么只要建立2个二级域名分别分配给其中的12个资源&＃xff0c;浏览器会同时并行下载它们了。

不过&＃xff0c;使用域名散列要适度&＃xff0c;每一个域名都需要额外的增加一次DNS查询时间。当然&＃xff0c;DNS本身也有缓存&＃xff0c;或许适当的增加DNS TTL时间也是个不错的主意。

压缩关键资源体积

对于js、css文件&＃xff0c;现在网上现成的压缩工具一堆&＃xff0c;而且应用十分广泛&＃xff0c;相信大家都知道了&＃xff0c;这里就不多说了。

说到压缩&＃xff0c;服务器开启一定的压缩策略&＃xff08;如gzip&＃xff09;是个不错的主意&＃xff0c;效果拔群&＃xff0c;资源大概会压缩到原有的1/3左右。

图片压缩&＃xff0c;这个需要知道什么情境下适合什么类型的图片&＃xff0c;GIF、JPG、PNG使用情景各不相同&＃xff0c;具体可以参考这篇文章&＃xff1a;图片格式那么多&＃xff0c;哪种更适合你&＃xff1f;

关键资源网络来回数

假如一个页面需要引入2个CSS才能工作&＃xff0c;下面有2种方式

• 2个均用link引入

• 1个用link引入&＃xff0c;在css中import另一个css

毫无疑问肯定是前者快&＃xff0c;因为前者的网络来回数是1&＃xff0c;而后者是2。

因此&＃xff0c;尽可能将资源加载扁平化&＃xff0c;减少关键资源网络来回数是个不错的主意。

当然&＃xff0c;优化时要注意的点也有不少&＃xff0c;比如前面提到的浏览器同域并发限制等&＃xff0c;需要权衡使其不要影响到其他的导致初次渲染时间延后。

一些无效的优化策略

使用document.write打印link标签引入css仍会阻塞初次渲染。

引用

奇舞团&＃64;瓜瓜老师&＃xff1a;

• PPT&＃xff1a;https://ppt.baomitu.com/d/258...

• 个人主页&＃xff1a;http://melonh.com/

奇舞团&＃64;屈屈老师&＃xff1a;

• PPT&＃xff1a;https://ppt.baomitu.com/d/a8a...

• 个人主页&＃xff1a;https://imququ.com/

W3C规范&＃xff1a;

• https://www.w3.org/TR/2016/RE...