关于前端:一道面试题是如何引发深层次的灵魂拷问

本文作者：dpfe- 程新松
起源：https://mp.weixin.qq.com/s/6z4qOBrNQcAfNu5ud4mazg

一、前言

有这么一道面试题，如下：

面试题：请具体介绍一下从输出 URL 到页面加载实现的过程？
这道题的覆盖面能够十分广，很适宜作为一道承载常识体系的题目。

每一个前端人员，如果要往更高阶倒退，必然会将本人的常识体系梳理一遍，没有牢固的常识体系，无奈往更高处走！

你不信这道题承载的常识体系宏大？往下看

二、分析题干

在对于这道题上，如果对于面试官想要晓得的是：简略叙述还是深刻叙述。

所以须要答复到关键词上，不然多而杂，成果不好，抓不住重点。

接下来咱们从骨干流程和深刻的具体叙述别离介绍，我感觉这道面试题可能须要 15 分钟能力讲完。

骨干流程答复：是基本功体现，常识演绎能力，八面玲珑，点到为止。

具体论述：考查的各个知识点的把握能力以及把握到什么水平。

三、骨干流程

在将浏览器渲染原理、JS 运行机制、JS 引擎解析流程梳理一遍后，感觉就跟买通了任督二脉一样，有了一个整体的架构，以前的知识点都连贯起来了。

1、从浏览器接管 url 到开启网络申请线程（波及到：浏览器机制，线程和过程之间的关系等）

2、开启网络线程到收回一个残缺的 http 申请（波及到：dns 查问，tcp/ip 申请，5 层网络协议栈等）

3、从服务器接管到申请到对应后盾接管到申请（波及到：平衡负载，平安拦挡，后盾外部的解决等）

4、后盾和前台的 http 交互（波及到：http 头，响应码，报文构造，cookie 等，能够提下动态资源的 cookie 优化，以及编码解码如 gzip 压缩等）

5、缓存问题：http 缓存（波及到：波及到 http 缓存头部，etag，expired，cache-control 等）

6、浏览器接管到 http 数据包后的解析流程（波及到：html 的词法剖析，而后解析成 dom 树，同时解析 css 生成 css 规定树，合并生成 render 树。而后 layout 布局、painting 渲染、复合图层的合成、GPU 绘制、外链接解决、loaded 和 documentloaded 等）

7、css 可视化格局模型（波及到：元素渲染规定，如：蕴含块，管制框，BFC，IFC 等概念）

8、js 引擎解析过程（波及到：js 解释阶段，预处理阶段，执行阶段生成执行上下文，VO（全局对象），作用域链，回收机制等）

9、其余（扩大其余模块：跨域，web 平安等）

四、从浏览器接管到 url 到开启网络申请线程

波及到：浏览器的过程和线程模型，js 的运行机制。

1、浏览器是多过程的

（1）浏览器是多过程的；

（2）不同类型的标签页会开启一个新的过程；

（3）雷同类型的标签页会合并到一个过程中。

浏览器中各个过程以及作用：

1、浏览器过程：只有 1 个过程，（1）负责管理各个标签的创立和销毁；（2）负责浏览器页面显示；（3）负责资源的治理和下载；

2、第三方插件过程：能够是多个过程，负责每一个第三方插件的应用，每一个第三方插件应用时候会创立一个对应的过程；

3、GPU 过程：最多 1 个过程，负责 3D 绘制和硬件加速；

4、浏览器渲染过程：能够是多个过程，浏览器的内核，每个 tab 页一个过程，次要负责 HTML、，css，js 等文件的解析，执行和渲染，以及事件处理等。

2、浏览器渲染过程（内核过程）

每一个 tab 页面是浏览器内核过程，而后这个每一个过程是多线程的，它有几大类子线程：

（1）GUI 线程；（2）JS 引擎线程；（3）事件触发线程；（4）定时器线程；（5）异步的 http 网络申请线程

能够看进去 JS 引擎是内核过程中的一个线程，所以常说 JS 引擎时单线程的。

3、解析 URL

输出 url 后，会进行解析（URL 是对立资源定位符）。

URL 包含几个局部：（1）protocol，协定头，比方 http，https，ftp 等；（2）host，主机域名或者 IP 地址；（3）port，端口号；（4）path，目录门路；（5）query，查问的参数；（6）fragment，# 后边的 hash 值，用来定位某一个地位。

4、网络申请时独自的线程

