加快網站速度的7個技巧：LCP 2.5秒內的實作清單

加快網站速度最有效的做法，是先量出瓶頸，再依序處理 7 件事：圖片轉 WebP 並壓縮、圖片標尺寸與延遲載入、管好 JavaScript 與動畫、精簡 CSS 與 HTML、設定快取與 CDN、減少第三方程式碼、控制頁面總重量。合格與否有客觀標準：Google 的 Core Web Vitals（核心網頁指標）要求主要內容在 2.5 秒內顯示；而依 Google 2016 年的研究，行動網頁載入超過 3 秒，53% 的訪客會直接離開——換句話說，速度不及格的網站，行銷預算有一半在替別人養客人。

多米諾資訊科技從業超過 20 年、網頁設計作品累積 465 件，網站健檢時速度幾乎是每一件的必查項目，我們也一再看到同一件事：讓網站變慢的原因，八成集中在圖片與第三方程式碼這兩處，而且多數不需要改版就能修。本文把我們實際優化與健檢時使用的做法與判斷門檻整理出來，您可以拿來檢查現有網站，也可以在與網頁設計公司討論時作為驗收依據。速度只是網站上線前該驗的其中一環，完整驗收項目另見〈SEO網頁設計上線前必驗 15 項〉。

一、網站速度多快才算快？Google 的三個指標

網站速度的合格標準是 Google 的 Core Web Vitals（核心網頁指標）：主要內容在 2.5 秒內顯示（LCP）、操作後 200 毫秒內有反應（INP）、載入過程版面位移不超過 0.1（CLS），三項都以 75% 的實際造訪達標為準。這不是嚴苛的標準——依 HTTP Archive 以 Chrome 使用者體驗報告（CrUX）統計，2025 年 10 月全球只有 49.7% 的行動版網站三項全數通過（電腦版 57.1%）。也就是說，把速度做及格，就已經贏過一半的網站。

三個指標各管一件事。LCP（Largest Contentful Paint，最大內容繪製）量「畫面上最大的那塊內容多久出現」，通常是首圖或主標題，合格線 2.5 秒；INP（Interaction to Next Paint，互動至下次繪製）量「訪客點擊、輸入之後畫面多久有反應」，合格線 200 毫秒，2024 年起取代舊指標 FID；CLS（Cumulative Layout Shift，累計版面位移）量「載入過程中版面跳動的程度」，合格線 0.1——就是那種正要按按鈕、整個版面突然往下跳的體驗。

速度影響的是排名與生意兩件事。排名方面，Google 搜尋中心的官方文件明確寫著「Core Web Vitals 被我們的排名系統使用」，但同時強調內容相關性優先，速度不會讓劣質內容排到前面。生意方面的數據更直接：Deloitte 與 Google 2020 年的《Milliseconds Make Millions》研究，實測 37 個歐美品牌網站、超過 3,000 萬個造訪工作階段，發現行動網站速度改善 0.1 秒，零售網站轉換率平均提升 8.4%、客單價提升 9.2%，旅遊網站轉換率提升 10.1%。0.1 秒就有感，是因為速度的影響是全站每一個訪客、每一頁累積出來的。

二、改之前先量：兩個免費工具測出網站速度

加快網站速度的第一步是測量，不是動手改：用 PageSpeed Insights 量單頁、用 Google Search Console 的「核心網頁指標」報表看全站，兩個工具都免費，五分鐘就有結果。沒有測量就開始改，常見的結局是花錢改了不痛不癢的地方，真正的瓶頸原封不動。

兩個工具的分工不同。PageSpeed Insights（pagespeed.web.dev）輸入網址就給兩組數據：上方「實際使用者體驗」來自 CrUX，是過去 28 天真實訪客的資料，這是 Google 排名參考的那一份；下方「效能診斷」是實驗室模擬，附上具體的改善建議清單，適合當工程待辦。Search Console 的「核心網頁指標」報表則把全站網址分成「良好、需要改善、不佳」三組，適合找出「哪一批頁面」有問題——常見的情況是文章頁都及格、產品頁整批不及格，一看就知道問題在產品頁的版型。

看報告時的 3 個重點

