內容說明

本文不是關於瀏覽器渲染的底層原理或前端優化具體細節的講解，而是關於瀏覽器對頁面的渲染——這一過程的描述及其背後原理的解釋。這是因為前端優化是一個非常龐大且零散的知識集合，一篇文章如果要寫優化的具體方法恐怕只能做一些有限的列舉。

然而，如果瞭解清楚瀏覽器的渲染過程、渲染原理，其實就掌握了指導原則。根據優化原則，可以實現出無數種具體的優化方案，各種預編譯、預加載、資源合併、按需加載方案都是針對瀏覽器渲染習慣的優化。

關鍵渲染路徑

提到頁面渲染，有幾個相關度非常高的概念，最重要的是關鍵渲染路徑，其他幾個概念都可以從它展開，下面稍作說明。

關鍵渲染路徑（Critical Rendering Path）是指與當前用戶操作有關的內容。例如用戶剛剛打開一個頁面，首屏的顯示就是當前用戶操作相關的內容，具體就是瀏覽器收到 HTML、CSS 和 JavaScript 等資源並對其進行處理從而渲染出 Web 頁面。

瞭解瀏覽器渲染的過程與原理，很大程度上是為了優化關鍵渲染路徑，但優化應該是針對具體問題的解決方案，所以優化沒有一定之規。例如為了保障首屏內容的最快速顯示，通常會提到漸進式頁面渲染，

瀏覽器渲染頁面的過程

從耗時的角度，瀏覽器請求、加載、渲染一個頁面，時間花在下面五件事情上：

1、DNS 查詢

2、TCP 連接

3、HTTP 請求即響應

4、服務器響應

5、客戶端渲染

本文討論第五個部分，即瀏覽器對內容的渲染，這一部分（渲染樹構建、佈局及繪製），又可以分為下面五個步驟：

1、處理 HTML 標記並構建 DOM 樹。

2、處理 CSS 標記並構建 CSSOM 樹。

3、將 DOM 與 CSSOM 合併成一個渲染樹。

4、根據渲染樹來佈局，以計算每個節點的幾何信息。

5、將各個節點繪製到屏幕上。

需要明白，這五個步驟並不一定一次性順序完成。如果 DOM 或 CSSOM 被修改，以上過程需要重複執行，這樣才能計算出哪些像素需要在屏幕上進行重新渲染。

實際頁面中，CSS 與 JavaScript 往往會多次修改 DOM 和 CSSOM，下面就來看看它們的影響方式。

阻塞渲染：CSS 與 JavaScript

談論資源的阻塞時，我們要清楚，現代瀏覽器總是並行加載資源。

例如，當 HTML 解析器（HTML Parser）被腳本阻塞時，解析器雖然會停止構建 DOM，但仍會識別該腳本後面的資源，並進行預加載。

同時，由於下面兩點：

【1】默認情況下，CSS 被視為阻塞渲染的資源，這意味著瀏覽器將不會渲染任何已處理的內容，直至 CSSOM 構建完畢。

【2】JavaScript 不僅可以讀取和修改 DOM 屬性，還可以讀取和修改 CSSOM 屬性。

存在阻塞的 CSS 資源時，瀏覽器會延遲 JavaScript 的執行和 DOM 構建。另外：

當瀏覽器遇到一個/>JavaScript 可以查詢和修改 DOM 與 CSSOM。
CSSOM 構建時，JavaScript 執行將暫停，直至 CSSOM 就緒。

所以，script 標籤的位置很重要。實際使用時，可以遵循下面兩個原則：

CSS 優先：引入順序上，CSS 資源先於 JavaScript 資源。
JavaScript 應儘量少影響 DOM 的構建。

瀏覽器的發展日益加快（目前的 Chrome 官方穩定版是 61），具體的渲染策略會不斷進化，但瞭解這些原理後，就能想通它進化的邏輯。下面來看看 CSS 與 JavaScript 具體會怎樣阻塞資源。

