从渲染原理谈前端性能优化_chromium prefetching
赞
踩
前言
合格的开发者知道怎么做，而优秀的开发者知道为什么这么做。
这句话来自《web性能权威指南》，我一直很喜欢，而本文尝试从浏览器渲染原理探讨如何进行性能提升。
全文将从网络通信以及页面渲染两个过程去探讨浏览器的行为及在此过程中我们可以针对那些点进行优化，有些的不足之处还请各位不吝雅正。
一、关于浏览器渲染的容易误解点总结
关于浏览器渲染机制已经是老生常谈，而且网上现有资料中有非常多的优秀资料对此进行阐述。遗憾的是网上的资料良莠不齐，经常在不同的文档中对同一件事的描述出现了极大的差异。怀着严谨求学的态度经过大量资料的查阅和请教，将会在后文总结出一个完整的流程。
1、DOM树的构建是文档加载完成开始的？
DOM树的构建是从接受到文档开始的，先将字节转化为字符，然后字符转化为标记，接着标记构建dom树。
这个过程被分为标记化和树构建
而这是一个渐进的过程。为达到更好的用户体验，呈现引擎会力求尽快将内容显示在屏幕上。它不必等到整个 HTML 文档解析完毕之后，就会开始构建呈现树和设置布局。在不断接收和处理来自网络的其余内容的同时，呈现引擎会将部分内容解析并显示出来。
参考文档：http://taligarsiel.com/Projects/howbrowserswork1.htm
2、渲染树是在DOM树和CSS样式树构建完毕才开始构建的吗？
这三个过程在实际进行的时候又不是完全独立，而是会有交叉。会造成一边加载，一边解析，一边渲染的工作现象。
参考文档：http://www.jianshu.com/p/2d522fc2a8f8
3、css的标签嵌套越多，越容易定位到元素
css的解析是自右至左逆向解析的，嵌套越多越增加浏览器的工作量，而不会越快。
因为如果正向解析，例如「div div p em」，我们首先就要检查当前元素到 html 的整条路径，找到最上层的 div，再往下找，如果遇到不匹配就必须回到最上层那个 div，往下再去匹配选择器中的第一个 div，回溯若干次才能确定匹配与否，效率很低。
逆向匹配则不同，如果当前的 DOM 元素是 div，而不是 selector 最后的 em，那只要一步就能排除。只有在匹配时，才会不断向上找父节点进行验证。
打个比如 p span.showing
你认为从一个p元素下面找到所有的span元素并判断是否有class showing快，还是找到所有的span元素判断是否有class showing并且包括一个p父元素快
参考文档：http://www.imooc.com/code/4570
二、页面渲染的完整流程
当浏览器拿到HTTP报文时呈现引擎将开始解析 HTML 文档，并将各标记逐个转化成“内容树”上的 DOM 节点。同时也会解析外部 CSS 文件以及样式元素中的样式数据。HTML 中这些带有视觉指令的样式信息将用于创建另一个树结构：呈现树。浏览器将根据呈现树进行布局绘制。
以上就是页面渲染的大致流程。那么浏览器从用户输入网址之后到底做了什么呢？以下将会进行一个完整的梳理。鉴于本文是前端向的所以梳理内容会有所偏重。而从输入到呈现可以分为两个部分：网络通信和页面渲染
我们首先来看网络通信部分：
1、用户输入url并敲击回车。
2、进行DNS解析。
如果用户输入的是ip地址则直接进入第三条。但去记录毫无规律且冗长的ip地址显然不是易事，所以通常都是输入的域名，此时就会进行dns解析。所谓DNS（Domain Name System）指域名系统。因特网上作为域名和IP地址相互映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。通过主机名，最终得到该主机名对应的IP地址的过程叫做域名解析（或主机名解析）。这个过程如下所示：
浏览器会首先搜索浏览器自身的DNS缓存（缓存时间比较短，大概只有2分钟左右，且只能容纳1000条缓存）。
- 如果浏览器自身缓存找不到则会查看系统的DNS缓存,如果找到且没有过期则停止搜索解析到此结束.
- 而如果本机没有找到DNS缓存，则浏览器会发起一个DNS的系统调用，就会向本地配置的首选DNS服务器发起域名解析请求（通过的是UDP协议向DNS的53端口发起请求，这个请求是递归的请求，也就是运营商的DNS服务器必须得提供给我们该域名的IP地址），运营商的DNS服务器首先查找自身的缓存，找到对应的条目，且没有过期，则解析成功。
- 如果没有找到对应的条目，则有运营商的DNS代我们的浏览器发起迭代DNS解析请求，它首先是会找根域的DNS的IP地址（这个DNS服务器都内置13台根域的DNS的IP地址），找打根域的DNS地址，就会向其发起请求（请问www.xxxx.com这个域名的IP地址是多少啊？）
- 根域发现这是一个顶级域com域的一个域名，于是就告诉运营商的DNS我不知道这个域名的IP地址，但是我知道com域的IP地址，你去找它去，于是运营商的DNS就得到了com域的IP地址，又向com域的IP地址发起了请求（请问www.xxxx.com这个域名的IP地址是多少?）,com域这台服务器告诉运营商的DNS我不知道www.xxxx.com这个域名的IP地址，但是我知道xxxx.com这个域的DNS地址，你去找它去，于是运营商的DNS又向linux178.com这个域名的DNS地址（这个一般就是由域名注册商提供的，像万网，新网等）发起请求（请问www.xxxx.com这个域名的IP地址是多少？），这个时候xxxx.com域的DNS服务器一查，诶，果真在我这里，于是就把找到的结果发送给运营商的DNS服务器，这个时候运营商的DNS服务器就拿到了www.xxxx.com这个域名对应的IP地址，并返回给Windows系统内核，内核又把结果返回给浏览器，终于浏览器拿到了www.xxxx.com对应的IP地址,这次dns解析圆满成功。
3、建立tcp连接
拿到域名对应的IP地址之后，User-Agent（一般是指浏览器）会以一个随机端口（1024< 端口 < 65535）向服务器的WEB程序（常用的有httpd,nginx等）80端口发起TCP的连接请求。这个连接请求（原始的http请求经过TCP/IP4层模型的层层封包）到达服务器端后（这中间通过各种路由设备，局域网内除外），进入到网卡，然后是进入到内核的TCP/IP协议栈（用于识别该连接请求，解封包，一层一层的剥开），还有可能要经过Netfilter防火墙（属于内核的模块）的过滤，最终到达WEB程序，最终建立了TCP/IP的连接。
tcp建立连接和关闭连接均需要一个完善的确认机制，我们一般将连接称为三次握手，而连接关闭称为四次挥手。而不论是三次握手还是四次挥手都需要数据从客户端到服务器的一次完整传输。将数据从客户端到服务端经历的一个完整时延包括：
- 发送时延：把消息中的所有比特转移到链路中需要的时间，是消息长度和链路速度的函数
- 传播时延：消息从发送端到接受端需要的时间，是信号传播距离和速度的函数
- 处理时延：处理分组首部，检查位错误及确定分组目标所需的时间
- 排队时延：到来的分组排队等待处理的时间以上的延迟总和就是客户端到服务器的总延迟时间
以上的延迟总和就是客户端到服务器的总延迟时间。因此每一次的连接建立和断开都是有巨大代价的。因此去掉不必要的资源和资源合并（包括js及css资源合并、雪碧图等）才会成为性能优化绕不开的方案。但是好消息是随着协议的发展我们将对性能优化这个主题有着新的看法和思考。虽然还未到来，但也不远了。如果你感到好奇那就接着往下看。
以下简述下tcp建立连接的过程：
第一次握手：客户端发送syn包（syn=x，x为客户端随机序列号）的数据包到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y，y为服务端生成的随机序列号），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=y+1)
此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP连接都将被一直保持下去
这里注意， 三次握手是不携带数据的，而是在握手完毕才开始数据传输。因此如果每次数据请求都需要重新进行完整的tcp连接建立，通信时延的耗时是难以估量的！这也就是为什么我们总是能听到资源合并减少请求次数的原因。
下面来看看HTTP如何在协议层面帮我们进行优化的：
HTTP1.0
在http1.0时代，每个TCP连接只能发送一个请求。发送数据完毕，连接就关闭，如果还要请求其他资源，就必须再新建一个连接。 TCP连接的新建成本很高，因为需要客户端和服务器三次握手，并且开始时发送速率较慢（TCP的拥塞控制开始时会启动慢启动算法）。在数据传输的开始只能发送少量包，并随着网络状态良好（无拥塞）指数增长。但遇到拥塞又要重新从1个包开始进行传输。
以下图为例，慢启动时第一次数据传输只能传输一组数据，得到确认后传输2组，每次翻倍，直到达到阈值16时开始启用拥塞避免算法，既每次得到确认后数据包只增加一个。当发生网络拥塞后，阈值减半重新开始慢启动算法。
因此为避免tcp连接的三次握手耗时及慢启动引起的发送速度慢的情况，应尽量减少tcp连接的次数。
而HTTP1.0每个数据请求都需要重新建立连接的特点使得HTTP 1.0版本的性能比较差。随着网页加载的外部资源越来越多，这个问题就愈发突出了。 为了解决这个问题，有些浏览器在请求时，用了一个非标准的Connection字段。 Kepp-alive 一个可以复用的TCP连接就建立了，直到客户端或服务器主动关闭连接。但是，这不是标准字段，不同实现的行为可能不一致，因此不是根本的解决办法。
HTTP1.1
http1.1（以下简称h1.1） 版的最大变化，就是引入了持久连接（persistent connection），即TCP连接默认不关闭，可以被多个请求复用，不用声明Connection: keep-alive。 客户端和服务器发现对方一段时间没有活动，就可以主动关闭连接。不过，规范的做法是，客户端在最后一个请求时，发送Connection: close，明确要求服务器关闭TCP连接。 目前，对于同一个域名，大多数浏览器允许同时建立6个持久连接。相比与http1.0，1.1的页面性能有了巨大提升，因为省去了很多tcp的握手挥手时间。下图第一种是tcp建立后只能发一个请求的http1.0的通信状态，而拥有了持久连接的h1.1则避免了tcp握手及慢启动带来的漫长时延。
从图中可以看到相比h1.0，h1.1的性能有所提升。然而虽然1.1版允许复用TCP连接，但是同一个TCP连接里面，所有的数据通信是按次序进行的。服务器只有处理完一个回应，才会进行下一个回应。要是前面的回应特别慢，后面就会有许多请求排队等着。这称为"队头堵塞"（Head-of-line blocking）。 为了避免这个问题，只有三种方法：一是减少请求数，二是同时多开持久连接。这导致了很多的网页优化技巧&#x