1. 以「行動版＋實際使用者體驗」為準。台灣的企業網站流量多半過半來自手機，而實驗室分數與真實體驗常有落差。實驗室分數低但實際體驗全綠的網站，不必急著動工。
2. 先看 LCP 元素是什麼。PageSpeed Insights 的診斷會直接指出 LCP 元素——十之八九是首圖。知道是哪張圖，後面第三、四節的技巧就知道往哪裡用。
3. 流量太小的網站看不到 CrUX 資料是正常的。CrUX 需要足夠的造訪量才有統計；看不到時，以實驗室數據搭配自己用手機 4G（關掉 Wi-Fi）實際開啟網站的體感為準。

三、技巧一：圖片轉 WebP 並壓縮——先處理最重的 42%

圖片是網頁上最重的資源：依 HTTP Archive《Web Almanac》2025 年的統計，行動版網頁的中位數總重量是 2,164 KB，其中圖片就占 911 KB，約 42%——所以加快網站速度，永遠先從圖片下手。做法是三件事：換格式、縮尺寸、壓品質，全部可以用免費工具完成，不需要寫程式。

換格式的效益最大。依 Google 的官方數據，WebP 格式在相同畫質下比 JPEG 小 25–34%，比 PNG 小約 26%；更新的 AVIF 格式壓縮率更高，但轉檔工具與相容性的支援仍以 WebP 較普及，對多數企業網站，我們目前建議以 WebP 為標準格式。縮尺寸則是把「相機直出的 4000px 大圖」改成版面實際需要的尺寸再上傳——版型只顯示 800px 寬，上傳 4000px 的原圖等於強迫每個訪客多下載十幾倍的資料。原文 2021 年版就提醒過：在 HTML 裡限制圖片的顯示長寬，檔案本身不會變小，只是看起來變小，這一點至今沒變。

圖片優化的 3 個做法

1. 上傳前先跑一次壓縮工具。Squoosh（Google 出品的免費網頁工具）可以轉 WebP、調品質、看前後對照；批次處理可用 TinyPNG 或圖片編輯軟體的批次匯出。我們替客戶上稿的內文圖，壓縮後多數落在 100 KB 以內。
2. 依版面實際尺寸出圖。先確認版型各位置的顯示寬度（首圖、內文圖、縮圖各不同），出圖寬度抓顯示寬度的 2 倍以內（供高解析螢幕使用）即可，不必更大。
3. 產品列表用縮圖，不要用原圖縮小。電商列表頁一次顯示幾十張圖，每張都應該是獨立產生的小尺寸縮圖檔；讓瀏覽器把大圖縮小顯示，等於整頁下載了幾十張用不到的大圖。這是原文 2021 年版「使用縮圖」建議的現代版，方向完全正確。

四、技巧二：圖片標寬高、延遲載入，首圖除外

圖片除了要小，還要「載得聰明」：每張圖標明寬高避免版面跳動、非首屏的圖加上延遲載入、而首圖反過來要優先載入——三件事都只是 HTML 屬性，成本極低。依《Web Almanac》2024 年的統計，行動版網頁上只有 32% 的圖片同時標了寬與高，也就是近七成的網站放著最便宜的優化沒做。

三個屬性各解決一個問題。width 與 height 讓瀏覽器在圖片下載完成前就預留好空間，版面不會在載入過程中跳動，直接改善 CLS；loading="lazy"（延遲載入）讓畫面外的圖片等訪客捲動到附近才下載，第一屏因此更快；而首圖（通常就是 LCP 元素）要用 fetchpriority="high" 告訴瀏覽器優先處理。依 Google web.dev 的 LCP 優化指南，最常見的錯誤正是把首圖也加上延遲載入——原本要最快出現的圖，反而被排到隊伍後面，LCP 直接變差。

圖片載入的 3 個做法

1. 每張 img 都標 width 與 height。寫圖片的原始比例即可，實際顯示大小交給 CSS；重點是讓瀏覽器知道比例、預留空間。
2. 首屏以下的圖一律 loading="lazy"。內文圖、頁尾圖、列表第二排以後的產品圖都適用。多數 CMS 與新版型已內建，健檢時看原始碼確認即可。
3. 首圖用 fetchpriority="high"，且絕不 lazy。連同「首圖直接寫在 HTML 裡、不要靠 JavaScript 或 CSS 背景圖載入」一起做，LCP 的改善通常立竿見影。

五、技巧三：管好 JavaScript 與動畫

