HTTP/2 和頁面速度簡介

已發表: 2020-01-03

介紹

1991 年，引入了請求-響應 HTTP (HTTP 0.9) 協議的第一個文檔版本。 從那時起，Web 急劇擴展，24 年後，最新版本的超文本傳輸協議 (HTTP/2) 於 2015 年發布，正確實施後為網站性能帶來了許多可能的好處。

本文針對希望將 HTTP/2 作為其頁面速度優化計劃的一部分的 SEO。

HTTP/2 是一個非常豐富的話題，可以非常詳細地討論。 有大量討論 HTTP/2 的在線信息，它為最終用戶和開發人員帶來了更廣泛的好處，但在您發現自己沉浸在有關 HTTP/2 的大量信息中之前，請確保您獲得了所需的信息。 首先要提出正確的問題：

  1. 這將如何直接影響搜索引擎優化和/或頁面速度？
  2. 可以根據洞察力提出建議嗎？
  3. 建議能否切實執行？

這些問題可以幫助您問“我所做的事情是否有效且有價值？” 並最終使您能夠更好地評估 HTTP/2 如何幫助改進網站。

由於該主題的廣泛性，在嘗試了解對 SEO 的重要性時，不需要大量關於 HTTP/2 的知識。 HTTP/2 對 SEO 的核心好處是頁面速度。

為了幫助您瀏覽豐富的在線信息，這裡是對 HTTP/2 的介紹，描述了從 HTTP 1.1 到 Google 的 HTTP 兼容 Spdy 以及最終到 HTTP/2 的演變。

了解 Web 是如何演變的將有助於突出由於添加 HTTP/2 協議而對其進行的改進。

Google 如何評估 Page Speed？

要了解 Google 如何評估 Page Speed，只需查看Chrome 用戶體驗報告即可。 這些報告提供用戶體驗指標，說明用戶如何體驗網絡上的熱門目的地。 這使用關鍵的用戶參與度指標（首次繪製、首次內容繪製、首次有意義的繪製、交互時間）提供支持，並通過頁面速度洞察、公共 Google 大查詢項目、燈塔和網頁測試等常用工具得到進一步支持。 利用這些指標和工具可以幫助提高頁面速度。

HTTP/2 簡介

HTTP 1.1

到 2015 年，HTTP 1.1 已經過時。 網頁/網站建立/依賴於基本的 HTML、CSS 和 JavaScript 以及大量資源和不同框架的日子已經一去不復返了。 2015 年之前的時代基於這樣一種想法，即每個 TCP 連接只能請求一個請求。 這導致 Web 客戶端有多個資源排隊等待下載，從而導致網絡擁塞和頁面加載時間變慢。

HTTP/2 旨在針對三個主要改進領域來緩解上述問題：

  • 簡單
  • 高性能
  • 魯棒性

HTTP/2 的 SEO 優勢

Page Speed 可能是 SEO 考慮在他們自己或客戶的網站上實施 HTTP/2 的主要原因。 頁面速度/性能是一組指標，自 2010 年以來一直是桌面查詢的排名因素。 由於移動設備使用率的上升，谷歌在 2018 年 7 月正式宣布Page Speed 將成為 Mobile 的排名因素。

HTTP/2 提供了 3 個主要功能，可在優化網站以提高頁面速度時使用：

  1. 多路復用
  2. 服務器推送
  3. 流優先級

多路復用

多路復用允許 Web 客戶端在一個 TCP 連接中包含多個請求，從而降低服務器負載並減少網絡擁塞。

使用較舊的 HTTP 1/1.1 協議的現代 Web 客戶端（Chrome、Firefox、Safari 和 Opera）對每個主機名的同時 TCP 連接數有默認限制。 因此，使用 HTTP 1/1.1 的 Web 客戶端很容易遇到 TCP 擁塞問題。 使用現代 Web 客戶端，可以使用多路復用解決此問題，這可以顯著提高頁面速度。

下面通過 HTTP/1.1 和 HTTP/2 的比較演示了多路復用的好處，顯示了啟用和未啟用 HTTP/2 多路復用時的典型行為。

（ WebpageTest，HTTP/1.1，未演示多路復用）

