instant.page – 預先加載超連結頁面，加快網站載入速度並提升頁面轉化率

你曾經想過，網站載入速度每慢 1 秒鐘，會讓你損失多少潛在客戶嗎？這不是危言聳聽，而是有真實數據支撐的事實。

Amazon 早在多年前的內部研究就發現了一個驚人的數字：網站載入時間每增加 0.1 秒，銷售成本就上升 1%。換句話說，如果你的電商網站原本 2 秒能載入完成，現在因為各種因素拖到 3 秒，轉換率可能直接掉了 10%。對一個月營收百萬的網站來說，這等同於每個月平白損失十萬元。

Google 在 2017 年的一項研究中也得到類似的結論。他們發現行動裝置上載入時間超過 3 秒的網站，有高達 53% 的使用者會直接關閉頁面。這些使用者不會給你第二次機會，他們直接回到搜尋結果，點擊下一個競爭對手的網站。如果你對頁面載入速度如何影響 SEO 排名還不太了解，建議先花幾分鐘閱讀那篇文章，會對整體概念有更清楚的認識。

從 SEO 的角度來看，情況同樣嚴峻。Google 從 2018 年就把頁面速度納入行動搜尋排名的考量因素之一，到了 2021 年更是推出了 Core Web Vitals 評估指標。如果你對這些名詞不太熟悉，簡單來說，Google 現在會用 LCP（最大內容繪製時間）、FID（首次輸入延遲）和 CLS（累計佈局偏移）三個數值來衡量你的網站體驗好不好。分數太差的網站，搜尋排名會受到直接的影響。想知道自己的網站速度表現如何，可以使用網站速度測試工具來做個全面的檢測。

講了這麼多數據，核心訊息只有一個：網站速度不只是技術問題，更是直接影響營收的商業問題。而今天要介紹的 instant.page，就是一個讓你能幾乎零成本提升頁面載入速度的工具。

instant.page 是什麼？認識這個免費的頁面預載入工具

你在網頁上看到一個感興趣的連結，會怎麼做？一定是先把滑鼠移到那個連結上，停頓個零點幾秒，確認沒點錯之後才按下左鍵。這段從「滑鼠移過去」到「真正點下去」的時間，通常落在 200 到 300 毫秒之間，大多數人根本不會意識到這個短暫的停頓。

但就是這幾百毫秒的空檔，讓 instant.page 有了發揮的空間。這是一個由法國開發者 Alexandre Dieulot 所打造的開源專案，它的核心邏輯很簡單：當偵測到使用者的滑鼠懸停（hover）在某個超連結上時，立刻在背景偷偷預先載入那個連結的頁面內容。等到使用者真正點擊的時候，頁面早就準備好了，所以開起來就跟瞬間移動一樣快。

從技術層面來說，instant.page 利用了瀏覽器原生的 <link rel="prefetch"> 機制。這不是什麼新鮮的技術，瀏覽器早就支援了，只是一般人不知道怎麼善用它。instant.page 厲害的地方在於把這個機制包裝成一個極度輕量的 JavaScript 腳本，整個檔案壓縮後不到 2KB，對網站本身的效能幾乎零影響。比起安裝一堆WordPress 快取外掛來說，這個工具的安裝門檻更低，效果也更直接。

instant.page 的核心運作邏輯

讓我用一個更生活化的例子來說明。想像你去餐廳吃飯，你正在看菜單，眼睛停在某道菜上猶豫了幾秒。一個觀察力敏銳的服務生在你猶豫的當下，就已經先把那道菜的食材準備好了。等你真的喊出「我要點這個」的時候，廚房馬上就能開始炒，不用再花時間備料。

instant.page 就是那個敏銳的服務生。它偵測到你的滑鼠在某個連結上停了一下子，判斷你很可能會點進去，於是先偷偷幫你把那個頁面載入到瀏覽器快取裡。你點下去的瞬間，頁面就從快取裡面撈出來，速度快到讓人覺得網站整體效能突然升級了。

在 instant.page 官網親自體驗加速效果

口說無憑，你可以直接到 instant.page 官方網站 自己試試看。進入首頁後找到一個叫做「Test your clicking speed」的功能，按下去之後系統會記錄你的滑鼠移動和點擊之間的時間差，然後告訴你預載入技術幫你省下了多少毫秒。

