［譯］關鍵渲染路徑

什麼是關鍵渲染路徑？

它是一系列在首屏渲染中必須發生事件。
例如：獲取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

注：轉載請註明出處！