效能與速度

先搞懂兩種數據

測速工具會給出兩類數據，意義完全不同，混在一起看會做出錯誤判斷。

優化時看實驗室數據找問題，判斷成效時看實際使用者數據。 兩者不一致是正常的——工具用的網路與裝置條件，跟你的訪客不一樣。

三個核心指標

目前業界共用的體驗指標大致分三類，衡量的是使用者實際感受到的三件事。指標的定義與門檻會隨時間調整，建議以測試工具當下顯示的標準為準。

一、最大內容繪製（LCP）

衡量什麼：主要內容多久才顯示出來。通常是首頁的大圖或主標題。

白話說：訪客多久才「看到東西」。

常見拖累原因：主視覺圖片過大、伺服器回應慢、字型載入阻塞。

二、互動回應速度（INP）

衡量什麼：使用者點擊後，畫面多久才有反應。

白話說：點了按鈕會不會卡住。

常見拖累原因：載入了過多的腳本與第三方追蹤碼，佔用了處理資源。

三、版面位移（CLS）

衡量什麼：載入過程中版面跳動的程度。

白話說：正要點按鈕，畫面突然往下推，結果點到別的地方。

常見拖累原因：圖片沒有事先指定顯示尺寸、廣告或嵌入內容載入後才撐開空間、字型切換造成文字重排。

這一項最容易被忽略，但對使用者的惱怒程度最高——尤其在手機上。

怎麼測

基本做法

1. 用線上的網頁效能測試工具，輸入網址
2. 分別看手機與電腦的結果——手機通常明顯較差，而那才是多數訪客的實際情況
3. 不要只測首頁。至少加測一個產品頁與一篇文章頁，這些頁面的問題常常不同

測試時的注意事項

• 多測幾次取中間值——單次結果會受當下網路狀況影響
• 避開自己的快取——用無痕視窗，或測試工具本身就是從外部連線
• 同一個工具前後比較——不同工具的計算方式不同，跨工具比分數沒有意義

分數怎麼看

測速工具通常會給一個總分。這個分數是參考，不是目標。

三個常見誤解：

1. 「一定要滿分」——不必。滿分需要極端的取捨，往往犧牲了功能與視覺。落在良好區間就足夠
2. 「分數高就會排名好」——不會。速度只是眾多因素之一，內容相關性影響大得多
3. 「分數低就是廠商做得爛」——不一定。有些分數損失來自必要的第三方服務，例如客服系統、追蹤碼、地圖嵌入

比分數更值得看的是「建議事項」清單——工具會直接指出哪幾張圖過大、哪些腳本阻塞載入。那才是可以行動的資訊。

最實際的測試方法

所有工具都比不上這一招：用手機的行動網路，站在戶外，開啟自己的網站。

關掉 Wi-Fi、不要用公司的網路。這才是訪客的真實情況。如果你自己都等得不耐煩，數據再好看也沒有意義。

同樣的方式測一次同業的網站，你會很快知道自己的位置。

定期檢查的建議

效能會隨時間劣化——內容累積、外掛增加、圖片越傳越多。建議：

• 每季測一次首頁與主要頁面
• 每次改版或新增功能後測一次，確認沒有明顯退步
• 如果有安裝分析工具，定期看實際使用者的數據趨勢

測出問題後的處理順序，見網站慢的常見原因與優先處理順序。

先處理影響最大的，不要從難的開始

效能優化最常見的錯誤，是一頭栽進技術細節，卻沒發現首頁有一張 8MB 的圖。

以下依影響程度與處理難度排序，多數網站處理完前三項就會有明顯改善。

第一優先：圖片

這是最大宗，而且處理起來最容易。

典型狀況是：同仁直接把手機拍的原圖上傳，一張好幾 MB。一頁十張就是幾十 MB，在行動網路下等同打不開。

處理方式

• 調整到實際顯示需要的尺寸
• 適度壓縮
• 畫面外的圖片延遲載入
• 事先指定顯示尺寸，避免載入時版面跳動

更根本的做法是讓後台自動處理——上傳時就縮圖、壓縮。否則問題會反覆發生，因為沒有人會記得每次都手動處理。

詳細作法見圖片尺寸與壓縮。

第二優先：首頁塞太多東西

首頁是最多人看、也最容易失控的頁面。常見的累積：

• 輪播圖放了八張，每一張都要載入
• 滿版背景影片沒有壓縮，手機也照播
• 嵌入了地圖、社群動態牆、影音播放器、客服視窗
• 各種行銷追蹤碼疊加

處理方式

