首頁/SEO 知識教學/SEO 知識教學
C1

網站速度優化指南：PageSpeed 從 60 分拉到 95+ 的實戰方法

網站速度影響 SEO 排名和轉換率。從圖片壓縮到程式碼優化，教你把 PageSpeed 分數拉到 95+。

✦
Astrapath Team
2026.03.0111 min read2,800 字
// TL;DR — 3 個重點帶著走
1網站速度優化的 CP 值排序：圖片壓縮（+15-25 分）> JS/CSS 瘦身（+5-15 分）> CDN 和快取（+5-10 分）
2Core Web Vitals 三指標：LCP < 2.5 秒、INP < 200ms、CLS < 0.1 — 這是 Google 排名的硬門檻
3最快見效的三步：圖片轉 WebP + lazy loading + 開啟 CDN — 3 小時內就能拉 20+ 分

你有沒有遇過這種情況：打開一個網站，轉圈圈轉了 3 秒，你就按了返回鍵？

你的潛在客戶也是這樣對待你的網站的。

Google 的研究數據很直接 — 網頁載入時間從 1 秒增加到 3 秒，跳出率上升 32%。從 1 秒到 5 秒？跳出率暴增 90%。每多等一秒，你就多流失將近三分之一的訪客。

更直接的影響是排名。Google 在 2021 年把 Core Web Vitals 正式納入排名因素，速度已經從「加分項」變成了「門檻」。速度不達標，其他 SEO 做得再好都會被拉低。

我們在管理超過 40 個 SEO 站點的過程中，親手把好幾個站的 PageSpeed 分數從 50-60 拉到 90+。這篇把最有效的優化手法整理出來，按照「CP 值」排序 — 讓你用最少的時間拿到最大的效果。

如果你對 SEO 的整體概念還不太熟，建議先看我們的[SEO 入門指南](/blog/seo-beginner-guide-2026)。

Core Web Vitals：Google 看的三個指標

在動手優化之前，先搞清楚 Google 到底在測量什麼。Core Web Vitals 有三個核心指標：

指標 全名 衡量什麼 通過標準 不及格標準
LCP Largest Contentful Paint 頁面最大元素的載入時間 < 2.5 秒 > 4.0 秒
INP Interaction to Next Paint 使用者操作後的反應速度 < 200ms > 500ms
CLS Cumulative Layout Shift 頁面元素跳動的程度 < 0.1 > 0.25

用白話講：

  • LCP — 你的頁面主要內容多快出現？（通常是 Hero 圖片或標題區塊）
  • INP — 使用者點按鈕後，畫面多快回應？
  • CLS — 頁面載入過程中會不會亂跳？（最惱人的是你要點某個按鈕，結果頁面突然位移，點到了別的東西）

這三個指標不只影響排名，也直接影響轉換率。我們實際觀察過一個美容品牌站，PageSpeed 從 55 分優化到 92 分之後，自然搜尋流量在 6 週內增加了 23%，詢問表單的填寫率也上升了 15%。

先測量再動手：找出你的問題在哪

盲目優化是浪費時間。先用工具診斷問題，再針對最大的瓶頸下手。

PageSpeed Insights

最直接的工具。打開 PageSpeed Insights，輸入你的網址。它會告訴你：

  • 手機版和桌機版的分數
  • Core Web Vitals 的實際數據
  • 每個問題的具體描述和預估可節省的時間

重點看手機版分數，因為 Google 用行動版優先索引。很多網站桌機版 90+ 但手機版只有 50-60，這是沒意義的 — Google 看的是手機版。

Chrome DevTools

按 F12 打開開發者工具，切到 Network 頁籤。重新載入頁面，你可以看到每個資源的載入時間和檔案大小。

重點關注三個肥肉：

  • 圖片 — 通常佔總載入量的 50-70%，是最大的優化空間
  • 第三方 JavaScript — Google Analytics、Facebook Pixel、聊天外掛，每個 40-200KB
  • 中文字型 — 一套 Noto Sans TC 可以到 4-5MB，非常恐怖

