為什麼網站速度這麼重要

Google 的研究數據清楚顯示速度和用戶行為的關係：

頁面載入時間從 1 秒增加到 3 秒，跳出率增加 32%
從 1 秒到 5 秒，跳出率增加 90%
從 1 秒到 10 秒，跳出率增加 123%

對電商網站，Amazon 曾分析：頁面速度每改善 100ms，收入增加 1%。

對服務業官網，速度慢意味著訪客在真正看到你的服務說明和 CTA 之前就離開了——你的設計和內容根本沒有機會發揮作用。

2021 年，Google 正式將 Core Web Vitals 納入搜尋排名算法，速度和用戶體驗成為 SEO 的直接因素。

如何測量你的網站速度

在優化之前，先了解現況。幾個免費工具：

Google PageSpeed Insights（pagespeed.web.dev）：輸入你的 URL，會得到 Mobile 和 Desktop 兩個分數，以及具體的優化建議，並細分 Core Web Vitals 指標。

GTmetrix（gtmetrix.com）：更詳細的瀑布圖分析，顯示每個資源的載入時間。

重點關注的 Core Web Vitals 指標：

LCP（最大內容繪製）：頁面上最大的可見元素（通常是 Hero 圖片或標題）載入完成的時間。目標：< 2.5 秒
CLS（累積版面偏移）：頁面元素在載入過程中移動的累積量（影響用戶閱讀體驗的「跳來跳去」）。目標：< 0.1
INP（互動到下一次繪製）：用戶點擊後頁面反應的速度。目標：< 200ms

方法 1：圖片優化（最高效的單一改善）

圖片通常是網頁最重的資源，也是最容易優化的地方。

壓縮圖片

上傳之前先壓縮。免費工具：

Squoosh（squoosh.app）：由 Google 開發，支援多種格式，可以直觀比較壓縮前後
TinyPNG/TinyJPG（tinypng.com）：拖放就能批次壓縮

目標：一般展示用圖片控制在 100-300KB，Hero 大圖盡量不超過 500KB。

使用現代圖片格式

WebP 格式比 JPEG 小 25-35%，比 PNG 小 80%，同時保持接近的畫質。現代瀏覽器（Chrome, Edge, Firefox, Safari 14+）都支援。

在 Next.js 中，使用元件（來自 next/image）會自動將圖片轉換為 WebP 格式並進行懶載入，這是 Next.js 對 Core Web Vitals 的一大貢獻。

Lazy Loading（延遲載入）

只有在用戶滾動到圖片附近時才載入圖片，而不是一進入頁面就載入所有圖片。

HTML 原生支援：

Next.js 的 Image 元件預設就是 lazy loading（但 Hero 區的關鍵圖片應設為 priority，避免 LCP 因延遲載入而惡化）。

方法 2：字型優化

自定義字型是常見的效能瓶頸，尤其是 Google Fonts 的傳統載入方式。

使用 next/font 或 font-display: swap

在 Next.js App Router 中，使用 next/font 模組載入 Google Fonts，它會在建構時預載字型並自動優化字型顯示策略：

import { Noto_Sans_TC } from 'next/font/google'

const notoSansTC = Noto_Sans_TC({
  subsets: ['latin'],
  display: 'swap',
})

display: 'swap' 讓瀏覽器先用系統字型渲染文字，自定義字型載入完成後再換上去——用戶不會看到「空白文字」的 FOIT（Flash of Invisible Text）問題。

只載入需要的字重

不要引入一個字型家族的所有字重，只引入你實際使用的：

400（Regular）
500（Medium）
700（Bold）

每增加一個字重，就增加一個字型檔案的下載。

方法 3：減少無用的 JavaScript

JavaScript 是影響頁面互動性能（INP）和整體載入速度最重要的因素。

分析 JS Bundle 大小

Next.js 可以使用 @next/bundle-analyzer 視覺化分析你的 JavaScript bundle：

ANALYZE=true npm run build

這會生成一個互動地圖，顯示哪些套件佔用了最多空間。常見的大型套件（如 moment.js、lodash 完整版）往往可以替換為更輕量的替代品（dayjs、lodash-es 加上 tree-shaking）。

Server Components 優先

Next.js App Router 的 RSC（React Server Components）讓元件在伺服器端渲染，不包含在客戶端 JS bundle 中。盡量讓沒有互動需求的元件保持為 Server Components（不加 'use client'），只對確實需要瀏覽器 API 或互動的元件使用 Client Components。

方法 4：正確的快取策略

Static Generation + CDN 快取

對不常變動的頁面（關於我們、服務說明），使用靜態生成（Static Generation）配合 CDN 邊緣節點快取，可以達到毫秒級的全球響應速度。

ISR（增量靜態再生）

需要定期更新但不需要即時的頁面（如部落格文章），使用 ISR：

export const revalidate = 3600 // 每小時最多重新生成一次

圖片和字型資源快取

確認你的主機或 CDN 有設定正確的 Cache-Control 標頭，讓靜態資源（圖片、字型、CSS）在瀏覽器端有長期快取（至少 1 年）。

方法 5：選擇正確的主機

最後，不管你怎麼優化代碼，糟糕的主機基礎設施都會拖累你。

Vercel（Next.js 官方推薦主機）：對 Next.js 有原生優化，全球 CDN 部署，App Router 的所有功能都有完整支援。免費方案已足夠個人工作室使用。

台灣主機的考量：如果你的用戶主要在台灣，選擇有台灣或亞洲資料中心的主機（AWS ap-northeast-1 東京區、GCP asia-east1 台灣區）比使用美國資料中心快很多。延遲從可能的 200ms+ 降到 30-50ms 級別。

速度優化不需要一次全部做完。按照影響評估，從最高 ROI 的改善開始（通常是圖片優化），循序漸進地提升你的 Core Web Vitals 分數。

網站速度優化實戰：5 個馬上可以做的改善方法