每一次网络申请都是须要独自开拓独自的线程进行，比方 URL 解析到 http 协定，就会新建一个网络线程去解决资源下载。

因而浏览器会依据解析出得协定，开拓一个网络线程，返回申请资源。

五、开启网络线程到收回一个残缺的 http 申请

包含：DNS 查问，tcp/ip 申请构建，五层互联网协议等等。

1、DNS 查问失去 IP

如果输出的域名，须要 DNS 解析成 IP，流程如下：

（1）浏览器有缓存，间接用浏览器缓存，没有就去本机缓存，没有就看是不是 host。

（2）如果还没有，就向 DNS 域名服务器查问（这个过程通过路由，路由也有缓存），查问到对应的 IP。

留神：1、域名查问的时候有可能通过 CDN 调度器（如果 CDN 有存储性能）；

2、DNS 解析是很耗时的，因而如果解析域名过多，首屏加载会变慢，能够思考应用 dns-prefetch 优化。

2、tcp/ip 申请构建

http 的实质就是 tcp/ip 申请构建。须要 3 次握手规定简历连贯，以及断开连接时候的 4 次挥手。

tcp 将 http 长报文划分为短报文，通过 3 次握手与服务端建设连贯，进行牢靠的传输。

3 次握手步骤：

客户端：hello，你是 server 么？
服务端：hello，我是 server，你是 client 么
客户端：yes，我是 client
建设胜利之后，接下来就是正式传输数据。

而后，等到断开连接时，须要进行 4 次挥手（因为是全双工的，所以须要 4 次握手）。

4 次挥手步骤：

被动方：我曾经敞开了向你那边的被动通道了，只能被动接管了
被动方：收到通道敞开的信息
被动方：那我也通知你，我这边向你的被动通道也敞开了
被动方：最初收到数据，之后单方无奈通信

tcp/ip 的并发限度

浏览器对同一域名下并发的 tcp 连贯是有限度的（2-10 个不等）。而且在 http1.0 中往往一个资源下载就须要对应一个 tcp/ip 申请。所以针对这个瓶颈，又呈现了很多的资源优化计划。

get 和 post 区别

get 和 post 实质都是 tcp/ip，然而除了 http 外层外，在 tcp/ip 层面也有区别。get 会产生 1 个 tcp 数据包，post 产生 2 个 tcp 数据包。

具体就是：

（1）get 申请时，浏览器会把 header 和 data 一起发送进来，服务器响应 200（返回数据）。

（2）post 申请时，浏览器首先发送 headers，服务器响应 100 continue，浏览器再发送 data，服务器响应 200（返回数据）。

3、五层网络协议栈

客户端收回 http 申请到服务器接管，两头会通过一系列的流程。

客户端发送申请具体：从应用层动员 http 申请，到传输层通过三次握手简历 tcp/ip 连贯，再到网络层的 ip 寻址，再到数据链路层的封装成帧，最初在物理层通过物理介质传输。

服务端接管申请具体：反过来。

五层网络协议：

1、应用层（DNS，HTTP）：DNS 解析成 IP 并发送 http 申请；

2、传输层（TCP，UDP）：建设 TCP 连贯（3 次握手）；

3、网络层（IP，ARP）：IP 寻址；

4、数据链路层（PPP）：封装成帧；

5、物理层（利用物理介质传输比特流）：物理传输（通过双绞线，电磁波等各种介质）。

其实也有一个残缺的 OSI 七层框架，与之相比，多了会话层、表示层。

OSI 七层框架：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层

表示层：次要解决两个通信零碎中交互信息的示意形式，包含数据格式替换，数据加密和解密，数据压缩和终端类型转换等。

会话层：具体治理不同用户和过程之间的对话，如管制登录和登记过程。

六、从服务器接管申请到对应后盾接管到申请

服务端接管到申请时，外部会有很多解决，其中最次要的是负载平衡和后盾解决。

1、负载平衡

对于大型项目，并发拜访很大，一台服务器吃不消，个别会有若干台服务器组成一个集群，而后配合反向代理实现平衡负载。平衡负载不止一种实现形式。

概括的说：用户发送的申请指向调度服务器（反向代理服务器，比方 nginx 的平衡负载），而后调度服务器依据理论的调度算法，调配不同的申请给对应的集群中的服务器执行，而后调度服务器期待理论服务器的 HTTP 响应，并且反馈给用户。

2、后盾解决

