網站速度優化指南：Core Web Vitals 與驗收指標
打開自己的官網，用手機連行動網路點進去，然後默數到畫面出現內容。如果你自己都數到不耐煩，訪客早就關掉了。
速度在會議上常被歸類成「技術細節」，但它同時吃掉兩件事：搜尋引擎對頁面的評價，以及願意留下來把內容看完的人數。這篇把「網站很慢」拆成可以討論、可以驗收的具體項目。
Core Web Vitals 是什麼
Core Web Vitals（核心網頁指標）是 Google 提出的一組使用者體驗量測標準。它的設計邏輯很務實：不看伺服器的技術數據，而是模擬一般人打開網頁時真正感受到的三件事。
LCP：主要內容多久才出現
LCP（Largest Contentful Paint，最大內容繪製）量的是「頁面上最大的那塊內容，多久之後被畫出來」。對訪客來說，這就是「我什麼時候才看得到東西」。
常見的拖累來源是首屏的大圖、由程式動態產生的主視覺，以及必須等伺服器算完才回傳的頁面。
INP：點下去多久才有反應
INP（Interaction to Next Paint，互動到下次繪製）量的是「使用者點擊或輸入之後，畫面多久才給出回應」。
畫面已經出現、但按了沒反應，體感上比載入慢更糟。這項指標的主要拖累是同時間有太多程式碼在背景執行，讓瀏覽器忙到沒空理會你的點擊。
CLS：版面會不會亂跳
CLS（Cumulative Layout Shift，累積版面位移）量的是「內容載入過程中，版面跳動的程度」。你正要按下按鈕，廣告或圖片突然插進來把按鈕擠走——那就是 CLS。
這項最常見的原因是圖片、廣告或嵌入內容沒有事先預留位置。
這三項要一起看。 官方會公布建議的分級門檻，且會隨著使用者行為調整，實務上不必背數字，直接看量測工具標示的「良好／需要改進／不佳」分級即可，並以官方最新說明為準。
網頁為什麼會變肥
網站剛上線時通常不慢。速度是被「一點一點加上去的東西」拖垮的。
圖片沒有處理。 直接把相機或設計稿輸出的原始檔上傳，是最常見也最好修的問題。同一張視覺，壓縮並轉成較新的圖片格式後，檔案大小往往差一個量級，而肉眼看不出差別。另外也要確認圖片有依照裝置提供不同尺寸，不要讓手機下載桌機用的大圖。
第三方腳本越掛越多。 分析工具、廣告像素、客服對話框、線上預約外掛、社群嵌入——每一個都是別人家的程式碼，載入時間不在你的控制之內。這類東西的特性是「加的時候很快，沒人負責移除」，時間一久就累積成一整串。
字型檔案太大或載入方式不對。 中文字型的檔案本來就大，若又同時載入多種字重與樣式，會明顯延後文字出現的時間。
外掛與套件疊加。 內容管理系統上裝的每個外掛，通常都會在所有頁面載入自己的樣式與程式碼，即使那個頁面根本用不到。
伺服器端的等待。 每次開頁都要即時查詢大量資料、或主機規格與流量不匹配，會讓前面所有優化都白做，因為瀏覽器一開始就在等。
量測工具怎麼讀
不需要買工具，瀏覽器內建的開發者工具與 Google 提供的免費檢測服務就足夠。重點是讀的方式：
- 一律以行動裝置的結果為準。 桌機的成績通常好看很多，但那不是多數訪客的體驗。
- 分開看「實驗室數據」與「真實使用者資料」。 前者用來找瓶頸與比較改善前後，後者用來確認真實訪客感受到的變化。
- 不要只測首頁。 首頁常常是最被照顧的一頁。真正要測的是流量最大的產品頁、文章頁與表單頁。
- 看分數不如看清單。 總分是給老闆看的，真正有用的是報告裡列出的具體問題項目。
改善的優先順序
預算與時間有限時，照這個順序做，投入產出比最高：
| 順位 | 工作項目 | 為什麼放這裡 |
|---|---|---|
| 1 | 圖片壓縮與格式轉換 | 改動小、風險低、效果最明顯 |
| 2 | 盤點並移除無用的第三方腳本 | 不需開發，只需決策 |
| 3 | 為圖片與嵌入區塊預留尺寸 | 直接解決版面跳動 |
| 4 | 調整字型載入方式與字重數量 | 影響文字出現的時間 |
| 5 | 延後非首屏資源的載入 | 需要開發介入，效果穩定 |
| 6 | 快取與主機規格調整 | 治本，但要一併評估成本 |
| 7 | 架構層級的重整 | 最後才考慮，通常併入改版 |
先做前三項，再回頭量一次。 很多網站在完成前三項之後，成績就已經回到可接受的範圍，後面幾項可以按需要再排。
如果你正好在規劃改版，效能應該在改版時就一併處理，而不是上線後再補；改版本身還有另一組必須顧的風險，見網站改版 SEO 檢查清單。
三個常見的誤解
「換一台更貴的主機就會快」：主機升級只解決伺服器端的等待，對圖片過大、腳本過多造成的延遲毫無幫助。先做量測、確認瓶頸在哪一端，再決定要不要花這筆錢。
「裝一個加速外掛就好」：這類外掛通常做的是快取與檔案壓縮，確實有效，但它無法替你移除不需要的第三方追蹤碼，也無法把沒壓縮的原始圖檔變小。它是輔助，不是替代品。
「首頁分數好看就沒問題」：訪客從搜尋進來時，多半直接落在內頁。真正該優化的是流量集中、且承擔轉換任務的那幾個頁面。
與廠商溝通：把速度寫進驗收
「網站要跑得快」這種需求沒辦法驗收。把它改寫成可檢驗的條件，才有意義：
- 指定量測條件：用哪個工具、以行動裝置模式、測哪幾個代表性頁面（首頁、主要產品或服務頁、文章頁、表單頁）。
- 指定驗收分級：以工具當下的分級標準為準，要求三項指標都落在「良好」，而不是約定一個會過期的數字。
- 列出基本要求：圖片需壓縮並提供多種尺寸、圖片與嵌入區塊需預留尺寸、非首屏資源延後載入、移除未使用的樣式與程式碼。
- 約定第三方腳本的責任歸屬：日後行銷需求要加的追蹤碼，由誰評估、誰負責移除。
- 約定量測時機：上線前驗一次，上線後間隔一段時間再驗一次（真實使用者資料需要累積）。
這幾條放進合約的驗收章節，成本幾乎是零，但能擋掉「上線當天很快、三個月後很慢」的狀況。維護階段的責任分界怎麼寫，可以參考網站維護費用包含什麼。
NETVANA 的軟體開發流程在測試與上線階段會做跨瀏覽器相容性與效能測試，開發期間以兩週為一個 Sprint、每個週期結束提供可操作的 Demo，讓效能問題在早期就被看見，而不是等到驗收前一週。
速度以外，別忘了另外兩件事
速度只是「網頁品質」的一部分。和它常常一起被忽略、但同樣影響真實使用體驗的還有兩項：
一是無障礙。版面對比不足、只能用滑鼠操作、圖片沒有替代文字，會直接把一部分訪客擋在門外，詳見網頁無障礙設計指南。
二是內容本身。頁面再快，如果沒有回答訪客真正想問的問題，也留不住人。內容規劃的方法可以看品牌部落格怎麼經營。
網站速度不是玄學，它是一連串可以列舉、可以排序、可以驗收的工作。你不需要看懂每個技術名詞，但你需要知道該要求什麼。
如果你的網站速度一直上不來，或正在評估改版並希望把效能條件寫進規格，與 NETVANA 討論你的網站需求。NETVANA 的軟體服務採先諮詢再報價，沒有固定套餐，各項服務的內容與交付物可以看軟體服務介紹。
延伸閱讀：想了解建置階段的費用會花在哪些地方，可以看網站製作費用怎麼算；上線後的維護責任怎麼劃分，可以看網站維護費用包含什麼；準備改版舊站，先看網站改版 SEO 檢查清單；速度的天花板，一開始就由主機方案決定，可以看網站主機怎麼選指南；速度只是技術面的一項，其他項目一樣會扣分，可以看技術 SEO 檢查清單；這些指標要寫進上線驗收才不會被略過，可以看網站上線前檢查清單；平常的速度優化在流量暴增時不一定夠用，可以看活動檔期流量高峰怎麼準備。
