網頁速度為何影響排名、廣告成本與轉換率

說不定你也遇過這種狀況：網站排名做上來了，廣告也投了，內容寫得紮實，但跳出率就是壓不下來，轉換也一直起不來。你懷疑過文案、懷疑過版面、懷疑過關鍵字精準度，卻很少有人第一時間去懷疑，是不是網站根本還沒載入完，訪客就走了。

網頁速度（Page Speed）就是這樣一個被嚴重低估的變數。它的影響範圍遠超出「純技術指標」這個分類，實際上是一條貫穿自然搜尋、付費廣告與轉換的暗線。說穿了，網頁慢，你等於同時在自然流量、廣告成本與成交率這三個地方繳稅，而且這筆稅金很少出現在報表上，所以大家也就默默繳了好幾年。

接下來會把網頁速度這件事從頭講清楚：它到底是什麼、Google 從什麼時候開始把它寫進排名規則、行動裝置為什麼讓它變成不可妥協的底線、慢半拍會在哪三個地方偷走你的錢，以及你應該從哪裡先動刀。如果你僅想要一句話的答案，緊接著這段就是。

快速重點整理

• 網頁速度其實是一組描述載入與互動體驗的指標（LCP、INP、CLS 是目前最被看重的三個），無法用單一數字概括。
• Google 自 2018 年起將行動版速度列為排名因素，2020 年再納入「網頁體驗」訊號，2023 年完成全站行動優先索引。
• 網頁慢會在三個地方同時失血：自然搜尋排名、Google Ads 的到達網頁品質（直接影響品質分數與點擊成本）、轉換率。
• 量速度要分清楚「實驗室數據」與「現場數據」，不要僅追 PageSpeed Insights 那個滿分。
• 優化有優先級：先壓伺服器回應（TTFB）與圖片，再處理轉譯阻塞資源與第三方腳本，最終才是微調。

網頁速度到底是什麼？先拆掉三個常見誤解

很多人把「網頁速度」想像成一個單一數字，好像量到一個秒數就搞定。這是第一個要打破的觀念。網頁速度不是一個點，而是一段時間裡好幾個關鍵時刻的集合：從你按下連結、瀏覽器開始抓資料、畫面出現第一個有意義的內容、使用者能夠點按，一直到頁面完全穩定不再亂跳。每一個時刻都對應到不同的指標，也對應到不同的優化手段。

實務上，每次被問到「你們網站多快」，得到的答案多半是「大概兩秒吧」。但再追問「兩秒是指什麼」，十個人有九個答不出來。這很正常，因為這個領域的詞彙本來就很雜。先把三個最容易混淆的觀念拆乾淨，後面才不會越看越糊塗。

誤解一：頁面速度等於主機連線速度

第一個誤解，是把網頁速度跟「主機頻寬」或「連線速度」畫上等號。換一台比較貴的主機、拉一條比較快的線，網站就會變快，這個直覺對了一半，但也僅對一半。主機的回應速度（TTFB，Time to First Byte）確實是基礎，TTFB 慢，後面什麼都快不起來；可是當 TTFB 已經壓到合理範圍之後，真正拖垮速度的，往往是圖片沒壓、JavaScript 塞太多、字體載入方式不對、第三方追蹤碼一大堆這類「前端」問題。換主機換到最終，常常是安慰劑大於療效。

換句話說，主機是地基，前端是樓上的裝修。地基爛，樓一定塌；但地基穩了之後，訪客感受到的快慢，幾乎都是裝修決定的。

誤解二：「載入完成」有一個明確的終點

第二個誤解更普遍：我們嘴巴上說「網頁載入完成」，好像那是一個清楚的瞬間。對工程師的瀏覽器來說，「load 事件觸發」是一個技術定義；但對一個盯著螢幕等畫面的真人來說，他根本不在乎你的 load 事件有沒有觸發，他在乎的是「我能不能看到內容」以及「我能不能點」。

