从渲染原理谈前端性能优化

摘要：通过主机名，最终得到该主机名对应的地址的过程叫做域名解析或主机名解析。因此去掉不必要的资源和资源合并包括及资源合并雪碧图等才会成为性能优化绕不开的方案。

作者：李佳晓 原文：学而思网校技术团队

合格的开发者知道怎么做，而优秀的开发者知道为什么这么做。

这句话来自《web性能权威指南》，我一直很喜欢，而本文尝试从浏览器渲染原理探讨如何进行性能提升。
全文将从网络通信以及页面渲染两个过程去探讨浏览器的行为及在此过程中我们可以针对那些点进行优化，有些的不足之处还请各位不吝雅正。

关于浏览器渲染机制已经是老生常谈，而且网上现有资料中有非常多的优秀资料对此进行阐述。遗憾的是网上的资料良莠不齐，经常在不同的文档中对同一件事的描述出现了极大的差异。怀着严谨求学的态度经过大量资料的查阅和请教，将会在后文总结出一个完整的流程。

DOM树的构建是从接受到文档开始的，先将字节转化为字符，然后字符转化为标记，接着标记构建dom树。这个过程被分为标记化和树构建
而这是一个渐进的过程。为达到更好的用户体验，呈现引擎会力求尽快将内容显示在屏幕上。它不必等到整个 HTML 文档解析完毕之后，就会开始构建呈现树和设置布局。在不断接收和处理来自网络的其余内容的同时，呈现引擎会将部分内容解析并显示出来。
参考文档：
http://taligarsiel.com/Projec...

这三个过程在实际进行的时候又不是完全独立，而是会有交叉。会造成一边加载，一边解析，一边渲染的工作现象。
参考文档：

http://www.jianshu.com/p/2d52...

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 中这些带有视觉指令的样式信息将用于创建另一个树结构：呈现树。浏览器将根据呈现树进行布局绘制。

以上就是页面渲染的大致流程。那么浏览器从用户输入网址之后到底做了什么呢？以下将会进行一个完整的梳理。鉴于本文是前端向的所以梳理内容会有所偏重。而从输入到呈现可以分为两个部分：网络通信和页面渲染

我们首先来看网络通信部分：

如果用户输入的是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解析圆满成功。

拿到域名对应的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时代，每个TCP连接只能发送一个请求。发送数据完毕，连接就关闭，如果还要请求其他资源，就必须再新建一个连接。 TCP连接的新建成本很高，因为需要客户端和服务器三次握手，并且开始时发送速率较慢（TCP的拥塞控制开始时会启动慢启动算法）。在数据传输的开始只能发送少量包，并随着网络状态良好（无拥塞）指数增长。但遇到拥塞又要重新从1个包开始进行传输。

以下图为例，慢启动时第一次数据传输只能传输一组数据，得到确认后传输2组，每次翻倍，直到达到阈值16时开始启用拥塞避免算法，既每次得到确认后数据包只增加一个。当发生网络拥塞后，阈值减半重新开始慢启动算法。

因此为避免tcp连接的三次握手耗时及慢启动引起的发送速度慢的情况，应尽量减少tcp连接的次数。

而HTTP1.0每个数据请求都需要重新建立连接的特点使得HTTP 1.0版本的性能比较差。随着网页加载的外部资源越来越多，这个问题就愈发突出了。 为了解决这个问题，有些浏览器在请求时，用了一个非标准的Connection字段。 Kepp-alive 一个可以复用的TCP连接就建立了，直到客户端或服务器主动关闭连接。但是，这不是标准字段，不同实现的行为可能不一致，因此不是根本的解决办法。

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）。 为了避免这个问题，只有三种方法：一是减少请求数，二是同时多开持久连接。这导致了很多的网页优化技巧，比如合并脚本和样式表、将图片嵌入CSS代码、域名分片（domain sharding）等等。如果HTTP协议能继续优化，这些额外的工作是可以避免的。三是开启pipelining，不过pipelining并不是救世主，它也存在不少缺陷：

