本文中瀏覽器特指Chrome瀏覽器

開始之前說說幾個概念美旧，以及在準備寫這篇文章之前對瀏覽器的渲染機制的了解：

DOM：Document Object Model，瀏覽器將HTML解析成樹形的數(shù)據(jù)結構纱兑，簡稱DOM。
CSSOM：CSS Object Model化借，瀏覽器將CSS代碼解析成樹形的數(shù)據(jù)結構
Render Tree：DOM 和 CSSOM 合并后生成 Render Tree(Render Tree 和DOM一樣潜慎，以多叉樹的形式保存了每個節(jié)點的css屬性、節(jié)點本身屬性蓖康、以及節(jié)點的孩子節(jié)點铐炫，display:none 的節(jié)點不會被加入 Render Tree，而 visibility: hidden 則會钓瞭，所以驳遵，如果某個節(jié)點最開始是不顯示的，設為 display:none 是更優(yōu)的山涡。)

查閱了一些關于瀏覽器渲染機制的文章后堤结，得到以下比較重要或者有爭議性的觀點：

1.Create/Update DOM And request css/image/js：瀏覽器請求到HTML代碼后唆迁，在生成DOM的最開始階段（應該是 Bytes → characters 后），并行發(fā)起css竞穷、圖片唐责、js的請求，無論他們是否在HEAD里瘾带。注意：發(fā)起 js 文件的下載 request 并不需要 DOM 處理到那個 script 節(jié)點鼠哥，比如：簡單的正則匹配就能做到這一點，雖然實際上并不一定是通過正則：）看政。這是很多人在理解渲染機制的時候存在的誤區(qū)朴恳。
2.Create/Update Render CSSOM：CSS文件下載完成，開始構建CSSOM
3.Create/Update Render Tree：所有CSS文件下載完成允蚣，CSSOM構建結束后于颖，和 DOM 一起生成 Render Tree。
4.Layout：有了Render Tree嚷兔，瀏覽器已經(jīng)能知道網(wǎng)頁中有哪些節(jié)點森渐、各個節(jié)點的CSS定義以及他們的從屬關系。下一步操作稱之為Layout冒晰，顧名思義就是計算出每個節(jié)點在屏幕中的位置同衣。
5.Painting：Layout后，瀏覽器已經(jīng)知道了哪些節(jié)點要顯示（which nodes are visible）壶运、每個節(jié)點的CSS屬性是什么（their computed styles）耐齐、每個節(jié)點在屏幕中的位置是哪里（geometry）。就進入了最后一步：Painting蒋情，按照算出來的規(guī)則蚪缀，通過顯卡，把內容畫到屏幕上恕出。

出處

瀏覽器的主要組件為 (1.1)：
1.用戶界面 - 包括地址欄、前進/后退按鈕违帆、書簽菜單等浙巫。除了瀏覽器主窗口顯示的您請求的頁面外，其他顯示的各個部分都屬于用戶界面刷后。
2.瀏覽器引擎 - 在用戶界面和呈現(xiàn)引擎之間傳送指令的畴。
3.呈現(xiàn)引擎 - 負責顯示請求的內容。如果請求的內容是 HTML尝胆，它就負責解析 HTML 和 CSS 內容丧裁，并將解析后的內容顯示在屏幕上。
4.網(wǎng)絡 - 用于網(wǎng)絡調用含衔，比如 HTTP 請求煎娇。其接口與平臺無關二庵，并為所有平臺提供底層實現(xiàn)。
5.用戶界面后端 - 用于繪制基本的窗口小部件缓呛，比如組合框和窗口催享。其公開了與平臺無關的通用接口，而在底層使用操作系統(tǒng)的用戶界面方法哟绊。
6.JavaScript 解釋器因妙。用于解析和執(zhí)行 JavaScript 代碼。
7.數(shù)據(jù)存儲票髓。這是持久層攀涵。瀏覽器需要在硬盤上保存各種數(shù)據(jù)，例如 Cookie洽沟。新的 HTML 規(guī)范 (HTML5) 定義了“網(wǎng)絡數(shù)據(jù)庫”以故，這是一個完整（但是輕便）的瀏覽器內數(shù)據(jù)庫。
值得注意的是玲躯，和大多數(shù)瀏覽器不同据德，Chrome 瀏覽器的每個標簽頁都分別對應一個呈現(xiàn)引擎實例。每個標簽頁都是一個獨立的進程跷车。

主流程
呈現(xiàn)引擎一開始會從網(wǎng)絡層獲取請求文檔的內容棘利，內容的大小一般限制在 8000 個塊以內。
然后進行如下所示的基本流程：