• 輪播圖減到三張以內——實際上多數訪客不會看到第三張以後
• 背景影片壓縮，且手機版改用靜態圖
• 嵌入的第三方內容改為捲動到該區才載入
• 盤點追蹤碼，移除已經不用的

這一項的效益通常僅次於圖片，而且不需要動到程式。

第三優先：字型

容易被忽略的隱形負擔。整套中文字型可能達數 MB，比許多圖片還大。

處理方式

• 整站字型控制在兩種以內
• 只載入實際用到的字重（粗體、細體各算一份）
• 標題用特殊字體、內文用系統字體，是兼顧特色與速度的常見做法
• 設定成字型載入前先用系統字體顯示，避免文字空白一段時間

第四優先：外掛與第三方服務

每一個外掛、每一段追蹤碼，都會增加載入負擔與可能的阻塞。

處理方式

• 盤點目前安裝了什麼——很多網站有裝了但早就不用的功能
• 移除重複功能的外掛
• 追蹤碼改為延後載入
• 客服視窗、聊天工具改為使用者互動後才載入

這一項在維護中的網站特別值得定期檢視，因為外掛通常只增不減。

第五優先：主機與伺服器回應

如果上述都處理了還是慢，或是連純文字頁面都要等很久，那問題可能在伺服器端。

判斷方式：測速工具通常會顯示「伺服器回應時間」這類指標。如果這個數值就已經偏高，前端怎麼優化都有限。

詳見主機規格與速度的關係。

第六優先：程式與資料庫

屬於較深層的問題，通常出現在功能較複雜的網站：

• 資料庫查詢沒有建立適當索引，資料量大時明顯變慢
• 一個頁面重複執行大量查詢
• 沒有使用快取，每次都重新運算相同的結果

這一層需要開發人員處理，見快取是什麼。

怎麼判斷自己屬於哪一種

幾個快速的判斷：

手機專屬的問題見手機版破版與常見問題排查。

一個務實的提醒

處理完前三項後再測一次。多數企業網站到這裡就已經足夠了。

後面的項目投入成本較高、改善幅度較小。除非網站流量大或有明確的效能需求，否則把力氣放在內容經營上，投報率通常更高。

快取的概念：把算過的答案存起來

動態網站每次有人來訪，程式都要去資料庫取資料、組合成頁面再送出。如果一千個人看同一頁，這件事就重複做了一千次。

快取的作用是：第一次算完之後把結果存起來，後面的人直接拿現成的。

這是效能優化中效益最大的手段之一，但也是最容易造成困惑的——因為它會讓你看到舊的內容。

四層快取

從離訪客最近的一層往回算：

各層在做什麼

瀏覽器快取

訪客第一次來訪時下載的圖片、樣式檔、腳本，會存在他的裝置上。第二次來就不用重新下載。

這是為什麼第一次開很慢、之後就快——但新訪客感受到的永遠是第一次的速度，這也是優化時要注意的地方。

CDN 快取

把靜態檔案放在各地的節點，由離使用者較近的節點提供。對海外客群或主機在國外的網站效益明顯；台灣客群、主機也在台灣時，改善幅度有限。

取捨見要不要用 Cloudflare 這類第三方 DNS 與 CDN。

頁面快取

效益最大的一層。把組好的完整頁面存成靜態檔案，後續的訪客直接取用，完全跳過程式運算與資料庫查詢。

對內容變動不頻繁的企業網站（公司簡介、服務說明、產品頁），這一層可以帶來數倍的差異。

程式與資料庫快取

比較底層的處理，包含把程式碼編譯結果存起來、把常用的查詢結果暫存等。通常由廠商在主機端設定，業主不需要操心。

快取造成的常見困惑

「我改了內容，但網站上還是舊的」

這是最常見的狀況，而且很容易被誤判為系統故障。可能卡在任何一層：

1. 先用無痕視窗開一次——如果無痕看得到新的，那是你自己的瀏覽器快取
2. 換一支手機或換網路開——如果都是新的，那也是本機問題
3. 如果所有裝置都看到舊的——那是伺服器或 CDN 的快取，需要清除

好的後台應該在內容更新時自動清除相關頁面的快取。如果每次改完都要手動清，那是可以改善的設定。

「改了圖片，但顯示的還是舊圖」

圖片如果用相同的檔名覆蓋，各層快取都會認為是同一個檔案而不重新取。

解法很簡單：換一個檔名上傳。這比清各層快取快得多。

「登入後看到別人的資料」

這是快取設定錯誤中最嚴重的一種——把應該因人而異的頁面（會員專區、購物車、訂單）也快取了。

