大家好，我是ConardLi。
說到HTTP?的103狀態碼，你可能很早就聽說過了，但是你不一定真的理解了它。
【資料圖】
這很正常，這個狀態碼早在2017年就被提出來了，但是支持它的服務器和瀏覽器真的很少。
直到前幾天，Chrome?宣布在Chrome 103?版本對HTTP 103狀態碼提供了支持，不得不說老外還挺皮啊...
今天我們就來看一下，HTTP 103狀態碼究竟有什么用途。
資源加載的性能問題隨著時間的推移，網站變得越來越復雜。一些大型網站的服務器可能需要執行很多重要的工作（例如，訪問數據庫或訪問源服務器的CDN?）來為請求的頁面生成HTML。
但是，這種服務器的思考時間?會在瀏覽器開始渲染頁面之前帶來額外的延遲。因為瀏覽器需要先把HTML?頁面加載回來，才能知道下一步去加載哪些JavaScript、CSS或字體文件等。中間這段時間實際上就浪費掉了，對用戶訪問我們的頁面來講，這段等待時間就是白屏或是不可用的狀態。
我們來看看抖音Web?站的資源加載：瀏覽器先要等待前面兩個HTML?的大約800 ms?的時間才能去加載后面的JS 、CSS等資源文件。
有沒有辦法在等待HTML響應的同時就去提前把重要的靜態資源文件也加載回來呢？
HTTP 103 狀態碼HTTP 103?狀態碼 (Early Hints?) 是一個信息性HTTP?狀態代碼，可以用于在最終響應之前發送一個初步的HTTP響應。
利用HTTP 103?狀態碼，就可以讓服務器在服務器處理主資源的同時向瀏覽器發送一些關鍵子資源（JavaScript、CSS或字體文件）或頁面可能使用的其他來源的提示。
瀏覽器可以使用這些提示來預熱連接，并在等待主資源響應的同時請求子資源。換句話說，Early Hints?可以通過提前做一些工作來幫助瀏覽器利用這種服務器思考時間，從而提升頁面的渲染性能。
在某些情況下，這可以幫助LCP?（最大內容繪制）至少提升幾百毫秒。例如在Shopify?和Cloudflare?所觀察到的來看，LCP大概提升了 1 秒。
啟用 Early Hints 前后對比
什么樣的網站適合 Early Hints在開始使用之前，可能要先思考下，什么樣的網站比較適合這個優化。
如果你的網站的主頁面響應非?？?，可能沒什么必要。比如對于大部分SPA（單頁應用），可能用處不是那么大。
在SPA?中，大部分的邏輯都在客戶端，HTML?很小，下發HTML?的服務器也基本就是沒有什么邏輯的靜態服務器。大部分情況下只會包括一個Root?節點，以及一些資源的Link?，大部分邏輯和加載時間其實都在打包后的JavaScript?中。這種情況我們只需要使用常規的rel=preload、rel=preconnect等手段就可以了。
但是在SSR?項目中，加載HTML?往往需要在服務端花費更多的時間，因為服務端可能和數據庫交互以及將數據拼接成HTML?元素。相比之下，加載其他的腳本和樣式資源可能花費的時間要更短一點，這種站點啟用Early Hints是比較合適的。
啟用 Early Hints在Chrome 103?版本，對HTTP 103?狀態碼 (Early Hints) 提供了支持。
啟用Early Hints?的第一步就是要確認我們站點的主頁面?，也就是用戶通常在訪問我們的網站時開始的頁面。如果我們有很多來自其他網站的用戶，主頁面可能就是主頁或熱門的產品列表頁面。
Early Hints的用途會隨著用戶在我們的站內導航的次數而降低，因為瀏覽器可能已經在前幾次導航中把所有需要的子資源請求回來了，給用戶良好的第一印象是最重要的！
確認了站點的主頁面?，下一步就是確定哪些來源或子資源將是最佳預連接或預加載的候選者。通常情況家，我們要找的就是對關鍵用戶指標（LCP?或FP?）貢獻最大的源和子資源。具體一點，就是找到阻塞渲染的子資源，例如同步JavaScript、樣式表，甚至網絡字體等。
然后就是盡量避免選擇已經過時或者不再被主頁面使用的資源。
比如一些經常更新或者帶有hash?的資源（conardli.top/static/home.aaaa1.js），盡量不要選擇，這可能會導致頁面需要加載的資源和實際預加載的資源不匹配。
比如我們舉個例子：
首先我們去服務器請求主頁面：
GET /home.htmlHost: conardli.topUser-Agent: [....] Chrome/103.0.0.0 [...]
服務器預測站點將需要home.aaaa1.js?，并建議通過Early Hints預加載它：
103 Early HintsLink: ; rel=preload; as=script[...]
隨后，客戶端馬上向服務端請求了home.aaaa1.js?。然而，這時JS?資源更新了，主頁面已經需要另外一個版本的JS了。
200 OK[...]
所以，我們最好選擇一些比較穩定的資源進行預加載，我們可以對 JS 進行拆包，將不經常發生變化的穩定部分和經常發生更新的動態腳本部分拆成多個資源。我們只對穩定部分實施預加載，在瀏覽器獲取到主頁面后再去加載動態部分。
最后，在服務器端，查找已知支持Early Hints?的瀏覽器發送的主頁面請求，并響應103 Early Hints?。在103?響應中，會包括相關的預連接和預加載提示。主頁面準備好后，再按照正常的響應進行響應。為了向后兼容，最好在最終響應中包含LINK HTTP標頭，甚至也可以增加在生成主頁面時需要的一些明顯的關鍵資源。
Early Hints響應：
GET /main.htmlHost: conardli.topUser-Agent: [....] Chrome/103.0.0.0 [...]103 Early HintsLink: 成功響應： 200 OKContent-Length: 7531Content-Type: text/html; charset=UTF-8Content-encoding: brLink: 看到這里你可能發現了，這玩意和HTTP2?的服務器推送 (Server Push) 很像啊。 Server Push?即在瀏覽響應HTML文件的時候，服務器會同時將所需的資源文件主動推送給瀏覽器。 瀏覽器在收到推送的資源之后會緩存到本地。等解析HTML發現需要加載對應資源的時候會直接從本地讀取，不必再等待網絡傳輸了。 雖然這聽起來很神奇，但這個方案有非常大的缺陷：Server Push?很難避免推送瀏覽器已經擁有的子資源，其實很多資源在瀏覽器第一次請求到就已經緩存下來了。這種 “過度推動” 會導致網絡帶寬的使用效率降低，從而顯著阻礙性能優勢。總體而言，Chrome?數據顯示HTTP2/Push實際上對整個網絡的性能產生了負面影響。 所以，Chrome?宣布移除了對HTTP/2 Server Push特性的支持： 相比之下，Early Hints?在實踐中表現更好，因為它結合了發送初步響應的能力和提示，瀏覽器實際上只負責獲取它實際需要的資源。雖然Early Hints?還沒有涵蓋HTTP/2 Server Push?理論上可以解決的所有用例，但是它解決了網絡帶寬浪費的問題，可以說是HTTP/2 Server Push的升級版。 瀏覽器支持情況： 服務器支持情況：
X 關閉
X 關閉