呈現(xiàn)引擎將開始解析 HTML 文檔朽缴，并將各標記逐個轉化成“內容樹”上的 DOM 節(jié)點善玫。同時也會解析外部 CSS 文件以及樣式元素中的樣式數(shù)據(jù)。HTML 中這些帶有視覺指令的樣式信息將用于創(chuàng)建另一個樹結構：呈現(xiàn)樹密强。
呈現(xiàn)樹包含多個帶有視覺屬性（如顏色和尺寸）的矩形茅郎。這些矩形的排列順序就是它們將在屏幕上顯示的順序。
呈現(xiàn)樹構建完畢之后或渤，進入“布局”處理階段系冗，也就是為每個節(jié)點分配一個應出現(xiàn)在屏幕上的確切坐標。下一個階段是繪制 - 呈現(xiàn)引擎會遍歷呈現(xiàn)樹薪鹦，由用戶界面后端層將每個節(jié)點繪制出來掌敬。
需要著重指出的是，這是一個漸進的過程池磁。為達到更好的用戶體驗奔害，呈現(xiàn)引擎會力求盡快將內容顯示在屏幕上。它不必等到整個 HTML 文檔解析完畢之后地熄，就會開始構建呈現(xiàn)樹和設置布局华临。在不斷接收和處理來自網(wǎng)絡的其余內容的同時，呈現(xiàn)引擎會將部分內容解析并顯示出來端考。

解析算法
HTML 無法用常規(guī)的自上而下或自下而上的解析器進行解析雅潭。
原因在于：
1.語言的寬容本質揭厚。
2.瀏覽器歷來對一些常見的無效 HTML 用法采取包容態(tài)度。
3.解析過程需要不斷地反復寻馏。源內容在解析過程中通常不會改變棋弥，但是在 HTML 中，腳本標記如果包含 document.write诚欠，就會添加額外的標記顽染，這樣解析過程實際上就更改了輸入內容。
由于不能使用常規(guī)的解析技術轰绵，瀏覽器就創(chuàng)建了自定義的解析器來解析 HTML

處理腳本和樣式表的順序
腳本
網(wǎng)絡的模型是同步的粉寞。網(wǎng)頁作者希望解析器遇到 <script> 標記時立即解析并執(zhí)行腳本。文檔的解析將停止左腔，直到腳本執(zhí)行完畢唧垦。如果腳本是外部的，那么解析過程會停止液样，直到從網(wǎng)絡同步抓取資源完成后再繼續(xù)振亮。此模型已經(jīng)使用了多年，也在 HTML4 和 HTML5 規(guī)范中進行了指定鞭莽。作者也可以將腳本標注為“defer”坊秸，這樣它就不會停止文檔解析，而是等到解析結束才執(zhí)行澎怒。HTML5 增加了一個選項褒搔，可將腳本標記為異步，以便由其他線程解析和執(zhí)行喷面。
預解析
WebKit 和 Firefox 都進行了這項優(yōu)化星瘾。在執(zhí)行腳本時，其他線程會解析文檔的其余部分惧辈，找出并加載需要通過網(wǎng)絡加載的其他資源琳状。通過這種方式，資源可以在并行連接上加載盒齿，從而提高總體速度算撮。請注意，預解析器不會修改 DOM 樹县昂，而是將這項工作交由主解析器處理；預解析器只會解析外部資源（例如外部腳本陷舅、樣式表和圖片）的引用倒彰。
樣式表
另一方面，樣式表有著不同的模型莱睁。理論上來說待讳，應用樣式表不會更改 DOM 樹芒澜，因此似乎沒有必要等待樣式表并停止文檔解析。但這涉及到一個問題创淡，就是腳本在文檔解析階段會請求樣式信息痴晦。如果當時還沒有加載和解析樣式，腳本就會獲得錯誤的回復琳彩，這樣顯然會產生很多問題誊酌。這看上去是一個非典型案例，但事實上非常普遍露乏。Firefox 在樣式表加載和解析的過程中碧浊，會禁止所有腳本。而對于 WebKit 而言瘟仿，僅當腳本嘗試訪問的樣式屬性可能受尚未加載的樣式表影響時箱锐，它才會禁止該腳本。
呈現(xiàn)樹構建
在 DOM 樹構建的同時劳较，瀏覽器還會構建另一個樹結構：呈現(xiàn)樹驹止。這是由可視化元素按照其顯示順序而組成的樹，也是文檔的可視化表示观蜗。它的作用是讓您按照正確的順序繪制內容臊恋。