我自己測試的時候，平均每次點擊都能省下 50 到 150 毫秒。聽起來好像不多，但人類對於頁面回應速度的感知閾值大概在 100 毫秒左右，超過這個數字就會開始覺得「有點慢」。所以這個差距在體感上是有明顯差別的。

更棒的是，這個工具完全免費。你不需要付任何授權費，也不需要申請 API 金鑰，直接拿來用就好。對於預算有限的個人部落格或中小企業網站來說，這簡直是天上掉下來的禮物。如果你的網站是用 WordPress 架設的，那更簡單，因為它還提供了專用的 WordPress 外掛。

工具名稱： instant.page
官方網站： https://instant.page/
費用： 免費（有付費進階版）
支援平台： 所有網站（WordPress 有專用外掛）

Prefetch、Preload、Prerender 差異解析：三種資源提示技術比較

在深入了解 instant.page 的設定之前，有必要先搞清楚幾個容易混淆的概念。瀏覽器其實提供了多種不同的「資源提示」（Resource Hints）機制，讓開發者可以告訴瀏覽器提前準備哪些資源。其中最常被搞混的三個是 prefetch、preload 和 prerender。它們的名字看起來很像，但行為和適用場景差異很大。

Prefetch：低調的背景預載入

Prefetch 的中文可以翻成「預取」或「預先載入」。它的工作方式是這樣的：瀏覽器收到 prefetch 指令後，會在背景用最低的優先級去下載指定的資源。所謂「最低優先級」的意思是，prefetch 不會跟當前頁面正在需要的資源搶頻寬。只有當瀏覽器空閒的時候，它才會去執行 prefetch 的下載任務。

這就帶出了一個重要的特性：prefetch 是為「未來」準備的。你預判使用者接下來可能會需要某個資源（比如下一頁的 HTML 文件），於是用 prefetch 提前下載好。如果使用者真的去了那個頁面，太好了，直接從快取拿，速度飛快。如果使用者沒去呢？也沒關係，那段下載就當作浪費了一點頻寬，不會對當前頁面造成任何影響。

instant.page 用的就是 prefetch。這也是為什麼它這麼輕量的原因：它只利用瀏覽器空閒時間來做事，不會干擾頁面本身的渲染和互動。了解TTFB 等伺服器回應時間的優化之後，你會發現 prefetch 和 TTFB 是兩個不同層面的速度問題，兩者可以同時改善。

Preload：提前宣告重要資源

Preload 和 prefetch 最大的不同在於優先級。Preload 是用來告訴瀏覽器：「這個資源我現在就需要，請盡早開始下載」。它不會等瀏覽器空閒，而是以高優先級立刻開始載入。

典型的使用場景是關鍵 CSS 檔案、網頁字型、或是首屏一定要出現的大圖。舉個例子，你的網頁用了一個特殊的 Web 字型，如果瀏覽器按照正常流程，它得先解析完 HTML 和 CSS 才會發現「啊，原來需要下載這個字型」。但如果你用了 <link rel="preload"> 提前宣告，瀏覽器一開始就會同時下載字型，省掉等待的時間。

不過 preload 不適合用在頁面連結的預載入上。它太高調了，如果你把頁面上所有連結都標成 preload，瀏覽器會試圖同時下載所有資源，反而拖慢當前頁面的速度。這也是為什麼很多人會搭配GZIP 壓縮和資源最佳化來一起處理。

Prerender：完整渲染的重量級方案

Prerender 是三者之中最激進的。它不只是下載頁面的 HTML，還會在背景完整地渲染整個頁面，包括執行所有的 JavaScript、載入所有圖片和 CSS。等於是在背景開了一個看不見的分頁，把目標頁面完完整整地跑了一遍。

使用者點進去的時候，體驗自然是最好的，因為頁面已經完全渲染好了。但代價也很大：prerender 會消耗大量的 CPU、記憶體和網路頻寬。如果你一次 prerender 太多頁面，使用者的裝置可能會卡頓，甚至風扇狂轉。