个别后盾都部署到容器中。过程如下：

（1）先是容器接管到申请（比方 tomcat 容器）；

（2）而后对应容器中的后台程序接管到申请（比方 java 程序）；

（3）而后就是后盾本人的对立解决，处理完毕后响应后果。

具体概括一下：

（1）个别有的后端有对立的验证，比方平安拦挡，跨域验证；

（2）如果不合乎验证规定，就间接返回相应的 http 报文（拒绝请求等）；

（3）如果验证通过了，才会进入到理论的后盾代码，此时程序接管到申请，而后执行查询数据库，大量计算等等；

（4）等程序执行结束后，会返回一个 http 响应包（个别这一步会通过多层封装）；

（5）而后将这个数据包从后端返回到前端，实现交互。

七、后盾和前台的 http 交互

前后端的交互，http 报文作为信息的载体。

1、http 报文构造

报文个别包含：通用头部，申请 / 响应头部，申请 / 响应体

1.1 通用头部

Request Url: 申请的 web 服务器地址

Request Method: 申请形式
（Get、POST、OPTIONS、PUT、HEAD、DELETE、CONNECT、TRACE）

Status Code: 申请的返回状态码，如 200 代表胜利

Remote Address: 申请的近程服务器地址（会转为 IP）
比方跨区回绝时，methord 为 option，状态码 404/405。

其中 method 分为两批次：

HTTP1.0 定义了三种申请办法：GET, POST 和 HEAD 办法。
以及几种 Additional Request Methods：PUT、DELETE、LINK、UNLINK

HTTP1.1 定义了八种申请办法：GET、POST、HEAD、OPTIONS, PUT, DELETE, TRACE 和 CONNECT 办法。
比方有些状态码来判断：

200——表明该申请被胜利地实现，所申请的资源发送回客户端
304——自从上次申请后，申请的网页未修改过，请客户端应用本地缓存
400——客户端申请有错（譬如能够是平安模块拦挡）401——申请未经受权
403——禁止拜访（譬如能够是未登录时禁止）404——资源未找到
500——服务器外部谬误
503——服务不可用

大抵范畴

1xx——批示信息，示意申请已接管，持续解决
2xx——胜利，示意申请已被胜利接管、了解、承受
3xx——重定向，要实现申请必须进行更进一步的操作
4xx——客户端谬误，申请有语法错误或申请无奈实现
5xx——服务器端谬误，服务器未能实现非法的申请

1.2 申请头 / 响应头

罕用的申请头（局部）

Accept: 接管类型，示意浏览器反对的 MIME 类型（对标服务端返回的 Content-Type）Accept-Encoding：浏览器反对的压缩类型, 如 gzip 等, 超出类型不能接管
Content-Type：客户端发送进来实体内容的类型
Cache-Control: 指定申请和响应遵循的缓存机制，如 no-cache
If-Modified-Since：对应服务端的 Last-Modified，用来匹配看文件是否变动，只能准确到 1s 之内，http1.0 中
Expires：缓存管制，在这个工夫内不会申请，间接应用缓存，http1.0，而且是服务端工夫
Max-age：代表资源在本地缓存多少秒，无效工夫内不会申请，而是应用缓存，http1.1 中
If-None-Match：对应服务端的 ETag，用来匹配文件内容是否扭转（十分准确），http1.1 中
Cookie: 有 cookie 并且同域拜访时会主动带上
Connection: 当浏览器与服务器通信时对于长连贯如何进行解决, 如 keep-alive
Host：申请的服务器 URL
Origin：最后的申请是从哪里发动的（只会准确到端口）,Origin 比 Referer 更尊重隐衷
Referer：该页面的起源 URL(实用于所有类型的申请，会准确到具体页面地址，csrf 拦挡罕用到这个字段)
User-Agent：用户客户端的一些必要信息，如 UA 头部等

罕用的响应头（局部）

Access-Control-Allow-Headers: 服务器端容许的申请 Headers
Access-Control-Allow-Methods: 服务器端容许的申请办法
Access-Control-Allow-Origin: 服务器端容许的申请 Origin 头部（譬如为 *）Content-Type：服务端返回的实体内容的类型
Date：数据从服务器发送的工夫
Cache-Control：通知浏览器或其余客户，什么环境能够平安的缓存文档
Last-Modified：申请资源的最初批改工夫
Expires：应该在什么时候认为文档曾经过期, 从而不再缓存它
Max-age：客户端的本地资源应该缓存多少秒，开启了 Cache-Control 后无效
ETag：申请变量的实体标签的以后值
Set-Cookie：设置和页面关联的 cookie，服务器通过这个头部把 cookie 传给客户端
Keep-Alive：如果客户端有 keep-alive，服务端也会有响应（如 timeout=38）Server：服务器的一些相干信息

