題幹與適用場景
你負責一個首屏 HTML 需要較久產生的電商首頁。候選方案是在最終回應前送出 103 Early Hints，提前提示關鍵 CSS、字型或腳本。請說明何時有效、如何避免重複下載，以及如何驗證 LCP 是否改善。假設請求是頂層導覽，連線使用 HTTP/2 或 HTTP/3，最終回應仍會送出正確的 Link 標頭。
面試官考察點
- 能否把 103 說成「提示」而非最終資源清單：瀏覽器可以提前連線或預載，但最終回應仍是權威來源。
- 能否辨識收益來自伺服器產生 HTML 的等待時間；伺服器立即回傳 200 時，主回應中的
preload或preconnect更簡單。 - 能否處理資源穩定性、快取、跨來源重新導向、瀏覽器支援與通訊協定版本等邊界。
- 能否用 LCP、快取命中、重複請求與錯誤率驗證，而不是只背狀態碼。
回答前需要釐清的問題
- 第一個位元組前的伺服器時間多長？ 若幾乎為零，103 沒有可重疊的等待窗口，應先最佳化後端或主回應的資源提示。
- 提示的資源是否穩定且必要？ 若取決於使用者、實驗或權限結果，誤提示會浪費頻寬；只提示跨頁穩定的關鍵資源。
- 請求是否為頂層導覽、連線是否為 HTTP/2+？ 瀏覽器對 103 的處理主要針對導覽，並建議在 HTTP/2 或更高版本使用。
- 資源是否可快取？ 不可快取的預載可能在 HTML 到達後再次下載，收益會變成額外成本。
30 秒回答框架
「我先確認頁面有足夠的伺服器思考時間，以及請求是支援 103 的頂層導覽。接著只提示高機率必要、穩定且可快取的 CSS、字型或連線來源，並在最終回應重複正確的 Link 標頭。若資源取決於實驗或使用者權限，我不會提前提示。上線前後用真實導覽比較 TTFB 到資源請求的重疊、LCP、重複下載與頻寬；遇到跨來源重新導向或不支援的用戶端則回退到一般回應。」
分步驟深入解答
1. 先計算可重疊的時間窗口
103 讓瀏覽器在伺服器準備最終 HTML 時開始連線或下載資源。可獲得的上限接近「伺服器準備時間減去瀏覽器收到最終回應後才開始請求資源的時間」。伺服器很快回傳 200 時，窗口接近零，Chrome 官方建議使用主回應中的一般 Link 或 HTML link。
2. 選擇穩定資源，不要複製全部 HTML 提示
Early Hints 沒有最終 HTML，也不知道使用者最後看到的變體。適合的候選包括穩定的主 CSS、共用腳本、字型與關鍵 CDN 連線。個人化圖片、實驗分支腳本和權限資源應留在最終回應之後。可以把資源拆成穩定部分和動態部分：前者提前提示，後者由 HTML 決定。
3. 把快取與通訊協定當成正確性條件
預載資源必須能被最終頁面重用；若資源不可快取，瀏覽器可能先下載一次，HTML 到達後再觸發一次。跨來源資源還要維持正確的 crossorigin 語意。MDN 建議優先在 HTTP/2 或更高版本送出 103，舊用戶端或中介設備可能無法正確處理 1xx 回應。
4. 保留最終回應的權威宣告
最終回應應繼續送出 Link 標頭，作為不支援 103 用戶端的回退，也補上產生 HTML 期間才知道的動態資源。若最終結果發生跨來源重新導向，瀏覽器可能丟棄早期建立的連線和資源；因此不能把 103 當成不可撤銷的下載指令。
5. 用實驗驗證，而不是假設收益
在支援與不支援 Early Hints 的真實導覽上分組，記錄伺服器思考時間、資源請求開始時間、LCP、重複請求位元組和錯誤率。Chrome DevTools 可觀察 Early Hints initiator 與快取命中，但測試時不能關閉快取。若 LCP 沒改善，檢查提示資源是否已在快取、是否太晚送出、是否被重新導向丟棄，或伺服器等待本身才是瓶頸。
6. 與 HTTP/2 Push 的差異
103 只提供線索，由瀏覽器決定是否連線或取得；HTTP/2 Push 直接推送，容易重複傳送瀏覽器已快取的資源。面試時應強調 103 的控制權留在用戶端，代價是仍需一個網路往返並受瀏覽器支援限制。
高品質示範回答
我會先看第一個位元組前的伺服器時間。如果首頁 SSR 需要 300 毫秒，而主 CSS 和字型每次導覽都穩定存在，103 可以讓瀏覽器把連線和下載放進這 300 毫秒。我只會放穩定、可快取的資源，確保跨來源字型帶上正確的 crossorigin；個人化圖片和實驗腳本不提前發。最終回應仍送出 Link，讓不支援 103 的用戶端也能正常載入。
我不會把它當成加上狀態碼就一定提速。我要用真實導覽做對照實驗，比較 LCP、資源請求起點、重複下載位元組和跨來源重新導向比例。若伺服器很快回傳 200、資源已在快取，或提示資源常被最終頁面否決，一般主回應提示甚至不做預載會更合適。這同時涵蓋收益窗口、錯誤成本和回退路徑。
常見錯誤
- 錯誤表現 → 認為 103 等同於 200。 失敗原因：103 是資訊提示，最終回應才決定資源和狀態。修正方法：說明提示可被忽略，並保留最終
Link。 - 錯誤表現 → 把所有 HTML 的
preload原樣複製到 103。 失敗原因：早期階段沒有使用者變體資訊，動態資源會浪費。修正方法：只選擇穩定且高機率必要的資源。 - 錯誤表現 → 只看 LCP，不看重複下載。 失敗原因：預載不可快取或跨來源屬性錯誤時，表面上可能較早請求卻增加總位元組。修正方法：同時記錄快取重用、重複請求、頻寬和錯誤率。
- 錯誤表現 → 預設對所有 HTTP/1.1 請求送出。 失敗原因：用戶端和中介設備對 1xx 支援不一致，而且 Early Hints 主要針對導覽。修正方法：依協定、請求類型和用戶端能力啟用，準備一般回應回退。
追問及應對
如果最終回應經常 302 到另一個來源，還該送 103 嗎？
要謹慎。MDN 與 Chrome 資料都指出，跨來源重新導向後瀏覽器可能丟棄早期資源和連線。先把 103 限定在穩定的最終入口，或只提示不會因重新導向失效的同源資源，並以重新導向比例作為門檻。
如果 CSS 在不同實驗組不同，如何提示？
只提示所有實驗組共用的基礎 CSS，實驗專屬部分留到最終 HTML。若沒有穩定交集，就不要預載；錯誤預取的頻寬成本可能超過節省的等待時間。
如何證明收益來自 103 而不是快取變熱？
使用相同快取狀態的隨機分組，分別記錄冷快取和熱快取。比較資源請求與伺服器思考時間的重疊，而不只比較單次 LCP；同時檢查 Early Hints initiator、快取命中和重複下載。
瀏覽器不支援某個 Early Hints 指令怎麼辦？
保留最終回應的 Link 和 HTML 宣告作為回退。先送出相容性較廣的 preconnect，對 preload 則依目標瀏覽器支援矩陣逐步啟用，並監控錯誤率。