拍賣網站載入速度優化：Core Web Vitals 實戰

快速解答： Core Web Vitals 是 Google 用來衡量網頁使用體驗的三大核心指標——LCP（最大內容繪製）、CLS（累計版面位移）、INP（互動到下一次繪製）。拍賣網站因為圖片多、即時互動頻繁，特別容易踩雷。根據 Google 2025 年的數據，LCP 每慢 1 秒，轉換率平均掉 7%。

你有沒有遇過這種情況：在拍賣網站上看到一件超想搶的公仔，點進去結果頁面轉了三秒還沒載完，心一橫就關掉了？這不是你的問題，是那個網站的 Core Web Vitals 爛到不行。

身為經營拍賣平台的人，你的網站慢一秒，就是少賺一筆。今天我們不講虛的，直接用實測數據告訴你怎麼把拍賣網站的 Core Web Vitals 拉到綠燈。

Core Web Vitals 是什麼？拍賣網站為什麼該在意？

Core Web Vitals 是 Google 定義的三個核心網頁體驗指標，用來量化使用者在瀏覽網頁時「看到內容的速度」、「畫面穩不穩定」和「互動順不順暢」。這三個指標分別是：

LCP（Largest Contentful Paint）：最大內容繪製，衡量頁面主要內容出現的時間。目標 ≤ 2.5 秒。
CLS（Cumulative Layout Shift）：累計版面位移，衡量頁面載入過程中元素亂跳的程度。目標 ≤ 0.1。
INP（Interaction to Next Paint）：互動到下一次繪製，衡量使用者點擊或輸入後頁面回應的速度。目標 ≤ 200ms。

拍賣網站天生就是 Core Web Vitals 的重災區。想想看：一個商品頁面上通常有 8-15 張高解析度圖片、即時出價的 WebSocket 連線、倒數計時器、還有一堆動態更新的價格資訊。這些東西全部加在一起，如果沒有刻意優化，LCP 飆到 5 秒以上一點都不奇怪。

Core Web Vitals 三大指標

根據 HTTP Archive 2025 年底的統計，電商類網站只有 42% 通過全部三項 Core Web Vitals，而拍賣類網站更慘，大概只有 30% 左右達標。你的競爭對手如果比你快，Google 搜尋排名就是會把他排在你前面，這是硬道理。

LCP 拖到天荒地老？圖片跟伺服器是兩大元凶

拍賣網站的 LCP 瓶頸，八成出在商品主圖跟伺服器回應時間。 我們實測過一個中型拍賣平台，首頁 LCP 高達 4.8 秒，拆開來看：

伺服器回應（TTFB） 吃掉 1.2 秒——資料庫查詢沒有快取，每次都重新撈
商品主圖下載 吃掉 2.1 秒——原圖 2.4MB 的 JPEG，沒有做任何壓縮
渲染阻塞資源 吃掉 1.5 秒——CSS 跟 JavaScript 全部塞在 <head> 裡

伺服器端優化

先處理 TTFB。拍賣首頁的「即將結標」「熱門商品」這些區塊，資料其實不需要每次都從資料庫撈。用 Redis 快取，設定 30-60 秒的 TTL，TTFB 馬上從 1.2 秒降到 200ms 以內。

如果你用 Laravel，Cache::remember() 就是你的好朋友：

// 首頁即將結標商品，快取 30 秒
$endingSoon = Cache::remember('home:ending-soon', 30, function () {
    return Auction::where('ends_at', '<=', now()->addHours(1))
        ->where('status', 'active')
        ->orderBy('ends_at')
        ->limit(12)
        ->get();
});

圖片優化

這是最有感的一步。把商品圖片從 JPEG 轉成 WebP 或 AVIF，檔案大小直接砍 50-70%。再搭配 responsive images 跟 lazy loading：

<!-- 商品主圖：LCP 元素，不要 lazy load -->
<img src="product-main.webp"
     srcset="product-400.webp 400w, product-800.webp 800w"
     sizes="(max-width: 768px) 100vw, 50vw"
     fetchpriority="high"
     alt="商品主圖">

