網站速度慢怎麼辦？影響客人多少

網站開太慢，客人還沒看到你的服務就關掉了——這是很多老闆心裡的疙瘩。白話版：Google 是用三個數字在判斷你的網站「快不快」，這三個數字沒有達標，就算你內容寫得很好，排名也會被拉開距離。
這篇先用白話講清楚那三個數字是什麼、門檻在哪裡，再講「慢到底影響多少客人」這個問題要怎麼誠實回答，最後教你用兩個免費的工具，自己查出你的網站卡在哪一段、該先改哪一件事。

喵總先把位置放對

換句話說一次：「網站慢」不是一句感覺，是三個可以查的數字。

Google 官方把「網站體驗好不好」拆成三件事：載入快不快（LCP）、點下去有沒有反應（INP）、畫面會不會跳動（CLS）。三個都有明確門檻，超過門檻就算「需要改進」。

知道了這三個數字，「我的網站很慢」就變成「我的 LCP 是 4.2 秒，超過門檻」——前者是抱怨，後面那個才能開工。

當場就能做的動作：打開 PageSpeed Insights（pagespeed.web.dev，免費、不用登入），把你的網址貼進去按「分析」。
捲到畫面中段的「Core Web Vitals」，你會直接看到 LCP／INP／CLS 三個數字跟紅綠燈。先拿到這三個數字，再往下看這篇會更有感。

「慢」到底在講什麼：Google 看的三個數字

多數老闆說「網站很慢」，其實混了三種不同的抱怨：東西跑很久才出現、點了沒反應、畫面還會跳。這三件事在 Google 官方說明中心裡剛好對應三個不同的指標，處方完全不同，不能混著開藥。Google 官方說明中心（查詢日期：2026-11-06）對這三個指標的定義與門檻寫得很清楚：

這三個數字還有兩個容易被忽略的前提。第一，不是看平均，是看第 75 百分位：官方建議用「至少 75% 的實際造訪都能達到良好門檻」當作通過標準。第二，手機版和桌面版分開算，因為兩種裝置的網路與處理器天差地別，而台灣客人現在大多是用手機在找。所以「我用電腦很快啊」這句話，在判斷上等於沒說。

還有一件事要先講清楚，免得你比錯對象：速度不是單獨一根槓桿，它跟「內容夠不夠相關」是兩件事。Google 官方說明中心寫得很直接——排序系統會參考多種與頁面體驗相關的訊號，並且「永遠會優先顯示相關的內容，即使頁面體驗不理想」。換句話說，把速度修好是必要的基本盤，不是讓你從第十名跳到第一名的萬靈丹。速度真正影響到的是「客人願不願意等你把頁面看完」。

不過速度差還有一個看不見、但會實際發生的影響：Google 官方說明中心的爬蟲管理文件寫得很清楚，網站回應慢，會直接影響 Google 願意分配給這個網站的抓取量。抓取量少＝新內容比較慢被看到。這一條對「靠新內容賺錢」的網站影響最大：不是排名的問題，是「我的新文章什麼時候會被看到」的問題。

順便把兩個很常見的誤會先講掉：「我用手機測很快啊」——很多人在自己家裡的 WiFi 上測，那是最理想的環境；你的客人在捷運上、在巷口、在有線寬頻剛好很慢的時候。「Lighthouse 拿 100 分就沒問題了」——官方說明中心講得很清楚，實驗室高分不代表現場好，而且為了 SEO 硬追滿分「可能不是時間最好的用法」。真正用來判斷排名的是現場數據（Chrome 使用者體驗報告），不是實驗室分數。

慢影響客人多少？這題要怎麼誠實回答

「網站慢會少多少客人」是這一類文章最愛亂編數字的地方。市面上常見的「慢 1 秒少幾成客人」多數來自特定業者的行銷研究或實驗室測試，對你的產業、你的客群、你的價格帶不一定適用。所以這裡不給你一個聽起來很精確、但其實查不到出處的轉換率數字。

那怎麼回答？誠實的答案是：影響確實存在，但「少多少」只有你自己能測出來，因為它取決於你的客人從哪裡來、對你什麼急迫感、你的頁面是不是他要的東西。可是在測之前，有一件事是確定的、而且不用測也知道：等待本身是一種成本。一個要等四秒才出現的頁面，等於在客人還沒讀到你一句話之前，就先請他做了一次沒有回報的等待。

Google 官方對「速度跟排名」的說法，能幫你把期待放在正確的位置：官方說明中心寫了兩句話——Core Web Vitals「確實被排序系統採用」；但「除了 Core Web Vitals 之外，其他頁面體驗面向不會直接幫助你的網站在搜尋結果中排得更高」。合起來的意思是：速度是入場券，不是加分的王牌。真正拉開距離的，還是內容有沒有回答到客人的問題——SEO 是什麼？中小企業白話版 那篇把 Google 決定順序的三個步驟講得比較完整，可以接著看。

