網站速度優化不只是技術問題,它直接影響你的錢。
Google 的研究顯示,網頁載入時間從 1 秒增加到 3 秒,跳出率上升 32%。從 1 秒到 5 秒?跳出率暴增 90%。
我們在管理超過 40 個 SEO 站點的過程中,親手把好幾個站的 PageSpeed 分數從 50-60 分拉到 90+。這篇把實戰中最有效的網站速度優化手法整理出來,按照「投入時間 vs 效果」排序,讓你用最少的力氣拿到最大的分數提升。
為什麼網站速度對 SEO 很重要
Google 在 2021 年正式把 Core Web Vitals 納入排名因素,這代表網站速度從「加分項」變成了「門檻」。
Core Web Vitals 有三個指標:
| 指標 | 全名 | 衡量什麼 | 通過標準 | 權重 |
|---|---|---|---|---|
| LCP | Largest Contentful Paint | 最大內容的載入時間 | < 2.5 秒 | 25% |
| INP | Interaction to Next Paint | 互動反應速度 | < 200ms | 30% |
| CLS | Cumulative Layout Shift | 頁面視覺穩定性 | < 0.1 | 25% |
除了排名,速度也直接影響轉換率。Amazon 曾經測試發現,每延遲 100 毫秒,營收就下降 1%。你的網站可能沒有 Amazon 的規模,但邏輯一樣 — 使用者不會等。
這不是理論。我們實際觀察過一個美容品牌站,PageSpeed 從 55 分優化到 92 分之後,自然搜尋流量在 6 週內增加了 23%。
如果你想深入了解,可以參考我們的[SEO入門](/blog/seo-beginner-guide-2026)完整指南。先測量,再優化:網站速度優化的第一步
在動手之前,你需要知道問題出在哪。
PageSpeed Insights
最直接的工具。打開 PageSpeed Insights,輸入你的網址,它會告訴你:
- 整體分數(0-100)
- Core Web Vitals 的實際數據
- 具體的優化建議 + 預估節省時間
重點看手機版的分數,因為 Google 用行動裝置優先索引。
Chrome DevTools
按 F12 → Network tab,可以看到每個資源的載入時間和大小。特別注意:
- 圖片:通常是最大的肥肉,佔總載入量 50-70%
- JavaScript:第三方腳本(分析、廣告、聊天工具)是常見的拖累
- 字型檔案:中文字型特別大,一個 Noto Sans TC 可以到 4-5MB
WebPageTest
比 PageSpeed Insights 更詳細。它可以模擬不同地區、不同網路速度的載入情況,還有「瀑布圖」讓你看到每個資源的載入順序。
這部分和[外部連結策略](/blog/backlink-building-strategy-2026)有直接關聯。第一步:圖片優化(效果最大,+15-25 分)
在網站速度優化的所有項目中,圖片壓縮幾乎是最值得做的第一步。一般網站的圖片佔總載入量超過一半,所以壓縮圖片的效果最明顯。
轉換格式:JPEG/PNG → WebP
WebP 是 Google 開發的圖片格式,壓縮率比 JPEG 好 25-35%,比 PNG 好 50-70%。現在所有主流瀏覽器都支援 WebP。
實際操作方式取決於你的網站架構:
- WordPress:安裝 ShortPixel 或 Imagify 外掛,自動轉換
- Next.js / React:用 sharp 套件在 build 時自動轉換
- 手動:用 squoosh.app 線上轉換
我們在站群遷移中用 sharp 自動處理:原本總共 8GB 的圖片壓到 2.3GB,省了 70%。
設定正確的圖片尺寸
這是很多人忽略的細節。如果你上傳一張 4000×3000 的原圖,瀏覽器需要下載完整檔案再縮小顯示。正確做法:
✅ 首屏大圖:最大寬度 1200px
✅ 文章內圖:最大寬度 800px
✅ 縮圖/卡片:最大寬度 400px
✅ 所有 <img> 標籤都要設 width 和 height 屬性
Lazy Loading(延遲載入)
讓非首屏的圖片等到使用者滾動到附近才載入。這大幅減少初始載入量。
<!-- 首屏圖片:不要 lazy load,用 fetchPriority -->
<img src="hero.webp" fetchpriority="high" width="1200" height="600" alt="...">
<!-- 非首屏圖片:加 lazy load -->
<img src="product.webp" loading="lazy" decoding="async" width="800" height="400" alt="...">
關鍵規則:首屏圖片不要加 loading="lazy",否則反而會拖慢 LCP。
第二步:JavaScript 和 CSS 瘦身(+5-15 分)
分析你的 JS Bundle
用 webpack-bundle-analyzer 或 next build --analyze 看你的 JavaScript 到底有多大、是什麼東西佔了空間。
常見的肥肉:
| 來源 | 典型大小 | 解決方案 |
|---|---|---|
| moment.js | 300KB+ | 換成 day.js(2KB) |
| lodash 全量引入 | 70KB+ | 改成 lodash-es 按需引入 |
| Google Analytics | 45KB | 換成 GA4 lite 或 Plausible |
| 聊天外掛 | 200KB+ | 改成點擊後才載入 |
| 字型檔案 | 2-5MB | 用 font-display: swap + subset |
Dynamic Import(動態載入)
把非首屏需要的元件改成動態載入。以 Next.js 為例:
// ❌ 首次載入就全部載入
import FloatingTOC from './FloatingTOC';
import ShareButtons from './ShareButtons';
// ✅ 使用者滾動到才載入
import dynamic from 'next/dynamic';
const FloatingTOC = dynamic(() => import('./FloatingTOC'));
const ShareButtons = dynamic(() => import('./ShareButtons'));
我們在站群模板中把 FloatingTOC 和 ReadingProgress 改成 dynamic import,First Load JS 從 98KB 降到 87KB。
移除沒在用的 CSS
用 PurgeCSS 或 Tailwind 的 JIT 模式,自動移除沒有用到的 CSS 樣式。Tailwind 的 JIT 在 build 時只產生你實際使用的 class,通常可以把 CSS 從 200KB+ 壓到 10-20KB。
第三步:字型優化(+5-10 分)
中文網站的字型問題特別嚴重,因為中文字型檔案比英文大 10-50 倍。
font-display: swap
讓瀏覽器先顯示系統字型,等到自訂字型載入完再切換。這可以避免「白畫面」的問題(Flash of Invisible Text)。
@font-face {
font-family: 'Noto Sans TC';
src: url('/fonts/NotoSansTC-Regular.woff2') format('woff2');
font-display: swap;
}
精簡字重
不要一口氣載入所有字重。大多數網站只需要 2 個字重就夠了:
✅ Regular (400) — 內文
✅ Bold (700) — 標題
❌ Medium (500) — 除非設計稿明確指定,否則不需要
❌ Light (300) — 中文在小字級下可讀性差,不建議
每少載一個字重,就少 200-500KB。
preconnect 提前建立連線
如果字型從 Google Fonts 或其他 CDN 載入,加 preconnect 可以提前建立 DNS + TLS 連線,省下 100-300ms:
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
這跟[長尾關鍵字](/blog/long-tail-keyword-strategy)的概念密切相關,建議一併了解。
第四步:伺服器和 CDN 優化(+5-10 分)
使用 CDN
CDN 把你的靜態檔案快取在全球各地的節點。台灣的使用者從台灣的節點拿資料,不用跑到美國的主機。
推薦方案(依成本排序):
- Cloudflare 免費方案 — 足夠大多數中小企業,我們 40+ 站全都用 Cloudflare
- Vercel / Netlify — 如果你用 Next.js 或 Jamstack 架構
- AWS CloudFront — 企業級,需要更多設定
開啟 Brotli 壓縮
Brotli 是比 Gzip 更好的壓縮演算法,壓縮率高 15-25%。Cloudflare 預設就有開啟 Brotli。
啟用 HTTP/2 或 HTTP/3
HTTP/2 支援多路複用(multiplexing),讓瀏覽器同時下載多個資源而不用排隊。HTTP/3 更進一步用 QUIC 協定,在不穩定的網路環境下表現更好。Cloudflare 可以一鍵開啟。
TTFB 優化
Time To First Byte(第一個位元組回應時間)是伺服器效能的基準。
- 好:< 200ms
- 可接受:200-600ms
- 需要改善:> 600ms
如果 TTFB 太高,考慮:
- 升級主機方案
- 加入頁面快取(WordPress 用 WP Super Cache 或 W3 Total Cache)
- 改用靜態網站架構(SSG / Static Export)
我們把 WordPress 站群遷移到 Next.js Static Export + Cloudflare Pages 之後,TTFB 從平均 800ms 降到 50ms 以下。
第五步:CLS 修復(+2-5 分)
CLS(Cumulative Layout Shift)衡量頁面的視覺穩定性。你有沒有遇過正要點按鈕,結果頁面突然跳動,點到了廣告?那就是高 CLS。
常見 CLS 問題和修復
| 問題 | 修復方式 |
|---|---|
| 圖片沒有設定尺寸 | 所有 <img> 加 width 和 height |
| 字型載入後版面跳動 | 使用 size-adjust 或 font fallback 尺寸匹配 |
| 動態插入的廣告 | 預留固定空間(min-height) |
| 延遲載入的內容區塊 | 用 skeleton loading 佔位 |
aspect-ratio 技巧
/* 用 aspect-ratio 預留圖片空間,防止載入時跳動 */
.article-image {
width: 100%;
aspect-ratio: 16 / 9;
object-fit: cover;
}
第六步:進階優化技巧
Critical CSS 內嵌
把首屏需要的 CSS 直接內嵌在 <head> 裡,其餘的 CSS 非同步載入。這可以讓首屏更快渲染。
Resource Hints
<!-- preload:一定會用到的關鍵資源 -->
<link rel="preload" href="/hero.webp" as="image">
<!-- prefetch:下一頁可能會用到的資源 -->
<link rel="prefetch" href="/next-page.js">
<!-- dns-prefetch:第三方域名提前解析 -->
<link rel="dns-prefetch" href="https://analytics.google.com">
Service Worker 離線快取
如果你的網站有重複訪客(例如部落格讀者),Service Worker 可以把已瀏覽的頁面快取在使用者裝置上,二次訪問幾乎是瞬間載入。
這跟[關鍵字研究](/blog/keyword-research-guide-2026)的概念密切相關,建議一併了解。優化順序建議:按 CP 值排列
網站速度優化的項目很多,如果你時間有限,按這個順序做:
| 順序 | 優化項目 | 預估效果 | 難度 | 時間 |
|---|---|---|---|---|
| 1 | 圖片壓縮 + WebP | +15-25 分 | 低 | 1-2 小時 |
| 2 | 圖片 lazy loading | +3-5 分 | 低 | 30 分鐘 |
| 3 | CDN 設定 | +5-10 分 | 低 | 1 小時 |
| 4 | 字型優化 | +5-10 分 | 中 | 1-2 小時 |
| 5 | JS dynamic import | +3-8 分 | 中 | 2-4 小時 |
| 6 | CLS 修復 | +2-5 分 | 中 | 1-3 小時 |
| 7 | Critical CSS | +2-3 分 | 高 | 3-5 小時 |
前 3 項只花 3 小時左右,就能拿到 20-40 分的提升。
常見錯誤:不要做這些事
-
不要開 Rocket Loader — Cloudflare 的 Rocket Loader 會延遲載入所有 JS,聽起來很好但會破壞 React / Vue 的 hydration,造成白畫面
-
不要過度壓縮圖片 — 壓到品質低於 60% 會明顯模糊,對品牌形象有害。建議壓縮品質 75-85%
-
不要一次載入所有第三方腳本 — Google Analytics、Facebook Pixel、聊天外掛、熱力圖工具 — 每個都是 40-200KB。評估哪些真的在用,沒在用的就移除
-
不要忽略手機版 — 桌機版 95 分但手機版 55 分是沒意義的。Google 用的是手機版分數
-
不要只看分數不看實際體驗 — PageSpeed 分數是參考,真正重要的是 Core Web Vitals 的實際數據(Field Data)
我們的實戰結果
在管理 40+ 個 SEO 站點的過程中,我們建立了一套標準化的速度優化流程:
| 優化前 | 優化後 | 主要手段 |
|---|---|---|
| 手機 55 分 | 手機 92 分 | 圖片 WebP + lazy load + CDN |
| LCP 4.2 秒 | LCP 1.8 秒 | Hero 圖 preload + 伺服器端快取 |
| CLS 0.25 | CLS 0.02 | 圖片尺寸固定 + font-display: swap |
| TTFB 800ms | TTFB 50ms | WordPress → Next.js Static Export |
從 WordPress 遷移到 Next.js Static Export + Cloudflare Pages 是效果最大的單一改變。靜態網站不需要伺服器端運算,每個頁面都是預先產生的 HTML 檔案,載入速度天生就快。
但如果你暫時不想換架構,光是做好前面列的網站速度優化 1-4 步,通常就能把分數從 50-60 拉到 80+。
想知道你的網站速度還有多少優化空間? 我們可以幫你做一次免費的 PageSpeed 健檢,告訴你最值得先做的 3 件事。免費諮詢 →
關於 Astrapath Marketing
我們是台灣的數位行銷團隊,專精 SEO、網站建置與 AI 行銷。目前管理超過 40 個 SEO 站點,橫跨美容、營造、餐飲、電商等 7 大產業,累計月搜尋流量超過 100 萬次。如果你正在尋找能真正落地執行的 SEO 夥伴,歡迎和我們聊聊。
FAQ
專精 SEO、網站建置與 AI 行銷。管理超過 40 個 SEO 站點,橫跨 7 大產業,累計月流量 100 萬+。