http系列--从输入 URL 到页面加载完成的过程

1、前言

这道题的覆盖面能够很是广，很适合做为一道承载知识体系的题目。每个前端人员，若是要往更高阶发展，必然会将本身的知识体系梳理一遍，没有牢固的知识体系，没法往更高处走！

 

2、主干流程

在将浏览器渲染原理、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安全等）

 

3、从浏览器接收到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协议，就会新建一个网络线程去处理资源下载。

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

 

4、开启网络线程到发出一个完整的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七层框架：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层

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

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

 

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

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

包括：均衡负载，

一、负载均衡

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

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

二、后台处理

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

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

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

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

具体归纳一下：

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

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

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

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

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

 

6、后台和前台的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 方法。

好比有些状态码来判断：

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

 

二、 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域名，不过请合理使用）

 

关于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），而后证书中的公钥以及制定的加密方法加密`Premaster secret`（预主密码），发送给服务器。

三、利用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并利用对称加密算法进行加密

 

7、缓存问题：http缓存

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

一、强缓存与弱缓存

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

区别简介一下：

（1）强缓存（200 from cache）时，浏览器若是判断本地缓存未过时，就直接使用，无需发起http请求。

（2）协商缓存（304）时，浏览器会向服务器发起http请求，而后服务端告诉浏览器文件未改变，让浏览器使用户本地缓存。

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

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

 

二、缓存头部简述

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

经过不一样的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">

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

 

三、缓存头部区别

在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优先级高。

 

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

 

8、解析页面流程

前面提到是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页面：

<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对象

最后的DOM树：

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

CSS规则树的生成也是相似

Bytes → characters → tokens → nodes → CSSOM

好比：style.css内容以下：

body { font-size: 16px } p { font-weight: bold } span { color: red } p span { display: none } 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）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!'));

 

六、简单层和复合层

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

简单介绍下：

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

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

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

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

更多参考：http://www.javashuo.com/article/p-apnenkgt-db.html

 

七、Chrome的调试

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

 

八、资源外链的下载

上面介绍了html解析，渲染流程。但实际上，在解析html时，会遇到一些资源链接，此时就须要进行单独处理了。

简单起见，这里将遇到的静态资源分为一下几大类（未列举全部）：

（1）css样式资源

（2）js脚本资源

（3）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，样式表，脚本，图片都已经加载完成了。