（網頁測試，HTTP/2，多路復用演示）

在上面的圖像中，基於性能的瀑布用於演示網頁的用戶（請求資源）和服務器（響應哪些資源）之間的資源加載。 通常，頁面資源包括 HTML、JavaScript、CSS 和圖像。 基於性能的瀑布演示了在客戶端中調用、下載和呈現特定資源的確切時間點，這對於發現、評估和分析站點上的頁面速度問題至關重要。 如上圖“HTTP/2”所示，所有資源都開始同時下載，而沒有任何資源在不同的點開始加載。 由於 HTTP/2 利用多路復用，不再依賴於通過單個 TCP 連接僅發送 1 個請求，因此可以同時下載多個資源，如上所示。 相反，如圖“HTTP/1.1”所示，資源不會同時下載，因為它們無法利用多路復用功能。 HTTP/1.1 下的現代瀏覽器平均能夠同時擁有 6 個連接，但實現 HTTP/2 的好處是每個請求都不需要 TCP 握手，而無論有多少連接可以與 HTTP/1.1 並發運行初始每次都必須完成連接過程。 因此，它們開始在不同的點下載，從而導致用戶的頁面加載時間更長。

（ Upwork HTTP/1.1 vs HTTP/2 圖）

Google 和 Bing 等搜索爬蟲不會直接從 HTTP/2 實施中受益。 如上所述，這些優化的主要好處可能是頁面速度。 因此，儘管 HTTP/2 實施可能不會直接影響搜索爬蟲，但它會影響頁面速度，這是自 2010 年以來谷歌桌面查詢和自 2018 年 7 月以來移動查詢的直接排名因素。因此，網站不交付至關重要給用戶帶來緩慢的體驗，因為 Google 可能會通過影響排名來抑制性能，或者最近向用戶標記您的網站可能運行緩慢。

服務器推送

服務器推送允許特定服務器或邊緣網絡在客戶端未請求資源時將資源發送到 Web 客戶端。 要了解服務器推送的功能，首先要了解網站遵循的請求-響應模式。 用戶從網站請求頁面，服務器以請求的內容/資源進行響應。

假設地，考慮一個站點，它的所有樣式都定義在一個名為 styles.css 的外部樣式表中。 當用戶請求頁面的 HTML 骨架時（假設在本例中為 index.html），服務器推送可以在開始向 index.html 發送響應後立即將 CSS“推送”給用戶。

（ S糖化雜誌，服務器推送）

在了解服務器推送如何幫助提高頁面速度之前，了解瀏覽器如何處理不同資源（例如圖像、CSS 和 JavaScript）以顯示在瀏覽器中非常重要。 您會看到，瀏覽器會發送有關如何下載圖像、CSS 和 JavaScript 資源的說明。 首次訪問網站時，您通常會發出 GET 請求，即 .html 文件。 一旦收到這個​​ .html 文件，瀏覽器就會掃描它以理解它，然後可能會根據 HTML 文件中包含的內容髮出額外的 GET 請求。

服務器推送如何幫助提高頁面速度？

通過使用服務器推送，減少了瀏覽器（往返）所需的 GET 請求數量，並避免了導致頁面加載時間增加的渲染延遲。 這可以極大地幫助改善 Web 客戶端的呈現時間，從而幫助用戶更快地顯示網頁，從而為他們提供更好的體驗。

雖然服務器推送不會直接影響 Googlebot 如何抓取您的網站或其他抓取工具，但 SEO 的好處是通過改進以用戶為中心的因素（例如 First Paint 和 First Meaningful Content）而獲得的。

利用網頁測試、Lighthouse、Page Speed Insights 和 Chrome 用戶體驗報告，您可以確定網站/頁面與同行業競爭對手相比的表現。 下面是兩張圖片，展示了沒有（圖 1）和使用服務器推送（圖 2）的實現。

（網頁測試，無服務器推送）

(WebpageTest, HTTP/1.1, With Server Push)

使用服務器推送，可以對服務器進行配置，使其在被要求通過包含它們的 .html 文件發送時始終發送任何其他頁面組件（例如 CSS 文件、JavaScript 和圖像）。

在上面的瀑布圖中，我們可以看到 push.php 使用了四個 CSS 文件。