這就是為什麼後來大家不再僅看「總載入時間」，而是看三個更貼近真實感受的指標：

• LCP（Largest Contentful Paint，最大內容繪製）：頁面上那塊最大的可見內容（通常是一張主圖或大標題）畫出來的時間，代表「使用者覺得頁面差不多出現了」。
• INP（Interaction to Next Paint，互動到下一次繪製）：使用者點按之後，畫面回應的流暢度，代表「這個網站會不會卡卡的」。它已在 2024 年正式取代舊的 FID，成為 Core Web Vitals 的回應力指標。
• CLS（Cumulative Layout Shift，累計版面位移）：頁面元素跳動的累計程度，代表「內容會不會在我準備點的時候突然跑掉」。

這三個指標合起來，構成 Google 的 Core Web Vitals。它們是排序系統採用的小幅訊號，也是檢查真實使用體驗的一組共同標準，但好分數不保證高排名。想看完整解析，可以參考我們寫的 Core Web Vitals 完全攻略；這篇要談的是速度背後的行銷與商業邏輯。

誤解三：實驗室跑出來的分數等於真實體驗

第三個誤解是最花錢的一個。很多團隊拿著 PageSpeed Insights 跑出來的 90 幾分，就心安理得地覺得「我們網站很快」。但這裡有一個關鍵差異：實驗室數據（Lab Data）跟現場數據（Field Data）不是同一件事。

實驗室數據是在一個受控環境裡跑出來的：固定的網路速度、固定的設備、固定的腳本，它告訴你「在理想條件下，這個頁面潛在可以多快」，適合用來抓程式碼層面的問題、適合在開發階段做 A/B 比較。可是你的真實訪客不會用實驗室那台機器、不會坐在光纖網路上、更不會照著腳本瀏覽。他們可能在捷運上用 4G、手機是三年前的舊款、同時還開著十幾個分頁。

現場數據（Field Data）來自符合條件的 Chrome 使用者真實造訪資料，也就是 CrUX 資料集；實驗室數據則適合在可重複的環境中找出效能問題。Core Web Vitals 是小幅排序訊號，現場數據較差不代表頁面必然無法排名。實務上可用實驗室數據診斷、用現場數據觀察真實體驗。想看同時涵蓋兩種數據的工具，可延伸閱讀網站速度測試工具推薦。

Google 從 2018 年就把速度寫進排名規則了

聊完定義，接下來回答一個很多老闆會問的問題：「速度到底是不是排名因素？」答案是肯定，而且時間點比大多數人想的早。

Google 在 2018 年 1 月正式公告，會把「網頁速度」做為行動搜尋的排名因素之一。注意那個「行動」二字，這可不是順便帶過的，它其實是整個故事的轉折點，Google 從那時候起，就明確把速度跟行動裝置綁在一起看待。

到了 2020 年 5 月，Google 提出「網頁體驗」（Page Experience）概念，當時在官方公告中列出 Core Web Vitals、行動裝置友善、HTTPS 與插頁妨礙等考量。目前 Google 明確表示沒有單一「網頁體驗訊號」可直接判定排名；速度與其他體驗面向應整體改善，不能當成保證名次的分數。隔年 Google 也取消了 AMP 頁面在熱門新聞（Top Stories）的專屬優勢，改以網頁體驗標準做門檻，這段轉變的來龍去脈可以看AMP 排名紅利消失的始末。

用一個比喻來解釋：把 Google 想像成一個會幫朋友推薦餐廳的人。如果你的朋友問「哪家咖啡廳適合邊工作邊喝」，你推薦的那家，一定是東西不錯、環境舒服、而且「不會讓人等到不耐煩」的店。Google 對使用者的推薦邏輯也是一樣，它不會推薦一個內容很好、但點進去要等八秒才有畫面的網站，因為它知道使用者會立刻按上一頁，然後怪 Google 給了爛結果。對 Google 來說，推薦一個慢網站，等於拿自己的信譽去冒險。

