如何優化WordPress網站的關鍵渲染路徑

關鍵渲染路徑是瀏覽器首先在螢幕上渲染頁面所執行的一系列任務，即下載、處理並將HTML、CSS和JavaScript程式碼轉換為實際畫素並將它們繪製在螢幕上。

關鍵渲染路徑優化是最小化瀏覽器執行序列的每個步驟所花費的時間的過程，優先顯示與當前使用者操作相關的內容。

此過程的大部分與無需向下滾動瀏覽器視窗即可看到的頁面部分有關。該部分也稱為“摺疊上方（Above the Fold）”。為了更好的可用性，應該儘快渲染ATF，這可以通過至少減少網路往返次數來實現。渲染ATF所需的資源被認為是關鍵的，優化Above the Fold意味著將關鍵資源對首頁渲染時間的影響降至最低。

在這篇文章中，我們將介紹關鍵渲染路徑優化序列。

首先，我將概述瀏覽器呈現頁面內容的任務。
接下來，我將剖析我們可以執行的最相關的操作來優化關鍵渲染路徑。
最後，我將列出一些有用（且流行）的WordPress優化外掛。

關鍵渲染路徑序列

以下是瀏覽器為呈現頁面而執行的一系列步驟：

首先，瀏覽器下載並解析HTML標記並構建DOM
然後它下載並處理CSS標記並構建CSS物件模型
它在渲染樹中結合了渲染頁面所需的DOM和CSSOM節點，渲染樹是所有可見節點的樹形結構
它計算頁面上每個物件的尺寸和位置
最後，它在螢幕上繪製畫素

DOM

正如Google的關鍵渲染路徑優化指南中所解釋的那樣，瀏覽器按四步順序構建文件物件模型：

首先，瀏覽器讀取行位元組並將它們轉換為單個字元。
然後它將尖括號內的字串轉換為標記。
這些標記被轉換為節點物件。
節點物件以樹狀資料結構連結，其中包含HTML內容、屬性和節點之間的關係。這個結構就是文件物件模型。

這裡需要注意的重要一點是瀏覽器是逐步構建DOM的。這允許我們通過建立高效的DOM結構來加速頁面的渲染。

DOM結構

CSSOM

當解析器遇到一個引用外部CSS樣式表的標籤link時，它會阻止解析併發出對該資源的請求。收到CSS檔案後，瀏覽器開始構建CSS節點的樹形資料結構。

瀏覽器讀取 .css 檔案的行位元組並將它們轉換為單個字元
它將大括號內的字串轉換為標記
這些標記被轉換為節點物件
節點物件以樹狀資料結構連結，其中包含每個節點的CSS屬性以及節點之間的關係。這種結構就是CSS物件模型( CSSOM )。

與DOM構建不同，CSSOM構建不是增量的。瀏覽器不能使用樣式表的一部分，因為樣式可以在同一個樣式表中進行細化和重新宣告。出於這個原因，瀏覽器會阻塞渲染過程，直到它接收並解析所有CSS。這意味著CSS是渲染阻塞的。

CSSOM結構

渲染樹

瀏覽器將DOM和CSSOM組合到渲染樹中，最終的樹結構包含用於將頁面渲染到螢幕的所有節點和屬性。

渲染樹僅包含渲染頁面所需的節點。結果，忽略了不可見的節點。

瀏覽器使用渲染樹計算節點尺寸和位置作為繪畫過程的輸入。

渲染樹結構

佈局和繪製

在佈局階段，瀏覽器計算渲染樹每個節點的尺寸和位置。瀏覽器從根開始遍歷渲染樹，並在此階段生成一個盒子模型。該資訊最終用於將渲染樹的每個節點轉換為螢幕上的實際畫素。

關鍵渲染路徑優化

執行整個過程所需的時間是可變的。這取決於文件大小、請求數量、應用的樣式、使用者裝置等。最相關的Google建議之一是優先考慮可見內容以儘可能快地呈現“首屏”，並提供兩個主要規則跟隨：

構建HTML以首先載入關鍵的首屏內容
減少HTML、CSS和JS資源使用的資料量

正如Google的PageSpeed指南中所解釋的那樣，如果渲染ATF所需的資料量超過了初始擁塞視窗 (14.6kb)，則需要在伺服器和瀏覽器之間進行額外的網路往返。在具有高延遲的行動網路上，這將顯著延遲頁面載入（閱讀有關延遲的更多資訊）。瀏覽器以增量方式構建DOM，允許我們通過構建HTML以首先載入首屏並延遲頁面的其餘部分來減少渲染ATF所需的時間。

摺疊上方的內容因使用者裝置而異

但是優化並不會隨著構建有效的DOM結構而結束。相反，它是一個涉及整個關鍵渲染路徑序列的改進和測量過程。

讓我們深入研究。

最小化資源維度

我們可以通過壓縮、壓縮和快取HTML、CSS和JavaScript資源來減少瀏覽器要下載的資料量：

最小化是從原始碼中刪除不必要的字元（如註釋和空格）的過程。這些字元在開發中很有幫助，但它們對於渲染頁面沒有用。
壓縮是Web伺服器和客戶端減小傳輸檔案大小以提高速度和頻寬利用率的能力
快取：每個瀏覽器都帶有一個HTTP快取的實現。我們需要做的是確保每個伺服器響應都提供正確的HTTP標頭，以指示瀏覽器何時以及應快取請求的資源多長時間

優化CSS

現在我們知道瀏覽器必須等到它獲取並處理CSS程式碼才能呈現頁面（CSS是render-blocking）。但並不是所有的CSS資源都是渲染阻塞的。