pipelining只能适用于http1.1，一般来说，支持http1.1的server都要求支持pipelining

只有幂等的请求（GET，HEAD）能使用pipelining，非幂等请求比如POST不能使用，因为请求之间可能会存在先后依赖关系。

head of line blocking并没有完全得到解决，server的response还是要求依次返回，遵循FIFO(first in first out)原则。也就是说如果请求1的response没有回来，2，3，4，5的response也不会被送回来。

绝大部分的http代理服务器不支持pipelining。 和不支持pipelining的老服务器协商有问题。 可能会导致新的队首阻塞问题。

鉴于以上种种原因，pipelining的支持度并不友好。可以看看chrome对pipelining的描述：

https://www.chromium.org/deve...

2015年，HTTP/2 发布。它不叫 HTTP/2.0，是因为标准委员会不打算再发布子版本了，下一个新版本将是 HTTP/3。HTTP2将具有以下几个主要特点：

二进制协议 ：HTTP/1.1 版的头信息肯定是文本（ASCII编码），数据体可以是文本，也可以是二进制。HTTP/2 则是一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为"帧"（frame）：头信息帧和数据帧。

多工 ：HTTP/2 复用TCP连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应，这样就避免了"队头堵塞"。

数据流：因为 HTTP/2 的数据包是不按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。 HTTP/2 将每个请求或回应的所有数据包，称为一个数据流（stream）。每个数据流都有一个独一无二的编号。数据包发送的时候，都必须标记数据流ID，用来区分它属于哪个数据流。另外还规定，客户端发出的数据流，ID一律为奇数，服务器发出的，ID为偶数。 数据流发送到一半的时候，客户端和服务器都可以发送信号（RST_STREAM帧），取消这个数据流。1.1版取消数据流的唯一方法，就是关闭TCP连接。这就是说，HTTP/2 可以取消某一次请求，同时保证TCP连接还打开着，可以被其他请求使用。 客户端还可以指定数据流的优先级。优先级越高，服务器就会越早回应。

头信息压缩： HTTP 协议不带有状态，每次请求都必须附上所有信息。所以，请求的很多字段都是重复的，比如Cookie和User Agent，一模一样的内容，每次请求都必须附带，这会浪费很多带宽，也影响速度。 HTTP2对这一点做了优化，引入了头信息压缩机制（header compression）。一方面，头信息使用gzip或compress压缩后再发送；另一方面，客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。

服务器推送： HTTP/2 允许服务器未经请求，主动向客户端发送资源，这叫做服务器推送（server push）。 常见场景是客户端请求一个网页，这个网页里面包含很多静态资源。正常情况下，客户端必须收到网页后，解析HTML源码，发现有静态资源，再发出静态资源请求。其实，服务器可以预期到客户端请求网页后，很可能会再请求静态资源，所以就主动把这些静态资源随着网页一起发给客户端了。

就这几个点我们分别讨论一下：
就多工来看：虽然http1.1支持了pipelining，但是仍然会有队首阻塞问题，如果浏览器同时发出http请求请求和css，服务器端处理css请求耗时20ms，但是因为先请求资源是html，此时的css尽管已经处理好了但仍不能返回，而需要等待html处理好一起返回，此时的客户端就处于盲等状态，而事实上如果服务器先处理好css就先返回css的话，浏览器就可以开始解析css了。而多工的出现就解决了http之前版本协议的问题，极大的提升了页面性能。缩短了通信时间。我们来看看有了多工之后有那些影响：

无需进行资源分片：为了避免请求tcp连接耗时长的和初始发送速率低的问题，浏览器允许同时打开多个tcp连接让资源同时请求。但是为了避免服务器压力，一般针对一个域名会有最大并发数的限制，一般来说是6个。允许一个页面同时对相同域名打开6个tcp连接。为了绕过最大并发数的限制，会将资源分布在不同的域名下，避免资源在超过并发数后需要等待才能开始请求。而有了http2，可以同步请求资源，资源分片这种方式就可以不再使用。

