一道面试题是如何引起深层次的灵魂拷问？

Hello，豆皮粉们，大家的小可爱来了，这回约稿又获得来自字节跳动的“songEagle ｜ saucxs” ，《一道面试题是如何引起深层次的灵魂拷问？》文章写的由浅入深，从各个方面剖析一道经典面试题须要全方面考虑，尽量考察整个研发测涉及到的知识点，文章以点带面，详细叙述，可能存在不足的地方欢迎你们评论，后续再出一个遗漏地方的文章😘。

做者：saucxs ｜ songEagle

来源：原创

1、前言

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

面试题：请详细介绍一下从输入 URL 到页面加载完成的过程？

这道题的覆盖面能够很是广，很适合做为一道承载知识体系的题目。

每个前端人员，若是要往更高阶发展，必然会将本身的知识体系梳理一遍，没有牢固的知识体系，没法往更高处走！

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

2、分析题干

在对于这道题上，若是对于面试官想要知道的是：简单叙述仍是深刻叙述。

因此须要回答到关键词上，否则多而杂，效果很差，抓不住重点。

接下来咱们从主干流程和深刻的详细叙述分别介绍，我以为这道面试题可能须要15分钟才能讲完。

主干流程回答：是基本功体现，知识概括能力，面面俱到，点到为止。

详细阐述：考察的各个知识点的掌握能力以及掌握到什么程度。

3、主干流程

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

一、从浏览器接收url到开启网络请求线程（涉及到：浏览器机制，线程和进程之间的关系等）

二、开启网络线程到发出一个完整的http请求（涉及到：dns查询，tcp/ip请求，5层网络协议栈等）

三、从服务器接收到请求到对应后台接收到请求（涉及到：均衡负载，安全拦截，后台内部的处理等）

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

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

六、浏览器接收到http数据包后的解析流程（涉及到：html的词法分析，而后解析成dom树，同时解析css生成css规则树，合并生成render树。而后layout布局、painting渲染、复合图层的合成、GPU绘制、外连接处理、loaded和documentloaded等）

七、css可视化格式模型（涉及到：元素渲染规则，如：包含块，控制框，BFC，IFC等概念）

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

九、其余（扩展其余模块：跨域，web安全等）

4、从浏览器接收到url到开启网络请求线程

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

一、浏览器是多进程的

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

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

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

浏览器中各个进程以及做用：

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

二、第三方插件进程：能够是多个进程，负责每个第三方插件的使用，每个第三方插件使用时候会建立一个对应的进程；

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

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

二、浏览器渲染进程（内核进程）

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

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

能够看出来JS引擎是内核进程中的一个线程，因此常说JS引擎时单线程的。

三、解析URL

输入url后，会进行解析（URL是统一资源定位符）。

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

四、网络请求时单独的线程

每一次网络请求都是须要单独开辟单独的线程进行，好比URL解析到http协议，就会新建一个网络线程去处理资源下载。

所以浏览器会根据解析出得协议，开辟一个网络线程，前往请求资源。

5、开启网络线程到发出一个完整的http请求

包括：DNS查询，tcp/ip请求构建，五层互联网协议等等。

一、DNS查询获得IP

若是输入的域名，须要DNS解析成IP，流程以下：

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

（2）若是尚未，就向DNS域名服务器查询（这个过程通过路由，路由也有缓存），查询到对应的IP。

注意：一、域名查询的时候有可能通过CDN调度器（若是CDN有存储功能）；

二、DNS解析是很耗时的，所以若是解析域名过多，首屏加载会变慢，能够考虑使用dns-prefetch优化。

二、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（返回数据）。

三、五层网络协议栈

客户端发出http请求到服务器接收，中间会通过一系列的流程。

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

服务端接收请求具体：反过来。

五层网络协议：

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

二、传输层（TCP，UDP）：创建TCP链接（3次握手）；

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

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

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

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

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

表示层：主要处理两个通讯系统中交互信息的表示方式，包括数据格式交换，数据加密和解密，数据压缩和终端类型转换等。

会话层：具体管理不一样用户和进程之间的对话，如控制登陆和注销过程。

6、从服务器接收请求到对应后台接收到请求

服务端接收到请求时，内部会有不少处理。

包括：均衡负载，

一、负载均衡

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

归纳的说：用户发送的请求指向调度服务器（反向代理服务器，好比nginx的均衡负载），而后调度服务器根据实际的调度算法，分配不一样的请求给对应的集群中的服务器执行，而后调度服务器等待实际服务器的HTTP响应，而且反馈给用户。

二、后台处理

通常后台都部署到容器中。过程以下：

（1）先是容器接收到请求（好比tomcat容器）；

（2）而后对应容器中的后台程序接收到请求（好比java程序）；

（3）而后就是后台本身的统一处理，处理完毕后响应结果。

具体归纳一下：

（1）通常有的后端有统一的验证，好比安全拦截，跨域验证；

（2）若是不符合验证规则，就直接返回相应的http报文（拒绝请求等）；