一般来说，申请头部和响应头部是匹配剖析的。

比方：

（1）申请头部的 Accept 要和响应头部的 Content-Type 匹配，否则会报错；

（2）跨域申请中，申请头部的 Origin 要匹配响应头的 Access-Control-Allow-Origin，否则会报跨域谬误；

（3）应用缓存，申请头部的 if-modified-since，if-none-match 别离和响应头的 Last-modified，etag 对应。

1.3 申请 / 响应实体

http 申请时，除了头部，还有音讯实体。

申请实体中会将一些须要的参数都放入进入（用于 post 申请）。

比方：（1）实体中能够放参数的序列化模式（a=1&b=2 这种），或者间接放表单（Form Data 对象，上传时能够夹杂其余以及文件）等等。

响应实体中，就是服务端须要传给客户端的内容。

个别当初的接口申请时，实体中就是对应信息的 json 格局，而像页面申请这种，外面就是间接放一个 html 的字符串，而后浏览器本人解析并渲染。

1.4 CRLF

CRLF（Carriage-Return Line-Feed），意思是回车换行，个别作为分隔符存在。

申请头和实体音讯之间有一个 CRLF 分隔，响应头部和响应实体之间用一个 CRLF 分隔。

下图是对某申请的 http 报文构造的简要剖析：

2、cookie 以及优化

cookie 是浏览器的一种本地存储形式，个别用来帮忙客户端和服务端通信的，罕用来进行身份校验，联合服务端的 session 应用。

在登陆页面，用户登陆了

此时，服务端会生成一个 session，session 中有对于用户的信息（如用户名、明码等）而后会有一个 sessionid（相当于是服务端的这个 session 对应的 key）而后服务端在登录页面中写入 cookie，值就是:jsessionid=xxx

而后浏览器本地就有这个 cookie 了，当前拜访同域名下的页面时，主动带上 cookie，主动测验，在无效工夫内无需二次登陆。

一般来说，cookie 是不容许寄存敏感信息的（千万不要明文存储用户名、明码），因为十分不平安，如果肯定要强行存储，首先，肯定要在 cookie 中设置 httponly（这样就无奈通过 js 操作了），另外能够思考 rsa 等非对称加密（因为实际上，浏览器本地也是容易被攻克的，并不平安）

比方这样的场景：

客户端在域名 A 下有 cookie（这个能够是登陆时由服务端写入的）而后在域名 A 下有一个页面，页面中有很多依赖的动态资源（都是域名 A 的，譬如有 20 个动态资源）此时就有一个问题，页面加载，申请这些动态资源时，浏览器会默认带上 cookie

也就是说，这 20 个动态资源的 http 申请，每一个都得带上 cookie，而实际上动态资源并不需要 cookie 验证

此时就造成了较为重大的节约，而且也升高了访问速度（因为内容更多了）

当然了，针对这种场景，是有优化计划的（多域名拆分）。具体做法就是：

（1）将动态资源分组，别离放到不同的域名下（如 static.base.com）

（2）而 page.base.com（页面所在域名）下申请时，是不会带上 static.base.com 域名的 cookie 的，所以就防止了节约

说到多域名拆分，还有一个问题？

（1）在挪动端，如果申请的域名数过多，会升高申请速度（因为域名整套解析流程很浪费时间，而且挪动端个别带宽比不上 PC）。

（2）这时候有个优化计划：dns-prefetch（这个是干嘛的？就是让浏览器闲暇时提前解析 dns 域名，不过请正当应用）

3、gzip 压缩

首先，gzip 是申请头里的 Accept-Encoding：浏览器反对的压缩类型之一。gzip 是一种压缩格局，须要浏览器反对才无效（个别浏览器都反对），而且 gzip 的压缩率很好（高达 70%）；

而后 gzip 个别是 apach，nginx，tomcat 等 web 服务器开启。

除了 gzip 的压缩格局，还有 deflate，没有 gzip 高效，不风行。

所以个别只须要在服务器上开启 gzip 压缩，而后之后的申请都是基于 gzip 压缩格局的，十分不便。