如果要看「有沒有研究證明速度跟生意有關」，有一份常被引用的：Google 委託 55 與 Deloitte 做的「Milliseconds Make Millions」——分析 37 個歐美品牌網站、超過 3,000 萬次使用者瀏覽，結論是當用戶旅程中每一頁的載入速度都改善 0.1 秒時，零售轉換率提高 8.4%、旅客預訂率提高 10%，而「表單型網站」的推進率提升幅度是各產業中最高的（21.6%）。台灣中小企業最像的正是「表單型網站」那一類（留電話、留表單、線上詢價）。但要連帶讀四個前提：這是 2019 年底、30 天的觀察性研究不是隨機對照實驗；對象是歐美大型品牌不是台灣中小企業；條件是「旅程中每一頁」都要改善 0.1 秒不是只有首頁變快；統計的是「頁面推進率」不完全等於總轉換率。所以正確用法是：把它當成「速度確實跟營收有關係」的證據，不是「照著做就能拿到這個數字」的保證。真正對你有用的數字，還是得從自己的紀錄裡量。

那「影響多少」要怎麼自己量？這裡給你四個讀者自己就能拉數字的替代指標，都不需要買工具：

最後一項特別值得說明。「速度值多少錢」只有一個算法：改版前後，同一個月份、同一個廣告預算，來電與訂單數的差異。這也是我們做服務月報時，會把「我們做了什麼」跟「看到什麼數字」分開寫的原因——前面那項可以被驗收，後面那項不能開成保證。想知道我們每個月怎麼看這些數字，可以看 公司沒有人做行銷怎麼辦 裡的月度節奏安排。

慢在哪一段？把等待時間拆成四塊

知道「慢」還不夠用，因為「慢」的處方差很多。Google 官方在 LCP 的說明文件裡，把整段等待拆成四塊依序發生的部分：TTFB（伺服器回應）→ 資源載入延遲 → 資源下載時間 → 元素渲染延遲。這四塊的責任人完全不同，拆開看才知道該找誰、該花什麼錢。

回到台灣中小企業的現況，有兩種很常見的型態。第一種是卡在第一段與第二段：主機放在國外，台灣使用者每次都要跨網路過去，實測回應時間常在 200 毫秒以上；再加上首屏大輪播圖常常設定成延遲載入（因為工程師直覺這樣省頻寬），結果最大的那張圖反而最晚出現。第二種是卡在第三段：圖片是從社群平台下載後直接丟上去的原始檔，一張幾百 KB 到幾 MB，手機版卻照樣下載桌機尺寸的大檔。兩種的修正成本其實不高，網站維護費多少？每年該預留多少錢 那篇有講過維護工作裡哪些屬於這類型態。

反過來說，如果你的 TTFB 本來就很快、LCP 卻還是很慢，那問題多半在圖片或程式，不在主機。這種情況下換主機多半是白花錢——換主機只會改善 TTFB 那一段，如果你的瓶頸是圖片太大或是程式太重，換完會發現幾乎沒變。先量，再決定。這也是我們做健康檢查時一定會把四段數字一起量出來的原因：數位體質健檢 會實際測出來給你看，不用你先買任何東西。

工程喵先量再決定改哪裡

換句話說一次：「網站慢」這句話裡面藏著四種完全不同的病，一帖藥治不了四種病。

伺服器慢、圖片太大、圖片來得太晚、程式太重——這四個的處理者、處理成本、處理天數都不一樣。把四段拆開量，是為了避免花大錢修錯地方。

當場就能做的動作：在 PageSpeed Insights 跑完之後，往下找到「效能診斷」區塊，Google 會把問題依「可節省多少時間」排序。
你就照那個順序做，從省最多時間的那一項開始，一項一項往下修。這比自己猜「我猜是圖片吧」可靠得多。

我們自己官網的實測數字，以及量測條件

講別人容易，講自己才需要勇氣。我們把同一套方法用在自家官網上，數字與量測條件一起公開——因為沒有條件的數字沒有意義：同樣一個網站，在實驗室裡量跟台灣真實使用者點開，是兩個答案。

這次用的是 Lighthouse 13.6.0，測試出口在台灣高雄（家用寬頻），手機版另外做了慢速 4G 模擬（RTT 150ms、頻寬約 1.6Mbps、CPU 降速 4 倍），桌面版用預設設定：

這張表裡有三件事值得老闆注意，而且全部是實測、不是猜的。第一，LCP 與 CLS 都在門檻內——手機版 1.5 秒、桌面 0.9 秒，版面位移手機是 0。第二，手機版的主執行緒阻塞高達 1,730 毫秒，桌面只有 90 毫秒——同一個網站、同一支程式，手機慢 19 倍。這正是官方說明中心特別強調「手機版與桌面版要分開算」的原因：只看桌面分數，會以為自己沒問題。第三，真實網路回應是 230～255 毫秒，比一般人想像的慢，因為我們的伺服器在香港，台灣使用者每次都要跨網路過去。

還有一個只有自己實測才會發現的問題：我們的網域有兩種寫法——輸入 jsz.com.tw 會被轉到 www.jsz.com.tw，多走一道來回（實測：直接打 www 約 288 毫秒，輸入不帶 www 約 470 毫秒）。這種事在後台完全看不出來，只有真的量才會發現。