出處

根據(jù)以上長篇大論，可以歸結為以下幾點：

文章一：
1.瀏覽器請求到html結構后嫂便，并發(fā)請求js,css,圖片等資源捞镰，并不是解析到相應節(jié)點才去發(fā)送網(wǎng)絡請求。

文章二：
1.HTML解析為dom樹毙替，不是簡單的自上而下岸售，而是需要不斷地反復，比如解析到腳本標簽厂画，腳本修改之前已經(jīng)解析的dom凸丸，這就要往回重新解析一遍
2.HTML 解析一部分就顯示一部分（不管樣式表是否已經(jīng)下載完成）
3.<script> 標記會阻塞文檔的解析(DOM樹的構建)直到腳本執(zhí)行完，如果腳本是外部的袱院，需等到腳本下載并執(zhí)行完成才繼續(xù)往下解析屎慢。
4.外部資源是解析過程中預解析加載的(腳本阻塞了解析，其他線程會解析文檔的其余部分忽洛，找出并加載)腻惠，而不是一開始就一起請求的(實際上看起來也是并發(fā)請求的，因為請求不相互依賴)

為了直觀的觀察瀏覽器加載和渲染的細節(jié)欲虚，本地用nodejs搭建一個簡單的HTTP Server集灌。
server.js:

const http = require('http');
const fs = require('fs');
const hostname = '127.0.0.1';
const port = 8080;
http.createServer((req, res) => {
    if (req.url == '/a.js') {
        fs.readFile('a.js', 'utf-8', function (err, data) {
            res.writeHead(200, {'Content-Type': 'text/plain'});
            setTimeout(function () {
                res.write(data);
                res.end()
            }, 10000)
        })
    } else if (req.url == '/b.js') {
        fs.readFile('b.js', 'utf-8', function (err, data) {
            res.writeHead(200, {'Content-Type': 'text/plain'});
            res.write(data);
            res.end()
        })
    } else if (req.url == '/style.css') {
        fs.readFile('style.css', 'utf-8', function (err, data) {
            res.writeHead(200, {'Content-Type': 'text/css'});
            res.write(data);
            res.end()
        })
    } else if (req.url == '/index.html') {
        fs.readFile('index.html', 'utf-8', function (err, data) {
            res.writeHead(200, {'Content-Type': 'text/html'});
            res.write(data);
            res.end()
        })
    }
}).listen(port, hostname, () => {
    console.log('Server running at ' + hostname);
});

index.html:

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="cache-control" content="no-cache,no-store, must-revalidate"/>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>瀏覽器渲染</title>
    <script src='http://127.0.0.1:8080/a.js'></script>
    <link rel="stylesheet" >
</head>
<body>
<p id='hh'>1111111</p>
<script src='http://127.0.0.1:8080/b.js'></script>
<p>222222</p>
<p>3333333</p>
</body>
</html>

可以看到，服務端將對a.js的請求延遲10秒返回复哆。

Server啟動后欣喧，在chrome瀏覽器中打開http://127.0.0.1:8080/index.html

外部資源是如何請求的

看一下TimeLine

可以看到腌零，第一次解析html的時候，外部資源好像是一起請求的唆阿，最后一次Finish Loading是a.js的益涧，因為服務端延遲的10秒鐘。文章二中說資源是預解析加載的驯鳖，就是說style.css和b.js是a.js造成阻塞的時候才發(fā)起的請求闲询，圖中也是可以解釋得通，因為第一次Parse HTML的時候就遇到阻塞臼隔，然后預解析就去發(fā)起請求嘹裂，所以看起來是一起請求的。
將index.html內容增加足夠多摔握，并且在最后面才加入script:

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="cache-control" content="no-cache,no-store, must-revalidate"/>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>瀏覽器渲染</title>
    <link rel="stylesheet" >
</head>
<body>
<p id='hh'>1111111</p>
<p>重復</p>
<p>重復</p>
....
....重復5000行
<script src='http://127.0.0.1:8080/b.js'></script>
<script src='http://127.0.0.1:8080/a.js'></script>
<p>3333333</p>
</body>
</html>

多刷新幾次寄狼，查看TimeLine

可以發(fā)現(xiàn)，當html內容太多的時候氨淌，瀏覽器需要分段接收泊愧，解析的時候也要分段解析。還可以看到盛正，請求資源的時機是無法確定的删咱，但肯定不是同時請求的，也不是解析到指定標簽的時候才去請求豪筝，瀏覽器會自行判斷痰滋，如果當前操作比較耗時，就會去加載后面的資源续崖。