4、长连贯和短连贯

首先咱们看一下 tcp/ip 的定义：

（1）长连贯：一个 tcp/ip 连贯上能够间断发送多个数据包，tcp 连贯放弃期间，如果乜有数据包发送，须要单方发检测包以维持此连贯，个别须要本人做在线维持（相似于心跳包）。

（2）短连贯：通信单方有数据交互是，简历一个 tcp 连贯，数据发送实现后，则断开此 tcp 连贯。

咱们再看一下 http 层面上：

（1）http1.0 中，默认是应用的短连贯，浏览器每进行一次 http 操作，就建设一次连贯，工作完结就中断连贯，比方每一个动态资源申请都是一个独自的连贯

（2）http1.1 开始，默认是应用长连贯，长连贯会设置 connection: keep-alive，在长连贯的状况下，当一个网页关上后，客户端和服务端之间用于传输 http 的 tcp 连贯不会敞开，如果客户端再次拜访服务器这个页面，会持续应用这一条曾经建设起来的连贯。

留神：kee-alive 不会永远放弃，他有一个持续时间，个别服务中进行配置，另外长连贯是须要客户端和服务器端都反对才无效。

5、http2.0

http2.0 不是 https，它相当于 http 的下一代标准（https 也可能是 http2.0 标准）

比拟一下 http1.1 和 http2.0 显著不同中央：

（1）http1.1 中，每申请一个资源，都是须要开启一个 tcp/ip 连贯的，所以对应的后果是：每一个资源对应一个 tcp/ip 申请，因为 tcp/ip 自身有个并发数的限度，资源一旦多了，速度会降落慢下来。

（2）http2.0 中，一个 tcp/ip 申请能够申请多个资源，也就说，只有一次 tcp/ip 申请，就能够申请多个资源，分隔成更小的帧申请，速度显著晋升。

所以，如果 http2.0 全面利用的，很多 http1.1 中的优化计划无需用到（比方：精灵图，动态组员多域名拆分等）。

当初介绍一下 http2.0 的一些个性：

（1）多路复用（一个 tcp/ip 能够申请多个资源）；

（2）首部压缩（http 头部压缩，缩小体积）；

（3）二进制分帧（在应用层跟传输层之间减少一个二进制分帧层，改良传输性能，实现低提早和高吞吐）；

（4）服务器端推送（服务端能够对客户端的一个申请收回多个响应能够被动告诉客户端）；

（5）申请优先级（如果流被赋予了优先级，就会基于这个优先级来解决，有服务器决定须要多少资源来解决该申请）

6、https

https 就是平安版本的 http，比方一些领取操作服务基本上都是基于 https 的，因为 http 申请的安全系数太低了。

简略来看，https 和 http 区别是：在申请前，会建设 ssl 链接，确保接下来的通信都是加密的，无奈轻易截取剖析。

一般来说，须要将网站降级到 https，须要后端反对（后端须要申请证书等），而后 https 的开销比 http 大（因为要额定的简历平安链接和加密等），所以一般来说 http2.0 配合 https 的体验更佳（http2.0 更快）。

次要关注的就是 SSL/TLS 的握手流程，如下（简述）：

（1）浏览器申请建设 SSL 链接，并向服务端发送一个随机数（client random）和客户端反对的加密办法，比方是 RSA 加密，此时是明文传输。

（2）服务端从中选出一组加密算法和 hash 算法，回复一个随机数（server random），并将本人的身份信息以证书的模式发回给浏览器（证书中蕴含了网站地址，非对称加密的公钥，以及证书颁发机构等信息）。

（3）浏览器收到服务端证书后：

1、首先验证证书的合法性（颁发机构是否非法，证书蕴含的网站是否和正在拜访的一样），如果证书信赖，浏览器会显示一个小头锁，否则会有提醒。

2、用户承受到证书后（不论信赖不信赖），浏览器会产生一个新的随机数（Premaster secret），而后证书中的公钥以及制订的加密办法加密Premaster secret（预主明码），发送给服务器。

3、利用 client random，server random 和 premaster secret 通过肯定的算法生成 HTTP 链接数据传输的对称加密 key-‘sessionkey’

4、应用约定好的 hash 算法计算握手音讯，并应用生成的 session key 对音讯进行加密，最初将之前生成的所有信息发送给服务端。

（4）服务端收到浏览器的回复