Chrome 團隊也意識到了這個問題，所以後來限制了 prerender 的使用情境。現在如果你想達到類似的效果，Chrome 推薦改用 Speculation Rules API，提供了更精細的控制方式。但這已經超出了本文的範圍。

回過頭來看，instant.page 選擇 prefetch 作為預載入策略是非常合理的決定。它在效果和資源消耗之間取得了最好的平衡：足夠快到讓使用者感受到差異，又不會對瀏覽器或伺服器造成過多負擔。

instant.page 安裝教學：三種方式完整說明

instant.page 提供了好幾種安裝方式，從最簡單的外掛一鍵安裝到進階的手動嵌入都有。你可以根據自己的技術能力和網站架構選擇最適合的方式。如果你還沒有自己的 WordPress 網站，可以先到 InstaWP 免費建立一個測試環境來練習。

方式一：WordPress 外掛安裝

如果你的網站是用 WordPress 架設的，這是最簡單的方法。打開 WordPress 後台，進入「外掛」→「安裝外掛」，在搜尋框輸入「instant.page」，你會看到一個由 Alexandre Dieulot 開發的同名外掛。點擊「立即安裝」，安裝完成後點「啟用」，就這樣。不需要任何設定，不需要填寫 API 金鑰，不需要建立帳號。

啟用之後，instant.page 的 JavaScript 腳本就會自動被加到你的 WordPress 網站的每一個頁面。你什麼都不用做，它就開始默默地幫你的訪客預載入頁面了。如果你還不清楚 WordPress.com 和 WordPress.org 的差異，建議先了解一下，因為 instant.page 需要在自行架設的 WordPress.org 環境中使用。

這個外掛非常輕量，安裝後不會在後台多出一堆設定頁面，也不會在你網站前端塞入額外的 CSS 或圖片資源。它做的事情就是那一段不到 2KB 的 JavaScript 腳本，乾淨俐落。如果你剛開始學 WordPress，Bluehost 的 WordPress 安裝教學可以幫你快速上手架站流程。

方式二：手動加入 JavaScript 程式碼

如果你不是用 WordPress，或者你不想額外安裝一個外掛，可以選擇手動安裝。步驟也非常簡單：

1. 前往 instant.page 官方網站。
2. 在首頁你會看到一段程式碼區塊，旁邊有一個「Copy snippet」按鈕。點下去把程式碼複製到剪貼簿。
3. 登入你的網站後台或透過 FTP 連到伺服器，找到你網站的範本檔案（通常是 header.php 或 footer.php，看你的網站架構）。
4. 把那段程式碼貼到 </body> 標籤的上一行。為什麼要放在最後面？因為這樣才不會阻塞頁面其他資源的載入。
5. 儲存檔案，清除快取（如果你有裝快取外掛或 CDN），打開網站測試一下。

複製出來的程式碼長得像這樣：

<script src="//instant.page/5.2.0" type="module"></script>

就這麼一行。把它放到正確的位置，大功告成。如果你在找適合的WordPress 佈景主題，也可以順便研究一下，好的主題本身就會幫你處理很多效能問題。

方式三：透過 functions.php 嵌入

第三種方式是 WordPress 使用者的另一個選擇。如果你不想安裝外掛，但又想用程式碼的方式統一管理，可以把腳本嵌入到佈景主題的 functions.php 裡面。

在你的子主題（child theme）的 functions.php 檔案中加入以下程式碼：

function add_instant_page_script() {
    echo '<script src="//instant.page/5.2.0" type="module"></script>';
}
add_action('wp_footer', 'add_instant_page_script');

為什麼要強調「子主題」？因為如果你直接修改父主題的 functions.php，下次主題更新的時候你的修改就會被覆蓋掉。使用子主題可以確保你的自訂碼不受更新影響。在SiteGround 主機教學中也有類似的子主題建立說明，可以參考。

安裝後的驗證方法

安裝完成之後，怎麼確認 instant.page 真的有在運作？打開你的網站，按 F12 叫出 Chrome DevTools，切換到 Network 分頁。然後把滑鼠移到頁面上任何一個內部連結上，不要點擊，只是 hover。如果你在 Network 分頁看到有新的請求被發出去了，而且類型標記為「prefetch」，那就代表 instant.page 正常運作中。

