在周四的一篇Chrome Developer 博客文章中，Barry Pollard 介紹了Chromium 社區的下一發展方向。其中最重要的，莫過於從Chrome 106（以及其它基於Chromium 內核的第三方瀏覽器的下一個版本）起，開發商將默認禁用對“HTTP/2 服務器推送”功能的支持。

截圖（via Jake Archibald）

據悉，HTTP/2 Server Push 允許網站向客戶端主動發送頁面所需的資源，而無需等待它們被請求。

然而正如Jake Archibald 之前嘮過的那樣，這項功能存在一些問題與爭議，且通常難以實現其性能優勢。

結果就是該功能未被太多使用，僅1.25% 的HTTP/2 站點啟用了這項特性。

對HTTP/2 服務器推送功能使用狀況的分析結果，表明有好有壞（Chrome、Akamai）。

然而很多时候看不到显著的净性能争议，甚至许多情况下会遇到性能下降。

此外即使被包含在了規範裡面，Push 也沒有在許多HTTP/3 服務器和客戶端中實現。

對於使用較新的HTTP/3 的大部分網絡，Push 已被有效地淘汰。

最近重新觀察到的分析結果表明，各網站對HTTP/2 的支持率，已從1.25% 滑落至0.7% 。

作為一種替代方案，103 Early Hints 響應代碼是一個不太容易出錯的選項。

與服務器推送資源不同，其僅向瀏覽器發送可能受益於立即請求的資源的提示。

這意味著瀏覽器可自行決斷是否需要相關資源—— 比如已有HTTP 緩存的情況下。

其次是預加載關鍵資源，其允許頁面和瀏覽器一起工作，以在頁面加載的早期，搶先加載關鍵部分的資源。

由於仍需發送頁面本身，它較服務器推送/ 103 早期提示有一定的速度劣勢。

即便如此，預加載關鍵資源仍具有不延遲關鍵頁面資源的優點（另外兩套方案都可能遇到這種狀況）。

最後需要指出的是，所有嘗試提前加載資源的解決方案，都有可能導致性能下降、因而需要綜合評估並適度使用。

通常情況下，瀏覽器本身就非常擅長做出正確的選擇，僅在某些條件下可獲得額外的增益。

當然，Web 社區一直在積極嘗試新鮮事物，並在不合時宜的情況下及時棄用，這也是它能保持長久生命力的一個主要原因。

至於聽起來潛力似乎很大的Push 能夠發展到哪一步，仍有待時間去檢驗。