HTML 是否解析一部分就顯示一部分

修改 index.html：

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="cache-control" content="no-cache,no-store, must-revalidate"/>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>瀏覽器渲染</title>
    <link rel="stylesheet" >
</head>
<body>
<p id='hh'>1111111</p>
<p>222222</p>
<script src='http://127.0.0.1:8080/b.js'></script>
<script src='http://127.0.0.1:8080/a.js'></script>
<p>3333333</p>
</body>
</html>

因為a.js的延遲敲街，解析到a.js所在的script標簽的時候，a.js還沒有下載完成严望，阻塞并停止解析多艇，之前解析的已經(jīng)繪制顯示出來了。當a.js下載完成并執(zhí)行完之后繼續(xù)后面的解析像吻。當然峻黍，瀏覽器不是解析一個標簽就繪制顯示一次，當遇到阻塞或者比較耗時的操作的時候才會先繪制一部分解析好的拨匆。

<script>標簽的位置對HTML解析有什么影響

修改index.html：

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="cache-control" content="no-cache,no-store, must-revalidate"/>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>瀏覽器渲染</title>
    <link rel="stylesheet" >
    <script src='http://127.0.0.1:8080/b.js'></script>
    <script src='http://127.0.0.1:8080/a.js'></script>
</head>
<body>
<p id='hh'>1111111</p>
<p>222222</p>
<p>3333333</p>
</body>
</html>

還是因為a.js的阻塞使得解析停止姆涩，a.js下載完成之前，頁面無法顯示任何東西惭每。

整個處理過程中阵面，Parse HTML 3次，計算元素樣式1次，頁面布局計算1次样刷，繪制一次。

修改index.html：

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="cache-control" content="no-cache,no-store, must-revalidate"/>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>瀏覽器渲染</title>
    <link rel="stylesheet" >
</head>
<body>
<p id='hh'>1111111</p>
<p>222222</p>
<p>3333333</p>
<script src='http://127.0.0.1:8080/b.js'></script>
<script src='http://127.0.0.1:8080/a.js'></script>
</body>
</html>

解析到a.js部分的時候览爵，頁面要顯示的東西已經(jīng)解析完了置鼻，a.js不會影響頁面的呈現(xiàn)速度。

整個處理過程中蜓竹，Parse HTML 3次箕母，計算元素樣式2次，頁面布局計算1次俱济，繪制一次嘶是。

修改index.html

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="cache-control" content="no-cache,no-store, must-revalidate"/>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>瀏覽器渲染</title>
    <link rel="stylesheet" >
</head>
<body>
<p id='hh'>1111111</p>
<script src='http://127.0.0.1:8080/b.js'></script>
<script src='http://127.0.0.1:8080/a.js'></script>
<p>222222</p>
<p>3333333</p>
</body>
</html>

阻塞后面的解析，導致不能很快的顯示蛛碌。

整個處理過程中聂喇，Parse HTML 3次，計算元素樣式2次蔚携，頁面布局計算2次希太，繪制2次。
可以發(fā)現(xiàn)瀏覽器優(yōu)化得非常好酝蜒，當阻塞在a.js的時候誊辉，現(xiàn)將已經(jīng)解析的部分顯示（計算元素樣式，布局排版亡脑，繪制）堕澄，當a.js下載好后接著解析和顯示后面的（因為a.js后面還有要顯示到頁面上的元素，所以還需要進行1次計算元素樣式霉咨，布局排版蛙紫，繪制）

修改index.html

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="cache-control" content="no-cache,no-store, must-revalidate"/>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>瀏覽器渲染</title>
    <link rel="stylesheet" >
</head>
<body>
<p id='hh'>1111111</p>
<p>222222</p>
<script src='http://127.0.0.1:8080/a.js'></script>
<p>3333333</p>
<script>
    document.getElementById("hh").style.height="200px";
</script>
</body>
</html>

a.js阻塞的時候，排版躯护，繪制1次惊来；a.js下載完后重排，重繪一次棺滞；修改DOM,引起重排裁蚁，重繪一次。是不是這樣呢继准？看下圖

事實是修改DOM并沒有引起重排枉证，重繪。因為瀏覽器將a.js下載完成并執(zhí)行后的一次重排和重繪與修改DOM本應該導致的重排和重繪積攢一批移必，然后做一次重排室谚，重繪