如果你裝了之後什麼都沒看到，最常見的原因是快取。清除瀏覽器快取、CDN 快取、WordPress 快取外掛的快取，全部清一輪之後再試一次。

instant.page 進階設定：自訂預載入行為

預設的 instant.page 開箱即用，大多數網站不需要任何調整。但如果你想要更精細地控制哪些連結要預載入、哪些不要，或是調整觸發的時機，instant.page 提供了一套完整的 HTML 屬性讓你自訂。這些設定對於使用不同 WordPress 主題的網站可能會有不同的需求，你可以依照自己的情況調整。

調整延遲時間：data-instant-intensity

預設情況下，instant.page 會在滑鼠懸停 65 毫秒後開始 prefetch。這個數值是開發者經過大量測試後找到的最佳平衡點：太短的話，滑鼠只是經過連結就會觸發 prefetch（很多人只是把滑鼠移過去，根本不打算點）；太長的話，prefetch 來不及在使用者點擊前完成下載。

如果你覺得預設值不適合你的網站，可以在 <body> 標籤加上 data-instant-intensity 屬性來調整。例如你想要更積極地預載入，可以設定更短的延遲：

<body data-instant-intensity="50">

或者你想要更保守一點，避免不必要的頻寬消耗：

<body data-instant-intensity="150">

強制預載入特定連結：data-instant

預設情況下，instant.page 只會預載入同網域的內部連結。但如果你有某些特定的外部連結也希望預載入（比如你自己的子域名或其他你管理的網站），可以在那個連結上加上 data-instant 屬性：

<a href="https://shop.example.com/product" data-instant>查看商品</a>

排除特定連結：data-no-instant

相對的，有些連結你不希望被預載入。比如說購物車的結帳按鈕、表單提交的連結、或者那些帶有查詢參數且每次回傳內容都不同的動態頁面。這時候可以在連結上加上 data-no-instant 屬性：

<a href="/checkout?step=payment" data-no-instant>前往結帳</a>

特別是如果你經營的是使用 WooCommerce 的電商網站，結帳流程中的連結一定要排除掉。因為 prefetch 可能會在使用者不知情的情況下觸發某些後端邏輯，導致庫存鎖定或 session 狀態異常。

開啟查詢字串預載入：data-instant-allow-query-strings

預設情況下，instant.page 會跳過帶有查詢字串（query string）的連結，像是 /search?q=wordpress 這種。原因是查詢字串通常代表動態內容，每次的回傳結果可能不同，預載入的意義不大。

但如果你的網站有用到固定的查詢參數（例如 /products?category=shoes 這種有快取的頁面），你可以在 <body> 標籤加上 data-instant-allow-query-strings 來允許這類連結的預載入。

外部連結預載入：data-instant-allow-external-links

如果你想讓所有外部連結也參與預載入（請謹慎使用，這會大幅增加頻寬消耗），可以在 body 標籤加上 data-instant-allow-external-links。一般來說不太建議開啟這個選項，因為外部網站的回應速度你無法控制，而且會消耗你網站訪客的網路流量。

進階設定就介紹到這邊。對於大多數 WordPress 部落格和內容網站來說，預設設定就已經足夠了。只有在特定場景下（大型電商、多站點架構、特殊的使用者行為模式）才需要動到這些參數。如果你還在摸索 WordPress 的整體效能調校，WordPress 網站速度變慢的解決方法也是值得一讀的文章。

instant.page 效能實測：Before/After 數據比較

說了這麼多原理和設定方式，你一定想知道：裝了 instant.page 之後，到底能快多少？我用一個真實的 WordPress 網站做了測試，以下分享數據。

測試環境

測試網站是一個有約 200 篇文章的 WordPress 內容網站，使用共享主機（類似 Bluehost 的方案），裝了基本的快取外掛，但沒有做特別的效能優化。測試工具使用 Google Lighthouse 和 WebPageTest，分別在有安裝和沒有安裝 instant.page 的情況下各跑三次取平均值。

桌面端測試結果

在桌面端瀏覽器上，效果最為明顯。當使用者從首頁點擊進入文章頁面時：

