Google 搜尋如何使用推測規則

Barry Pollard
Oleksiy Busaryev
Oleksiy Busaryev
LinkedIn

發布日期：2025 年 2 月 12 日

Google 搜尋是網路上最受歡迎的網站之一，也是速度最快的網站之一。搜尋團隊持續投入心力，讓搜尋體驗更快速。在 Google 搜尋這樣熱門的網頁上，即使只縮短幾毫秒，累積起來的效益也相當可觀！這項速度相關的興趣包括知名的 Google 首頁、搜尋引擎結果網頁 (SERP)，以及從這些搜尋結果點選至其他網站的次數。

Google 搜尋一直在使用 Speculation Rules API，改善從搜尋結果頁面前往結果連結的導覽速度，而且他們一直在使用 API 的幾項功能，其他網站擁有者可能會對這些功能感興趣。

預先擷取前兩個結果

推測規則的最初用途之一，就是預先擷取前兩個搜尋結果。例如，搜尋「test」時，頁面會包含下列推測規則：

{
    "prefetch": [{
        "source": "list",
        "requires": [
            "anonymous-client-ip-when-cross-origin"
        ],
        "referrer_policy": "strict-origin",
        "urls": [
            "https://www.merriam-webster.com/dictionary/test",
            "https://dictionary.cambridge.org/dictionary/english/test"
        ]
    }]
}

底部的兩個網址是前兩個搜尋結果，會立即預先擷取。如果使用者點選這些連結，由於瀏覽器已可使用 HTML 文件，因此使用者會先看到這些連結。

如先前所述，您可以在「DevTools」應用程式 ->「Speculation」分頁中查看規則和預先載入嘗試：

開發人員工具的「Speculation」面板，顯示兩個字詞「text」的字典定義，兩者都已成功預先擷取
「Speculations」面板顯示兩個成功的預先擷取。

隱私權保護預先載入

由於這些連結是其他網站上的內容，使用者尚未造訪這些網站，因此預先載入時需要考量額外的隱私權問題。

所幸，我們在設計 API 時就考量到這一點，Google 搜尋也運用了兩項功能來保護使用者的隱私權。

第一個是使用 requires 設定，確保預先擷取功能使用 Chrome 中的私人預先擷取 Proxy：

"requires": [
    "anonymous-client-ip-when-cross-origin"
],

這項功能會使用 Proxy，確保連線會將 IP 位址設為匿名，因此在使用者點選連結前，我們不會將使用者的 IP 位址洩漏給網站。

其次，Google 搜尋會使用 referrer_policy 設定，確保系統不會透過 referer HTTP 標頭，將搜尋頁面網址中編碼的詳細資料傳送至網站：

"referrer_policy": "strict-origin",

目前大多數瀏覽器都會預設為 strict-origin-when-cross-origin，但這項設定會採用更嚴格的設定，即使是同源預先載入，也要使用 strict-origin 參照網址政策。

如果使用者有該網站的 Cookie，系統就會自動啟用第三層防護機制。在這種情況下，他們可能會根據這些 Cookie 收到不同的結果，而 Chrome 不會使用預先擷取的 HTML：

開發人員工具的「Speculation」面板顯示兩個網址，但其中一個網址無法預先擷取，並顯示錯誤訊息，指出使用者有該來源的 Cookie，因此無法預先擷取
「Speculations」面板，其中一個預先擷取失敗，是因為 Cookie。

這確實表示使用 Cookie 的使用者在點按該網站時，不會享有預先載入所提供的效能提升優勢，但系統會優先保護隱私權和確保網頁正確載入。此外，如果使用者已造訪網站並有該網站的 Cookie，則該使用者更有可能將該網站的部分素材資源快取，因此即使未預先載入，網頁載入速度也可能會更快。

預先載入前兩個搜尋結果對使用者造成的影響

如同大多數變更，Google 搜尋在 A/B 測試實驗中推出預先載入功能，並評估其影響。最大內容繪製 (LCP) 的表現大幅進步。在 Android 版 Chrome 中，Google 搜尋點擊事件的 LCP 縮短了 67 毫秒。後續推出的 Chrome 桌面版也達到類似的改善效果，LCP 縮短了 58.6 毫秒。這些改善措施是針對導向的網站，而非 Google 搜尋網站本身，但對 Google 搜尋使用者有益。

雖然 LCP 的改善幅度似乎不大，但對於 Google 搜尋這類經過極致最佳化的網站而言，即使是幾毫秒的改善，我們都會為使用者感到高興，因此幾十毫秒的改善幅度就很不尋常！你的網站可能會獲得更顯著的效益，不妨試試看！

