HTTP 新增的 103 狀態碼，這次終于派上用場了！
大家好，我是 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.html
Host: conardli.top
User-Agent: [.] Chrome/103.0.0.0 []
服務器預測站點將需要 home.aaaa1.js? ，并建議通過 Early Hints 預加載它：
103 Early Hints
Link: </home.aaaa1.js>; rel=preload; as=script
[]
隨后，客戶端馬上向服務端請求了 home.aaaa1.js?。然而，這時 JS? 資源更新了，主頁面已經需要另外一個版本的 JS 了。
200 OK
[]
<HTML>
<head>
<title>Conardli's Blog</title>
<link rel="script" href="/home.aaaa2.js">
所以，我們最好選擇一些比較穩定的資源進行預加載，我們可以對 JS 進行拆包，將不經常發生變化的穩定部分和經常發生更新的動態腳本部分拆成多個資源。我們只對穩定部分實施預加載，在瀏覽器獲取到主頁面后再去加載動態部分。
<HTML>
<head>
<title>code秘密花園</title>
<link rel="script" href="/home.js">
<link rel="script" href="/home.aaaa1.js">
最后，在服務器端，查找已知支持 Early Hints? 的瀏覽器發送的主頁面請求，并響應 103 Early Hints?。在 103? 響應中，會包括相關的預連接和預加載提示。主頁面準備好后，再按照正常的響應進行響應。為了向后兼容，最好在最終響應中包含 LINK HTTP 標頭，甚至也可以增加在生成主頁面時需要的一些明顯的關鍵資源。
Early Hints 響應：
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
成功響應：
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 有什么關系？
看到這里你可能發現了，這玩意和 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 的升級版。
支持情況
瀏覽器支持情況：
服務器支持情況：
- Node.js?：通過Fastify 插件提供支持；
- Apache?：通過mod_http2 支持；
- H2O：支持；
- Nginx：實驗模塊。