CSS可以限定在特定條件下，我們可以使用媒體型別和媒體查詢對其進行優化。如果您在螢幕上檢視網頁，瀏覽器將傳送列印媒體型別請求，但不會阻止此資源的頁面呈現。獲取以下link標籤：

<link href="style.css" />

此標記的引用樣式表適用於任何條件，獨立於當前媒體型別、螢幕解析度、裝置方向等。這意味著CSS資源始終是渲染阻塞的。

幸運的是，我們可以在特定條件下傳送對CSS資源的請求。我們可以將列印樣式移動到一個單獨的檔案中，並使用media屬性告訴瀏覽器指定的樣式表只應在列印頁面時載入，並且不需要阻塞螢幕上的呈現：

<link href="print.css" media="print" />

瀏覽器仍會下載print.css樣式表，但不會阻止呈現。此外，瀏覽器必須為主要的CSS檔案下載更少的資料，這將有助於我們加快下載速度。我們可以在link屬性上指定任何媒體查詢，因此我們可以將CSS拆分為多個檔案並有條件地載入它們：

<link href="style.css" media="screen" />
<link href="portrait.css" media="orientation:portrait" />
<link href="widescreen.css" media="(min-width: 42rem)" />

確保您的樣式實際上是呈現頁面所必需的。您可以將適當的值新增到媒體標籤屬性並取消阻止呈現（如果不是）。

媒體型別和查詢可以幫助我們加快頁面渲染，但我們可以做的更多。

最小化CSS：空白和註釋只能幫助我們閱讀CSS宣告。通過從樣式表中刪除註釋和空格，我們可以顯著減少CSS檔案的位元組數。
合併多個CSS檔案：這將減少HTTP請求的數量。此操作在移動連線中非常重要，其中效能受到高延遲的影響（閱讀更多關於延遲的內容）。
內聯關鍵CSS：某些樣式很關鍵，因為它們需要呈現頁面的首屏。最好始終將內聯關鍵樣式直接考慮到HTML標記中，以避免額外的HTTP請求。但是避免內聯大型CSS檔案，因為這可能需要額外的往返來呈現首屏，從而導致PageSpeed警告。

加快佈局和渲染過程

瀏覽器佈局文件所花費的時間取決於要佈局的DOM元素的數量以及這些佈局的複雜性。

如果你有很多DOM元素，瀏覽器可能需要很長時間來計算它們的位置和尺寸：儘可能避免佈局。
更喜歡新的Flexbox模型，因為它比舊的Flexbox和浮動佈局更快。
避免使用JavaScript強制同步佈局。

計算元素大小和位置需要時間並降低效能。使DOM儘可能簡單並避免使用JavaScript來預測佈局過程將有助於瀏覽器加速頁面呈現（閱讀更多關於佈局優化的內容）。

與Layout緊密相連的是Paint過程，這可能是關鍵渲染路徑序列中最耗時的階段。每當您更改元素或任何非幾何屬性的佈局時，瀏覽器都會觸發繪製事件。在這個階段使事情儘可能簡單可以幫助瀏覽器加快繪畫過程。例如，需要計算的box-shadow屬性比純邊框顏色需要更長的時間來繪製。

Chrome DevTools允許識別正在繪製的頁面部分

優化頁面繪製過程可能並不容易，您應該使用瀏覽器的開發工具來測量瀏覽器觸發每個繪製事件所需的時間。您可以在Google的渲染效能指南中閱讀有關此主題的更多資訊。

使JavaScript解除阻塞

當瀏覽器遇到指令碼標籤時，它必須停止解析HTML程式碼。內聯指令碼在文件中的確切位置執行並阻止DOM構建，直到JS引擎完成執行。換句話說，內聯JavaScript會顯著延遲頁面的初始呈現。但是JavaScript也允許操作CSS屬性，因此瀏覽器必須暫停指令碼執行，直到它完成下載和構建CSSOM。這意味著JavaScript是解析器阻塞的。

在外部JS檔案的情況下，解析器還必須等到從快取或遠端伺服器獲取資源，這可能會大大減慢第一頁渲染的時間。話雖如此，我們可以做些什麼來最小化瀏覽器載入和執行JavaScript所花費的時間呢？

非同步載入JavaScript：script標籤的布林async屬性指示瀏覽器非同步執行指令碼，如果可能，不阻塞DOM構造。瀏覽器傳送指令碼的HTTP請求並繼續解析DOM。此外，該指令碼不會阻塞CSSOM構建，這意味著它不會阻止關鍵渲染路徑（有關指令碼標籤屬性的更多資訊，請參閱MDN 文件）
Defer JavaScript：script標籤的布林defer屬性告訴瀏覽器在解析文件之後、觸發事件DOMContentLoaded之前執行指令碼。如果src屬性不存在，則不得使用此屬性，即內聯指令碼（在Mozilla Hacks上閱讀更多資訊）
推遲內聯 JavaScript：許多指令碼不操作DOM或CSSOM，因此沒有充分的理由阻塞解析。不幸的是，我們不能為內聯指令碼使用async和defer屬性，所以在文件載入後載入它們的唯一方法是將它們移動到底部。優點是內聯指令碼不需要額外的HTTP請求。但是，在多個頁面中使用內聯指令碼會導致程式碼冗餘。

總結優化規則

這是很多東西，不是嗎？讓我們喘口氣，寫下到目前為止描述的優化操作列表。

最小化、壓縮和快取HTML、CSS和JavaScript資源。
儘量減少使用渲染阻塞資源（特別是CSS）
- 在link標籤上使用媒體查詢
- 拆分樣式表和內聯關鍵CSS
- 合併多個CSS 檔案
儘量減少使用解析器阻塞資源 (JavaScript)
- 在指令碼標籤上使用defer屬性
- 在指令碼標籤上使用async屬性
- 內聯JavaScript並將script標籤移動到文件底部