1、利用已知的加密形式与本人的私钥进行解密，获取 Premaster secret，

2、和浏览器雷同规定生成 session key，

3、应用 session key 解密浏览器发来的握手音讯，并验证 hash 是否与浏览器发来的统一，

4、应用 session key 加密一段握手音讯，发送给浏览器

（5）浏览器解密并计算握手音讯的 hash 值，如果与服务端发来的 hash 统一，此时握手完结。

之后所有的 https 通信数据将由之前浏览器生成的 session key 并利用对称加密算法进行加密

八、缓存问题：http 缓存

http 交互中，缓存很大水平上晋升效率。

1、强缓存与弱缓存

缓存能够简略划分为两种类型：强缓存（200 from cache）与协商缓存（304）；

区别简介一下：

（1）强缓存（200 from cache）时，浏览器如果判断本地缓存未过期，就间接应用，无需发动 http 申请。（2）协商缓存（304）时，浏览器会向服务器发动 http 申请，而后服务端通知浏览器文件未扭转，让浏览器使用户本地缓存。

对于协商缓存，能够应用 ctrl/command + F5 强制刷新，使得协商缓存有效。

对于强制缓存，在未过期，必须更新资源门路能力发送新的申请。

2、缓存头部简述

怎么在代码中辨别强缓存和协商缓存？

通过不同的 http 的头部管制。

属于强制缓存的：

（http1.1）Cache-Control/Max-Age（http1.0）Pragma/Expires

留神：cache_control 的值：public，private，no-store，no-cache，max-age

属于协商缓存的：

（http1.1）If-None-Match/E-tag（http1.0）If-Modified-Since/Last-Modified

再提一点，其实 HTML 页面中也有一个 meta 标签能够管制缓存计划 -Pragma

<META HTTP-EQUIV="Pragma" CONTENT="no-cache">

不过，这种计划还是比拟少用到，因为反对状况不佳，譬如缓存代理服务器必定不反对，所以不举荐。

3、缓存头部区别

在 http1.1 中，呈现了一些新内容，补救 http1.0 有余。

http1.0 中的缓存管制:

（1）Pragma：严格来说不算缓存管制的头部，设置了 no-cache 会让本地缓存生效（属于编译管制，来实现特定的指令）。

（2）Expires：服务端配置，属于强缓存，用来管制在规定的工夫之前，浏览器不会发送大量申请，而间接应用本地缓存，留神：Expires 个别对应服务器端工夫，比方：Expires：Fri, 30 Oct 1998 14:19:41

（3）If-Modified-Since/Last-modified：这两个是成对呈现的，属于协商缓存。其中浏览器头部是 If-Modified-Since，而服务端是 Last-Modified，发送申请时，如果这两个匹配胜利，代表服务器资源并没有扭转，服务端不会返回资源实体，而是返回头部，告知浏览器应用本地缓存。Last-modifed 指文件最初的批改工夫，只能准确到 1S 以内。

http1.1 中缓存的管制：

（1）cache-control：缓存的管制头部，有 nocache，max-age 等多个取值。

（2）Max-Age：服务端配置的，用来管制强缓存的，在规定的工夫内，浏览器不必发出请求，间接应用本地的缓存。Max-Age 是 cache-control 的值，比方：cache-control: max-age=60*1000，值是相对工夫，浏览器本人计算。

（3）If-None-Match/E-tag：这两个是成对的呈现的，属于协商缓存，其中浏览器头部是 If-None-Match，而服务端是 E-tag，同样，发出请求后，如果 If-None-Match 和 E-tag 匹配，代表内容没有变动，通知浏览器应用本地缓存，和 Last-modified 不同，E-tag 更准确，它相似于指纹一样，基于 FileEtag INode Mtime Size 生成的，就是说文件变，指纹就会变，没有精确度的限度。

Cache-Control 相比 Expires？

1、都是强制缓存。

2、Expires 应用服务端工夫，因为存在时区，和浏览器本地工夫能够批改问题，在 http1.1 不举荐应用 Expires；Cache-Control 的 Max-Age 是浏览器端本地的相对工夫。

3、同时应用 Cache-Control 和 Expires，Cache_control 优先级高。

E-tag 相比 Last-Modified？

1、都是协商缓存。

2、Last-modified 指的是服务端文件最初扭转工夫，缺点是准确只能到 1s，文件周期性的扭转，导致缓存生效；E-tag 是一种指纹机制，文件指纹，只有文件扭转，E-tag 立即变，没有精度限度。