（3）若是验证经过了，才会进入到实际的后台代码，此时程序接收到请求，而后执行查询数据库，大量计算等等；

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

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

7、后台和前台的http交互

先后端的交互，http报文做为信息的载体。

一、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 方法。好比有些状态码来判断：

1. 200——代表该请求被成功地完成，所请求的资源发送回客户端

2. 304——自从上次请求后，请求的网页未修改过，请客户端使用本地缓存

3. 400——客户端请求有错（譬如能够是安全模块拦截）

4. 401——请求未经受权

5. 403——禁止访问（譬如能够是未登陆时禁止）

6. 404——资源未找到

7. 500——服务器内部错误

8. 503——服务不可用

大体范围

1. 1xx——指示信息，表示请求已接收，继续处理

2. 2xx——成功，表示请求已被成功接收、理解、接受

3. 3xx——重定向，要完成请求必须进行更进一步的操做

4. 4xx——客户端错误，请求有语法错误或请求没法实现

5. 5xx——服务器端错误，服务器未能实现合法的请求

1.2 请求头/响应头

经常使用的请求头（部分）

经常使用的响应头（部分）

通常来讲，请求头部和响应头部是匹配分析的。

好比：

（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报文结构的简要分析：

二、 cookie以及优化

cookie是浏览器的一种本地存储方式，通常用来帮助客户端和服务端通讯的，经常使用来进行身份校验，结合服务端的session使用。

通常来讲，cookie是不容许存放敏感信息的（千万不要明文存储用户名、密码），由于很是不安全，若是必定要强行存储，首先，必定要在cookie中设置httponly（这样就没法经过js操做了），另外能够考虑rsa等非对称加密（由于实际上，浏览器本地也是容易被攻克的，并不安全）

好比这样的场景：

固然了，针对这种场景，是有优化方案的（多域名拆分）。具体作法就是：

（1）将静态资源分组，分别放到不一样的域名下（如static.base.com）

（2）而page.base.com（页面所在域名）下请求时，是不会带上static.base.com域名的cookie的，因此就避免了浪费

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

（1）在移动端，若是请求的域名数过多，会下降请求速度（由于域名整套解析流程很浪费时间，并且移动端通常带宽比不上PC）。

（2）这时候有个优化方案：dns-prefetch（这个是干吗的？就是让浏览器空闲时提早解析dns域名，不过请合理使用）

关于cookie的交互，能够看下图总结

三、gzip压缩

首先，gzip是请求头里的Accept-Encoding：浏览器支持的压缩类型之一。gzip是一种压缩格式，须要浏览器支持才有效（通常浏览器都支持），并且gzip的压缩率很好（高达70%）；

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

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

因此通常只须要在服务器上开启gzip压缩，而后以后的请求都是基于gzip压缩格式的，很是方便。

四、长链接和短链接

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

（1）长链接：一个tcp/ip链接上能够连续发送多个数据包，tcp链接保持期间，若是乜有数据包发送，须要双方发检测包以维持此链接，通常须要本身作在线维持（相似于心跳包）。

（2）短链接：通讯双方有数据交互是，简历一个tcp链接，数据发送完成后，则断开此tcp链接。

咱们再看一下http层面上：

（1）http1.0中，默认是使用的短链接，浏览器每进行一次http操做，就创建一次链接，任务结束就中断链接，好比每个静态资源请求都是一个单独的链接

（2）http1.1开始，默认是使用长链接，长链接会设置connection: keep-alive，在长链接的状况下，当一个网页打开后，客户端和服务端之间用于传输http的tcp链接不会关闭，若是客户端再次访问服务器这个页面，会继续使用这一条已经创建起来的链接。

注意：kee-alive不会永远保持，他有一个持续时间，通常服务中进行配置，另外长链接是须要客户端和服务器端都支持才有效。

五、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）请求优先级（若是流被赋予了优先级，就会基于这个优先级来处理，有服务器决定须要多少资源来处理该请求）

六、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）浏览器收到服务端证书后：

一、首先验证证书的合法性（颁发机构是否合法，证书包含的网站是否和正在访问的同样），若是证书信任，浏览器会显示一个小头锁，不然会有提示。

二、用户接受到证书后（无论信任不信任），浏览器会产生一个新的随机数（Premaster secret），而后证书中的公钥以及制定的加密方法加密 Premastersecret（预主密码），发送给服务器。

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

四、使用约定好的hash算法计算握手消息，并使用生成的session key 对消息进行加密，最后将以前生成的全部信息发送给服务端。

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

一、利用已知的加密方式与本身的私钥进行解密，获取Premaster secret，

二、和浏览器相同规则生成session key，

三、使用session key 解密浏览器发来的握手消息，并验证hash是否与浏览器发来的一致，

四、使用session key 加密一段握手消息，发送给浏览器

（5）浏览器解密并计算握手消息的hash值，若是与服务端发来的hash一致，此时握手结束。