所以當有人問起「速度優化值不值得投資」，最直接的回答是：如果你的網站打算活超過三年，這不是選配，是基本功。它跟寫好內容、做好 站內 SEO 一樣，是會長期複利的基礎投資，不是一次性的裝潢。

手機流量已是主角：行動優先時代沒有「桌面版優先」

既然 Google 從一開始就把速度跟行動綁在一起，那我們就得面對一個已經無法迴避的事實：手機流量早就不是「補充」，而是主流。

根據 Statista 的統計（2026 年 4 月），全球網站流量中有相當比例來自行動裝置。個別網站與台灣市場的比例仍應以第一方分析資料判斷，不能由全球統計直接推定。

而 Google 的索引方式，也早就配合這個趨勢走完最終一哩路。2020 年 3 月，Google 在官方公告中宣布將逐步對整個網路啟用行動優先索引（Mobile-first Indexing）。到了 2023 年 10 月，Google 在官方公告中正式宣告行動優先索引已全面到位。

這兩份公告合在一起讀，意思是 Google 主要使用手機版內容進行索引與排序。行動優先索引描述的是 Google 取用哪個版本，不是額外的排名加分；手機版若缺少桌機版的重要內容或索引訊號，Google 能理解與索引的資訊也會跟著缺漏。速度仍要分別看行動與桌機的真實使用者資料。

這也是為什麼，每次有人拿著桌機測出來的漂亮數字說「我們網站很快」，下一步都該做同一件事：把手機切到 4G、打開無痕視窗、用一般訪客的身分重新點一次自己的網站。十次有八次，做完之後對方的臉色都不太一樣。真實的手機網路環境，比你想像的嚴苛很多。

網頁慢，你在三個地方同時失血

前面鋪了定義和背景，這一節才是整篇文章最該認真讀的地方，也是行銷人與老闆們最該看清楚的核心：網頁慢不是單一成本，而是一筆橫跨三個漏斗環節的隱形稅。你以為僅是「慢一點」，其實是排名掉了、廣告變貴了、訂單也飛了。這三個失血點整理成下表，先給你一個全貌。

失血點	背後的機制	你實際付出的代價
自然搜尋	大型網站可能降低爬取效率，使用者也較容易離開	索引更新可能變慢，搜尋造訪與轉換機會減少
付費廣告	到達網頁體驗差，拉低 Google Ads 品質分數	同樣排名要出更高單次點擊成本，廣告預算燃燒加快
轉換成交	真人對延遲沒耐心，載入途中直接離開	轉換率下降，每一筆流量能換到的營收變少

下面把這三個點分開談，因為它們各自的成因和槓桿都不一樣。

失血點一：自然搜尋，爬蟲抓得少、訪客留不住

第一個失血點，發生在你最在意的自然搜尋。這裡有兩個獨立的機制同時在運作。第一個是「爬取預算」。Google 的爬蟲每天分配給每個網站的抓取時間和頁面數量是有限的，當你的網頁載入很慢，爬蟲在同樣的時間內能抓的頁面就變少，結果就是部分頁面根本沒被好好收錄，或者更新很久才被反映到索引裡。對內容多、頁面數量大的網站來說，這個影響特別明顯。如果你想知道自己的站是不是在這裡失血，可以先理解 爬取預算 的運作方式。

第二個機制更直接：慢網站會讓訪客在內容出現前離開，減少這次造訪的閱讀與轉換機會。不要把 GA4 的跳出率或所謂 pogo-sticking 直接當成 Google 公開確認的單頁排名訊號；能確定的是 Core Web Vitals 會被排序系統採用，但影響幅度小，相關性較高的內容仍可能排在體驗較差的頁面前。想分清楚跳出率與 SEO 的關係，可以看 跳出率與 SEO 那篇。