资源合并：资源合并会不利于缓存机制，因为单文件修改会影响整个资源包。而且单文件过大对于 HTTP/2 的传输不好，尽量做到细粒化更有利于 HTTP/2 传输。而且内置资源也是同理，将资源以base64的形式放进代码中不利于缓存。且编码后的图片资源大小是要超过图片大小的。这两者都是以减少tcp请求次数增大单个文件大小来进行优化的。

就头部压缩来看：HTTP/1.1 版的头信息是ASCII编码，也就是不经过压缩的，当我们请求只携带少量数据时，http头部可能要比载荷要大许多，尤其是有了很长的cookie之后这一点尤为显著，头部压缩毫无疑问可以对性能有很大提升。

就服务器推送来看：少去了资源请求的时间，服务端可以将可能用到的资源推送给服务端以待使用。这项能力几乎是革新了之前应答模式的认知，对性能提升也有巨大帮助。

因此很多优化都是在基于tcp及http的一些问题来避免和绕过的。事实上多数的优化都是针对网络通信这个部分在做。

以上是网络通信部分，接下来将会对页面渲染部分进行叙述。

当浏览器拿到HTML文档时首先会进行HTML文档解析，构建DOM树。

遇到css样式如link标签或者style标签时开始解析css，构建样式树。HTML解析构建和CSS的解析是相互独立的并不会造成冲突，因此我们通常将css样式放在head中，让浏览器尽早解析css。

当html的解析遇到script标签会怎样呢？答案是停止DOM树的解析开始下载js。因为js是会阻塞html解析的，是阻塞资源。其原因在于js可能会改变html现有结构。例如有的节点是用js动态构建的，在这种情况下就会停止dom树的构建开始下载解析js。脚本在文档的何处插入，就在何处执行。当 HTML 解析器遇到一个 script 标记时，它会暂停构建 DOM，将控制权移交给 JavaScript 引擎；等 JavaScript 引擎运行完毕，浏览器会从中断的地方恢复 DOM 构建。而因此就会推迟页面首绘的时间。可以在首绘不需要js的情况下用async和defer实现异步加载。这样js就不会阻塞html的解析了。当HTML解析完成后，浏览器会将文档标注为交互状态，并开始解析那些处于“deferred”模式的脚本，也就是那些应在文档解析完成后才执行的脚本。然后，文档状态将设置为“完成”，一个“加载”事件将随之触发。

注意，异步执行是指下载。执行js时仍然会阻塞。

在得到DOM树和样式树后就可以进行渲染树的构建了。应注意的是渲染树和 DOM 元素相对应的，但并非一一对应。比如非可视化的 DOM 元素不会插入呈现树中，例如“head”元素。如果元素的 display 属性值为“none”，那么也不会显示在呈现树中（但是 visibility 属性值为“hidden”的元素仍会显示）

渲染树构建完毕后将会进行布局。布局使用流模型的Layout算法。所谓流模型，即是指Layout的过程只需进行一遍即可完成，后出现在流中的元素不会影响前出现在流中的元素，Layout过程只需从左至右从上至下一遍完成即可。但实际实现中，流模型会有例外。Layout是一个递归的过程，每个节点都负责自己及其子节点的Layout。Layout结果是相对父节点的坐标和尺寸。其过程可以简述为：

此时renderTree已经构建完毕，不过浏览器渲染树引擎并不直接使用渲染树进行绘制，为了方便处理定位（裁剪），溢出滚动（页内滚动），CSS转换/不透明/动画/滤镜，蒙版或反射，Z （Z排序）等，浏览器需要生成另外一棵树 - 层树。因此绘制过程如下：1、获取 DOM 并将其分割为多个层(RenderLayer) 2、将每个层栅格化，并独立的绘制进位图中 3、将这些位图作为纹理上传至 GPU 4、复合多个层来生成最终的屏幕图像(终极layer)。