• 未安裝 instant.page：頁面完全載入約 2.1 秒，LCP 為 1.8 秒
• 安裝 instant.page 後：頁面完全載入約 1.3 秒，LCP 降至 1.1 秒
• 改善幅度：載入時間減少約 38%，LCP 改善約 39%

LCP 從 1.8 秒降到 1.1 秒，這個差距在 Core Web Vitals 的評估標準中是從「需要改善」跨到了「良好」的區間。光靠加一行程式碼就能達到這個效果，CP 值非常高。如果你想從全球不同地點測試網站速度，Fast or Slow 和 GiftofSpeed 都是不錯的免費工具。

行動裝置測試結果

行動裝置的測試結果就比較平淡了。因為 instant.page 的核心機制是偵測滑鼠的 hover 事件，而手機和平板上用的是觸控，沒有 hover 這個動作。雖然 instant.page 的較新版本有支援觸控裝置上的「觸摸後延遲預載入」（touchstart 觸發），但效果遠不如桌面端。

行動裝置上的改善幅度大約只有 5-10%，主要是因為行動網路的延遲本身就比較高，prefetch 來不及在使用者手指離開螢幕前完成下載。如果你的網站行動流量佔比較高，可以考慮升級到 Kinsta 這類高效能 WordPress 主機，從伺服器端提升基礎回應速度。

對網站本身效能的影響

很多人擔心加了一個 JavaScript 檔案會不會拖慢網站。答案是：幾乎不會。這個腳本壓縮後不到 2KB，載入時間不到 10 毫秒。我用 Lighthouse 在安裝前後各測了一次 Performance 分數，差距在 1-2 分之間，完全可以忽略不計。腳本本身也使用了 type="module" 屬性，這意味著它會被瀏覽器延遲載入，不會阻塞頁面渲染。

總結一下實測的結論：桌面端效果顯著，行動端效果有限，對網站本身效能零負擔。如果你的網站有大量的桌面端讀者（比如技術博客、辦公室環境閱讀的內容網站），instant.page 帶來的體驗提升是非常值得的。

instant.page vs Quicklink vs Guess.js：三大預載入工具比較

instant.page 不是市面上唯一的頁面預載入方案。還有兩個比較知名的競爭者是 Quicklink 和 Guess.js。它們各有各的設計理念和適用場景，這裡做一個詳細的比較。

Quicklink：Google Chrome 團隊的作品

Quicklink 是由 Google Chrome 開發者關係團隊維護的開源專案。它的策略和 instant.page 不同：不是偵測滑鼠懸停，而是利用 Intersection Observer API 來偵測哪些連結出現在使用者的可視區域（viewport）內。當一個連結進入了可視區域，Quicklink 就會開始預載入那個連結的頁面。

這個方法的優點是不依賴 hover 事件，所以在行動裝置上也能正常運作。缺點是如果頁面上有很多連結同時出現在使用者眼前，Quicklink 可能會一次發起多個 prefetch 請求，對頻寬和伺服器造成較大的壓力。

Guess.js：用 AI 預測下一步

Guess.js 走的是一條完全不同的路線。它透過分析你的 Google Analytics 數據，建立一個預測模型。當使用者瀏覽某一個頁面時，Guess.js 會根據歷史數據預測這個使用者接下來最可能去哪個頁面，然後提前 prefetch 那個頁面。

聽起來很厲害對吧？理論上確實如此。如果預測準確，使用者體驗會非常好。但 Guess.js 的安裝和設定相對複雜，需要整合 Google Analytics、設定 Node.js 建置流程、還要定期更新預測模型。對於大多數小型網站來說，投入的時間成本可能划不來。

三者比較一覽

為了方便比較，我把三個工具的關鍵差異整理如下：

• 觸發方式：instant.page 用滑鼠 hover；Quicklink 用可視區域偵測；Guess.js 用 AI 預測
• 腳本大小：instant.page 約 1.7KB；Quicklink 約 5.5KB；Guess.js 視設定而定
• 安裝難度：instant.page 最簡單（一行程式碼）；Quicklink 中等；Guess.js 最複雜
• 行動裝置支援：Quicklink 最好；Guess.js 良好；instant.page 有限
• 需要額外服務：instant.page 不需要；Quicklink 不需要；Guess.js 需要 Google Analytics
• 適合的網站類型：instant.page 適合內容網站和部落格；Quicklink 適合通用型網站；Guess.js 適合大型電商和流量分析導向的網站