失血點二：付費廣告，到達網頁太慢壓低品質分數

第二個失血點，可說是最被台灣行銷圈輕忽的一塊，也是這裡特別要點出來的視角。很多人以為「網頁速度是 SEO 的事，跟廣告無關」，這個想法會讓你白白多花很多廣告費。

Google Ads 在決定你的廣告排名與實際點擊成本時，看的不僅是你出多少錢，還有一個關鍵的調節變數叫做「品質分數」。而品質分數的三大組成之一，就是「到達網頁體驗」（Landing Page Experience）。你的到達網頁如果載入很慢、行動版體驗差、內容跟廣告承諾對不上，品質分數就會被壓低（定義見 Google Ads 的品質分數說明，2026）。

品質分數低的代價非常具體：在同樣的廣告排名上，你要出比競爭者更高的單次點擊價格才搶得到位置。換句話說，一個慢網站等於把你的廣告成本結構永久往上墊高。你以為是廣告越來越貴、平台在坑你，其實有一部分是你自己的網頁速度在幫你「加價」。

常見的狀況是，團隊花很多力氣在廣告素材、受眾設定、出價策略上反覆調整，卻從來沒人回頭看看那個大家點進去之後會到的到達網頁，到底要等多久才看得到內容。一旦把到達網頁速度壓下來，廣告帳號的整個效率結構都會跟著鬆動。這是一個 SEO 跟付費媒體交集的地方，也是為什麼建議做 SEM 的人也一定要懂速度。

失血點三：轉換成交，真人對延遲沒有耐心

第三個失血點，是直接發生在收銀台前的轉換流失。這部分的證據非常明確。Google 自己在 web.dev 上就整理過速度對使用者行為與商業指標的影響，慢的頁面會讓人更早放棄、更少互動、更不願意完成交易。

而 Google 早在 2017 年那篇被引用到爛、但至今仍然成立的行動速度研究中，就給出了清楚的基準數字：當行動版頁面載入時間從一秒拉長到三秒，跳出機率會大幅上升；到了五秒，情況會更嚴峻（見 Think with Google 的行動速度基準研究，2017）。這組數字雖然是將近十年前的基礎研究，但它建立的直覺到今天僅會更強烈：使用者對每一秒的延遲都有反應，而且反應是非線性的，因為大家對「即時」的期待僅會越來越高。

第三方研究也呼應同樣的結論。Semrush 在其頁面速度指南中同樣指出，載入時間每增加，跳出率與轉換流失就會跟著上升，並把圖片優化、程式碼精簡、快取策略列為最基本的改善方向。

把這三個失血點疊起來看，你就會明白為什麼網頁慢會被稱為一筆「複合稅」。它對獲利的侵蝕是同時從三個方向發生的，代價遠超過單純的「少賺一點」：自然流量變少（要花更多力氣或更多廣告補）、廣告變貴（每一筆點擊成本往上墊）、轉換變差（每一筆流量的產出變低）。三個一起發作，毛利率就被悄悄吃掉一塊。如果你正在評估整體的 SEO KPI 與行銷成效，速度絕對該被當成一個會牽動多個指標的根因變數，把它看成孤立的技術任務會嚴重低估它的影響。

速度為什麼在 AI 搜尋時代變得更致命

生成式搜尋增加了新的呈現方式，但沒有證據顯示它對網頁速度設定了比一般搜尋更嚴格的門檻。

第一個層面是技術可存取性。Google 對 AI Overviews 與 AI Mode 沒有額外的速度門檻；頁面要先符合一般搜尋的技術要求、可被索引並能顯示摘要，才有資格成為支援連結。若主要內容必須互動後才由 JavaScript 載入，Google 可能看不到內容；這是可爬取與渲染問題，不能直接推論成「慢頁面不會被 AI 引用」。