如果網站有會員或購物功能，這一項務必在驗收時測試：用兩個不同帳號分別登入，確認看到的是各自的資料。

哪些內容不該快取

• 登入後的個人頁面
• 購物車與結帳流程
• 後台管理介面
• 表單送出後的結果頁
• 即時性資料（庫存、報價）

快取時間怎麼設

沒有標準答案，原則是依內容的更新頻率決定：

• 幾乎不變的檔案（樣式、腳本、Logo）——可以設很長，更新時改檔名即可
• 一般頁面（公司簡介、服務說明）——數小時到一天
• 常更新的頁面（最新消息列表）——較短，或改為內容更新時自動清除
• 即時性內容——不快取

業主需要知道的三件事

1. 快取存在，所以改了東西不一定立刻看到——先用無痕視窗確認，不要急著回報故障
2. 後台應該要有清除快取的功能，或在內容更新時自動處理。發包時可以確認這一點
3. 換圖片時換檔名——最省事的做法

快取設定屬於技術範疇，但理解它的存在可以省下很多不必要的來回。

什麼時候問題出在主機

圖片處理了、首頁精簡了、外掛也清了，網站還是慢——這時候要往伺服器端看。

一個簡單的判斷：開一個純文字、幾乎沒有圖片的頁面（例如隱私權政策頁）。如果連這種頁面都要等好幾秒，那前端優化已經不是重點了。

測速工具通常也會顯示伺服器回應時間這類指標，這個數值偏高就是明確的訊號。

主機類型與效能

多數中小企業的形象網站，虛擬主機就足夠。 不要因為「聽說 VPS 比較快」就升級——如果慢的原因是圖片沒壓縮，換主機也不會變快。

共用主機的鄰居問題

虛擬主機是多個網站共用一台伺服器。如果同一台上有網站流量暴增、或程式寫得很耗資源，會排擠到其他人。

症狀

• 速度時快時慢，沒有規律
• 某些時段特別慢
• 自己的網站沒有任何變動，但效能下降了

處理方式

先聯繫主機商反映，多數會協助調整。若持續發生，才考慮換方案或換主機商。

主機位置的影響

資料傳輸的距離會影響回應時間。原則很單純：主機應該放在離主要訪客近的地方。

• 客群在台灣——選台灣機房
• 客群在海外——選當地或鄰近機房，或搭配 CDN
• 客群橫跨多國——可考慮 CDN，或評估主要市場優先

實務上要注意的是：從台灣連台灣的機房，也不是每一家都一樣順。 不同機房、不同線路之間的連線品質有差異，這需要實測才知道。

什麼時候該升級

幾個明確的訊號：

1. 純文字頁面的回應時間持續偏高，且前端已經優化過
2. 流量成長後才開始變慢——原本正常，訪客變多就撐不住
3. 主機商通知資源用量接近上限
4. 網站有較重的功能——會員、購物車、大量商品搜尋
5. 經常出現連線錯誤或逾時

不該升級的情況

• 圖片沒處理就想靠主機解決——換多好的主機都救不了 8MB 的圖
• 只是想「保險一點」而升級——多付的費用沒有對應的效益
• 被推銷說「升級就會變快」但沒有具體的診斷依據

升級前請先要求對方說明「目前的瓶頸是什麼」。 說不出來的，多半是在賣方案而不是解決問題。

主機以外的伺服器層因素

• 程式語言版本——較新的版本通常執行效率較好。長期沒更新的網站，光是升級版本就可能有明顯改善（但需先確認相容性）
• 資料庫效率——資料量大時，索引設計會造成明顯差異
• 伺服器端快取設定——見快取是什麼
• 壓縮傳輸——伺服器應啟用內容壓縮，減少傳輸量

這些屬於維護範疇，通常包含在主機代管或維護方案中。

選主機時該問的五件事

1. 機房位置在哪裡？
2. 資源配額是多少？超過會怎樣——是限速、加價，還是直接停用
3. 有沒有備份？頻率與保留份數？ 備份與網站放在同一台是沒有意義的
4. 故障時的支援時間與回應速度？
5. 支援的程式語言版本？多久更新一次？

價格通常不是最重要的差異——出事時找不找得到人、多久能處理，才是實際的成本。

主機的年度費用與其他固定支出見網站每年的固定支出有哪些。

一個常見的誤解

「換一個比較快的 DNS，網站就會變快。」

不會。DNS 只影響最初查詢網址那幾十毫秒，而且改的是你自己這台裝置的查詢速度，不會改變別人看你網站的體驗。

網站的速度取決於主機效能、網頁本身的重量，以及傳輸距離。這三件事才是重點。