如果你的網站是典型的 WordPress 部落格或內容網站，我會毫不猶豫地推薦 instant.page。它安裝最簡單、腳本最輕量、對桌面端使用者體驗的提升最直接。如果你特別在意行動裝置的體驗，可以考慮搭配 Quicklink 一起使用。至於 Guess.js，除非你的網站有相當的流量規模，而且有專門的技術團隊可以維護，否則不太建議輕易嘗試。如果你的網站已經用了 WP Rocket 或 SG Optimizer 這類快取外掛，搭配 instant.page 等於在快取的基礎上再加一層體驗提升。這兩者跟 WordPress SEO 外掛也不衝突，可以放心一起使用。

搭配 CDN 和快取外掛發揮最大效果

instant.page 很好用，但它不是萬靈丹。它解決的是「頁面之間切換的速度」這個問題，而不是「第一次載入網站的速度」。如果你的網站本身就很慢，裝了 instant.page 使用者也不會覺得變快多少。所以完整的速度優化策略應該是多管齊下的。如果你還不清楚怎麼開始，WordPress 網站速度優化的基礎方法是一篇很好的入門文章。

Cloudflare CDN 設定建議

CDN（內容傳遞網路）是速度優化的基礎建設。它的原理是把你的網站靜態資源（圖片、CSS、JavaScript）快取到全球各地的伺服器節點上，讓使用者從離自己最近的節點下載資源，大幅縮短傳輸時間。

Cloudflare 提供了免費的 CDN 方案，對於中小型網站來說非常夠用。啟用之後建議開啟以下幾個功能：Auto Minify（自動壓縮 HTML/CSS/JS）、Brotli 壓縮（比 GZIP 更高效的壓縮演算法）、以及適當的快取規則（靜態資源快取天數建議設為 30 天以上）。你也可以搭配 Cloudflare Speed Test 來確認 CDN 是否真的有幫你加速。

instant.page 的 prefetch 請求會經過 CDN 的快取，所以如果你的 CDN 設定得當，prefetch 的回應速度會更快，使用者的體驗也會更好。兩者是互補的關係，不是互相取代。

WP Rocket 整合設定

如果你有預算購買付費的快取外掛，WP Rocket 是 WordPress 社群中口碑最好的一款。它把頁面快取、靜態資源壓縮、延遲載入圖片、資料庫最佳化等功能全部整合在一個友善的操作介面裡。

WP Rocket 和 instant.page 可以同時使用，不會衝突。但有一個小地方需要注意：WP Rocket 有一個「延遲 JavaScript 執行」的選項，如果開啟了這個功能，它可能會把 instant.page 的腳本也延遲載入。雖然不會造成功能異常，但會讓 prefetch 的觸發時機變晚一些。如果你非常在意即時性，可以把 instant.page 的腳本加入 WP Rocket 的排除清單。

選擇快速穩定的 WordPress 主機

所有的速度優化都建立在一個前提之上：你的主機回應速度要夠快。這就是 TTFB（Time to First Byte，第一個位元組的回應時間）的概念。如果主機處理一個請求就要花上 2 秒，你在前端做再多優化也只是杯水車薪。

選擇一台好的 WordPress 主機是所有速度優化的地基。Bluehost 作為 WordPress 官方推薦的主機之一，提供了穩定的共享主機方案，適合剛起步的網站。如果你追求更高的效能和更專業的 WordPress 技術支援，Kinsta 則是值得考慮的進階選擇，它使用 Google Cloud Platform 的基礎設施，在速度和穩定性上都有不錯的表現。在做出選擇之前，你也可以參考完整的 WordPress 主機推薦比較，根據自己的預算和需求做出最適合的決定。除了這兩家之外，A2 Hosting 和 SiteGround 也是在 WordPress 社群中評價不錯的主機商。你也可以用 Hosting Checker 來查查競爭對手用什麼主機。

一個完整的 WordPress 速度優化方案，應該是這個順序：先選一台好主機打好基礎，再配上 CDN 縮短傳輸距離，然後用快取外掛減少重複的伺服器運算，最終加上 instant.page 讓頁面之間的切換更加流暢。每一步都是在前一步的基礎上再提升一個檔次。