第二個層面是「使用者耐心的底線又往下移了一格」。在傳統搜尋裡，使用者點進連結之後，多少還願意等個幾秒；但在 AI 搜尋裡，答案直接長在結果頁上，使用者連「點進去」這個動作都可能省掉。這代表一旦他真的願意點進你的網站，是因為他對你的內容抱著更高的期待，他想要更深、更完整的資訊。如果你的網站這時候還讓他盯著空白畫面等，那種被潑冷水的感覺會比過去任何時候都強烈，反彈也更直接。當答案引擎已經把使用者的耐心訓練得更薄，你的網站就更沒有本錢慢。想了解 AI 搜尋怎麼改變整個 SEO 生態，可以看我們對 Google AI Mode 與 AI Overviews 的完整分析。

速度主要是使用體驗與轉換問題，也可能透過 Core Web Vitals 對排序產生小幅影響；它不是 AI 引用的特殊門檻。長期來看，速度、安全性（HTTPS）、可爬取性（robots.txt 與 XML Sitemap）仍是網站應該維護的基礎工程。

別僅追分數：用對工具量對東西

知道速度為什麼重要之後，下一個問題自然是「我怎麼知道自己網站有多慢」。這裡最容易踩的坑，就是把「分數」當成「真相」。先講結論：不要把追求那個綠色 100 分當成目標，那是本末倒置。

原因在前面提過，實驗室數據跟現場數據是兩回事。PageSpeed Insights 的實驗室分數來自受控條件下的單次模擬，用來找出潛在瓶頸；CrUX 現場數據則反映真實使用者過去一段時間的體驗。兩者用途不同，而且都不能單獨預測排名。

所以正確的測量姿勢是雙軌並行：

• 找問題用實驗室數據：PageSpeed Insights、Lighthouse、WebPageTest 這類工具，給你瀑布圖、給你每一個資源的載入時間、告訴你哪一張圖太大、哪一段 JavaScript 在阻塞轉譯。它是診斷工具，不是成績單。
• 驗收成果用現場數據：Google Search Console 裡的「Core Web Vitals」報表、CrUX 資料集、PageSpeed Insights 的「實際使用者體驗」區塊，能反映真實使用者的 Core Web Vitals。若網站還沒接上 Search Console，可先完成 Google Search Console 的設定。

除了接下來會談到的分頁面類型，還有兩個測量細節很容易被忽略。第一個是設備與網路的代表性：如果你僅用辦公室的高速光纖配上最新款筆電測試，得到的數字會系統性地偏樂觀。建議至少加入一台兩三年前的中階手機、切到 4G 訊號再跑一次，那才比較接近多數訪客的真實處境。第二個是登入狀態：很多網站在會員登入後會走快取或個人化路徑，速度跟未登入的訪客差很多，而你的搜尋流量絕大多數來自未登入狀態，所以量測時記得用無痕視窗，模擬第一次造訪的冷啟動情境。這兩個細節做與不做，量出來的數字常常是天壤之別。

還有一個常被低估的點：量測要分頁面類型，不要僅量首頁。首頁通常被優化得最勤，所以最快；但你的訪客透過搜尋進來的，往往是某篇文章、某個產品頁、某個分類頁。這些「長尾入口頁」才是真正決定大部分流量體驗的地方。建議至少把流量最高的前 10 到 20 個頁面都跑一次，找出最慢的那幾支，那才是你的真實瓶頸所在。想知道完整的工具清單與使用方式，可以回頭看前面提過的網站速度測試工具比較；想搞懂指標怎麼挑，可以看 Core Web Vitals 入門。順帶一提，如果你聽過舊指標 FID 又看到現在的 INP 覺得困惑，這中間的演進可以參考 FID 到 INP 的演變。

先自我評估：你的網站屬於哪一種速度風險體質

