行動版的 1 秒 是訪客一輩子的耐心

技術主題:Web Performance / Lighthouse / Core Web Vitals
實作時間:2026/04
工時估計:約 8 小時
紀錄者:_YLin_Lai
參考資料: https://pagespeed.web.dev/, https://web.dev/vitals/

1.主題

本篇主題同詩意副標 — 行動版的 1 秒,是訪客一輩子的耐心。我的 freelance 站台第一次跑 PageSpeed mobile,跳出 50 分,LCP 4.2 秒,FCP 3.7 秒,CLS 0.31。客戶從 IG 點過來,在第 1 秒看不到任何東西,他不會等到第 4 秒。這篇是我用 1 個下午把分數推到 85 分的全紀錄,涵蓋圖片、字型、CSS、外掛、cache 五個維度。

2.背景(需求簡介)

PageSpeed 分數會出現在 Google Search Console、客戶搜尋自己網站的結果旁邊、行動版 Safari/Chrome 的「載入緩慢請等候」提示。它不是學院派的數字遊戲,它直接影響三件事 — SEO ranking、客戶第一眼印象、conversion rate。

Akamai 早年有一份研究 — 網站慢 1 秒,conversion rate 掉 7%。這個數字後來在 Amazon、Walmart、Pinterest 各自的內部研究裡都被驗證過。對 freelance 站台這種「客戶從社群點來,要 30 秒內決定要不要 /contact/」的場景,這 7% 是命門。

Google 的 Core Web Vitals 把 web performance 拆成三個核心指標 ──

LCP (Largest Contentful Paint):首屏最大元素的載入時間,< 2.5s 是 good。 FCP (First Contentful Paint):首個內容元素出現的時間,< 1.8s 是 good。 CLS (Cumulative Layout Shift):頁面載入過程中,元素位置跳動的累積量,< 0.1 是 good。

我的 baseline:LCP 4176ms ❌、FCP 3742ms ❌、CLS 0.31 ❌、TTFB 1262ms ❌、PageSpeed mobile 50 分。每一項都不及格。

3.使用技術

PHP GD:WordPress 內建的影像處理庫,支援 resize、palette quantization、WebP 輸出。我用它把 LOGO 從 892KB 壓到 33KB。

WP Super Cache:全站 page caching plugin。把 WP 動態渲染的 HTML 存成靜態檔案,訪客打到的就是純 HTML,不會穿透到 PHP / MySQL。TTFB 神器。

Google Fonts subset:不載整套字型,只載你網站真的用到的字符範圍 + 字重。Noto Sans TC 一個 weight 約 700KB,4 weights 就吃 2.8MB。

Critical CSS:把首屏會用到的 CSS(約 3KB)inline 進 <head>,其他非首屏 CSS 用 media="print" onload="this.media='all'" 模式做 deferred loading。

wp_dequeue_style / wp_deregister_script:WordPress 提供的 hook,可以從外掛 enqueue 的 asset list 裡把不需要的拔掉。Elementor、Astra Sites 這類大型 plugin 即使沒有實際用到頁面,也會 enqueue 自己的 CSS / JS。

4.心得

8 小時的優化分三條故事講。

第一條:LOGO 一張就吃 892KB

Lighthouse 報告第一行寫著 Properly size images — Estimated savings 1.4 s,我點開看,99% 的浪費來自一個檔案 — logo3.png,892KB,3072×3072 解析度,透明背景。

3072×3072 是手機螢幕物理像素的 5-6 倍,網站 header 顯示尺寸只有 88px。也就是說,我把一張可以放滿一面牆的圖,壓進一個小到看不見的 header,中間經過手機 4G 慢速網路 1.8 秒。

解法是寫一個 PHP GD 腳本:

$src = imagecreatefrompng('logo3.png');
$dst = imagecreatetruecolor(600, 600);
imagecolortransparent($dst, imagecolorallocatealpha($dst, 0,0,0,127));
imagealphablending($dst, false);
imagesavealpha($dst, true);
imagecopyresampled($dst, $src, 0,0,0,0, 600,600, 3072,3072);
imagetruecolortopalette($dst, false, 256);
imagepng($dst, 'logo.png', 9);

resize 到 600×600 + 8-bit palette quantization(從 32-bit 全彩降到 256 色)= 33KB。差 27 倍。

圖片不是背景
它是 LCP 本身
它就是訪客記得的第一個畫面

LCP 從 4176ms 直接掉到 2400ms,單一個改動。