css

<link>

這樣的 link 標籤（無論是否 inline）會被視為阻塞渲染的資源，瀏覽器會優先處理這些 CSS 資源，直至 CSSOM 構建完畢。

渲染樹（Render-Tree）的關鍵渲染路徑中，要求同時具有 DOM 和 CSSOM，之後才會構建渲染樹。即，HTML 和 CSS 都是阻塞渲染的資源。HTML 顯然是必需的，因為包括我們希望顯示的文本在內的內容，都在 DOM 中存放，那麼可以從 CSS 上想辦法。

最容易想到的當然是精簡 CSS 並儘快提供它。除此之外，還可以用媒體類型（media type）和媒體查詢（media query）來解除對渲染的阻塞。

<link>
<link>
<link>

第一個資源會加載並阻塞。

第二個資源設置了媒體類型，會加載但不會阻塞，print 聲明只在打印網頁時使用。

第三個資源提供了媒體查詢，會在符合條件時阻塞渲染。

JavaScript

JavaScript 的情況比 CSS 要更復雜一些。觀察下面的代碼：

Do not go gentle into that good night,




Old age should burn and rave at close of day;




Rage, rage against the dying of the light.
 

Do not go gentle into that good night,




Old age should burn and rave at close of day;




Rage, rage against the dying of the light.

這樣的>

所以實際工程中，我們常常將資源放到文檔底部。

改變阻塞模式：defer 與 async

為什麼要將>

換句話說，defer 與 async 方式可以改變之前的那些阻塞情形。

首先，注意 async 與 defer 屬性對於 inline-script 都是無效的，所以下面這個示例中三個>

下面討論的內容都是針對設置了 src 屬性的>

defer

defer 屬性表示延遲執行引入的 JavaScript，即這段 JavaScript 加載時 HTML 並未停止解析，這兩個過程是並行的。

整個 document 解析完畢且 defer-script 也加載完成之後（這兩件事情的順序無關），會執行所有由 defer-script 加載的 JavaScript 代碼，然後觸發 DOMContentLoaded 事件。

defer 不會改變>

async

async 屬性表示異步執行引入的 JavaScript，與 defer 的區別在於，如果已經加載好，就會開始執行——無論此刻是 HTML 解析階段還是 DOMContentLoaded 觸發之後。

需要注意的是，這種方式加載的 JavaScript 依然會阻塞 load 事件。

換句話說，async-script 可能在 DOMContentLoaded 觸發之前或之後執行，但一定在 load 觸發之前執行。

從上一段也能推出，多個 async-script 的執行順序是不確定的。值得注意的是，向 document 動態添加>

document.createElement

使用 document.createElement 創建的>

console.log(document.createElement("script").async); // true
 

所以，通過動態添加>

如果使用 document.createElement 創建 link 標籤會怎樣呢？

const style = document.createElement("link");
style.rel = "stylesheet";
style.href = "index.css";
document.head.appendChild(style); // 阻塞？

其實這隻能通過試驗確定，已知的是，Chrome 中已經不會阻塞渲染，Firefox、IE 在以前是阻塞的，現在會怎樣我沒有試驗。

document.write 與 innerHTML

通過 document.write 添加的 link 或>

即正常情況下， link 會阻塞渲染，script 會同步執行。不過這是不推薦的方式，Chrome 已經會顯示警告，提示未來有可能禁止這樣引入。

如果給這種方式引入的>

如果使用 innerHTML 引入>

當然，可以通過 eval() 來手工處理，不過不推薦。如果引入 link 標籤，我試驗過在 Chrome 中是可以起作用的。

另外，outerHTML、insertAdjacentHTML() 應該也是相同的行為，我並沒有試驗。

這三者應該用於文本的操作，即只使用它們添加 text 或普通 HTML Element。

閱讀更多 JS加加網 的文章

關鍵字: DNS 渲染 Chrome