什么是關鍵渲染路徑？
它是一系列在首屏渲染中必須發生事件。
例如：獲取html > 獲取資源 > 解析 > 顯示頁面
優化這些事件可以帶來頁面速度的巨大提升。
關鍵渲染路徑可以實現一件非常美妙的事。
它使得你可以讓一個具有許多資源需要加載的大型頁面變得比只需加載少許資源小頁面速度更快。
雖然大部分網頁可以分成許多塊內容，但我們不可能為了是頁面加載更快而簡單的刪除頁面的某些部分。如果你曾經有過“那我該怎么做才能時我的頁面變快呢？” 或者 “谷歌是如何讓頁面在一秒之內加載完成的？”，那么這個概念就是為你准備的！
優化關鍵渲染路徑
為了使概念更清晰，我們在解釋一些關鍵字：
critical：絕對必須的
render: 展現（這里是指頁面對用戶可視）
path：一些列事件使得我們的頁面可以展現
initial view：也叫做“above the fold”， 它指的是用戶不用滾動就可以看到的那部分頁面。
所以換句話說，渲染路徑就是指一系列事件使得首屏得以展現。
因為事實上幾乎每個網站在展現過程中都有一些多余的步驟，這是真正可以優化的地方。
優化關鍵路徑可以減少頁面加載時間，這是條捷徑！
路徑
在顯示頁面之前，瀏覽器必須先加載頁面中調用的所有資源。這里把一個只有一張圖片、一個css文件和js文件的頁面作為例子。
讓我們看看頁面呈現之前需要的步驟...
1.瀏覽器下載html文件
2.瀏覽器讀取html文件，發現里面包含一張圖片、一個css文件和一個js文件
3.瀏覽器開始下載圖片
4.瀏覽器阻塞渲染，直到css和js文件下載完成
5.瀏覽器下載css文件並解析，確認沒有內嵌的額外資源（通過import）需要記載
6.瀏覽器在未下載完js文件前，繼續組賽渲染
7.瀏覽器下載完js文件並解析，確保沒有額外的資源需要加載
8.最后瀏覽器渲染出頁面
以上只是一個簡單頁面渲染所需要的步驟，現在想象下你的頁面需要的步驟。
你的頁面可能有一個社交按鈕，多個css文件，多個js文件，許多圖片、插件以及音頻、視頻等。
這意味着你的渲染路徑將會是一大團亂。
很多網站的渲染路徑極其糟糕，因為他們的頁面調用了太多東西，導致瀏覽器需要先加載完這些資源，才能顯示網頁。
這是你的優勢。當你的網頁比競爭對手更快，你的用戶會很開心。（谷歌瀏覽器喜歡這樣的網站）
渲染
某些資源的加載會阻塞頁面渲染。最普遍的就是css和js文件。瀏覽器必須先加載這些東西，才能把網頁展現給用戶。然我們來看一個普遍的場景。
Wordpress 博客使用主題。大多數主題有多個css文件（這就是為什么有這么一條頁面加速方針－－“合並外部css資源”）。所有的css資源可以被合並成一個文件，但是當你添加主題時，實現上需要多個css文件。所以即使顯示一個字符都需要瀏覽器先加載和解析這些文件，這意味需要等待多個對服務器的請求返回。這就是眾所周知的阻塞渲染css。
一個訪客打開你的頁面時將是空白的，直到渲染的關鍵步驟完成。
但是即使你的css已經加載完成你的博客也不能完成渲染，因為wordpress主題還包括多個js文件。在這些js未被加載完成之前，頁面將被阻塞渲染，這就是所謂的渲染阻塞js。
所以一個典型的wordpress頁面渲染需要發出20多個請求去加載css和js。但是等等，你還有社交按鈕或者組建，這些都需要加載額外css和js文件。所以，在一邊博客呈現給用戶之前都需要加載好多資源。
但是不是只有wordpress才這樣，我只是用它作為一個例子。首屏渲染需要加載多個資源是相當普遍的。
這些渲染的延遲是可控的，這與關鍵渲染路徑有關。
關鍵性
目前為止我描述了一張非常灰暗的景象，但是好消息是你可以在頁面加載數以百萬的東西，它可以包含12000張圖片，200個js，然而頁面仍可以在一秒內加載完。
這是如何實現的？
通過理解什么對於首屏渲染是關鍵的。
優化渲染路徑
其實只有三件事我們需要關注：
- 優化關鍵資源數量
- 優化關鍵子節數
- 優化關鍵路徑長度
例子
圖片 － 即使一個頁面有12000張圖片，可能只有一二張在屏幕可視區。這意味着，如果我們只加載這倆張圖片，我們可以是的首屏加載時間更短。我們不用展示全部的12000張圖片，我們只需要展示首屏的圖片就行了，其余的可以延遲加載。
js文件 － 我們也可以有12000個js文件，但我們只需要加載首屏需要的js，其他的js可以延遲加載。
css文件 － 最小化css方法不是在線工具，而是在一開始的時候就不要用太多的css，比如減少20%的css。當然還有其他方式，比如合並外部css文件，這樣你可以減少渲染時需要加載的文件數量。你還可以內嵌一些css在頁面里。無論你的css是大是小，你的用戶在看到頁面之前都要先等待這些資源的加載。
下面我們將會看到一個頁面以及我們如何運用關鍵路徑的知識來使頁面顯著變快。
理解頁面速度的衡量
谷歌所說的頁面速度不是指下載一個頁面所需要的時間。他們關心的是用戶開始看到內容以及可交互能有多快。
谷歌使用頁面速度來作為網頁排名因素是基於對用戶的統計數據。用戶使用谷歌搜索到的頁面如果打開很慢的話，這將是一種糟糕的體驗。
大家會抱怨谷歌說，“為什么你發給我一個加載這么這么慢的頁面”，這就是所謂的可感知速度。
如果一個用戶需要看着一個空白頁等待10秒加載，谷歌將不會將這樣的頁面顯示在搜索結果中。
當我們談到頁面速度時，我們真正關心的是使用戶盡可能快的看到我們的首屏內容。
一個優化首屏加載速度的實際例子
你正在閱讀的這個頁面將會成為我們的例子。這個頁面在半秒之內能加載完，但是它並沒有你的網站那么復雜。我將會向你展示這個頁面的倆個版本，其中一個頁面是有做關鍵路徑優化的。
通過對比這倆個版本，你將會明白優化有多么重要。這里也會說明谷歌是如何衡量頁面加載的。這個頁面調用了多個js而不是統一的一個，然我們看看頁面都有些什么...
- 多張大圖
- css
- 谷歌分析插件
- 谷歌+插件
- Viglinks廣告插件
簡單說，我用到了一個頁面通常需要的一些東西(圖片、css、監控、社交)。你可能也在你的頁面用到了這些東西。通過優化關鍵路勁，我實際是將會使把對這些東西的調用合並為一個請求。瀏覽器渲染這個頁面只需要一個html文件。一個12k的小文件，這個頁面的加載幾乎是瞬間完成。
另一方面，非優化版本將會發出數十個請求，這在電腦上加載就很慢更別說在手機上了。然而，倆個頁面的內容給其實是一模一樣的。然我們繼續，亮出真貨...
優化版本
渲染時間：1.3s
注：這個頁面需要加載很多文件后，才能展示（圖片最右邊的藍色豎線標識頁面所需資源加載完成）
從圖中我們可以看到非優化版需要加載多少的文件，總共加載了1.5s，你可以在這里查看非優化的版本，查看html源碼以及具體加載情況。這個頁面是一個相當簡單的靜態頁，但是它仍然調用了20多個請求，這意味着頁面需要等待20個請求加載完成頁面才對用戶可見。
注意，瀏覽器首先加載html，然后是css、圖片、js，所遇這些必須被記載和解析完，頁面才會展示。非優化版本沒有關注關鍵路徑，所以基本上所有資源必須被加載下來在頁面能夠渲染之前。
優化版本
渲染時間：0.25s
注：從圖中我們看到，整個頁面只需要加載一個文件就能渲染了。
優化版本的首屏渲染只需要加載一個文件。這個頁面比非優化版本快5倍，雖然他們的頁面內容是一模一樣的。它依然加載相同的資源，使用同樣的js，但是不同的是，頁面可視時間只需要250ms。
我如何檢查頁面
我看着我的頁面然后問自己，“這個頁面的首屏真正需要加載的是哪些？”。我意識到只有下面這些是首屏需要的：
- logo
- 第一張大圖
- css
這就是說，下面這些資源跟首屏沒有關系：
- 谷歌+插件
- 其余的圖片
- 谷歌分析插件
然后，我看着加載瀑布流圖，意識到這些我不需要的東西，實際花了最多的時間去加載。所以如果我能夠以某種方式把這些非必須的資源移出關鍵路徑，那么我的頁面將會特別快。
我做的優化
- css內嵌 - 我把css從外部文件拿出來直接放在了html里面
- Base 64 編碼logo和第一張大圖 - 我使用base 64 編碼工具把logo圖片放到html文件中
- 優化所有文件 - 我壓縮了所有圖片的大小
- 延遲加載圖片 - 使用js延遲加載圖片
- 延遲加載所有插件的js代碼
- 使用頁面測速工具檢測我的頁面
這是盡我所能從關鍵路徑移出的所有東西，我合並關鍵路徑的所有請求為一個html文件，里面包含了首屏渲染需要的所有東西。
CSSOM
為了更好地理解關鍵選項路徑，需要對CSSOM的基礎理解。CSSOM是CSS 對象模型，它是由你的樣式腳步生成的。如果你想調節好關鍵路徑，對CSSOM的理解是必須的。
關鍵點
- 關鍵路徑是首屏渲染需要的一系列事件
- 優化渲染路徑是移出或者延遲加載首屏不需要的資源
- 大多數js代碼加載可以被延遲到首屏渲染后
- 我通過考慮什么是首屏需要加載的來檢測我的頁面
- 我使用頁面加速優化去移除或者延遲加載非首屏資源
注：我的優化還不是最理想的，因為我的html大小超過了14k這個理想值。
原文：https://varvy.com/pagespeed/critical-render-path.html
注：轉載請注明出處！