HTML解析是一个将字节转化为字符，字符解析为标记，标记生成节点，节点构建树的过程。。CSS样式的解析则由于复杂的样式层叠而变得复杂。对此不同的渲染引擎在处理上有所差异，后文将会就这点进行详细讲解

标记化算法：

是词法分析过程，将输入内容解析成多个标记。HTML标记包括起始标记、结束标记、属性名称和属性值。标记生成器识别标记，传递给树构造器，然后接受下一个字符以识别下一个标记；如此反复直到输入的结束。
该算法的输出结果是 HTML 标记。该算法使用状态机来表示。每一个状态接收来自输入信息流的一个或多个字符，并根据这些字符更新下一个状态。当前的标记化状态和树结构状态会影响进入下一状态的决定。这意味着，即使接收的字符相同，对于下一个正确的状态也会产生不同的结果，具体取决于当前的状态。
树构建算法：

在树构建阶段，以 Document 为根节点的 DOM 树也会不断进行修改，向其中添加各种元素。
标记生成器发送的每个节点都会由树构建器进行处理。规范中定义了每个标记所对应的 DOM 元素，这些元素会在接收到相应的标记时创建。这些元素不仅会添加到 DOM 树中，还会添加到开放元素的堆栈中。此堆栈用于纠正嵌套错误和处理未关闭的标记。其算法也可以用状态机来描述。这些状态称为“插入模式”。

以下将会举一个例子来分析这两个阶段：

标记化：初始状态是数据状态。

遇到字符 < 时，状态更改为“标记打开状态”。接收一个 a-z字符会创建“起始标记”，状态更改为“标记名称状态”。这个状态会一直保持到接收> 字符。在此期间接收的每个字符都会附加到新的标记名称上。在本例中，我们创建的标记是 html 标记。

遇到 > 标记时，会发送当前的标记，状态改回“数据状态”。 标记也会进行同样的处理。目前 html 和 body 标记均已发出。现在我们回到“数据状态”。接收到 Hello world 中的 H 字符时，将创建并发送字符标记，直到接收 中的<。我们将为 Hello world 中的每个字符都发送一个字符标记。

现在我们回到“标记打开状态”。接收下一个输入字符 / 时，会创建 end tag token 并改为“标记名称状态”。我们会再次保持这个状态，直到接收 >。然后将发送新的标记，并回到“数据状态”。 输入也会进行同样的处理。

还是以上的例子，我们来看看树构建

树构建：树构建阶段的输入是一个来自标记化阶段的标记序列。

第一个模式是“initial mode”。接收 HTML 标记后转为“before html”模式，并在这个模式下重新处理此标记。这样会创建一个 HTMLHtmlElement 元素，并将其附加到 Document 根对象上。

然后状态将改为“before head”。此时我们接收“body”标记。即使我们的示例中没有“head”标记，系统也会隐式创建一个 HTMLHeadElement，并将其添加到树中。

现在我们进入了“in head”模式，然后转入“after head”模式。系统对 body 标记进行重新处理，创建并插入 HTMLBodyElement，同时模式转变为“body”。

现在，接收由“Hello world”字符串生成的一系列字符标记。接收第一个字符时会创建并插入“Text”节点，而其他字符也将附加到该节点

接收 body 结束标记会触发“after body”模式。现在我们将接收 HTML 结束标记，然后进入“after after body”模式。接收到文件结束标记后，解析过程就此结束。解析结束后的操作

在此阶段，浏览器会将文档标注为交互状态，并开始解析那些处于“deferred”模式的脚本，也就是那些应在文档解析完成后才执行的脚本。然后，文档状态将设置为“完成”，一个“加载”事件将随之触发。

完整解析过程如下图：

每一个呈现器都代表了一个矩形的区域，通常对应于相关节点的 CSS 框，这一点在 CSS2 规范中有所描述。它包含诸如宽度、高度和位置等几何信息。就是我们 CSS 里常提到的盒子模型。构建呈现树时，需要计算每一个呈现对象的可视化属性。这是通过计算每个元素的样式属性来完成的。由于应用规则涉及到相当复杂的层叠规则，所以给样式树的构建造成了巨大的困难。为什么说它复杂？因为同一个元素可能涉及多条样式，就需要判断最终到底哪条样式生效。首先我们来了解一下css的样式层叠规则

