如何使用推測規則 API 即時載入網頁
已發表: 2024-02-172024 年，即時載入將成為 Web 效能的新標準，線上企業主將洗耳恭聽。
不過，從快速到即時的轉變已經進行了一段時間。
早在 2009 年，出於對更快、更有效率的頁面載入的追求，Chromium 團隊創建了第一個資源提示，後來添加了連結 rel=”prerender」。
它預計會對效能產生重大影響，因為它涉及在使用者導航到後續頁面之前在背景載入後續頁面，從而確保在發生轉換時更快地呈現。
然而，這個版本的預渲染並沒有被證明足夠高效，並於 2017 年被棄用。
快進到今天，Google推出了其推測規則 API 的有希望的開發，允許採用更複雜的方法來完全預先渲染和解鎖真正無縫的網頁瀏覽。
什麼是 Google 推測規則 API？
Speculation Rules API 是 Google 開發的 JSON 定義的 API，旨在透過推測載入策略來增強網頁載入的效能。
推測性載入涉及預測和預先載入後續頁面導航的資源，從而縮短渲染時間並改善使用者體驗。 Google 引入此 API 是為了向開發人員提供更靈活、更具表現力的方式來指定應預取或預渲染哪些文件。
有關推測規則 API 的關鍵詳細資訊：
- 定位文件 URL：與針對特定資源檔案的傳統預取機制不同，推測規則 API 專注於文件 URL。 這使得它特別適合多頁面應用程式（MPA）而不是單頁面應用程式（SPA）。
- 預渲染和預取： API 支援預渲染和預取策略。 預先渲染涉及獲取、渲染內容並將其加載到不可見的選項卡中，以便在使用者導航到頁面時幾乎可以立即啟動。 另一方面，預取下載並儲存指定的頁面資源（例如文件、映像、腳本等），從而優化使用者稍後導航到這些頁面時的載入時間。
- 瀏覽器支援：該 API 目前與所有基於 Chromium 的瀏覽器相容，包括 Chrome、Edge、Opera、Chrome Android、Opera Android 和 WebView Android。 有關完整的兼容性詳細信息，請參閱 Mozilla 的文檔：
您也可以使用以下程式碼檢查瀏覽器是否支援該 API：
- 已棄用功能的替代方案：它可作為舊技術（例如已棄用的 Chrome 專用功能）的替代方案，提供更好的性能和更具表現力的語法。
- 安全考量：跨站點預取有限制，以保護使用者隱私。 只有當使用者沒有為目標網站設定 cookie 時，跨網站預取才會起作用，從而防止潛在的使用者活動追蹤。
為什麼在您的網站上使用推測規則 API？
推測規則 API 支援近乎即時的頁面加載，實現無縫的瀏覽體驗。
改進的頁面載入時間、增強的用戶滿意度和潛在的 SEO 優勢是開發人員採用這項技術的令人信服的理由。
透過減少頁面導航之間的延遲，使用者會認為網站更加流暢且反應迅速。 這在您網站的核心網路生命週期中變得清晰可見，其中最大內容繪製 (LCP)、累積佈局偏移 (CLS) 和下次繪製互動 (INP) 急劇減少。
即時瀏覽體驗可以降低跳出率並提高用戶保留率，這是線上平台成功的重要指標。 從而強調了整合推測規則 API 的戰略價值。
推測規則 API 如何運作？
Google 的推測規則 API 旨在針對文件 URL 而不是特定的資源文件。 推測規則 API 引入了更具表現力和可配置的語法，用於指定應預取或預渲染哪些文件。
透過在腳本 type="speculationrules" 中以 JSON 格式定義的結構，開發人員可以闡明預先渲染和預取的規則。 這種增強的靈活性允許微調投機負載。
最近，Google 宣佈在 Chrome 121 中對推測規則 API 進行了新的增強，現在提供了自動連結查找的選項。
這是透過以下方式完成的：
- 指定文檔來源
- 根據 URL 或 CSS 選擇器選擇頁面上的鏈接
- 指定「渴望」等級 - 渴望（立即）、中等（懸停 200 毫秒）和保守（滑鼠或觸摸時）
但是，如果您不熟悉推測規則 API，我們建議您先測試以下不同的設定。
如何使用 Google 的推測規則 API
推測規則 API 允許開發人員遵循結構化方法來優化預渲染和預取過程。
設定
先建立一個腳本 type="speculationrules" 元素，並在其中的 JSON 結構中定義推測規則。
推測規則可以加入主機的頭部或主體。
重要提示：子訊框中的推測規則不會被執行，並且預渲染頁面中的推測規則僅在使用者導航到頁面本身時才會執行。
推測規則可以靜態或動態地包含。
- 靜態設定在頁面的 HTML 中完成（非常適合下一步操作具有高度確定性的網站，例如新聞網站可能想要預先渲染當天的亮點）
- 動態設定透過 JavaScript 完成（適合大量使用個人化使用者體驗的網站）
重要提示：選擇動態設定時，請務必參閱支援文件以了解未來的開發和未來可能提供的用例。
若要通知瀏覽器要預先渲染哪些 URL，您可以在頁面上插入 JSON 指令：
同樣，插入以下 JSON 指令進行預取：
可以為頁面新增多個推測規則，在這種情況下，您可以在下列任一層級上指示瀏覽器：
- 網址列表
- 多重推測規則
- 一組推測規則中的多個列表
指定預先渲染/預取的路由
微調推測載入涉及指定預渲染和預取的路由。 透過根據頁面的重要性或使用者導航的可能性對頁面進行分類，開發人員可以優化推測載入策略。
然而，有一些路線被認為是不安全的，例如：
- 註銷 URL；
- 語言切換 URL；
- 「加入購物車」網址；
- 伺服器要求發送 SMS 的登入流程 URL，例如，當需要雙重認證 (2FA) 時；
- 啟動伺服器端廣告轉換追蹤的網址；
- 觸發使用者使用限制的 URL，例如透過使用每月的免費文章限額。
與從快取中排除此類頁面類似，避免預取和預渲染它們的原因與動態變數有關。
這些是內容敏感的頁面，其中值會根據使用者操作進行更新，並且透過在背景預先載入它們，顯示頁面過時狀態的風險非常高。
準確性和權衡
正如 Barry Pollard 在我們的「立即加載頁面」網路研討會中提到的：
雖然預取是您可以在許多網頁上複製的最安全的方法，但它也提供最低的獎勵，因為它只涉及下載特定資源。
另一方面，全頁預渲染提供更高的獎勵，但應謹慎使用它們，因為它們可以：
- 壓垮瀏覽器，因為它只能在後台運行有限數量的任務。
- 消耗大量頻寬和 CPU 資源，這可能會導致速度較慢的網路或資源有限的裝置上的使用者效能下降。
- 如果訪客不導航到該頁面，則會導致更高的資源浪費。
要正確設定預呈現，您應該考慮使用者的行為並分析網站上的常見導航。 使用熱圖和 Google Analytics 流程圖，您可以確定基本路線並開始預測載入實驗。
若要檢查頁面是否已預先渲染，請使用PerformanceNavigationTiming的非零 activateStart條目。 然後可以使用自訂維度記錄這一點：
這樣，您將能夠衡量預渲染和其他類型的導航之間的比率。
此外，測量隨後未訪問的預渲染頁面的數量也很重要，以優化推測規則並實現更高的命中率和更低的資源浪費。
您可以透過在插入推測規則以指示請求預先渲染時觸發分析事件來執行此操作。 然後將這些事件的數量與實際預渲染頁面視圖進行比較。
或者你可以…
考慮使用 NitroPack 的導航 AI 進行自動頁面預渲染
Navigation AI 是 NitroPack 的 AI 支援的網頁瀏覽優化器，可主動預測和分析使用者行為，以在客戶旅程中預先渲染完整頁面。
導航 AI 使網站所有者能夠在桌面和行動裝置上提供即時瀏覽體驗，而無需編寫一行程式碼，從而提高客戶參與度和轉換率。
注意： Navigation AI 是一個單獨的產品，但它與 NitroPack 100% 相容，並進一步擴大了網站所有者的利益。
加入 Navigation AI 的候補名單並解鎖網站上的即時使用者體驗 →
NitroPack 的導航 AI 基於推測規則 API 構建，並提供自動化解決方案，以在預渲染場景中實現高命中率和資源效率。
透過基於資料對頁面載入應用人工智慧增強的初始預測並分析使用者行為，導航人工智慧可以調整預測並準確指示推測規則 API 預先渲染實際將存取的頁面。
由於該頁面已在背景繪製，因此結果是瞬時頁面載入。 在行動裝置上，導航 AI 依賴於識別用戶在頁面上的位置，並且考慮到較小的視口，它可以輕鬆預測他們將點擊的位置。
基於 1,200 個網站，Navigation AI 已經顯示出驚人的結果。
- 結果#1：使用 Navigation AI 的網頁始終顯示約 2.86 秒的載入時間，而沒有使用 Navigation AI 的網頁則為 6.12 秒
- 結果 #2：使用 Navigation AI，預先渲染頁面的 LCP 提高了 85%（從 3.1 秒到 0.4 秒），CLS 提高了 80%（從 0.3 秒到 0.06 秒）。 對於預取頁面，Navigation AI 將 LCP 提高了 52%（從 3.1 秒縮短到 1.5 秒）。
- 結果 #3：借助 Navigation AI，整個網站的效能指標顯著提高：LCP 提高 15%，CLS 提高 8%，TTFB 提高 26%
加入我們的候補名單即可使用 Navigation AI →
推測規則 API 和 WordPress
在我們的「即時頁面載入」網路研討會中，Google 的開發者關係工程師 Adam Silverstein 透露，WordPress 核心效能團隊正在致力於新的推測規則 API 的更穩定的實現。
目前，重點仍然是讓生態系統中的網站所有者和開發人員可以使用 API 的一小部分功能，以在將其成為核心的一部分之前測試效率和採用率。 以下是 WordPress 用戶迄今為止可以利用的功能：
- Performance Lab 外掛程式中的一個模組
- 僅實現推測規則 API 前端的獨立插件（應用保守的「渴望」級別，但開發人員可以自由修改行為）
預設情況下，WP 管理路由被排除在外，但由 WP 開發人員決定他們想要優先考慮的路由。
WordPress 核心效能團隊也致力於在生態系統的外掛程式中實現更複雜的實作。 這樣做的目的是減輕開發人員在確定哪些路線是最優先、哪些路線不可行時必須做的一些繁重工作。
投機規則將有哪些改進
目前，推測規則僅限於同一選項卡內的頁面，但正在努力減少這些限制。
預設情況下，預渲染僅限於同源頁面。 然而，Chrome 119 的最新更新現在支援同網站跨來源頁面的預渲染，需要透過 HTTP 標頭選擇加入。
未來的版本可能會將預渲染擴展到跨來源頁面，並允許在新分頁中進行預渲染。 推測規則 API 將進行擴展，引入文件規則的分數和語法，並提供更大的靈活性，例如滑鼠按下時預先渲染連結。
Chrome 中正在進行的實驗正在探索其他功能，網站可以參與原始試驗來測試並提供有關未來潛在添加功能的回饋。