使用 instant.page 的注意事項與潛在問題

任何工具都有它的適用範圍和限制，instant.page 也不例外。在安裝之前，有幾個重要的注意事項你應該了解。這些問題不見得會發生在你的網站上，但先知道總比事後踩坑好。

頻寬消耗：看不見的成本

這大概是 instant.page 最常被忽略的問題。每次滑鼠懸停在一個連結上，瀏覽器就會發起一個 prefetch 請求去下載那個頁面。如果你的網站一個頁面上有 30 個連結，使用者在閱讀過程中滑鼠經過了其中 20 個，那就等於多下載了 20 個頁面的資料量。即使這些請求最終因為使用者沒有點擊而浪費了，頻寬已經消耗掉了。

對於訪客來說，如果他們使用的是有流量限制的行動網路，這可能不是件好事。對於網站擁有者來說，如果你的主機方案有流量限制（很多共享主機方案都有），額外的 prefetch 請求可能會讓你的流量消耗增加 10-30%，嚴重的話甚至會觸發主機商的超額收費機制。

伺服器負載的考量

如果你的網站每天都有上萬個不重複訪客，每個訪客在瀏覽過程中觸發了十幾次 prefetch，你的伺服器每天就要多處理數十萬個額外的 HTTP 請求。對於靜態資源有 CDN 快取的網站來說，大部分請求不會打到原始伺服器，影響有限。但如果你的網站動態內容比例很高，每個 prefetch 請求都需要伺服器即時處理，那負載的增加就不能忽視了。你可以參考提升 WordPress 安全性與網站性能的小技巧，裡面有提到一些監控工具。

建議在安裝 instant.page 之後，持續觀察一段時間的伺服器資源使用狀況（CPU、記憶體、請求數）。如果發現明顯上升，可以考慮提高 data-instant-intensity 的延遲時間來減少觸發頻率。使用 WP Umbrella 這類監測工具可以幫你即時掌握網站的運行狀態。

不適合的使用場景

有些類型的網站不建議使用 instant.page：

• 單頁應用（SPA）：如果你的網站是用 React、Vue 或 Angular 開發的 SPA，頁面之間的切換是由 JavaScript 控制的，不需要 prefetch HTML 頁面。
• 大量外部連結的頁面：如果你的文章裡面有很多外部參考連結（比如新聞聚合網站、資源整理頁面），預設的 instant.page 只會 prefetch 內部連結，所以影響不大。但如果開啟了外部連結預載入，那就得小心了。
• 即時資料頁面：股票報價、即時聊天、遊戲等需要即時更新的頁面，prefetch 可能會拿到過期的資料。

Google Analytics 數據的影響

這是一個比較技術性的問題。當瀏覽器 prefetch 了一個頁面，那個頁面上的 Google Analytics 追蹤碼會不會執行？答案是：不一定。這取決於 prefetch 的實作方式和瀏覽器的行為。在大多數情況下，透過 <link rel="prefetch"> 預載入的頁面不會執行 JavaScript，所以不會影響 Analytics 數據。但如果你使用了更高級的預載入技術（比如 prerender），就有可能在使用者真正訪問頁面之前就記錄了一次瀏覽，導致數據膨脹。

好在 instant.page 只使用 prefetch，所以 Google Analytics 的數據不會受到影響。但如果你同時使用了其他預載入技術，就要特別注意這個問題。搭配 Site Kit by Google 來監控數據變化也是一個好習慣。

免費版 vs 付費版

instant.page 的核心功能是完全免費且開源的。但開發者後來也推出了付費版本，提供了額外的功能，比如更激進的預載入模式（Intense 模式會在頁面載入時就預載入所有可見連結，而不是等滑鼠 hover）、Strict 模式（只預載入最有可能被點擊的連結），以及優先的技術支援。

對於大多數網站來說，免費版已經完全夠用。付費版比較適合那些對速度有極致追求、而且流量夠大（大到能感受到微小的轉換率提升帶來的實質收益）的網站。圖片優化也是速度調校的一環，在 WordPress 中使用 WebP 格式和Imagify 圖片壓縮都是搭配 instant.page 的好幫手。別忘了定期使用 UpdraftPlus 備份網站，這樣即使優化過程中出了問題也能快速恢復。

