HTTP 新增的 103 狀態(tài)碼，這次終于派上用場了！
點擊關(guān)注公眾號，Java干貨及時送達(dá)
說到HTTP的103狀態(tài)碼，你可能很早就聽說過了，但是你不一定真的理解了它。
這很正常，這個狀態(tài)碼早在2017年就被提出來了，但是支持它的服務(wù)器和瀏覽器真的很少。
直到前幾天，Chrome宣布在Chrome 103版本對HTTP 103狀態(tài)碼提供了支持，不得不說老外還挺皮啊...
今天我們就來看一下，HTTP 103狀態(tài)碼究竟有什么用途。
資源加載的性能問題
隨著時間的推移，網(wǎng)站變得越來越復(fù)雜。一些大型網(wǎng)站的服務(wù)器可能需要執(zhí)行很多重要的工作（例如，訪問數(shù)據(jù)庫或訪問源服務(wù)器的CDN）來為請求的頁面生成HTML。
但是，這種服務(wù)器的思考時間會在瀏覽器開始渲染頁面之前帶來額外的延遲。因為瀏覽器需要先把HTML頁面加載回來，才能知道下一步去加載哪些JavaScript、CSS或字體文件等。中間這段時間實際上就浪費掉了，對用戶訪問我們的頁面來講，這段等待時間就是白屏或是不可用的狀態(tài)。
我們來看看抖音Web站的資源加載：瀏覽器先要等待前面兩個HTML的大約800 ms的時間才能去加載后面的JS 、CSS等資源文件。
有沒有辦法在等待HTML響應(yīng)的同時就去提前把重要的靜態(tài)資源文件也加載回來呢？
HTTP 103 狀態(tài)碼
HTTP 103狀態(tài)碼 (Early Hints) 是一個信息性HTTP狀態(tài)代碼，可以用于在最終響應(yīng)之前發(fā)送一個初步的HTTP響應(yīng)。
利用HTTP 103狀態(tài)碼，就可以讓服務(wù)器在服務(wù)器處理主資源的同時向瀏覽器發(fā)送一些關(guān)鍵子資源（JavaScript、CSS或字體文件）或頁面可能使用的其他來源的提示。
瀏覽器可以使用這些提示來預(yù)熱連接，并在等待主資源響應(yīng)的同時請求子資源。換句話說，Early Hints可以通過提前做一些工作來幫助瀏覽器利用這種服務(wù)器思考時間，從而提升頁面的渲染性能。
在某些情況下，這可以幫助LCP（最大內(nèi)容繪制）至少提升幾百毫秒。例如在Shopify和Cloudflare所觀察到的來看，LCP大概提升了 1 秒。
什么樣的網(wǎng)站適合 Early Hints
在開始使用之前，可能要先思考下，什么樣的網(wǎng)站比較適合這個優(yōu)化。
如果你的網(wǎng)站的主頁面響應(yīng)非常快，可能沒什么必要。比如對于大部分SPA（單頁應(yīng)用），可能用處不是那么大。
在SPA中，大部分的邏輯都在客戶端，HTML很小，下發(fā)HTML的服務(wù)器也基本就是沒有什么邏輯的靜態(tài)服務(wù)器。大部分情況下只會包括一個Root節(jié)點，以及一些資源的Link，大部分邏輯和加載時間其實都在打包后的JavaScript中。這種情況我們只需要使用常規(guī)的rel=preload、rel=preconnect等手段就可以了。
但是在SSR項目中，加載HTML往往需要在服務(wù)端花費更多的時間，因為服務(wù)端可能和數(shù)據(jù)庫交互以及將數(shù)據(jù)拼接成HTML元素。相比之下，加載其他的腳本和樣式資源可能花費的時間要更短一點，這種站點啟用Early Hints是比較合適的。
啟用 Early Hints
在Chrome 103版本，對HTTP 103狀態(tài)碼 (Early Hints) 提供了支持。
啟用Early Hints的第一步就是要確認(rèn)我們站點的主頁面，也就是用戶通常在訪問我們的網(wǎng)站時開始的頁面。如果我們有很多來自其他網(wǎng)站的用戶，主頁面可能就是主頁或熱門的產(chǎn)品列表頁面。
Early Hints的用途會隨著用戶在我們的站內(nèi)導(dǎo)航的次數(shù)而降低，因為瀏覽器可能已經(jīng)在前幾次導(dǎo)航中把所有需要的子資源請求回來了，給用戶良好的第一印象是最重要的！
確認(rèn)了站點的主頁面，下一步就是確定哪些來源或子資源將是最佳預(yù)連接或預(yù)加載的候選者。通常情況家，我們要找的就是對關(guān)鍵用戶指標(biāo)（LCP或FP）貢獻最大的源和子資源。具體一點，就是找到阻塞渲染的子資源，例如同步JavaScript、樣式表，甚至網(wǎng)絡(luò)字體等。
然后就是盡量避免選擇已經(jīng)過時或者不再被主頁面使用的資源。
比如一些經(jīng)常更新或者帶有hash的資源（conardli.top/static/home.aaaa1.js），盡量不要選擇，這可能會導(dǎo)致頁面需要加載的資源和實際預(yù)加載的資源不匹配。
比如我們舉個例子：
首先我們?nèi)シ?wù)器請求主頁面：
GET /home.html
Host: conardli.top
User-Agent: [....] Chrome/103.0.0.0 [...]
服務(wù)器預(yù)測站點將需要home.aaaa1.js，并建議通過Early Hints預(yù)加載它：
103 Early Hints
Link: </home.aaaa1.js>; rel=preload; as=script
[...]
隨后，客戶端馬上向服務(wù)端請求了home.aaaa1.js。然而，這時JS資源更新了，主頁面已經(jīng)需要另外一個版本的JS了。
200 OK
[...]
<HTML>
<head>
<title>Conardli's Blog</title>
<link rel="script" href="/home.aaaa2.js">
所以，我們最好選擇一些比較穩(wěn)定的資源進行預(yù)加載，我們可以對 JS 進行拆包，將不經(jīng)常發(fā)生變化的穩(wěn)定部分和經(jīng)常發(fā)生更新的動態(tài)腳本部分拆成多個資源。我們只對穩(wěn)定部分實施預(yù)加載，在瀏覽器獲取到主頁面后再去加載動態(tài)部分。
<HTML>
<head>
<title>code秘密花園</title>
<link rel="script" href="/home.js">
<link rel="script" href="/home.aaaa1.js">
最后，在服務(wù)器端，查找已知支持Early Hints的瀏覽器發(fā)送的主頁面請求，并響應(yīng)103 Early Hints。在103響應(yīng)中，會包括相關(guān)的預(yù)連接和預(yù)加載提示。主頁面準(zhǔn)備好后，再按照正常的響應(yīng)進行響應(yīng)。為了向后兼容，最好在最終響應(yīng)中包含LINK HTTP標(biāo)頭，甚至也可以增加在生成主頁面時需要的一些明顯的關(guān)鍵資源。
Early Hints響應(yīng)：
GET /main.html
Host: conardli.top
User-Agent: [....] Chrome/103.0.0.0 [...]
103 Early Hints
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script
成功響應(yīng)：
200 OK
Content-Length: 7531
Content-Type: text/html; charset=UTF-8
Content-encoding: br
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script
Link: </experimental.3eab3290.css>; rel=preload; as=style
<HTML>
<head>
<title>code秘密花園</title>
<link rel="stylesheet" href="/main.css">
<link rel="stylesheet" href="/home.aaaa1.css">
<script src="/common.js"></script>
<link rel="preconnect" href="https://fonts.googleapis.com">
和 HTTP2/Push 有什么關(guān)系？
看到這里你可能發(fā)現(xiàn)了，這玩意和HTTP2的服務(wù)器推送 (Server Push) 很像啊。
Server Push即在瀏覽響應(yīng)HTML文件的時候，服務(wù)器會同時將所需的資源文件主動推送給瀏覽器。
瀏覽器在收到推送的資源之后會緩存到本地。等解析HTML發(fā)現(xiàn)需要加載對應(yīng)資源的時候會直接從本地讀取，不必再等待網(wǎng)絡(luò)傳輸了。
雖然這聽起來很神奇，但這個方案有非常大的缺陷：Server Push很難避免推送瀏覽器已經(jīng)擁有的子資源，其實很多資源在瀏覽器第一次請求到就已經(jīng)緩存下來了。這種 “過度推動” 會導(dǎo)致網(wǎng)絡(luò)帶寬的使用效率降低，從而顯著阻礙性能優(yōu)勢。總體而言，Chrome數(shù)據(jù)顯示HTTP2/Push實際上對整個網(wǎng)絡(luò)的性能產(chǎn)生了負(fù)面影響。
所以，Chrome宣布移除了對HTTP/2 Server Push特性的支持：
相比之下，Early Hints在實踐中表現(xiàn)更好，因為它結(jié)合了發(fā)送初步響應(yīng)的能力和提示，瀏覽器實際上只負(fù)責(zé)獲取它實際需要的資源。雖然Early Hints還沒有涵蓋HTTP/2 Server Push理論上可以解決的所有用例，但是它解決了網(wǎng)絡(luò)帶寬浪費的問題，可以說是HTTP/2 Server Push的升級版。
支持情況
瀏覽器支持情況：
服務(wù)器支持情況：
Node.js：通過Fastify插件提供支持；Apache：通過mod_http2支持；H2O：支持；Nginx：實驗?zāi)K。
最后
參考鏈接：
https://developer.chrome.com/blog/early-hints/ https://github.com/bashi/early-hints-explainer https://httpd.apache.org/docs/2.4/howto/http2.html
往 期 推 薦
點分享
點收藏
點點贊
點在看