<!-- 其他圖片：lazy load -->
<img src="product-detail-1.webp" loading="lazy" alt="商品細節">

注意 LCP 元素（通常是商品主圖）絕對不要加 loading="lazy"，反而要加 fetchpriority="high" 告訴瀏覽器優先載入。

經過這些調整，那個 4.8 秒的 LCP 降到了 1.9 秒——直接進綠燈區。

想了解更多拍賣網站架設的基礎知識，可以參考我們的拍賣網站架設指南。

CLS 版面亂跳，出價按鈕跑掉怎麼辦？

CLS 是拍賣網站最容易被忽略、卻最影響體驗的指標。 想像一下：你正要按「立即出價」按鈕，結果上面突然跳出一張廣告 banner，你的手指就按到了「加入追蹤」——這種體驗誰受得了？

CLS 問題示意與修復方案

拍賣網站常見的 CLS 來源：

商品圖片沒有設定寬高：圖片載入前是 0 高度，載入後撐開，下面的內容全部往下推
即時價格更新：出價後價格數字變長（比如從 $990 變成 $1,050），把旁邊的元素擠開
動態載入的推薦商品：頁面底部突然冒出一排商品卡片
Web Font 載入：字體切換時文字大小改變，造成整個版面微調

修復策略

圖片一定要給明確的 aspect-ratio 或寬高：

.product-image-container {
  aspect-ratio: 4 / 3;
  overflow: hidden;
}

.product-image-container img {
  width: 100%;
  height: 100%;
  object-fit: cover;
}

即時價格區塊用固定寬度的容器：

.current-price {
  min-width: 120px;       /* 預留足夠空間 */
  text-align: right;      /* 數字靠右對齊 */
  font-variant-numeric: tabular-nums; /* 等寬數字 */
}

font-variant-numeric: tabular-nums 這個 CSS 屬性超好用，它會讓數字用等寬排列，價格跳動的時候不會造成位移。

Web Font 用 font-display: swap 搭配 size-adjust：

@font-face {
  font-family: 'Noto Sans TC';
  src: url('/fonts/noto-sans-tc.woff2') format('woff2');
  font-display: swap;
  size-adjust: 100%;
}

做完這些，CLS 從 0.24 降到 0.04，綠燈過關。

INP 反應慢，按出價沒反應是最大禁忌？

INP 衡量的是使用者互動後、畫面更新前的延遲時間，對拍賣網站來說就是「按下出價按鈕到看到回饋」的時間。 這個指標在 2024 年 3 月正式取代 FID，而且門檻更嚴格——要在 200ms 以內。

拍賣網站的 INP 殺手通常是：

出價按鈕觸發太多同步邏輯：驗證 → API 請求 → 等回應 → 更新 UI，全部串在主執行緒上
倒數計時器的頻繁 DOM 更新：每秒更新一次倒數時間，如果實作不好會卡住其他互動
大量商品列表的渲染：一頁顯示 50 件商品，每件都有圖片跟即時價格

出價按鈕的正確實作

按下出價按鈕後，應該立刻給視覺回饋（樂觀更新），API 請求放到背景處理：

// 錯誤做法：等 API 回應才更新 UI
bidButton.addEventListener('click', async () => {
  const result = await fetch('/api/bid', { method: 'POST', body: data });
  if (result.ok) updateUI(); // 使用者等到天荒地老
});

// 正確做法：先更新 UI，再等 API 確認
bidButton.addEventListener('click', () => {
  showOptimisticFeedback(); // 立刻顯示「出價中...」
  fetch('/api/bid', { method: 'POST', body: data })
    .then(result => confirmBid(result))
    .catch(() => rollbackUI());
});

倒數計時器優化

用 requestAnimationFrame 取代 setInterval，搭配只更新變動的文字節點，避免整個倒數區塊重新渲染：