瀏覽器是聰明的，它不會你每改一次樣式，它就reflow或repaint一次秒赤。一般來說猪瞬，瀏覽器會把這樣的操作積攢一批，然后做一次reflow入篮，這又叫異步reflow或增量異步reflow陈瘦。但是有些情況瀏覽器是不會這么做的，比如：resize窗口潮售，改變了頁面默認的字體痊项，等。對于這些操作酥诽，瀏覽器會馬上進行reflow鞍泉。

css文件的影響

服務端將style.css的相應也設置延遲。
修改index.html：

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="cache-control" content="no-cache,no-store, must-revalidate"/>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>瀏覽器渲染</title>
    <link rel="stylesheet" >
</head>
<body>
<p id='hh'>1111111</p>
<p>222222</p>
<p>3333333</p>
<script src='http://127.0.0.1:8080/a.js'></script>
</body>
</html>

可以看出來肮帐，css文件不會阻塞HTML解析咖驮，但是會阻塞渲染，導致css文件未下載完成之前已經(jīng)解析好html也無法先顯示出來泪姨。

接著修改index.html：

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="cache-control" content="no-cache,no-store, must-revalidate"/>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>瀏覽器渲染</title>
</head>
<body>
<p id='hh'>1111111</p>
<p>222222</p>
<p>3333333</p>
<link rel="stylesheet" >
<script src='http://127.0.0.1:8080/a.js'></script>
</body>
</html>

同樣阻塞渲染

修改index.html

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="cache-control" content="no-cache,no-store, must-revalidate"/>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>瀏覽器渲染</title>
    <link rel="stylesheet"  media="print">
</head>
<body>
<p id='hh'>1111111</p>
<p>222222</p>
<p>3333333</p>
<script src='http://127.0.0.1:8080/a.js'></script>
</body>
</html>

注意media="print"

因為指定了media="print"游沿，樣式不起作用，不會阻塞渲染肮砾。

<link href="style.css" rel="stylesheet">
<link href="style.css" rel="stylesheet" media="all">
<link href="portrait.css" rel="stylesheet media="orientation:portrait">
<link href="print.css" rel="stylesheet" media="print">
第一條聲明阻塞渲染诀黍，匹配所有情況。
第二條聲明一樣阻塞渲染："all" 是默認類型仗处，如果你未指定任何類型眯勾，則默認為 "all"。因此婆誓，第一條聲明和第二條聲明實際上是一樣的吃环。
第三條聲明有一條動態(tài)媒體查詢，在頁面加載時判斷洋幻。根據(jù)頁面加載時設備的方向郁轻，portrait.css 可能阻塞渲染，也可能不阻塞文留。
最后一條聲明只適用打印好唯，因此，頁面在瀏覽器中首次加載時燥翅，不會阻塞渲染骑篙。

但是。森书。靶端』咽疲看一下火狐的表現(xiàn)

圖片資源的影響

修改index.html

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="cache-control" content="no-cache,no-store, must-revalidate"/>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>瀏覽器渲染</title>
    <link rel="stylesheet"  media="print">
</head>
<body>
<p id='hh'>1111111</p>
<p>222222</p>
[站外圖片上傳中……(2)]
<p>3333333</p>
</body>
</html>

圖片比較大，2M多杨名，但服務端還是要延遲10秒響應脏榆。

圖片既不阻塞解析，也不阻塞渲染台谍。

圖片未請求回來之前姐霍，先進行一次layout和paint，paint的范圍就是頁面初始的可視區(qū)域典唇。當返回一部分圖片信息后（估計是得到了圖片的尺寸），再進行一次layout和paint,paint的范圍受到圖片尺寸的影響胯府。當圖片信息全部返回時介衔，最后進行一次paint。
如果固定img的寬高骂因，當返回一部分圖片信息后炎咖，不會再layout，但仍會paint一次寒波。
補充：圖片用作背景（不是寫在CSS文件內）是在Recalculate Style的時候才發(fā)起的請求乘盼，layout、paint次數(shù)和固定寬高的img一樣俄烁。背景圖屬性寫在CSS文件里绸栅，則CSS文件下載并執(zhí)行Recalculate Style的時候才會請求圖片。

參考

瀏覽器的渲染原理簡介
瀏覽器的工作原理：新式網(wǎng)絡瀏覽器幕后揭秘
JS 一定要放在 Body 的最底部么页屠？聊聊瀏覽器的渲染機制
https://blog.chromium.org/2015/03/new-javascript-techniques-for-rapid.html
https://developers.google.cn/web/fundamentals/performance/critical-rendering-path/render-blocking-css