在實際動手優化之前，這裡先給你一個更快的判斷工具。不同類型的網站，速度問題的「熱區」很不一樣，所以先對照接下來這張表、找出最可能出問題的地方，會比毫無頭緒地全面健檢更有效率，也才能把第一刀砍在最肥的瓶頸上。這張表把常見網站歸納成幾種最常見的「速度風險體質」，幫你把方向先收斂下來。

網站類型	速度風險	最可能的瓶頸熱區	建議的第一刀
圖片密集的電商或內容站（商品圖、圖文教學多）	高	未壓縮的大圖、缺少現代格式與延遲載入	先做全面圖片優化
重度互動的單頁應用或工具型網站	高	大量 JavaScript 阻塞轉譯、互動回應卡頓	先拆解轉譯阻塞與主執行緒任務
裝了很多外掛的 WordPress 站	中高	外掛載入的 CSS 與 JS 堆疊、缺乏快取	先做外掛健檢與快取設定
第三方追蹤碼很多的行銷導向站	中	廣告、熱圖、聊天、社群腳本爭搶資源	先做第三方腳本瘦身與延後載入
版面單純的純文字內容站	較低	通常是伺服器回應或字體載入	定期健檢即可，以維持為主

這張表的目的很具體：幫你把資源先押在最可能出問題的熱區上。真正的瓶頸還是要靠前面提過的雙軌量測（實驗室數據找問題、現場數據驗收）來確認。但至少你不必像無頭蒼蠅一樣，把每一種優化手法都試一遍；先針對自己網站的體質下手，再根據量測結果滾動調整，這才是效率最高的做法。

壓速度的優先級：先動哪一刀

診斷完，接下來就是動手。但優化速度最忌諱「全面開花、到處微調」，那種做法很容易忙了半天，現場數據卻文風不動。真正有效的做法，是按照投資報酬率排優先級，先砍掉最大的瓶頸，再做下一層。

接下來這張表是排定優化工作時常用的優先級框架，你可以直接拿來套用。核心觀念是：影響面越大、實作成本越低的，越要先做。

優先級	項目	為什麼優先	深入指南
第一刀	伺服器回應時間（TTFB）	地基等級的問題，壓不下來後面全部白做；常與主機、資料庫查詢、快取層有關	從 技術性 SEO 架構面檢視
第二刀	圖片優化	通常是頁面體積的最大宗；壓縮、改用現代格式、延遲載入的成效最立竿見影	圖片 SEO、Lazy Loading
第三刀	轉譯阻塞的 CSS 與 JavaScript	直接卡住畫面出現的時間，影響 LCP；關鍵 CSS 行內化、延後載入非必要腳本	理解 JavaScript SEO 的渲染機制
第四刀	快取與 CDN	讓重複造訪的訪客從最近的節點拿資料，對跨地理位置的流量效果顯著	CDN 原理
第五刀	第三方腳本瘦身	追蹤碼、聊天外掛、社群按讚鈕常是隱形的效能殺手，要逐一審查去留	用 GTM 統一管理載入時機
第六刀	字體與微互動優化	報酬遞減區，做完了前面五項再回頭處理即可	版面編排 的取捨

需要逐步操作時，可參考網站速度優化完整做法；若已確認網站很慢但尚未找到瓶頸，可先用網站速度慢的診斷與解法從測量結果反推原因。前者著重執行步驟，後者著重問題定位，可依目前階段選擇。

實務上重複出現的三個速度地雷

最終，這裡整理三個在實際網站上重複出現、但很少被主動發現的速度地雷。這些說不上是高深的技術問題，反倒比較像「大家都知道該做、卻總是漏掉」的盲點。之所以整理出來，是因為排除這三個地雷，往往比任何進階優化技巧都還能立刻看到效果。

第一個地雷：圖片看起來不大，檔案卻很大。原始照片直接上傳、格式選擇不當或缺少響應式尺寸，都可能增加傳輸量。圖片是否是頁面最大負擔要用工具確認；若 LCP 元素是圖片，優化尺寸、格式與載入方式通常值得優先處理。WordPress 網站可參考WordPress 速度優化。