如果沒有服務器推送，瀏覽器需要接收 push.php 文件，解析 HTML，然後對每個附加的 CSS 文件發出特定請求。 只有在收到所有 CSS 文件後，它才能開始在渲染過程中使用它們。

啟用服務器推送後，對 push.php 的請求會自動觸發服務器發送四個 CSS 文件。 瀏覽器接收它們並且可以更早地在渲染過程中開始使用它們。 這意味著瀏覽器可以更快地開始呈現頁面內容，從而獲得更好的頁面速度指標。

HTTP/2 優先級

HTTP/2 優先級將資源加載順序的控制權交還給站點所有者。 如果做得好，優先級通過以優化的順序提供頁面資源，從而有利於用戶體驗和頁面/站點速度，從而創造“快速”的用戶體驗。

如果我們看一下 HTTP/2 的前身 HTTP/1.1，Web 客戶端控制了資源加載的順序。 如上所述，這是因為每個 TCP 連接一次只能支持一個資源。 由瀏覽器通過決定選擇哪些資源以及並行打開多少連接來安排請求。

在了解它是如何完成的之前，重要的是要了解我們為什麼要對我們的資源使用優先級。

如果我們在頁面頂部有一個圖像，在頁面底部有一個圖像，從邏輯上講，我們希望確保頂部的圖像在底部的圖像之前加載。 這個概念有助於展示 HTTP/2 優先級可以帶來的重要性和影響。 HTTP/2 優先級允許我們指定哪些資源應該首先交付並在其他資源之前加載（無論是 JavaScript、CSS 還是圖像），從而確保頁面的最快加載時間。

雖然瀏覽器現在可以使用多路復用通過單個 TCP 連接同時請求多個資源，但它現在還可以為每個請求指定優先級信息，以幫助確定何時/如何交付資源。 如果服務器和瀏覽器都支持 HTTP/2 優先級，則瀏覽器應定義利用全帶寬的優先級規則，而不會使資源相互競爭。 為了更好地理解優先級流程的運作方式，討論對 HTTP/2 優先級很重要的三個參數很重要：

流：這是已建立連接中的雙向字節流，可以攜帶一個或多個消息。

父流：這是資源所依賴的流

子流：這是父流的依賴流。 它們共享相同的父級，因此被稱為子流

權重：這是一個分配在 1 到 256 之間的數字，用於標識在多個流共享連接時分配給流的帶寬。 帶寬是相對於所有其他活動流的權重分配的。

獨占位：這是一個標誌，指示應該在不與任何其他流共享帶寬的情況下下載流。

Headers Frame：這是流所屬幀的標識

二進制框架層：這是 HTTP 消息在客戶端和服務器之間封裝和傳輸的方式

下面的示例演示了上述示例：

（谷歌開發者 HTTP/2 流優先級）

為了執行 HTTP/2 優先級，您需要在位於新 HTTP/2 二進制幀層內的標頭幀中添加優先級信息。 父流和對其他子流的依賴/非依賴將確定優先級/權重，從而確定資源到 Web 客戶端的傳遞。

儘管現在許多平台都支持 HTTP/2 優先級，但許多 CDN 和託管服務提供商不支持 HTTP/2 優先級。 因此，如果您希望使用此優化技術，請務必使用支持 HTTP/2 優先級的 CDN/託管服務提供商。 下表描述了哪些 CDN/主機/服務器能夠和不能支持 HTTP/2 優先級。

HTTP/2 優先級 - 通用服務器/主機/CDN 兼容性

此比較在2020年 2 月 1 日是正確的，但在您決定選擇哪個之前，值得檢查潛在服務提供商是否提高了兼容性。

批判性地查看特定瀏覽器也很重要，因為不幸的是，並非所有瀏覽器都支持 HTTP/2 優先級，並且由於 Web 客戶端不同，優先級也不同。 下表描述了哪些 Web 客戶端能夠支持 HTTP/2 優先級。

HTTP/2 優先級 Web 客戶端兼容性

HTTP/2 優先級可以顯著提高用戶對頁面/站點速度的感知，並將對 Chrome 用戶體驗報告中積累的數據產生積極影響。 雖然這種優化對 Googlebot 等搜索爬蟲沒有影響，但Lighthouse和Page Speed Insights等工具將幫助您從用戶的角度評估 HTTP/2 優先級對頁面速度性能的影響。

