設計師做的每一個決定都在影響 Google 排名
很多設計師不知道，他們選的那張超大背景圖、加的那個華麗的載入動畫、用的那個自訂字體——都在影響網站的 Core Web Vitals 分數。而 Core Web Vitals 是 Google 排名的訊號之一。
簡單說，你的設計決策直接影響網站在 Google 的排名表現。
Core Web Vitals 是 Google 在 2020 年提出的三個核心效能指標，用來量化使用者在你的網站上的實際體驗。2021 年正式成為排名因素，到了 2024 年更新為新的指標組合，目前的三個指標是：
- LCP（Largest Contentful Paint）：最大內容繪製，衡量頁面主要內容載入完成的速度
- INP（Interaction to Next Paint）：互動到下次繪製，衡量頁面回應使用者操作的速度
- CLS（Cumulative Layout Shift）：累積版面偏移，衡量頁面載入過程中元素跑位的程度
這三個指標聽起來很技術，但其實都跟設計有直接關係。接下來一個一個拆解。
LCP：你放的那張大圖正在拖垮載入速度
LCP 衡量的是頁面上最大的可見元素（通常是首屏的主圖或大標題）完成載入的時間。Google 的標準是：LCP 在 2.5 秒以內算「好」，2.5 到 4 秒算「待改善」，超過 4 秒算「差」。
哪些設計決策會影響 LCP？
首屏大圖的選擇
很多網站的首屏放一張全寬的 Hero Image，解析度動輒 3000x2000 像素、檔案大小 2-3MB。這張圖就是 LCP 的計算對象，它載入得越慢，LCP 分數就越差。
設計師可以做的：用 WebP 格式取代 JPEG/PNG（同品質下檔案小 25-35%）、不要用超過實際顯示尺寸的圖片（如果顯示區域只有 1200px 寬，不需要放 3000px 的圖）、考慮用 CSS 漸層或幾何圖形取代照片。
自訂字體
自訂字體的載入需要額外的網路請求。如果你的大標題用了一個非系統字體，瀏覽器要先下載字體檔案，才能開始渲染標題文字。這個等待時間會拉長 LCP。
設計師可以做的：限制字體的種類和字重（不要同時載入 5 種字重）、使用 font-display: swap 讓文字先用系統字體顯示、考慮在標題使用系統字體堆疊。
影片背景
影片背景很炫，但影片檔案通常很大。即使做了壓縮，一個背景影片的載入時間也比一張圖片長得多。
設計師可以做的：用動態 CSS 效果或 Lottie 動畫取代影片、如果非用影片不可，確保設定 poster 屬性讓瀏覽器先顯示一張靜態圖。
根據 HTTP Archive 2025 年的資料，全球排名前 100 萬網站中，LCP 通過率（2.5 秒以內）約為 64%。換句話說，超過三分之一的網站在這個指標上不及格。如果你的網站通過了，你就已經在競爭中取得了優勢。
INP：頁面反應慢的話使用者會覺得網站壞了
INP 取代了原本的 FID（First Input Delay），是 2024 年 3 月正式上線的新指標。它衡量的是使用者在頁面上執行任何互動（點擊、敲鍵盤、觸控）之後，頁面更新所需的時間。Google 的標準是：INP 在 200 毫秒以內算「好」，200 到 500 毫秒算「待改善」，超過 500 毫秒算「差」。
跟 FID 只看第一次互動不同，INP 看的是整個頁面生命週期內最慢的那次互動。這代表你不能只優化首次載入，之後的每一次點擊都算。
哪些設計決策會影響 INP？
過多的第三方腳本
Google Analytics、Facebook Pixel、聊天機器人、A/B 測試工具、各種追蹤碼——每加一個第三方腳本，就在主執行緒上多了一段需要運算的程式碼。當使用者點擊一個按鈕的時候，瀏覽器可能正在忙著執行這些腳本，沒空處理你的點擊事件。
大量的 DOM 元素
如果你的頁面有上千個 HTML 元素（通常是設計太複雜的結果），瀏覽器每次更新畫面都要重新計算這些元素的佈局和繪製。DOM 越大，更新越慢。
沒有優化的動畫
用 JavaScript 控制的動畫比用 CSS 的 transform 和 opacity 慢得多。如果你的頁面上有大量用 JS 控制的動畫，每次動畫觸發都會佔用主執行緒的運算資源。
圖片輪播和無限滾動
這些 UI 元件通常需要大量的 JavaScript 來運作，而且會在每次互動時觸發大量的 DOM 操作。如果實作得不好，每次滑動都會造成明顯的延遲。
改善 INP 的設計原則是：能不用 JavaScript 就不用、能用 CSS 做的動畫就用 CSS、UI 元件能簡化就簡化。複雜的設計不一定是好的設計，但它一定會拖垮效能。
CLS：頁面跑版是最讓人抓狂的體驗
CLS 衡量的是頁面在載入過程中，元素發生非預期位移的程度。Google 的標準是：CLS 在 0.1 以內算「好」，0.1 到 0.25 算「待改善」，超過 0.25 算「差」。
你一定有過這種經驗：正要點一個按鈕，突然頁面跑了一下，你點到的變成另一個東西。或者正在讀一段文字，突然上面插進一張圖片，整段文字往下跳。
這就是 CLS 要量化的問題。
哪些設計決策會造成 CLS？
沒有設定尺寸的圖片和影片
瀏覽器在圖片載入之前不知道它有多大，所以先給 0 的空間。圖片載入完成後，瀏覽器重新分配空間，其他元素就被擠走了。解決方法是在 HTML 裡面指定圖片的 width 和 height，或者用 CSS 的 aspect-ratio 預留空間。
動態插入的內容
廣告橫幅、Cookie 通知、通知訊息——這些在頁面載入完成後才動態插入的內容，如果沒有預留空間，就會把下面的內容往下推。
Web Font 載入造成的文字跳動
自訂字體載入前後，文字的大小可能會改變（系統字體和自訂字體的字元寬度不同），造成整段文字重新排版。用 font-display: optional 可以避免這個問題，但代價是在某些情況下自訂字體不會顯示。
沒有固定高度的輪播
輪播裡面的每張圖片如果高度不同，切換的時候輪播的高度就會變化，推動下面的內容。輪播要設定固定高度。
CLS 的優化其實不難，核心原則就一個：所有元素在載入之前就要預留好空間。設計稿切版的時候就把尺寸定死，不要讓瀏覽器自己去猜。
Core Web Vitals 對排名的實際影響有多大？
講完了三個指標，一個很自然的問題是：這些指標到底對排名影響多大？
先說結論：Core Web Vitals 是排名因素，但不是最重要的排名因素。
Google 自己也說過，內容相關性和品質仍然是最重要的排名訊號。Core Web Vitals 更像是一個「門檻」——通過了不會讓你排名大幅提升，但沒通過可能會讓你在跟同等品質的競爭對手比較時吃虧。
Searchmetrics 在 2024 年的研究顯示，排名在 Google 前 10 的頁面中，78% 通過了所有三項 Core Web Vitals 指標。但這不代表是因為通過了指標所以排名高——排名高的網站通常技術底子也比較好，這是相關性不是因果關係。
不過有一個數據比較有說服力：如果你的網站目前 Core Web Vitals 全部不及格，把它們全部優化到及格，平均可以看到 5-15% 的自然流量提升。這個提升幅度不算巨大，但考慮到自然流量是免費的，這是一個投資報酬率很高的優化。
案例分析：一個媒體網站的 Core Web Vitals 修復之路
一個台灣的新聞媒體網站，日均自然搜尋流量約 15 萬。Google Search Console 顯示，他們只有 22% 的頁面通過了所有 Core Web Vitals 指標。主要問題是：
- LCP 平均 4.8 秒（文章頁的首圖太大，且沒有做 lazy loading）
- CLS 平均 0.35（文章中間插入的廣告橫幅沒有預留空間、圖片沒有設定尺寸）
- INP 平均 380 毫秒（頁面上載入了 14 個第三方腳本）
他們花了六週做了以下優化：
圖片全面轉為 WebP 格式並根據裝置尺寸提供不同大小的版本，首圖使用 fetchpriority="high" 預先載入。所有圖片和廣告位設定明確的 aspect-ratio。第三方腳本從 14 個精簡到 8 個，剩下的全部改為非同步載入。
六週後的成果：LCP 降到 2.1 秒、CLS 降到 0.06、INP 降到 160 毫秒。通過率從 22% 提升到 89%。
更重要的是，三個月後他們的自然搜尋流量增加了約 12%，大約每天多了 1.8 萬的免費流量。按照他們的 CPM 廣告收益來計算，這等於每月多了一筆可觀的廣告收入。
設計師和開發者需要一起做的事
Core Web Vitals 的優化不是設計師一個人的事，也不是開發者一個人的事。它需要兩邊一起協作。
設計師的責任：
- 設計稿裡的圖片要標明尺寸（寬高比），讓前端切版時可以預留空間
- 控制首屏的視覺複雜度，不要在首屏塞太多需要載入的元素
- 字體的選擇要考慮檔案大小，不要一次用 5 種不同的字體
- 動畫效果要考慮能不能用 CSS 實現，而不是全部丟給 JavaScript
- 元件設計要明確定義各種狀態下的尺寸，避免動態內容造成版面跳動
開發者的責任：
- 圖片要做壓縮、格式轉換、響應式載入
- 第三方腳本要評估必要性，非必要的移除，必要的改為非同步載入
- 關鍵 CSS 要 inline、非關鍵 CSS 要延遲載入
- JavaScript 要做 code splitting 和 tree shaking
- 使用
loading="lazy"延遲載入非首屏的圖片和 iframe
兩邊一起的責任：
- 定期檢查 Google Search Console 的 Core Web Vitals 報告
- 用 Lighthouse 和 PageSpeed Insights 測試每次改版的效能影響
- 建立效能預算（Performance Budget），約定好每個頁面的最大載入資源量
效能不是設計的對立面
有些設計師會覺得「追求效能就是在限制我的創意」。但其實不是。
效能好的網站不代表設計無聊。Apple 的網站、Stripe 的網站、Linear 的網站——這些都是設計精美而且效能優秀的例子。關鍵不是「不要做複雜的設計」，而是「用聰明的方式做複雜的設計」。
一張經過適當壓縮的 WebP 圖片和一張未壓縮的 PNG 在視覺上幾乎看不出差別，但檔案大小可能差三倍。一個用 CSS transform 做的動畫和一個用 JavaScript 做的動畫在視覺上一模一樣，但效能差距巨大。
設計的限制不在技術，在觀念。當設計師開始把效能當作設計的一部分來考慮——而不是設計完之後再讓開發去「修效能」——整個工作流程會順暢很多，成品也會好得多。
Core Web Vitals 不是 Google 用來為難你的指標，它是在告訴你「你的使用者體驗在這些地方有問題」。修好這些問題，不只是為了排名，更是為了讓每一個進到你網站的訪客都有好的體驗。