常見問題 FAQ

instant.page 會不會影響 SEO 排名？

不會。instant.page 使用的是瀏覽器原生的 prefetch 機制，它不會改變你網頁的 HTML 結構、不會加入任何搜尋引擎可見的內容、也不會影響爬蟲的抓取行為。Google 的爬蟲不會執行 JavaScript 中的 hover 相關邏輯，所以 prefetch 不會被觸發。你的 SEO 排名完全取決於網站內容品質、結構化資料、載入速度（首次載入）等因素，這些都不會因為裝了 instant.page 而受到負面影響。反而，因為使用者體驗變好了，頁面停留時間可能增加、跳出率可能降低，這些對 SEO 都是有正面幫助的。如果你對On-page SEO 優化技巧有興趣，也可以一起研究。

免費版和付費版有什麼差異？

免費版提供了完整的 hover prefetch 功能，對大多數網站來說已經足夠。付費版增加了 Intense 模式（頁面載入後就預載入所有可見連結，不用等 hover）和 Strict 模式（更精確地判斷哪些連結值得預載入）。如果你的網站有大量行動裝置讀者，付費版的 Intense 模式可能值得考慮，因為它不依賴 hover 事件。

不使用 WordPress 也能用嗎？

完全可以。instant.page 的本質就只是一段 JavaScript 腳本，可以在任何網頁上使用。不管是靜態 HTML 網站、React/Vue 單頁應用、Next.js 服務端渲染網站、還是其他 CMS（Joomla、Drupal）架設的網站，只要能在頁面的 </body> 前插入那行 script 標籤就可以運作。即使是用 DreamHost 或 Hostinger 等不同主機商的環境也能正常使用。

會不會增加伺服器流量成本？

會，但幅度通常不大。根據實際使用經驗，流量增加大約在 10-20% 之間，具體取決於你頁面上的連結數量和使用者的瀏覽行為。如果你的主機方案有流量上限，建議先監控一兩週的數據再決定是否繼續使用。搭配 CDN 使用的話，大部分的 prefetch 請求會由 CDN 快取回應，不會打到原始伺服器，額外的流量成本就更低了。

行動裝置上有沒有效果？

效果有限。免費版的 instant.page 主要偵測的是滑鼠 hover 事件，手機和平板上沒有滑鼠，所以觸發機會較少。不過較新版本有支援 touchstart 事件，可以在使用者的手指碰到連結的瞬間就開始 prefetch，雖然比桌面端的 hover 預載入慢了一些，但還是能省下幾十到上百毫秒的時間。你可以用 Speedcheck 測速工具來對比行動裝置上的實際差異。

instant.page 和瀏覽器的 DNS prefetch 衝突嗎？

不衝突。DNS prefetch（<link rel="dns-prefetch">）做的事情是在背景提前解析連結的網域名稱，而 instant.page 的 prefetch 是下載整個 HTML 頁面。兩者作用在不同的層級，可以同時存在。事實上，如果你的網站有使用外部資源（比如 CDN、第三方字型服務），加上 DNS prefetch 反而能讓 instant.page 的 prefetch 請求更快完成，因為 DNS 解析的時間已經被提前處理掉了。使用 Cloudflare 的 1.1.1.1 DNS 服務也能加快 DNS 解析速度，與 instant.page 形成互補。

可以跟 WP Rocket 或其他快取外掛一起用嗎？

可以，而且建議一起使用。instant.page 負責的是頁面之間切換的預載入，快取外掛負責的是減少伺服器的重複運算。兩者互補，搭配使用效果最好。唯一需要注意的是，如果你的快取外掛有「延遲 JavaScript 執行」的功能，可能需要把 instant.page 的腳本加入排除清單，確保它能及時載入和運作。

回顧一下整篇文章，instant.page 是一個非常值得推薦的工具：免費、輕量、安裝簡單、效果明確。它不是什麼銀彈，不能解決所有網站速度問題，但作為整體速度優化策略的一部分，它絕對是投資回報率最高的選擇之一。如果你還沒用過，今天就試試看吧。