一、前言
這道題的覆蓋面可以非常廣，很適合作為一道承載知識體系的題目。每一個前端人員，如果要往更高階發展，必然會將自己的知識體系梳理一遍，沒有牢固的知識體系，無法往更高處走！
二、主干流程
在將瀏覽器渲染原理、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域名，不過請合理使用）
關於cookie的交互，可以看下圖總結
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 + 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對象最后的DOM樹：
3、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樹就是
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!'));
6、簡單層和復合層
上述中的渲染中止步於繪制，但實際上繪制這一步也沒有這么簡單，它可以結合復合層和簡單層的概念來講。
簡單介紹下：
（1）可以默認只有一個復合層，所有的DOM節點都是在這個復合圖層下。
（2）如果開啟了硬件加速功能，可以將某一個節點變成復合圖層。
（3）復合圖層之間的繪制互不干擾，直接GPU直接控制。
（4）簡單圖層中，就算是absolute等布局，變化時不影響整體回流，但是由於在同一個圖層中，仍然會影響繪制的，因此做動畫時候性能仍然很低。而且復合層是獨立的，所以一般做動畫推薦使用硬件加速。
更多參考：https://segmentfault.com/a/1190000012925872#articleHeader16
7、Chrome的調試
Chrome的開發者工具中，Performance中可以看到詳細的渲染過程：
8、資源外鏈的下載
上面介紹了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的地方
9、loaded和domcontentloaded
對比：
（1）DOMContentLoaded 事件觸發時，僅當DOM加載完成，不包括樣式表，圖片(譬如如果有async加載的腳本就不一定完成)。
（2）load 事件觸發時，頁面上所有的DOM，樣式表，腳本，圖片都已經加載完成了。
【謝謝關注和閱讀，后續新的文章首發：sau交流學習社區：https://www.mwcxs.top/】