直接答你：網站慢一秒，查詢就少一截。要在手機上快兩秒，最有效的次序是——先修圖片（影響 LCP 最大）、再修 JavaScript（影響 INP）、最後修伺服器與字型。Google 的三項達標門檻是 LCP ≤ 2.5 秒、INP ≤ 200 毫秒、CLS ≤ 0.1，全部以真實 Chrome 用戶第 75 百分位、28 日滾動數據計算。現實是全球只有約 55.9% 網站三項同時達標，手機端失分尤其普遍。而最快見效的單一動作通常只有兩件事：把大圖轉成 AVIF 或 WebP（相對 JPEG 平均減 50% 與 31.5% 體積），以及把聊天視窗與追蹤腳本改成互動後才載入。這兩項在大部分香港中小企網站上，一個下午就做得完。
先記住這些數字
- 達標門檻：LCP ≤ 2.5 秒｜INP ≤ 200 毫秒｜CLS ≤ 0.1（2026 年門檻未變）
- 量度方式：真實用戶（CrUX）第 75 百分位、28 日滾動窗，三項同時達標才算通過
- 全球僅約 55.9% 網站三項同時達標（2026 年 5 月 CrUX）
- 圖片體積：AVIF 相對 JPEG 中位數減 50.3%；WebP 減 31.5%；AVIF 比 WebP 再細 20–30%
- 瀏覽器支援：WebP 約 97–98%；AVIF 約 92–93%
- 編碼速度：AVIF 比 WebP 慢 5–20 倍，所以「一次編碼長期供應」才適合用 AVIF
scheduler.yield()是 2026 年修 INP 最重要的 API：Chrome 2024 起、Firefox 2025 年 8 月起支援，Safari 未支援
三項指標與達標門檻
| 指標 | 量度什麼 | 良好 | 需改善 | 不佳 | 主要瓶頸 |
|---|---|---|---|---|---|
| LCP | 最大可見元素渲染完成的時間 | ≤ 2.5 秒 | 2.5 – 4 秒 | > 4 秒 | 伺服器回應慢、大圖未壓縮、阻斷渲染的 CSS／JS |
| INP | 整頁互動中最慢那一次的回應時間 | ≤ 200 毫秒 | 200 – 500 毫秒 | > 500 毫秒 | 主執行緒被長任務佔用、第三方腳本、過重的事件處理 |
| CLS | 非預期版面位移的累計分數 | ≤ 0.1 | 0.1 – 0.25 | > 0.25 | 圖片無尺寸、字型載入推擠、動態插入的橫幅與廣告 |
三個關鍵理解，很多人第一次看會誤會：
- 用真實用戶數據評分，不是用你的電腦。你在辦公室光纖上測到 1 秒，不代表客人在地鐵 4G 上也是 1 秒。
- 用第 75 百分位。即是說有四分之一用戶的體驗比這個數字更差，你仍然要達標——所以要照顧最慢那批裝置。
- 三項要同時達標。LCP 1.8 秒但 CLS 0.3，整頁仍然算不通過。
先量度：五步診斷流程
不要憑感覺改。以下次序能在 30 分鐘內找出真正的瓶頸。
- PageSpeed Insights：輸入網址，先看上半部「實際使用者體驗」（真實用戶 CrUX 數據），這才是 Google 用來評分的；下半部「診斷效能問題」（Lighthouse 實驗室數據）只是找問題的線索。兩者不一致時，以真實數據為準。
- Search Console 的 Core Web Vitals 報告：看哪一組網址（而非單一頁）出問題。同類型頁面會被歸為一組，修一頁等於修一批。
- Chrome DevTools 的 Performance 面板：開啟 CPU 4x 節流與 Fast 4G 節流模擬手機，錄製一次載入，找出哪個資源阻塞了渲染。
- Web Vitals 擴充功能或 LoAF API：實際點擊頁面上的按鈕、選單、表單，看哪一次互動觸發了長任務（Long Animation Frame）。INP 問題永遠要靠真實互動才找得到。
- 對照裝置分佈：在 GA4 看你的手機機型與網絡分佈。如果大部分客人用中低階 Android，用 iPhone 15 測試會令你嚴重低估問題。
圖片：做法 1 – 3（影響 LCP 最大）
絕大部分香港中小企網站的 LCP 問題，八成出在首屏那張大圖。先處理這裡，投入產出比最高。
做法 1：改用 AVIF 或 WebP
兩種格式的實測差異如下（以同等視覺品質、SSIM 對齊計算）：
| 格式 | 相對 JPEG 的體積 | 瀏覽器支援 | 編碼速度 | 建議用途 |
|---|---|---|---|---|
| JPEG | 基準 100% | 100% | 最快 | 最後備援 |
| WebP | 中位數減約 31.5% | 約 97–98% | 快 | 預設格式；動態生成、即時裁切的圖片 |
| AVIF | 中位數減約 50.3% | 約 92–93% | 比 WebP 慢 5–20 倍 | 首屏大圖、商品主圖等「編碼一次、長期供應」的圖片 |
實際數字感受一下：一張 1MB 的 JPEG 相片，轉 WebP 約 700KB，轉 AVIF 約 500KB。一個有 10 張圖的頁面，換 WebP 平均省約 900KB，換 AVIF 約省 1.5MB——這在 4G 網絡上就是幾秒的分別。
實務建議：靜態資源用 AVIF 主供、WebP 後備、JPEG 最後；動態生成或每次請求即時裁切的圖片只用 WebP（因為 AVIF 編碼太慢，會拖慢伺服器）。做法是用 <picture>：
<picture>
<source srcset="/img/hero.avif" type="image/avif">
<source srcset="/img/hero.webp" type="image/webp">
<img src="/img/hero.jpg" alt="香港網頁設計公司辦事處"
width="1600" height="900" fetchpriority="high" decoding="async">
</picture>
另外兩件常被忽略的事：一是不要供應超過顯示尺寸的圖片——手機顯示 400px 寬卻下載 2400px 原圖，是最常見的浪費，用 srcset 與 sizes 處理。二是壓縮品質設 75–80 已經足夠，肉眼看不出分別。
做法 2：為每張圖片指定 width 與 height
沒有尺寸的圖片，瀏覽器要等圖片下載完才知道要留多少空間，中間的內容跳動就是 CLS 扣分的主因。
兩種正確做法：在 HTML 直接寫 width 與 height 屬性（數值為原始像素，CSS 仍可用 max-width:100%; height:auto 控制顯示），或在 CSS 用 aspect-ratio。同樣邏輯適用於 iframe、廣告位、動態載入的橫幅——所有會後來才出現的元素，都要先預留空間。
做法 3：首屏主圖用 fetchpriority，其餘才 lazy load
這一項最多人做錯，而且是反效果：把首屏的 LCP 圖片設成 loading="lazy"，會令 LCP 明顯變差，因為瀏覽器會延後下載這張最重要的圖。
正確分工：
- 首屏 LCP 圖片：
fetchpriority="high"，不加 lazy load，並在<head>加<link rel="preload" as="image"> - 首屏以下的圖片：
loading="lazy"加decoding="async" - 純裝飾的背景圖：考慮用 CSS 漸變或 SVG 取代
還有一個常見陷阱：如果 LCP 元素是靠 JavaScript 掛載出來的（例如輪播圖用 JS 初始化），瀏覽器無法及早發現這張圖，LCP 一定慢。首屏應該由伺服器直接輸出 HTML，不要依賴前端框架渲染。
JavaScript：做法 4 – 6（影響 INP）
做法 4：移除用不著的第三方套件
最常見的浪費：為了一個淡入效果而載入整套動畫庫、為了一個日期選擇器而載入整個 UI 框架、為了一個圖表而載入完整圖表庫。逐個檢查你的 <script>，問三條問題：
- 這個功能有多少用戶真的會用到？
- 可否用原生 CSS 或少量原生 JS 取代？（例如淡入用 CSS
@keyframes、滾動偵測用IntersectionObserver） - 如果必須用，可否只載入需要的模組而非整個套件？
DevTools 的 Coverage 面板可以顯示每個檔案有多少比例的程式碼實際未被執行——通常會看到 60–80% 未用，這就是可以砍的部分。
做法 5：統計與聊天工具改為延後或互動後載入
聊天視窗、追蹤像素、彈出優惠、評價外掛，是 INP 的頭號殺手，因為它們在頁面剛載入時搶佔主執行緒。三種處理層級：
- 延後：所有非必要腳本加
defer，或在load事件後才注入 - 閒置時載入：用
requestIdleCallback等瀏覽器空閒才載入分析工具 - 互動後載入：聊天視窗先只放一個純 CSS 的按鈕，用戶真正點擊才載入完整套件
<!-- 聊天視窗：點擊才載入，省下數百 KB 與主執行緒時間 -->
<button id="chatBtn" aria-label="開啟對話">WhatsApp 查詢</button>
<script>
document.getElementById('chatBtn').addEventListener('click', function loadChat() {
const s = document.createElement('script');
s.src = 'https://example.com/chat-widget.js';
s.async = true;
document.head.appendChild(s);
this.removeEventListener('click', loadChat);
}, { once: true });
</script>
道理很簡單：大部分訪客從來不會打開聊天視窗，為什麼要所有人先付這個載入成本？
做法 6：避免在捲動事件中做大量運算
scroll 事件每秒可觸發數十次，在裡面做 DOM 讀寫或計算位置，會直接製造長任務。改用 IntersectionObserver：它由瀏覽器在合適時機回呼，成本低得多。
const io = new IntersectionObserver((entries) => {
entries.forEach(e => {
if (e.isIntersecting) {
e.target.classList.add('in-view');
io.unobserve(e.target);
}
});
}, { rootMargin: '100px' });
document.querySelectorAll('.reveal').forEach(el => io.observe(el));
同類原則：resize 事件要節流（throttle）、輸入框的搜尋建議要防抖（debounce）、避免在事件處理中讀取 offsetHeight 等會強制重排的屬性。
伺服器與快取：做法 7 – 9
做法 7：啟用 Brotli 或 Gzip 壓縮
Brotli 對文字資源（HTML、CSS、JS、SVG、JSON）的壓縮率比 Gzip 更好，應優先使用並保留 Gzip 作後備。留意：圖片、影片、字型（WOFF2）本身已壓縮，重複壓縮只會浪費 CPU，記得排除。
Apache 環境的 .htaccess 參考設定：
<IfModule mod_brotli.c>
AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/css text/javascript application/javascript application/json image/svg+xml
</IfModule>
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/css text/javascript application/javascript application/json image/svg+xml
</IfModule>
做法 8：為靜態資源設定長效快取標頭
CSS、JS、圖片、字型應設一年快取並加 immutable，同時用檔名版本號（style.a1b2c3.css）處理更新。HTML 則要短快取或不快取，否則改了內容用戶看不到。
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/avif "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType text/css "access plus 1 year"
ExpiresByType application/javascript "access plus 1 year"
ExpiresByType font/woff2 "access plus 1 year"
ExpiresByType text/html "access plus 0 seconds"
</IfModule>
<FilesMatch "\.(avif|webp|css|js|woff2)$">
Header set Cache-Control "public, max-age=31536000, immutable"
</FilesMatch>
做法 9：機房位置與伺服器層優化
LCP 的第一段就是 TTFB（首位元組時間）。如果伺服器在美國而客人在香港，光速往返已經吃掉幾百毫秒——後面做幾多優化都補不回。
四件應該做的事：
- 機房靠近受眾：做香港生意就用香港或亞洲機房。這是我們用自家伺服器的一個實際原因，見 網頁寄存服務
- 開啟 CDN：靜態資源交給 Cloudflare 等的亞洲節點，同時啟用 HTTP/2 或 HTTP/3
- PHP 與資料庫層：啟用 OPcache、為常用查詢加索引、避免每頁重複查詢同一批資料（N+1 問題）
- 頁面快取：內容變動不頻繁的頁面直接輸出靜態 HTML，TTFB 可以由幾百毫秒降到幾十毫秒
字型：做法 10
字型是中文網站的隱形負擔——一套完整的繁體中文字型可以有幾 MB。四個處理方向：
font-display: swap：先用系統字型顯示文字，字型到齊後再替換，避免一片空白（FOIT）。留意這會帶來輕微的字型切換位移，配合尺寸相近的後備字型可減輕- 預載關鍵字型：
<link rel="preload" as="font" type="font/woff2" crossorigin>，只預載首屏真正用到的一至兩個字重 - 只用必要字重：常見錯誤是載入 100 到 900 全套九個字重，實際只用兩個
- 認真考慮系統字型：對中文網站而言，用系統字型堆疊（
-apple-system, "PingFang HK", "Microsoft JhengHei", sans-serif）可以完全省掉字型下載，視覺差異其實很小，但速度提升很明顯
@font-face {
font-family: 'BrandSans';
src: url('/fonts/brand.woff2') format('woff2');
font-weight: 400;
font-display: swap;
size-adjust: 100%;
}
五個 2026 進階做法
11. 用 scheduler.yield() 切斷長任務
這是 2026 年修 INP 最重要的 API。它把控制權交還主執行緒，讓瀏覽器先處理用戶的點擊，然後以優先續行的方式恢復你的工作——比 setTimeout 優勝之處是你的程式碼會排到隊伍前面而非後面。支援狀況：Chrome 自 2024 年、Firefox 自 2025 年 8 月起支援，Safari 仍未支援，所以要加一行 polyfill。
globalThis.scheduler ??= {};
globalThis.scheduler.yield ??= () => new Promise(r => setTimeout(r, 0));
async function processItems(items) {
for (const item of items) {
doWork(item);
await scheduler.yield(); // 每處理一項就讓瀏覽器有機會回應用戶
}
}
如果長任務是純運算而不需要碰 DOM，更徹底的做法是整段搬到 Web Worker，完全離開主執行緒。
12. 確保 bfcache 可用
返回上一頁如果能用瀏覽器的 back/forward cache，載入幾乎是瞬間完成。常見的破壞因素：使用 unload 事件處理器（改用 pagehide）、回應標頭設了 Cache-Control: no-store、以及未關閉的 WebSocket 連線。DevTools 的 Application → Back/forward cache 可以直接測試並列出阻礙原因。
13. 用 Speculation Rules 預先渲染
對導覽路徑明確的網站（首頁 → 服務頁 → 聯絡頁），可以讓瀏覽器在用戶點擊前就預先載入或預先渲染下一頁，實際體感接近即時。
<script type="speculationrules">
{
"prerender": [{
"where": { "href_matches": "/contact*" },
"eagerness": "moderate"
}],
"prefetch": [{
"where": { "href_matches": "/*" },
"eagerness": "conservative"
}]
}
</script>
注意兩點：預渲染會消耗用戶流量與記憶體，所以只用在轉換路徑上的關鍵頁面；另外預渲染頁面的分析事件要正確處理，否則會虛報瀏覽量。
14. 用 content-visibility 跳過離屏渲染
長頁面（部落格列表、商品列表、FAQ 長頁）可以讓瀏覽器跳過螢幕外區塊的渲染工作：
.post-card, .product-card {
content-visibility: auto;
contain-intrinsic-size: auto 320px;
}
contain-intrinsic-size 一定要給合理估值，否則滾動條會跳動，反而製造 CLS。
15. 清掉未使用的 CSS 與內聯關鍵樣式
用套裝主題的網站經常載入整套 CSS 框架而只用到 10%。做法是把首屏需要的樣式內聯到 <head>，其餘 CSS 延後載入。這能直接縮短渲染阻塞時間，對 LCP 有明顯幫助。
做法影響力對照表
如果時間有限，按這張表由上至下做。
| 做法 | 主要改善 | 難度 | 預期效果 |
|---|---|---|---|
| 首屏大圖轉 AVIF／WebP 並正確定尺寸 | LCP、CLS | 低 | 最高：常見 0.5 – 2 秒 |
| 移除首屏圖片的 lazy load、加 fetchpriority | LCP | 低 | 高：0.3 – 1 秒 |
| 聊天／追蹤腳本改互動後載入 | INP | 低 | 高：常見減半 |
| 啟用 Brotli 與長效快取 | LCP（回訪） | 低 | 中至高 |
| 換用亞洲機房 + CDN | TTFB → LCP | 中 | 高：0.2 – 0.8 秒 |
| 字型改 swap／預載／系統字型 | LCP、CLS | 低 | 中 |
| 移除未用的 JS 套件 | INP | 中 | 中至高 |
| scroll 事件改 IntersectionObserver | INP | 中 | 中 |
| scheduler.yield 切長任務 | INP | 中至高 | 中至高（重運算頁面） |
| 頁面快取 + OPcache + 資料庫索引 | TTFB → LCP | 中 | 高（動態網站） |
| 修復 bfcache | 回訪體感 | 低 | 中 |
| Speculation Rules 預渲染 | 下一頁載入 | 中 | 中（體感明顯） |
| content-visibility | 長頁渲染 | 低 | 中（長列表頁） |
四個常見誤解
| 誤解 | 事實 |
|---|---|
| 「PageSpeed 拿到 100 分就等於達標」 | 100 分是實驗室模擬分數。Google 評分用的是真實用戶（CrUX）第 75 百分位數據，兩者可以完全不同 |
| 「裝個快取外掛就搞定」 | 快取只改善 TTFB 與重複造訪。INP 由 JavaScript 造成，CLS 由版面結構造成，兩者外掛都修不到 |
| 「所有圖片都應該 lazy load」 | 首屏 LCP 圖片加 lazy load 會令 LCP 明顯變差。lazy load 只應用於首屏以下 |
| 「加了 CDN 就一定快」 | CDN 主要加速靜態資源。如果瓶頸是 PHP 執行慢或資料庫查詢慢，CDN 幫不到，要修伺服器層 |
香港網站的特殊考慮
中文字型的重量
這是香港網站相對英文網站最大的額外負擔。一套完整繁體中文字型動輒幾 MB，即使做了子集化（subsetting）仍然可觀。除非品牌有強烈字型需求，系統字型堆疊通常是最理性的選擇。
機房與網絡現實
香港用戶的移動網絡整體不錯，但室內、地鐵與郊區差異很大。機房設在香港或鄰近地區，能直接壓低 TTFB；如果同時做內地生意，要另外評估跨境連線問題。
網店的速度直接等於收入
商品列表頁通常是全站最重的頁面（大量圖片加篩選 JS）。三個針對做法：列表圖片用較小尺寸並用 srcset、篩選功能用伺服器端渲染而非全部載入前端處理、商品卡片加 content-visibility。網店的完整準備事項見 開網店前必看九項清單與 電商平台服務。
速度也影響 AI 搜尋
部分 AI 爬蟲不執行 JavaScript，也有抓取超時限制。伺服器端渲染、輕量頁面同時有利於被 AI 引用——這與 GEO 的要求剛好一致，做法見 GEO 生成式引擎優化入門。
名詞速查
- LCP
- Largest Contentful Paint，最大可見元素完成渲染的時間，通常是首屏大圖或標題。
- INP
- Interaction to Next Paint，頁面對用戶互動的回應速度，已取代舊指標 FID。
- CLS
- Cumulative Layout Shift，非預期版面位移的累計分數。
- TTFB
- Time to First Byte，由請求發出到收到第一個位元組，反映伺服器與網絡速度。
- CrUX
- Chrome User Experience Report，Google 收集的真實用戶效能數據，是評分依據。
- 第 75 百分位
- 把所有用戶的數值排序後取第 75 名位置的值，即要照顧到較慢的四分之一用戶。
- 長任務（Long Task）
- 佔用主執行緒超過 50 毫秒的 JavaScript 工作，是 INP 變差的主因。
- bfcache
- back/forward cache，瀏覽器把整頁狀態保存起來，令上一頁／下一頁近乎即時顯示。
- 子集化（Subsetting）
- 只保留字型中實際使用的字元，大幅減少中文字型檔案大小。
- 渲染阻塞
- 某些 CSS 或 JS 會阻止瀏覽器先顯示內容，直接拖慢 LCP。
常見問題
Core Web Vitals 真的影響 SEO 排名嗎？
影響，但它是眾多排名因素之一，不是決定性因素。內容相關性仍然排第一。實際價值在於：同等內容質素下，速度是可控的優勢，而且它直接影響轉換率——這部分的回報通常比排名更直接。
改完之後多久會反映在報告上？
CrUX 用 28 日滾動數據，所以完整反映需要約四星期。Lighthouse 實驗室分數會即時改變，但那不是評分依據。修完後請耐心等一個月再判斷成效。
為什麼我在電腦上很快，PageSpeed 卻說慢？
因為評分看的是真實手機用戶的數據，包括中低階 Android 與較差的網絡環境。你的辦公室光纖加高階裝置，通常是最好的那 25%，剛好不在被評核的範圍。
三項指標應該先修哪一項？
先看 Search Console 哪一項不達標。若三項都差，建議次序是 LCP（改善最明顯）→ CLS（最容易修）→ INP（最花時間）。
WebP 還是 AVIF？
WebP 是 2026 年的安全預設：支援率 97–98%、編碼快、相對 JPEG 省 25–34%。AVIF 適合首屏大圖與商品主圖這類「編碼一次、長期供應」的圖片，可再省 20–30%，但編碼慢 5–20 倍。務實做法是 <picture> 供應 AVIF，WebP 後備。
WordPress 網站可以做到達標嗎？
可以，但難度較高，因為主題與外掛通常會載入大量未使用的 CSS 與 JS。優先次序是：減少外掛數量、換用輕量主題、啟用頁面快取與 CDN、處理圖片格式。如果主題本身臃腫，換主題往往比逐項優化更快見效。
只裝一個效能外掛夠不夠？
不夠。外掛能處理快取、壓縮與圖片格式，但修不到 INP（源自 JavaScript 執行）與 CLS（源自版面結構）。這兩項需要改動程式碼與版面。
移除聊天視窗會不會少了查詢？
不是移除，是改成點擊後才載入。按鈕依然一直在，功能完全一樣，只是把幾百 KB 的載入成本轉移給真正會用的那批訪客。
要花幾多時間才修得好？
一般 5–10 頁的企業網站，圖片與腳本層面的優化約 4–8 小時就能見到明顯改善。伺服器層與深度 JS 重構則視架構而定。最沒有效率的做法是逐項亂試——先做上方的五步診斷。
改版會不會影響已有的排名？
如果網址結構改變而沒有處理 301 轉址，會。改版前必須做好舊網址對照表，見 301 轉址實務。
速度和設計靚是不是必須取捨？
大部分情況不需要。拖慢網站的通常是未優化的大圖、多套字型、與為單一效果載入的整套動畫庫——這三樣都有輕量替代方案。真正需要取捨的只有大型影片背景與複雜 3D 互動。
可以幫我測一次嗎？
可以。把網址傳給我們，我們會回覆一份簡短報告：三項指標的真實用戶數據、最大的兩個瓶頸、以及按投入產出比排序的修復建議。
想知道你的網站在手機上實際有幾快？把網址傳給我們，我們會回覆三項 Core Web Vitals 的真實用戶數據、最大兩個瓶頸與具體修復次序，並說明哪些可以自己做、哪些需要改動伺服器。立即 免費查詢，或了解 網頁寄存與效能調校服務。