根据不同的样式来源优先级排列从小到大：

1>、用户端声明：来自浏览器的样式，被称作 UA style，是浏览器默认的样式。 比如，对于 DIV 元素，浏览器默认其 ‘display’ 的特性值是 “block”，而 SPAN 是 “inline”。

2>、一般用户声明：这个样式表是使用浏览器的用户，根据自己的偏好设置的样式表。比如，用户希望所有 P 元素中的字体都默认显示成蓝色，可以先定义一个样式表，存成 css 文件。

3>、一般作者声明:即开发者在开发网页时，所定义的样式表。

4>、加了’!important’ 的作者声明

5>、加了’!important’ 的用户声明

!important 规则1:根据 CSS2.1 规范中的描述，’!important’ 可以提高样式的优先级，它对样式优先级的影响是巨大的。
注意，’!important’ 规则在 IE7 以前的版本中是被支持不完善。因此，经常被用作 CSS hack2。

如果来源和重要性相同则根据CSS specificity来进行判定。

特殊性的值可以看作是一个由四个数组成的一个组合，用 a，b，c，d 来表示它的四个位置。 依次比较 a，b，c，d 这个四个数比较其特殊性的大小。比如，a 值相同，那么 b 值大的组合特殊性会较大，以此类推。 注意，W3C 中并不是把它作为一个 4 位数来看待的。
a，b，c，d 值的确定规则：

如果 HTML 标签的 ‘style’ 属性中该样式存在，则记 a 为 1；

数一下选择器中 ID 选择器的个数作为 b 的值。比如，样式中包含 ‘#c1’ 和 ‘#c2’ 的选择器；

其他属性以及伪类（pseudo-classes）的总数量是 c 的值。比如’.con’，’:hover’ 等；

元素名和伪元素的数量是 d 的值

在这里我们来看一个W3C给出的例子：

那么在如下例子中字体的显示应当为绿色：

总结为表格的话计算规则如下：

为了简化样式计算，Firefox 还采用了另外两种树：规则树和样式上下文树。Webkit 也有样式对象，但它们不是保存在类似样式上下文树这样的树结构中，只是由 DOM 节点指向此类对象的相关样式。

样式上下文包含端值。要计算出这些值，应按照正确顺序应用所有的匹配规则，并将其从逻辑值转化为具体的值。例如，如果逻辑值是屏幕大小的百分比，则需要换算成绝对的单位。规则树的点子真的很巧妙，它使得节点之间可以共享这些值，以避免重复计算，还可以节约空间。
所有匹配的规则都存储在树中。路径中的底层节点拥有较高的优先级。规则树包含了所有已知规则匹配的路径。规则的存储是延迟进行的。规则树不会在开始的时候就为所有的节点进行计算，而是只有当某个节点样式需要进行计算时，才会向规则树添加计算的路径。
这个想法相当于将规则树路径视为词典中的单词。如果我们已经计算出如下的规则树：

假设我们需要为内容树中的另一个元素匹配规则，并且找到匹配路径是 B - E - I（按照此顺序）。由于我们在树中已经计算出了路径 A - B - E - I - L，因此就已经有了此路径，这就减少了现在所需的工作量。

那么Firefox是如何解决样式计算难题的呢？接下来看一个样例，假设我们有如下HTML代码：

并且我们有如下规则：

为了简便起见，我们只需要填充两个结构：color 结构和 margin 结构。color 结构只包含一个成员（即“color”），而 margin 结构包含四条边。
形成的规则树如下图所示（节点的标记方式为“节点名 : 指向的规则序号”）：

上下文树如下图所示（节点名 : 指向的规则节点）：

假设我们解析 HTML 时遇到了第二个