WebPageTest

比 PageSpeed Insights 更進階。可以模擬不同地區、不同網路速度、不同裝置的載入情況。它的「瀑布圖」會清楚顯示每個資源的載入順序和阻塞關係。

第一優先：圖片優化（效果最大，+15-25 分）

如果你的時間有限只能做一件事，做這個。圖片壓縮是所有優化項目中 CP 值最高的。

格式轉換：JPEG/PNG 轉 WebP

WebP 是 Google 開發的圖片格式，同品質下體積比 JPEG 小 25-35%，比 PNG 小 50-70%。一張 500KB 的 JPEG 轉 WebP 可能只剩 150KB。你的網站如果有 20 張圖片，光這一步就能省下好幾 MB。

操作方式看你的技術架構：

  • WordPress — 裝 ShortPixel 或 Imagify 外掛，上傳圖片時自動轉換
  • Next.js — 用內建的 next/image 元件，自動產生 WebP 並根據裝置調整尺寸
  • 手動 — 用 squoosh.app 線上轉換，免費且好用

我們在站群裡用 sharp 套件做自動處理，原本合計 8GB 的圖片壓到 2.3GB，節省了超過 70%。

設定正確的圖片尺寸

這個細節很多人忽略。上傳一張 4000x3000 的原圖，瀏覽器得下載完整檔案再縮小顯示。正確做法：

  • 首屏大圖（Hero）：最大寬度 1200px
  • 文章內圖：最大寬度 800px
  • 縮圖和卡片圖：最大寬度 400px
  • 所有 <img> 標籤都要設定 width 和 height 屬性（這也能避免 CLS 問題）

Lazy Loading（延遲載入）

非首屏的圖片不需要在頁面一打開就載入。加上 loading="lazy" 屬性，瀏覽器會等使用者滾動到附近才載入。

<!-- 首屏圖片：不要 lazy load，反而要優先載入 -->
<img src="hero.webp" fetchpriority="high" width="1200" height="600" alt="...">

<!-- 非首屏圖片：延遲載入 -->
<img src="product.webp" loading="lazy" decoding="async" width="800" height="400" alt="...">

注意：首屏圖片千萬不要加 loading="lazy"。這會讓 LCP 的主角延遲載入，分數反而更低。

第二優先：JavaScript 和 CSS 瘦身（+5-15 分）

找出你的 JS 到底有多肥

用 webpack-bundle-analyzer 或 Next.js 的 next build --analyze 看你的 JavaScript bundle 組成。

常見的肥肉和解法：

來源 典型大小 解決方案
moment.js 300KB+ 換成 day.js（只有 2KB）
lodash 全量引入 70KB+ 改成 import get from 'lodash-es/get' 按需引入
聊天外掛 200KB+ 改成使用者點擊後才載入
Google Analytics 45KB 考慮改用更輕量的分析工具
中文字型 2-5MB 用 font-display: swap + 精簡字重

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'));

我們在站群模板裡把非關鍵元件改成 dynamic import 後，First Load JS 從 98KB 降到 87KB。11KB 看起來不多，但在手機 3G 網路下就是 0.3-0.5 秒的差距。

移除沒在用的 CSS

如果你用 Tailwind CSS，JIT 模式會在 build 時只產生你實際使用到的 class。一般的 CSS 框架可能有 200KB+，經過 JIT 處理後通常只剩 10-20KB。

沒用 Tailwind 的話，可以用 PurgeCSS 做類似的事。

第三優先：字型優化（+5-10 分）

中文網站的字型問題特別頭痛。英文字型只有 26 個字母，檔案通常 20-50KB。中文字型有上萬個字，一套字型動輒 2-5MB。

font-display: swap

先用系統字型顯示文字，等自訂字型載入完再切換。避免使用者看到「一片空白等字型載入」的情況。

@font-face {
  font-family: 'Noto Sans TC';
  src: url('/fonts/NotoSansTC-Regular.woff2') format('woff2');
  font-display: swap;
}