第二個地雷：測試用快取，正式上線沒快取。這個地雷特別陰險。團隊在測試環境裡跑分，分數很漂亮，因為測試環境可能開著完整的快取、沒有真實流量、也沒有第三方追蹤碼。結果一上正式環境，面對真實流量與完整的外掛清單，速度整個垮下來。這也是為什麼要反覆強調：量速度一定要量「正式環境、真實流量」的現場數據，不要用測試環境的分數自我安慰。一個更極端的版本是，頁面連快取機制都沒設定，每次訪客來都要重新組裝一次完整的頁面，等於讓主機做了十倍的工作。

第三個地雷：以「功能」為名堆上去的第三方腳本。聊天外掛、A/B 測試工具、熱圖追蹤、社群分享按鈕、廣告追蹤碼，每一個單獨看都很合理、都很「有用」，可是當你把頁面上所有第三方腳本攤開來看，會發現它們加起來的載入成本，常常比你自己網站的內容還重。實務上的做法是定期做一次「第三方腳本健檢」，逐一問：這個工具上個月有人看過它的報表嗎？這個分享按鈕真的有人點嗎？如果答案是沒有，就大膽拿掉。功能是為了服務生意，不是為了服務功能本身。

這三個地雷真正的共通點是紀律：技術本身沒有那麼難，難在沒有人定期去檢查。速度優化更像一種需要定期保養的衛生習慣，一次性的工程思維在這裡是行不通的。

你的下一步行動清單

讀到這裡，如果你心裡已經開始想「那我該從哪裡下手」，整套流程濃縮成五個步驟，照著走就對了。這份清單的設計是「一個下午可以做完第一輪」，不需要動員整個工程團隊那種規模的大計畫。

1. 先量現場數據，別僅看實驗室分數。打開 Google Search Console 的 Core Web Vitals 報表，看看你的頁面在真實使用者手上是綠字還是紅字。如果連 Search Console 都還沒接上，這就是你的第一步。
2. 找出最慢的前十個頁面。用 PageSpeed Insights 或 WebPageTest 跑一遍你流量最高的那幾個頁面，特別是透過搜尋進來的長尾入口頁，記下它們的 LCP、INP、CLS 與主要瓶頸。
3. 從最大瓶頸下手，通常先是圖片與伺服器回應。別一頭栽進微調，先把頁面體積的最大宗（圖片）與地基（TTFB）處理掉，這兩刀的投資報酬率最高。
4. 做一次第三方腳本健檢。把頁面上所有非自己寫的腳本列出來，逐一問「上個月有人用它嗎」，沒有的就移掉。用 GTM 統一管理它們的載入時機，避免阻塞轉譯。
5. 把速度變成定期保養項目。每季跑一次全站健檢，特別是每次新增功能、新增外掛之後。速度是會倒退的資產，不保養就會慢慢爛掉。

網頁速度這件事，說到底就是一句話：你給使用者的每一秒等待，最終都會用某種形式回到你身上，可能是排名、可能是廣告成本、可能是訂單。把這筆隱形稅砍掉，你的整個行銷漏斗才會真的鬆開來。而當你把速度這個根因變數照顧好，你會發現很多原本各自頭痛的指標（跳出率、轉換率、廣告成效），會一起跟著改善。也因此，速度應該放在跟 關鍵字排名、E-E-A-T 同一個層級的基礎工程來看待。

如果你看完這篇，覺得自己的網站可能正在繳這筆隱形稅、但不知道該怎麼系統性地動手，這正是我們 Whoops SEO 平常在做的事。從速度健檢、瓶頸診斷到優化排程，我們可以陪你把這台車從底盤開始整理一遍。你當然也可以拿著這份行動清單自己先跑一輪，真的卡住了再找人。無論哪一種，都希望你今天就把那個前三慢的頁面找出來，那是整件事最划算的起點。