題幹與適用場景
新聞網站希望用 Speculation Rules API 加速文章詳情跳轉。請說明如何選擇 prefetch 與 prerender、限制規則範圍，並處理登入態副作用、資料新鮮度、瀏覽器降級、取消和監控。
Chrome 文件指出，prefetch 主要提前取得資源，prerender 會在不可見頁面中載入並渲染；後者收益較高，也更容易提前觸發腳本和副作用。題目考察效能工程、漸進增強和安全邊界，不是背 API 欄位。
面試官考察點
重點看候選人能否依導航命中率和副作用風險選擇策略；能否控制規則選擇器、同源範圍、快取和隱私；能否在不支援 API 或預先渲染被取消時保持正常導航；能否用真實使用者指標證明收益，而非只看實驗室分數。
30 秒回答框架
「我先用高命中、唯讀、同源文章連結做保守 prefetch；只有確認頁面沒有寫入副作用、命中率高且資源預算允許時才 prerender。規則按範本和使用者意圖分層，登入、付款、個人化和有副作用的路由不預先渲染。伺服器用快取和請求冪等保護，客戶端偵測 document.prerendering 並延後分析上報。舊瀏覽器直接走普通導航，最後比較啟用率、LCP、INP、頻寬和取消率。」
分步驟深入解答
第一步：先劃分導航風險
把文章詳情、說明頁等唯讀頁列為候選；排除下單、登出、按讚寫入、付款和強個人化頁面。預先渲染會執行頁面生命週期程式碼，任何寫入都必須由使用者真實啟用觸發。
第二步：選擇 prefetch 或 prerender
命中率低或副作用不確定時只做 prefetch。prerender 適用於高命中、同源、首屏穩定且能承受額外 CPU 與記憶體的頁面。不要把全站連結都設為 prerender；按範本或明確意圖設定規則。
第三步：控制規則和資源預算
使用文件規則或伺服器產生規則，只匹配文章連結；限制並行候選數量和資源大小。為預取回應設定合適快取、Vary 和失效策略，避免帶有使用者私密資料的回應被錯誤共用。
第四步：隔離副作用與登入態
伺服器寫入介面必須要求真實操作和 CSRF 防護，不能因預先渲染請求改變狀態。分析、廣告和通知腳本在 document.prerendering 階段延後，啟用後再傳送一次並去重。個人化回應使用私有快取或直接排除。
第五步：設計相容與取消路徑
不支援 Speculation Rules 的瀏覽器直接使用普通連結。預先渲染可能因記憶體、網路或規則限制被取消，頁面仍須正常載入。不要假設預先渲染一定完成，也不要為追求瞬時導航阻塞點擊回饋。
第六步：處理資料新鮮度
內容變更頻繁時縮短快取並在啟用時校驗版本；對帶 ETag 的資源使用條件請求。若預先渲染頁面已過期，啟用後靜默刷新可變區域，不閃回舊內容，也不重複傳送使用者操作。
第七步：觀測真實收益
分組比較啟用與未啟用使用者的啟用率、導航等待、LCP、INP、CLS、頻寬、CPU、記憶體和取消率。按瀏覽器、網路、裝置和登入狀態分層；若首屏更快但流量或錯誤率上升，應縮小規則或退回 prefetch。
設計取捨與邊界
命中率與資源成本
prerender 命中率低時會浪費 CPU、記憶體和頻寬；prefetch 成本較低但收益有限。以真實啟用率和資源預算設定門檻。
新鮮度與瞬時導航
長快取提高命中率卻增加陳舊風險。靜態內容可使用版本化 URL；動態內容在啟用時校驗，並將刷新限制在可變區域。
相容性與維護成本
規則應是漸進增強層，普通連結始終可用。避免把業務狀態機綁在預先渲染生命週期，減少跨瀏覽器差異。
失敗演練與演進計畫
預先渲染提前觸發寫入
在測試環境記錄預先渲染請求，確認按讚、統計和通知介面沒有副作用；將寫操作改為真實啟用後執行。
低命中率造成資源浪費
按裝置和網路關閉低階環境的 prerender，比較頻寬與 INP，再由 prefetch 小流量灰度到 prerender。
啟用後內容過期
模擬發布更新發生在預先渲染與點擊之間，驗證 ETag 和局部刷新，確保看到最新標題與正文。
常見誤區與追問
誤區一：所有連結都 prerender
追問：命中率、並行上限和記憶體預算是多少？應提出規則篩選與關閉條件。
誤區二：預先渲染等同快取
追問：頁面執行哪些腳本？如何延後分析並保護登入態？
誤區三：只看 Lighthouse 分數
追問：真實使用者的啟用率、取消率和頻寬變化如何分層驗證？
誤區四：沒有普通導航回退
追問：瀏覽器不支援或預先渲染被取消時，點擊鏈路是否仍可用？
誤區五：忽略資料新鮮度
追問：文章在預先渲染後更新，啟用時怎樣避免顯示舊內容？
延伸追問與參考答案
為什麼不直接對所有頁面 prerender？
因為預先渲染會消耗額外資源並可能執行腳本。只選高命中、唯讀、同源且有預算的頁面。
如何避免分析事件重複？
在預先渲染階段偵測 document.prerendering，延後事件到啟用並以導航 ID 去重。
如何證明優化有效？
用真實使用者分流，比較啟用導航的 LCP、INP、等待時間、頻寬和取消率，並按裝置與網路分層。