只載入需要的字重

大多數網站只需要兩個字重：Regular（400）用在內文，Bold（700）用在標題。每少載一個字重就省 200-500KB。

preconnect 提前建立連線

如果字型從外部 CDN（如 Google Fonts）載入，加 preconnect 可以提前建立連線，省下 100-300ms：

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

第四優先：伺服器和 CDN 優化（+5-10 分）

CDN：讓使用者從最近的節點拿資料

CDN（Content Delivery Network）把你的靜態檔案快取在全球各地的節點。台灣的使用者從台灣的節點拿資料，不用跑到美國的主機房。

推薦方案：

方案 費用 適合
Cloudflare 免費方案 免費 大多數中小企業，我們 40+ 站全用 Cloudflare
Vercel 免費額度充足 用 Next.js 的團隊
AWS CloudFront 依用量計費 大型企業、高流量站

TTFB 優化

Time To First Byte — 伺服器回應第一個位元組的時間。

  • 好：< 200ms
  • 可接受：200-600ms
  • 需要改善：> 600ms

TTFB 太高的解法：升級主機、加入頁面快取、或改用靜態網站架構。

我們把客戶的 WordPress 站群遷移到 Next.js Static Export + Cloudflare Pages 之後，TTFB 從平均 800ms 降到 50ms 以下。靜態網站不需要伺服器端運算，每個頁面都是預先產生好的 HTML，速度天生就快。這也是為什麼我們選擇 Next.js + Cloudflare CDN 作為技術堆疊 — 從架構層面就解決了速度問題。

開啟 Brotli 壓縮

Brotli 比 Gzip 的壓縮率高 15-25%。Cloudflare 預設就有開啟，如果你的伺服器還在用 Gzip，建議切換到 Brotli。

技術 SEO 還有很多細節可以優化，完整清單請參考[技術 SEO 檢查清單](/blog/technical-seo-checklist-2026)。

第五優先：CLS 修復（+2-5 分）

CLS 是三個指標中最容易被忽略、但也最容易修的。

常見的 CLS 問題和修法：

問題 修復方式
圖片沒有設定尺寸 所有 <img> 加 width 和 height 屬性
字型載入後版面跳動 用 font-display: swap + 設定 fallback 字型的 size-adjust
動態插入的廣告或橫幅 預留固定高度（min-height）
延遲載入的內容區塊 用 skeleton loading 佔位

一個特別好用的 CSS 技巧：

.article-image {
  width: 100%;
  aspect-ratio: 16 / 9;
  object-fit: cover;
}

用 aspect-ratio 預留圖片空間，即使圖片還沒載入完，版面也不會跳動。

優化順序總覽：按 CP 值排列

順序 優化項目 預估效果 難度 時間
1 圖片壓縮 + 轉 WebP +15-25 分 低 1-2 小時
2 圖片 lazy loading +3-5 分 低 30 分鐘
3 CDN 設定（Cloudflare） +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 小時，就能拿到 20-40 分的提升。這是最佳的投入產出比。

我們的實戰結果：Before vs After

在管理 44 個 SEO 站點的過程中，我們建立了一套標準化的速度優化流程。以下是實際數據：

指標 優化前 優化後 主要做了什麼
手機版 PageSpeed 55 分 92 分 圖片 WebP + lazy load + CDN
LCP 4.2 秒 1.8 秒 Hero 圖 preload + 伺服器快取
CLS 0.25 0.02 圖片尺寸固定 + font-display: swap
TTFB 800ms 50ms WordPress 遷移到 Next.js Static Export
INP 350ms 120ms 減少第三方 JS + dynamic import

最大的單一改變是從 WordPress 遷移到 Next.js Static Export + Cloudflare Pages。靜態網站從根本上消除了伺服器端運算的瓶頸。

但如果你暫時不打算換架構，也不用擔心。光是把前面列的第 1-4 步做好（圖片、lazy load、CDN、字型），通常就能把分數從 50-60 拉到 80+。