自 2022 年 10 月起，Android 版搜尋服務預設會啟用使用推測規則的預先擷取功能，並在 2024 年 9 月前推出電腦版。

顯示前兩個結果以外的結果

自 Speculation Rules API 推出以來，我們已強化其急迫性屬性，讓系統只在使用者將滑鼠游標懸停在連結上，或開始點選連結時，才會進行推測。

Google 搜尋決定超越前兩個搜尋結果，並預先擷取剩餘的搜尋結果，但只有在使用者將滑鼠游標懸停在連結上時才會執行，方法是使用 moderate 急迫度設定。這樣一來，系統就不會浪費資源在較少人點擊的連結上。

再次提醒，在 Chrome 中搜尋時，您可以在開發人員工具中看到這項規則，而且與先前的規則相同，但這次已設定 "eagerness": "moderate" 選項：

開發人員工具「規則」面板顯示使用 anonymouse-client-ip-when-cross-origin 的清單規則、strict-origin 參照網址政策、中等急迫性和七個網址
Google 搜尋使用的推測規則。

將游標懸停在這些連結上，即可觸發預先載入功能。請注意，Google 搜尋會明確列出網址，而不是使用 Speculation Rules API 的 文件規則功能，因為 Google 不想預先擷取廣告等其他網址。

預先載入前兩個結果以外的影響

根據 A/B 測試結果，Chrome 電腦版將 Google 搜尋導覽的首次顯示內容所需時間 (FCP) 縮短了 7.6 毫秒，LCP 縮短了 9.5 毫秒。與前兩個結果的 58.6 毫秒改善幅度相比，這代表較小的增幅，但這一點並不令人意外，因為這兩個結果的預先擷取速度較慢，不過，基於先前提到的原因，這些都是不錯的成果。

我們已在 2024 年 12 月預設啟用電腦版的預先擷取功能，以便擷取剩餘的搜尋結果。

在行動裝置上，由於通常無法使用懸停功能，因此我們並未發現實際的改善效果，因此雖然沒有回歸現象，但這些額外的預先載入功能並未在行動裝置上啟用。

Google 仍在實驗這項令人期待的新 API，希望能盡可能加快網頁瀏覽速度。我們正在努力開發其他一些技巧。

舉例來說，Chrome 會為已啟用預先載入功能的使用者推出預先算繪的搜尋結果頁面，當使用者在 Chrome 網址列和 Android 的搜尋框等其他位置輸入搜尋查詢時，就會顯示這些頁面。這項功能也開放其他搜尋引擎導入，而不僅限於 Google 搜尋，不過我們目前並未發現其他搜尋引擎有導入這項功能。

Google 搜尋不會進一步為搜尋結果連結實作預先載入功能，因為這項功能不適用於跨網站導覽 (甚至必須為同網站跨來源預先載入)。

關於瀏覽器支援功能的附註

Browser Support

  • Chrome: 109.
  • Edge: 109.
  • Firefox: not supported.
  • Safari: not supported.

Source

目前 Speculation Rules API 已在以 Chromium 為基礎的瀏覽器中實作，但 Chrome 會透過 W3C 標準程序發布 API 規格，並希望其他瀏覽器也能實作此 API。

私人預先擷取 Proxy 目前僅在 Chrome 中實作，其他以 Chromium 為基礎的瀏覽器則未實作，但如果其他瀏覽器實作自己的私人預先擷取 Proxy，Google 搜尋可能也會在這些瀏覽器中實作這些改善項目。

由於預先擷取功能在沒有私人預先擷取 Proxy 的情況下，可能會影響隱私權，因此 Google 搜尋不會在不支援這項技術的瀏覽器上預先擷取，因此並未針對其他瀏覽器實作使用其他技術的備用方案。不過，由於這是漸進式增強功能，這只是表示使用這些瀏覽器的使用者不會因為速度略微提升而受惠。

歡迎在你的網站上試用這項功能！

Speculation Rules API 適用於所有網站，而非僅限於 Google 搜尋。除了本文所述的預先載入功能外，預先轉譯功能還可在特定時間和位置提供更多優勢。像 Google 搜尋這樣的大型網站，已證明這個 API 對使用者體驗有明顯的益處，因此我們鼓勵所有網站擁有者研究如何使用這個 API，並從中獲益。

此外，其他網站也可以使用這篇文章中詳述的隱私權保護措施，但請注意，使用者必須在設定中啟用擴充預先載入支援功能，才能讓非 Google 網站使用 Google 的私人預先載入 Proxy 來轉送流量。這是因為這會讓 Google 成為使用者與網站之間的額外第三方，但在 Google 網站上，這並非必要，因為 Google 本身就是相關當事人之一。