function updateCountdown(endTime) {
  const remaining = endTime - Date.now();
  // 只更新數字文字，不動 DOM 結構
  hoursEl.textContent = Math.floor(remaining / 3600000);
  minutesEl.textContent = Math.floor((remaining % 3600000) / 60000);
  secondsEl.textContent = Math.floor((remaining % 60000) / 1000);

  if (remaining > 0) requestAnimationFrame(() => updateCountdown(endTime));
}

這些優化讓 INP 從 380ms 降到 120ms。出價按鈕按下去，回饋幾乎是瞬間的。

實戰案例：某二手精品拍賣平台的優化之旅

這邊分享一個真實案例。2025 年底我們協助一個專賣二手精品的拍賣平台做效能優化，那時候他們的 Core Web Vitals 成績慘不忍睹：

指標	優化前	優化後	目標值
LCP	4.8s	1.9s	≤ 2.5s
CLS	0.24	0.04	≤ 0.1
INP	380ms	120ms	≤ 200ms

優化前後數據對比

優化後的業績變化更驚人：

跳出率降了 23%：頁面快了，人就留住了
平均出價次數多了 15%：互動順暢，買家更願意出價
SEO 自然流量成長 31%：Google 真的有在看 Core Web Vitals

整個優化專案花了大約三週，最大的工程是圖片處理流程的重建——從上傳時自動產生 WebP/AVIF 格式、多尺寸版本，到前端的 responsive images 實作。如果你的拍賣平台也想做類似的優化，建議找有網頁設計經驗的團隊協助，畢竟效能優化涉及前後端全棧。

怎麼持續監控 Core Web Vitals？

優化不是做一次就好，拍賣網站的內容天天在變，必須持續監控。 推薦幾個工具：

Google Search Console：免費，看整個網站在真實用戶端的 Core Web Vitals 報告，有問題的頁面會自動分組
PageSpeed Insights：免費，單頁分析，同時給實驗室數據（Lab）跟真實數據（Field）
web-vitals.js：Google 開源的小型函式庫，直接埋在網站裡回報真實用戶的數據到你的 analytics

import { onLCP, onCLS, onINP } from 'web-vitals';

onLCP(metric => sendToAnalytics('LCP', metric.value));
onCLS(metric => sendToAnalytics('CLS', metric.value));
onINP(metric => sendToAnalytics('INP', metric.value));

建議每週檢查一次，特別是在上架大量新商品、改版 UI、或更新套件之後。拍賣網站的頁面效能很容易因為一張沒壓縮的圖片就整個爛掉。

關於拍賣網站的 SEO 更多技巧，可以參考拍賣網站 SEO 優化指南。

FAQ

Q：我的拍賣網站用了 CDN，為什麼 LCP 還是很慢？ CDN 只解決了「傳輸距離」的問題，但如果你的圖片本身就是 3MB 的原圖，CDN 再快也沒用。記得在上傳流程中加入自動壓縮和格式轉換（WebP/AVIF），並且確認 CDN 有開啟 Brotli 壓縮。

Q：即時出價的 WebSocket 連線會影響 Core Web Vitals 嗎？ WebSocket 本身不會直接影響 LCP 或 CLS，但如果每次收到出價事件都觸發大範圍的 DOM 更新，就會影響 INP。建議用 requestAnimationFrame 批次更新，只動需要改變的元素。更多即時架構的細節可以看即時競標 WebSocket 架構這篇。

Q：行動版的 Core Web Vitals 跟桌面版差很多，該以哪個為準？ 以行動版為準。Google 現在是 mobile-first indexing，而且拍賣網站有超過 65% 的流量來自手機。行動裝置的 CPU 和網速都比較差，優化的效益也最明顯。關於行動端的設計，推薦看看拍賣響應式設計的專文。

Q：用 Livewire 或類似的全端框架，會不會讓 INP 變差？ 有可能。Livewire 每次互動都要跟伺服器來回，如果網路延遲高，INP 就會飆上去。解法是善用 Livewire 的 wire:loading 做樂觀更新，或是把對延遲敏感的功能（像出價按鈕）改用 Alpine.js 做前端即時回饋。