五個常見的速度優化陷阱

  1. 不要開 Cloudflare 的 Rocket Loader — 聽起來很好，但它會延遲載入所有 JS，會破壞 React 和 Vue 的 hydration 機制，導致白畫面

  2. 不要過度壓縮圖片 — 品質低於 60% 會明顯模糊，傷害品牌形象。建議壓縮品質設在 75-85%

  3. 不要堆疊一堆第三方腳本 — GA4、Facebook Pixel、熱力圖、聊天工具、彈出視窗... 每裝一個就多 40-200KB。誠實問自己：你真的有在看這些數據嗎？沒用的就移除

  4. 不要只看桌機版分數 — 桌機 95 分但手機 55 分是沒意義的。Google 用的是手機版分數來決定排名

  5. 不要只追分數忽略真實數據 — PageSpeed 的「Lab Data」是模擬數據，「Field Data」才是真實使用者的體驗。如果你的 Field Data 三個指標都是綠色，即使總分沒有 95，也不用太焦慮

做好速度優化之後，下一步可以研究[外部連結策略](/blog/backlink-building-strategy-2026)來提升網站權威度。

常見問題

Q: 網站速度對 SEO 影響有多大？

A: 影響明確。Google 把 Core Web Vitals 納入排名因素。速度慢不只直接扣分，還間接導致跳出率升高、停留時間降低，這些使用者行為信號也會拖累排名。

Q: PageSpeed 分數多少算及格？

A: 沒有官方及格線。手機版 90+ 是優秀，70-89 需要改善，70 以下會影響排名。建議以手機版 85+ 為目標。

Q: 不會寫程式也能優化網站速度嗎？

A: 可以。最有效的三件事 — 圖片壓縮、CDN、快取 — 都不需要寫程式。WordPress 裝好 ShortPixel + WP Super Cache + Cloudflare 就能處理八成的問題。

Q: WordPress 網站速度特別慢怎麼辦？

A: 三個最常見的原因：外掛太多（控制在 15 個以內）、沒有快取（裝快取外掛）、圖片沒壓縮（裝 ShortPixel）。做完這三件事通常能提升 15-25 分。

開始行動

網站速度優化不需要一次做完。今天先做圖片壓縮和 CDN 設定，明天處理字型，下週再看 JavaScript。按照上面的 CP 值排序，一步一步來。

如果你不確定自己的網站速度問題出在哪裡，或是想知道還有多少優化空間，我們可以幫你做一次 PageSpeed 診斷 — 告訴你最值得先做的三件事。

看完還有疑問？我們的 SEO 顧問可以幫你解答 預約諮詢 →

關於 Astrapath Marketing

我們是台灣的數位行銷團隊，專精 SEO、網站建置與 AI 行銷。目前管理超過 40 個 SEO 站點，橫跨美容、營造、餐飲、電商等 7 大產業，累計月搜尋流量超過 100 萬次。如果你正在尋找能真正落地執行的 SEO 夥伴，歡迎和我們聊聊。

FAQ

影響明確但不是唯一因素。Google 在 2021 年把 Core Web Vitals 納入排名因素，速度太慢會直接扣分。但更大的影響是間接的 — 速度慢導致跳出率升高、停留時間降低，這些使用者行為信號也會拉低排名。

// NEXT STEP
想讓你的品牌被更多人搜到？

我們管理超過 40 個 SEO 站點，累計月流量 100 萬次。

SHARE
✦
ASTRAPATH Marketing

專精 SEO、網站建置與 AI 行銷。管理超過 40 個 SEO 站點，橫跨 7 大產業，累計月流量 100 萬+。

// 推薦閱讀
C1
外部連結怎麼做？2026 白帽 Backlink 策略完整教學
11 min read
C1
關鍵字研究完整教學：從零找到高價值搜尋字
12 min read
C1
長尾關鍵字策略：用低競爭字累積大流量的方法
10 min read