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