在周四的一篇ChromeDeveloper博客文章中，BarryPollard介紹Chromium社區的下一發展方向。其中最重要的，莫過於從Chrome106（以及其它基於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 能夠發展到哪一步，仍有待時間去檢驗。