通過使用支持 HTTP/2 的 CDN/主機正確配置服務器和客戶端的流權重，您將能夠顯著提高客戶端的頁面速度指標。

HTTP/2 的先決條件是什麼

在您能夠利用 HTTP/2 的速度優勢之前，請確保您能夠利用它。 有幾個先決條件需要考慮：

  1. 確保啟用 HTTPS 很重要。
  2. 使用來自認證機構的 TLS 證書並激活和安裝證書。
  3. 確保您的 Web 服務器軟件（例如 Nginx、Apache 和 IIS）支持 HTTP/2。 可以在http://ayi.ma/browsershttp2找到完整的認證支持列表，其中將顯示瀏覽器對 HTTP/2 的支持。 如果您正在尋找對 CDN/Hosting 的 HTTP/2 支持，請參閱http://ayi.ma/serverhosting 。

常見的陷阱/隨著 HTTP/2 的引入必須改變的事情

由於早期 HTTP 1.0 和 HTTP 1.1 協議的限制，開發人員和 SEO 一直在努力尋找解決這些限制為頁面速度性能和安全性帶來的眾多問題的方法。

最終，他們能夠找到“黑客”來避開其中的一些限制，但其中許多方法導致開發人員付出了更多的工作。 您可能會問這些黑客有哪些？ 以下是您將在網站上看到的一些最常見的黑客攻擊，這些黑客攻擊可以通過正確實施 HTTP/2 來解決。

避免域分片

令人驚訝的是，儘管已經正確實現了 HTTP/2，但仍有許多網站使用這種 hack。 啟用 HTTP/2 後，避免使用域分片非常重要。 域分片是一種跨不同主機名拆分資源的技術，從而允許同時提供更多資源。

多虧了更新的 HTTP/2 協議，不再需要域分片，事實上，導致的問題多於解決的問題。 如果為您的站點正確配置和啟用了 HTTP/2，並且您還使用了域分片，那麼您實際上抵消了 HTTP/2 的一些好處，因為瀏覽器將無法從跨多個主機名的多路復用和下載中受益。

此外，通過域分片，您實際上打破了流優先級，您的資源將無法加載以充分利用頁面速度。

正確使用服務器推送

服務器推送有一些你應該注意的缺點。 服務器推送實際上可能被過度使用，您在選擇何時使用它時應該有所選擇。 您不一定要推送太多資源，因為這可能導致 Web 客戶端不僅下載 HTML，而且下載它“推送”的所有內容。 這意味著頁面實際上可能需要更長的時間來加載和呈現（增加 Google 關注的以用戶為中心的指標，例如交互時間）。

服務器推送的第二個常見陷阱是弄清楚如何不推送 Web 客戶端已經擁有的資源。 這可以通過多種方法來控制。 一種方法是選擇不向返回用戶推送資源，從而允許返回用戶使用他們的緩存資產。 這是迄今為止最簡單的實現。 這可以通過檢查資源的緩存標頭來簡單地完成，確保標頭不與服務器推送實現重疊。

HTTP/2 下的實際測試

理論知識對於為理解 HTTP/2 及其好處奠定基礎總是很重要的。 一旦掌握並理解了這些概念，測試這些理論以衡量 HTTP/2 對 Page Speed 的影響很重要。

本 Page Speed 系列HTTP/2 在現實生活中的第 2 部分 - 使用網站測試和分析將討論 HTTP/2 在頁面速度和 SEO 價值方面的真正好處，所以不要錯過！

HTTP/3 呢？

儘管 HTTP/3 顯示出作為 HTTP/2 後繼協議的明顯潛力，但它不會也不應該標誌著整個網絡的 SEO 的 HTTP/2 結束。 與全球網絡的每一個新的重大發展一樣，它將經歷一個正常的推出階段，並且一個網站可能需要一段時間才能採用新協議，並且在它成為 SEO 行業的事實上的標準之前。 HTTP/2 實施仍然是一個有益而簡單的收穫，如果實施得當，它可以幫助提高您網站的性能。