至於我們自己還有哪些可以改的地方，同樣公開講：頁面上 19 張圖片，沒有一張設定成延遲載入（等於一開頁就全部抓）；有 6 張圖沒有寫明寬度與高度（圖片載入前後版面可能位移）；沒有一張使用 WebP 等現代格式、也沒有響應式尺寸——三張首屏輪播圖原始 1536×942，手機上只顯示 390 像素寬，等於給手機傳了四倍大的檔案。Lighthouse 診斷直接算出來：光改圖片格式與尺寸，可以少傳 1,052 KB；三張輪播圖合計 685 KB，占首頁全部資源的 43%。改完不只速度會好，行動網路的流量費也會跟著降。

我們把這些寫在這裡，與其說是自夸，不如說是示範：同一把尺，我們對自己跟對客人的站都用。而且這篇要提醒的是——「三個指標達標」不等於「這個網站沒問題」。我們的 LCP 與 CLS 都合格，但轉址多一道、圖片全部同步下載、手機版主執行緒塞了 1.7 秒，這些在指標上看不出來，卻真實存在。指標是門檻線，不是及格證書。

五個自己就能動手的動作

好消息是，速度問題有相當一部分不需要動到主機、不需要改版、不需要花大錢。以下五個動作依「見效快慢」排序，前兩個通常半天內就有感覺：

這五項做完，通常能省下的是整頁重量的一大半。以我們自己的官網為例，1,531.7 KB 的圖片裡，如果把三張首屏圖從 1536 寬降到適合手機的尺寸、把其餘圖片改成延遲載入，手機版開頁時要抓的量可以砍掉相當可觀的一截。這件事還有一個額外好處：網站每年要多少錢 裡頭提到的長期維護，圖片處理是每次更新都會遇到的工作，早做早省。

至於什麼情況才真的需要花錢：當量測結果顯示問題出在 TTFB（主機或資料庫慢）、或是頁面裡塞了很重的 JavaScript 應用程式，那就不是老闆自己按按鈕能解決的了，這一類要由技術端處理。但請記住順序：先量、再自己試、最後才決定要不要花錢——因為網站速度最常見的浪費，就是還沒量就買了最貴的方案，結果瓶頸根本不在那裡。前面五個動作做完再量一次，多數狀況會有明確的落差可以直接比較。

用兩個免費工具查自己的網站

講到這裡，你手上有兩個 Google 官方的免費工具可以用。兩個都要用，因為它們回答的是不同的問題：

用 PageSpeed Insights 的五個步驟：

① 開 pagespeed.web.dev，把首頁網址貼進輸入欄，按「分析」；② 畫面載入後先看上半段「真實使用者經驗」那一區——那是 CrUX 收集的真實訪客資料（過去 28 天），如果造訪量太少，這裡會顯示「資料不足」或直接跳過，這很正常，不代表網站沒問題，往下看診斷就好；③ 再看下半段的「Lighthouse 診斷」區，Google 會列出「可機會的改進」並寫明每項能省多少時間——把清單存起來，依省下的秒數排序；④ 切換手機版與桌面版各跑一次，台灣客人以手機為主，優先看手機版；⑤ 隔一陣子再跑一次，把三個數字記下來做前後對照。

這裡要補一個很多人會踩的坑：「Lighthouse 分數」不等於「Core Web Vitals 門檻」。前者是模擬環境下的綜合分數，後者只看三個指標；官方也提醒過分數高不代表現場就好。而且 Lighthouse 在沒有真實互動的情況下量不到 INP，只能用 TBT（主執行緒阻塞時間）當代理指標——看診斷時把手機版的 TBT 一起看，那才是點擊反應慢不慢的線索。

用 Search Console 的五個步驟：

① 登入 search.google.com/search-console 並把網站加入（需在網站上放一個驗證檔案）；② 左邊選「網頁體驗」→「核心網頁指標」；③ 切到「網址群組」看整體狀態——官方建議一般網站每個月做一次網站檢查就夠了；④ 看到標示為不良的群組就點進去看是哪幾頁、卡在哪個指標；⑤ 這個報告的價值是：它看的是真實客人的手機與電腦，不是模擬環境。

所以這篇講到最後只留了一件事：先把手伸進免費工具，把三個數字和四段拆解都量出來，再決定要不要花錢。

稽核喵交件前照這張單子

換句話說一次：拿到一份「你的網站有做速度優化」的報告，先不要看漂亮的百分比，先照下面五題問一次。

① 三個指標的數字是多少（不是分數）？② 手機版跟桌面版各是多少？③ 量測方法是現場數據還是模擬數據？④ 這次改完，減少了多少 KB 的傳輸量？⑤ 上次改完到現在，有沒有人再複查過？

當場就能做的動作：把這五題印出來放在桌上，下次不管誰跟你談速度優化，先要求對方用這五題回答。
答不出來、或只給一張分數截圖不給三個數字與量測條件的，就是沒有在做事——這個判準比問「你們做多久了」有用得多。