JavaScript 是網頁第二重的資源（行動版中位數 632 KB，《Web Almanac》2025），也是 INP 不及格的主因：程式碼要下載、還要執行，執行期間畫面就是卡的。原文 2021 年版提醒「有限制的使用動畫」，方向正確，但今天拖慢網站的主角已經從 GIF 動畫換成了滿版輪播、特效函式庫與載入動畫本身。

動畫的成本要分開看。CSS 動畫（位移、淡入淡出、hover 效果）由瀏覽器直接處理，成本極低，放心用；GIF 動圖是最貴的動畫形式，同樣的內容轉成 MP4／WebM 影片常能小 80% 以上，Lighthouse 的診斷也長期把「用影片格式取代 GIF」列為標準建議；而靠大型 JavaScript 函式庫驅動的滿版特效、粒子背景、進場動畫，付出的不只是下載量，還有主執行緒被占住的卡頓——這正是很多網站「看起來很炫、用起來很頓」的原因。首頁輪播是另一個常見的重災區：五張輪播圖等於五張首圖的重量，而點擊率集中在第一張，我們在〈首頁設計的 6 個關鍵〉裡對輪播的取捨另有說明。

管 JavaScript 的 3 個做法

1. 動畫優先用 CSS，動態展示用影片，不用 GIF。影片記得加 muted 與 playsinline 屬性自動播放，並同樣延遲載入。
2. 用不到的外掛與函式庫直接移除。健檢時常見網站同時載入兩三個版本的 jQuery、早已停用的輪播與燈箱外掛。每季清一次，比任何壓縮技巧都有效。
3. 非必要的程式碼加 defer 延後執行。讓 HTML 與 CSS 先把畫面畫出來，統計、聊天、特效類的程式碼等畫面出來再跑。這項需要網站廠商配合，驗收時看 PageSpeed Insights 的「減少未使用的 JavaScript」與「最小化主執行緒工作」兩項是否改善。

六、技巧四：精簡 CSS 與 HTML，別讓樣式擋住畫面

CSS 與 HTML 本身不大，但 CSS 是「渲染阻擋資源」——樣式表沒下載完，瀏覽器一個字都不會畫出來，所以精簡的重點不是省流量，而是讓畫面早點出現。依 Google web.dev 的分析，LCP 的時間裡有將近一半花在「拿到第一個位元組之前」與「資源下載」，樣式表愈肥、載入的字型愈多，這段等待就愈長。

原文 2021 年版的兩項建議在此合併更新。「簡潔您的程式碼」在今天的做法是最小化（minify）——用工具移除空格、註解與換行，CSS 與 JavaScript 檔案通常能小 10–30%，且完全不影響功能；「將表格式改為 CSS 方式」在 2021 年是進行式，今天已是完成式——用 table 排版的網站在 RWD（響應式網頁設計）時代已經被淘汰，若您的網站還在用表格排版，該做的不是優化而是改版，這類網站通常也伴隨〈網頁設計常見錯誤〉裡的其他問題。

精簡樣式的 3 個做法

1. CSS、JavaScript 上線前一律最小化。建置工具或線上 minifier 都可以；驗收標準是原始碼打開來是壓成一團的，而不是留著整齊註解的開發版。
2. 網頁字型最多兩套，並設 font-display: swap。中文字型檔動輒數 MB，是隱形的重量大戶；能用系統字型（如本文使用的思源黑體系列堆疊）就不掛外部字型，要掛就先顯示替代字型、避免整頁文字空白等字型。
3. 刪掉沒在用的樣式與版型模組。套版網站常載入整套模板的全部樣式，實際只用到兩三成；PageSpeed Insights 的「減少未使用的 CSS」會直接列出可刪的比例。模板網站的先天限制與挑選原則，另見〈網頁設計模板〉一文。

七、技巧五：快取與 CDN，縮短伺服器回應時間

快取（cache）的原理是「同一份東西不要重複做、重複傳」：瀏覽器快取讓回訪的訪客不必重新下載沒變的檔案，伺服器快取讓程式不必每次重新組頁面，CDN 則把檔案放到離訪客更近的節點。依 Google web.dev 的拆解，LCP 的時間約有四成耗在 TTFB（Time to First Byte，第一位元組時間）——也就是伺服器把第一個位元組送到瀏覽器之前，前面六節的功夫做得再好，伺服器慢半天回應，一切都白搭。