以后全部的https通讯数据将由以前浏览器生成的session key并利用对称加密算法进行加密

8、缓存问题：http缓存

http交互中，缓存很大程度上提高效率。

一、强缓存与弱缓存

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

区别简介一下：

对于协商缓存，可使用ctrl + F5强制刷新，使得协商缓存无效。

对于强制缓存，在未过时，必须更新资源路径才能发送新的请求。

二、缓存头部简述

怎么在代码中区分强缓存和协商缓存？

经过不一样的http的头部控制。

属于强制缓存的：

1. （http1.1）Cache-Control/Max-Age

2. （http1.0）Pragma/Expires

注意：cache_control的值：public，private，no-store，no-cache，max-age

属于协商缓存的：

1. （http1.1）If-None-Match/E-tag

2. （http1.0）If-Modified-Since/Last-Modified

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

1. <METAHTTP-EQUIV="Pragma"CONTENT="no-cache">

不过，这种方案仍是比较少用到，由于支持状况不佳，譬如缓存代理服务器确定不支持，因此不推荐。

三、缓存头部区别

在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？

一、都是强制缓存。

二、Expires使用服务端时间，由于存在时区，和浏览器本地时间能够修改问题，在http1.1不推荐使用Expires；Cache-Control的Max-Age是浏览器端本地的绝对时间。

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

E-tag相比Last-Modified？

一、都是协商缓存。

二、Last-modified指的是服务端文件最后改变时间，缺陷是精确只能到1s，文件周期性的改变，致使缓存失效；E-tag是一种指纹机制，文件指纹，只要文件改变，E-tag马上变，没有精度限制。

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

各大缓存头部的总体关系以下图

9、解析页面流程

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

一、流程简述

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

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

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

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

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

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

以下图：

二、html解析，构建DOM

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

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

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

浏览器的处理以下：

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

例如：body对象的父节点就是HTML对象，而后段略p对象的父节点就是body对象 最后的DOM树：

三、css解析，构建css规则树

CSS规则树的生成也是相似

1. Bytes→ characters → tokens → nodes → CSSOM

好比：style.css内容以下：

1. body { font-size: 16px}

2. p { font-weight: bold }

3. span { color: red }

4. p span { display: none }

5. img { float: right }

最终的CSSOM树就是

四、构建渲染树

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

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

五、渲染

有了render树，接下来就是开始渲染，基本流程以下：

图中重要的四个步骤就是：

（1）计算CSS样式 ；

（2）构建渲染树 ；

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

（4）绘制，将图像绘制出来。

而后，图中的线与箭头表明经过js动态修改了DOM或CSS，致使了从新布局（Layout）或渲染（Repaint）

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

（1）Layout，也称为Reflow，即回流。通常意味着元素的内容、结构、位置或尺寸发生了变化，须要从新计算样式和渲染树。

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

回流的成本开销要高于重绘，并且一个节点的回流每每回致使子节点以及同级节点的回流， 因此优化方案中通常都包括，尽可能避免回流。

六、什么引发回流

1.页面渲染初始化

2.DOM结构改变，好比删除了某个节点

3.render树变化，好比减小了padding

4.窗口resize

5.最复杂的一种：获取某些属性，引起回流， 不少浏览器会对回流作优化，会等到数量足够时作一次批处理回流， 可是除了render树的直接变化，当获取一些属性时，浏览器为了得到正确的值也会触发回流，这样使得浏览器优化无效，包括

回流必定伴随着重绘，重绘却能够单独出现。

优化方案：

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

（2）避免循环操做dom，建立一个documentFragment或div，在他上面进行全部的dom操做，最后添加到window.document中。

（3）避免屡次读取offset等属性，没法避免就将他们缓存到变量中。

（4）将复杂的元素绝对定位或者固定定位，使他们脱离文档流，不然回流代价很高。

注意：改变字体大小会引发回流。

再看一个例子：

七、简单层和复合层

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

简单介绍下：

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

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

（3）复合图层之间的绘制互不干扰，直接GPU直接控制。

（4）简单图层中，就算是absolute等布局，变化时不影响总体回流，可是因为在同一个图层中，仍然会影响绘制的，所以作动画时候性能仍然很低。并且复合层是独立的，因此通常作动画推荐使用硬件加速。

更多参考：segmentfault.com/a/119000001…

八、Chrome的调试

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

九、资源外链的下载

上面介绍了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的地方

十、loaded和domcontentloaded

对比：

（1）DOMContentLoaded 事件触发时，仅当DOM加载完成，不包括样式表，图片(譬如若是有async加载的脚本就不必定完成)。

（2）load 事件触发时，页面上全部的DOM，样式表，脚本，图片都已经加载完成了。

10、Reference

0、一道面试题是如何引起深层次的灵魂拷问？ mp.weixin.qq.com/s/jy5CmIGHd…

一、github.com/saucxs/full…

二、blog.csdn.net/sinat_21455…

三、book.douban.com/subject/269…

四、github.com/kaola-fed/b…