3、带有 E-tag 和 Last-modified 时候，E-tag 优先级高。

九、解析页面流程

后面提到是 http 交互，接下来是浏览器获取到 html，而后解析，渲染。

1、流程简述

浏览器内核拿到内容后，渲染大抵分为以下几步：

（1）解析 html，构建 DOM 树；同时解析 CSS，生成 CSS 规定树。

（2）合并 DOM 树和 CSS 规定树，生成 Render 树。

（3）布局 Render 树（layout/reflow）, 负责各元素的尺寸，地位计算。

（4）绘制 render 树（paint），绘制页面像素信息。

（5）浏览器会将各层的信息发给 GPU。GPU 会将各层合成（composite），显示在屏幕上。

2、html 解析，构建 DOM

这一步的流程是这样的：浏览器解析 HTML，构建 DOM 树。实际上，略微开展一下。

解析 html 到构建 dom 过程简述如下：

Bytes -> characters -> tokens -> nodes ->DOM
比方，有这样一个 html 页面：

<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <link href="style.css" rel="stylesheet">
    <title>Critical Path</title>
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg"></div>
  </body>
</html>

列举一下其中一些重点过程：

1. Conversion 转换：浏览器将取得的 HTML 内容（Bytes）基于他的编码转换为单个字符

2. Tokenizing 分词：浏览器依照 HTML 标准规范将这些字符转换为不同的标记 token。每个 token 都有本人独特的含意以及规定集

3. Lexing 词法剖析：分词的后果是失去一堆的 token，此时把他们转换为对象，这些对象别离定义他们的属性和规定

4. DOM 构建：因为 HTML 标记定义的就是不同标签之间的关系，这个关系就像是一个树形构造一样

例如：body 对象的父节点就是 HTML 对象，而后段落 p 对象的父节点就是 body 对象

3、css 解析，构建 css 规定树

CSS 规定树的生成也是相似

Bytes → characters → tokens → nodes → CSSOM

4、构建渲染树

当 DOM 树和 CSSOM 都有了后，就要开始构建渲染树了。一般来说，渲染树和 DOM 树绝对应的，但不是严格意义上的一一对应。

因为有一些不可见的 DOM 元素不会插入到渲染树中，如 head 这种不可见的标签或者 display: none 等

5、渲染

有了 render 树，接下来就是开始渲染，其中重要的四个步骤就是：

（1）计算 CSS 款式；

（2）构建渲染树；

（3）布局，次要定位坐标和大小，是否换行，各种 position overflow z-index 属性；

（4）绘制，将图像绘制进去。

而后，图中的线与箭头代表通过 js 动静批改了 DOM 或 CSS，导致了从新布局（Layout）或渲染（Repaint）

这里 Layout 和 Repaint 的概念是有区别的：

（1）Layout，也称为 Reflow，即回流。个别意味着元素的内容、构造、地位或尺寸产生了变动，须要从新计算款式和渲染树。

（2）Repaint，即重绘。意味着元素产生的扭转只是影响了元素的一些外观之类的时候（例如，背景色，边框色彩，文字色彩等），此时只须要利用新款式绘制这个元素就能够了。

回流的老本开销要高于重绘，而且一个节点的回流往往回导致子节点以及同级节点的回流，所以优化计划中个别都包含，尽量避免回流。

6、什么引起回流

1. 页面渲染初始化

2.DOM 构造扭转，比方删除了某个节点

3.render 树变动，比方缩小了 padding

4. 窗口 resize

5. 最简单的一种：获取某些属性，引发回流，
很多浏览器会对回流做优化，会等到数量足够时做一次批处理回流，
然而除了 render 树的间接变动，当获取一些属性时，浏览器为了取得正确的值也会触发回流，这样使得浏览器优化有效，包含

(1) offset(Top/Left/Width/Height)
(2) scroll(Top/Left/Width/Height)
(3) cilent(Top/Left/Width/Height)
(4) width,height
(5) 调用了 getComputedStyle()或者 IE 的 currentStyle

回流肯定随同着重绘，重绘却能够独自呈现。

优化计划：

（1）缩小逐项更改款式，做好一次性更改款式。或者将款式定义为 class，并一次性更新。

（2）防止循环操作 dom，创立一个 documentFragment 或 div，在他下面进行所有的 dom 操作，最初增加到 window.document 中。