三層快取各自負責一段。瀏覽器快取由伺服器的 Cache-Control 標頭控制，圖片、CSS、JavaScript 這類不常變動的檔案設長效期，回訪與翻頁的速度差異立刻有感；伺服器端快取對 WordPress 這類動態網站效益最大，快取外掛把組好的頁面存成靜態檔，省去每次查資料庫的時間；CDN（Content Delivery Network，內容傳遞網路）把靜態檔案分發到各地節點，訪客從最近的節點取檔。要提醒的是：主要客群在台灣的網站，主機放台灣、選擇可靠的主機商，效益往往比架 CDN 更直接——CDN 對跨國流量的幫助大，對「主機在台灣、訪客也在台灣」的網站幫助有限。主機與網址等基礎架構的選擇，在〈如何建立專業網站〉有更完整的說明。

快取設定的 3 個做法

1. 靜態檔案設長快取、改版時換檔名。圖片與樣式檔設 30 天以上的快取效期；檔案更新時以新檔名（或版本參數）發布，就不會有「改了版客戶看到舊畫面」的問題。
2. 確認主機支援 HTTP/2 以上與文字壓縮。HTTP/2 讓多個檔案共用同一條連線，gzip 或 brotli 壓縮讓 HTML、CSS、JavaScript 傳輸時再小 60–80%；這兩項是現代主機的基本配備，健檢時偶爾還是會遇到沒開的。
3. TTFB 持續偏高就換主機，不要硬撐。PageSpeed Insights 顯示「縮短初始伺服器回應時間」且 TTFB 經常超過 0.8 秒，多半是主機等級或程式效率的問題；廉價虛擬主機省下的月費，通常遠低於流失訪客的成本。

八、技巧六：減少第三方程式碼的請求

每掛一個第三方服務——聊天視窗、分析工具、廣告代碼、社群外掛、地圖——網站就多一批對外部伺服器的請求，而這些程式碼的速度您完全無法控制。原文 2021 年版的「減少對伺服器發送要求」講的正是這件事，而它在今天更重要：現代網站自己的檔案多半已經過優化，健檢時真正失控的常常是行銷部門這些年來「加一下就好」累積出來的十幾個追蹤碼。

我們自己的網站也走過這段：分析、廣告、防無效點擊、行為錄影等工具一路累積，後來定期盤點，把已經不看報表的工具直接下架——每個第三方腳本都是用速度換功能，值不值得，要用「還有沒有人在看這個數據」來判斷，而不是「當初裝都裝了」。管理第三方程式碼最好的工具是 Google Tag Manager（GTM）：所有行銷代碼集中在一處，加誰、停誰一目瞭然，也避免同一支代碼被重複安裝。

清第三方的 3 個做法

1. 每季盤點一次，列出全部第三方服務。PageSpeed Insights 的「減少第三方程式碼的影響」會列出每個外部來源花的時間；看到不認識的網域，先問「這是誰裝的、還有人在用嗎」。
2. 行銷代碼統一走 GTM 管理。並且約定：新代碼一律進 GTM，不直接改網站原始碼；停用的代碼當月移除，不是「先暫停放著」。
3. 重的元件改成「點了才載入」。聊天視窗、YouTube 影片、地圖是最重的三類：影片可先放縮圖、點擊才載入播放器；聊天視窗可延後幾秒或互動後才載入。這些做法不影響功能，只是把成本移出關鍵路徑。

九、技巧七：控制頁面總重量

前面六個技巧各管一段，最後要有一個總量觀念：頁面總重量。依《Web Almanac》2025 年的統計，行動版網頁中位數已達 2,164 KB——原文 2021 年版建議的「理想 300 KB」在今天已不現實，我們實務上的建議門檻是：行動版首頁在 1.5 MB 以內、一般內頁在 1 MB 以內、LCP 首圖在 200 KB 以內。這組數字不是官方標準，而是我們專案中「能同時保住設計質感與 Core Web Vitals 及格」的經驗值，供您作為與廠商討論的起點。

總重量的意義在於它是「設計決策的預算」。單看每一項——多一張情境照、多一段影片背景、多一個特效——都有理由，加總起來就是一個 5 MB 的首頁。把重量當預算來管理，討論就會從「這個效果好不好看」變成「這個效果值不值 800 KB」；預算內，設計與速度可以兼得，超了預算，再好看的元素都該排優先序。這也是為什麼速度應該在設計階段就談定，而不是上線後才來補救——上線後能救的，只剩壓圖與清代碼。