第二條:Google Fonts 是隱形殺手

第二個 Lighthouse 警告是 Reduce unused CSS — Estimated savings 0.8s,點開看,主要來自 Google Fonts 載的 4 個 weight 的 Noto Sans TC。

中文字型跟英文字型不一樣 — 英文 Latin 一個 weight 約 50KB,中文 CJK Han 一個 weight 約 700KB,因為要塞 8000+ 個常用漢字。我同時載 300/400/500/700 四個 weight = 2.8MB,等於每個訪客第一次來都要先下載一本電子書。

我把網站實際用到的 weight 統計了一遍 ──

body / nav / footer 大部分文字:400(regular)
H1 / H2 / strong / 重點 CTA:600(semibold)

只有兩個。把 Google Fonts 的 link 從 wght@300;400;500;700 砍到 wght@400;600,省 1.4MB。

設計師說「我要 5 個粗細隨時切換」
工程師心裡想的是
5 個粗細 = 訪客多等 3 秒

外加 font-display: swap 屬性,讓字型還沒載完時用 fallback font 先撐住版面 — FCP 從 3742ms 降到 1900ms。

第三條:WebP 嘗試失敗的故事

我以為 WebP 會是 silver bullet。它比 PNG 小 30-50%,Chrome / Edge / Firefox / Safari 14+ 全部支援,規格上沒有理由不用。

我把 LOGO 從 PNG 改 WebP,部署上線。Safari 顯示正常,Chrome 顯示正常,但用某些舊版 Edge / 公司鎖定 IE compatibility 模式的瀏覽器,LOGO 變成破圖,旁邊顯示一個小小的「此圖片無法顯示」icon。

第一個原因是 IIS 預設不認識 .webp 副檔名,要在 web.config 加:

<staticContent>
  <mimeMap fileExtension=".webp" mimeType="image/webp" />
</staticContent>

加完之後大部分瀏覽器正常,但 Safari 17.x 在某些情況下對「PHP GD 產生的 transparent WebP」會顯示異常 — 同樣的 WebP 用 cwebp CLI 產的就正常,但用 PHP GD 產的就壞。我花了 2 小時 debug,最後發現是 GD 的 WebP encoder 在某個 alpha channel 細節上跟 Safari 的 decoder 不對盤。

想了想,revert 回 PNG。LOGO 已經壓到 33KB,WebP 再省也省不了多少了,不值得為了 5KB 跟 Safari 兼容性玩躲貓貓。

不是每個優化都該被做
有些工具對於你的環境
本身就是個 mismatch

如果你的圖片很多 / 很大,WebP 的 ROI 才會值得弄這個整合。對我這種「就一張 LOGO + 幾張 case study 縮圖」的小站,PNG / JPEG 已經夠了。

結語:

最終分數 ── PageSpeed mobile 從 50 → 85,LCP 從 4176ms → 1850ms,FCP 從 3742ms → 1100ms,CLS 從 0.31 → 0.04,TTFB(裝完 WP Super Cache 後)從 1262ms → 220ms。

「行動版的 1 秒是訪客一輩子的耐心」這句副標想說的,是 web performance 不是「跑分遊戲」,是替訪客省下他原本不會給你的時間。客戶從 IG 點來,他並沒有承諾要等你 4 秒,他只是給了你 1 秒的試用期。1 秒內看不到任何東西,他就回上一頁。

對工程師讀者 — 上面三條(圖片 / 字型 / WebP)是 80% 案例的 80% 痛點。對客戶讀者 — 你的站台慢嗎?我能 audit + 優化,不換主機、不換 CMS,單純把現有的東西調對。

彩蛋:Before / After 數據對照

指標	Before	After	改善幅度
TTFB	1262 ms	220 ms	-82.6%
FCP	3742 ms	1100 ms	-70.6%
LCP	4176 ms	1850 ms	-55.7%
CLS	0.31	0.04	-87.1%
PageSpeed mobile	50	85	+35
LOGO 檔案大小	892 KB	33 KB	-96.3%
Google Fonts 總量	2.8 MB	1.4 MB	-50.0%

8 小時 = 1 個下午 + 1 杯咖啡 + 2 杯水。投資報酬率高得不像話。

真的快自己看都覺得爽 σ`∀´)σ

1.主題

2.背景(需求簡介)

3.使用技術

4.心得

結語:

相關紀錄

彩蛋:Before / After 數據對照