（3）防止屡次读取 offset 等属性，无奈防止就将他们缓存到变量中。

（4）将简单的元素相对定位或者固定定位，使他们脱离文档流，否则回流代价很高。

留神：扭转字体大小会引起回流。

再看一个例子：

var s = document.body.style;

s.padding = "2px"; // 回流 + 重绘
s.border = "1px solid red"; // 再一次 回流 + 重绘
s.color = "blue"; // 再一次重绘
s.backgroundColor = "#ccc"; // 再一次 重绘
s.fontSize = "14px"; // 再一次 回流 + 重绘
// 增加 node，再一次 回流 + 重绘
document.body.appendChild(document.createTextNode('abc!'));

7、简略层和复合层

上述中的渲染中止步于绘制，但实际上绘制这一步也没有这么简略，它能够联合复合层和简略层的概念来讲。

简略介绍下：

（1）能够默认只有一个复合层，所有的 DOM 节点都是在这个复合图层下。

（2）如果开启了硬件加速性能，能够将某一个节点变成复合图层。

（3）复合图层之间的绘制互不烦扰，间接 GPU 间接管制。

（4）简略图层中，就算是 absolute 等布局，变动时不影响整体回流，然而因为在同一个图层中，依然会影响绘制的，因而做动画时候性能依然很低。而且复合层是独立的，所以个别做动画举荐应用硬件加速。

更多参考：https://segmentfault.com/a/11…

8、Chrome 的调试

Chrome 的开发者工具中，Performance 中能够看到具体的渲染过程

9、资源外链的下载

下面介绍了 html 解析，渲染流程。但实际上，在解析 html 时，会遇到一些资源连贯，此时就须要进行独自解决了。

简略起见，这里将遇到的动态资源分为一下几大类（未列举所有）：

1. 遇到外链的解决
2. css 款式资源
3. js 脚本资源
4. img 图片类资源

以下针对每种状况进行具体阐明：

1. 遇到外链的解决

当遇到上述的外链时，会独自开启一个下载线程去下载资源（http1.1 中是每一个资源的下载都要开启一个 http 申请，对应一个 tcp/ip 链接）

2. 遇到 css 款式资源

css 资源解决特点：

（1）css 下载时异步的，不会阻塞浏览器构建 DOM 树；

（2）然而会阻塞渲染，也就是在构建 render 树时，等到 css 下载解析后才进行（与浏览器优化无关，避免 css 规定一直变动，防止反复的构建）

（3）有例外，遇到 media query 申明的 css 是不会阻塞构建 render 树

3. 遇到 js 脚本资源

JS 脚本资源的解决有几个特点：

（1）阻塞浏览器的解析，也就是说发现一个外链脚本时，需期待脚本下载实现并执行后才会持续解析 HTML。

（2）浏览器的优化，个别古代浏览器有优化，在脚本阻塞时，也会持续下载其它资源（当然有并发下限），然而尽管脚本能够并行下载，解析过程依然是阻塞的，也就是说必须这个脚本执行结束后才会接下来的解析，并行下载只是一种优化而已。

（3）defer 与 async，一般的脚本是会阻塞浏览器解析的，然而能够加上 defer 或 async 属性，这样脚本就变成异步了，能够等到解析结束后再执行。

留神，defer 和 async 是有区别的：defer 是提早执行，而 async 是异步执行。

简略的说：

（1）async 是异步执行，异步下载结束后就会执行，不确保执行程序，肯定在 onload 前，但不确定在 DOMContentLoaded 事件的前或后。

（2）defer 是提早执行，在浏览器看起来的成果像是将脚本放在了 body 前面一样（尽管按标准应该是在 DOMContentLoaded 事件前，但实际上不同浏览器的优化成果不一样，也有可能在它前面）。

4. 遇到 img 图片类资源

遇到图片等资源时，间接就是异步下载，不会阻塞解析，下载结束后间接用图片替换原有 src 的中央

10、loaded 和 domcontentloaded

比照：

（1）DOMContentLoaded 事件触发时，仅当 DOM 加载实现，不包含样式表，图片(譬如如果有 async 加载的脚本就不肯定实现)。

（2）load 事件触发时，页面上所有的 DOM，样式表，脚本，图片都曾经加载实现了。

十、Reference

1、https://github.com/saucxs/ful…

2、https://blog.csdn.net/sinat_2…

3、https://book.douban.com/subje…

4、https://github.com/kaola-fed/…

The End