控制重量的 3 個做法

1. 用開發者工具量一次現況。Chrome 按 F12 開啟開發者工具，Network（網路）分頁重新整理頁面，左下角就有請求數與傳輸總量；勾選「Disable cache」量到的才是新訪客的真實成本。
2. 給每頁設重量預算，寫進委外規格。做新站時把「行動版首頁 ≤1.5 MB、LCP ≤2.5 秒」寫進合約的驗收條件，比上線後才提出要求有效得多。
3. 上稿流程加一道「圖片過磅」。網站變重的主因往往不是版型，而是日後上稿的人直接把相機原圖丟上去。訂一條簡單規則——內文圖壓縮後超過 300 KB 就不上稿——就能擋住大多數的體重回升。

十、我們健檢時最常見的 5 個速度問題

以下 5 種情形，來自多米諾接手網站健檢與改版案的實際觀察，出現頻率由高到低——每一項都對應前面的一個技巧，改善前先對照一輪。

1. 相機原圖直接上稿，單張 2–5 MB。（對應技巧一）最常見也最好修：壓縮加轉 WebP，不動版面就能把頁面重量砍掉一半以上。
2. 追蹤碼與外掛累積十幾支，沒有人記得全部是誰裝的。（對應技巧六）常見同一支 GA 代碼裝了兩次、停用多年的行銷工具還在載入。盤點加下架，INP 與請求數立刻改善。
3. 首圖被延遲載入，或藏在 JavaScript 輪播裡。（對應技巧二、三）LCP 不及格的頭號原因；把首圖改回 HTML 直出並加上優先載入，常常一項就讓 LCP 及格。
4. 圖片沒標寬高，載入時版面跳動。（對應技巧二）CLS 不及格的主因，補上屬性即可，是全文成本最低的修正。
5. 廉價主機的 TTFB 過長，或主機在海外。（對應技巧五）前端再怎麼優化都被伺服器回應吃掉；台灣客群的網站，換回台灣或鄰近節點的可靠主機，改善最直接。

十一、網站速度 10 題檢核清單

改版前或上線驗收時，拿以下 10 題逐題檢查：每題 10 分，哪一題失分，就回頭補對應的章節。第 1–2 題對應第一、二節，第 3–5 題對應技巧一、二，第 6 題對應技巧三，第 7 題對應技巧四，第 8 題對應技巧五，第 9 題對應技巧六，第 10 題對應技巧七。

1. PageSpeed Insights 行動版的 LCP、INP、CLS 是否三項皆為「良好」？
2. Search Console 的核心網頁指標報表中，是否沒有「不佳」的網址群組？
3. 網站圖片是否以 WebP（或 AVIF）格式為主，內文圖多數在 300 KB 以內？
4. 每張圖片是否都標了 width 與 height？
5. 非首屏圖片是否延遲載入，而首圖確定沒有被延遲載入？
6. 是否已無 GIF 動圖與用不到的外掛、函式庫？
7. CSS 與 JavaScript 是否已最小化，網頁字型是否在兩套以內？
8. 靜態檔案是否設了長效快取，主機是否支援 HTTP/2 與文字壓縮，TTFB 是否穩定低於 0.8 秒？
9. 第三方程式碼是否在半年內盤點過，且統一由 GTM 管理？
10. 行動版首頁總重量是否在 1.5 MB 以內？

十二、網站速度常見問題

十三、結論：速度是設計出來的，不是上線後才擠出來的

加快網站速度的 7 個技巧，本質上是同一件事：對頁面上的每一份重量問一句「值得嗎」。圖片值得，就給它對的格式與尺寸；特效值得，就用便宜的 CSS 做；追蹤碼值得，就留下並管好——其餘的，刪掉。標準已經很清楚：LCP 2.5 秒、INP 200 毫秒、CLS 0.1，達標就贏過一半的網站；而達標最省力的時機是設計階段，把重量預算與驗收數字寫進規格，比上線後補救便宜得多。網站速度沒有一勞永逸，每一次上稿、每一支新代碼都在增加重量；把第十一節的 10 題清單排進例行檢查，速度才守得住。