我在過去四年裡一直在優化 Next.js 應用中的圖片，我會坦白說——2026 年的情況與 next/image 首次發布時完全不同。Google 的核心網頁指標門檻變得更加嚴格，新的圖片格式已經成熟，而 next/image 元件本身經歷了多次重寫。如果您的圖片配置方式仍然停留在 2023 年，那您將失去性能（和排名）機會。

這不是對 Next.js 文件的重複。這是我從數十個實際生產網站中學到的知識——在這些網站上，LCP 分數確實重要——圖片載入時間相差 200ms 就意味著在第一頁和第三頁之間的區別。

目錄

Next.js Image Optimization for Core Web Vitals in 2026

2026 年核心網頁指標：發生了什麼變化

Google 在 2025 年末更新了核心網頁指標的門檻，而且這些變化並不是微不足道的。以下是目前的情況：

指標 2023 年"良好"門檻 2026 年"良好"門檻 衡量內容
LCP ≤ 2.5s ≤ 2.0s 最大內容繪製
INP ≤ 200ms ≤ 150ms 互動至下一繪製
CLS ≤ 0.1 ≤ 0.1 累積版面配置偏移
TTFB N/A（不是 CWV） 非正式 ≤ 600ms 首字節時間

LCP 門檻從 2.5 秒降至 2.0 秒對圖片豐富的網站造成了最大衝擊。半秒聽起來不多，直到您意識到 60% 以上的頁面上，LCP 元素就是圖片。通常是主圖像、產品照片或特色文章縮圖。

INP 取代 FID 已經在執行中，但更嚴格的 150ms 門檻意味著龐大的 JavaScript 套件——包括配置不當的圖片延遲載入指令碼——會毀掉您的互動性分數。

CLS 保持不變，這是個好消息。但圖片仍然是沒有明確尺寸時版面配置偏移的首要原因。

為什麼這對 Next.js 特別重要

Next.js 應用本質上往往是 JavaScript 密集型的。您在運送 React，在運送框架代碼，如果不小心的話，您也在運送圖片優化邏輯到用戶端。結合更嚴格的 LCP 預算和 React 應用的 JS 開銷，您的出錯空間比靜態 HTML 網站要少。

這正是為什麼我們高度關注 Next.js 開發——該框架提供了令人難以置信的工具，但只有在您知道如何配置它們時才行。

next/image 實際上如何在幕後運作

讓我們揭開當您使用 next/image 中的 <Image /> 時發生什麼的神秘面紗。理解該管道有助於您做出更好的優化決策。

請求流程

  1. 構建時間：Next.js 生成指向 /_next/image?url=...&w=...&q=... 的 <img> 標籤
  2. 首次請求：Next.js 圖片優化 API 接收請求，獲取原始圖片，調整大小，轉換格式，並緩存結果
  3. 後續請求：直接提供緩存版本

在 Next.js 15（截至 2026 年初的當前穩定版本）中，圖片優化器在 Node.js 環境中預設使用 sharp。在 Vercel 上，它使用他們基於邊緣的圖片優化服務。在其他平台上，它根據您的配置回退到 sharp 或 squoosh。

// 基本用法——但這背後發生了很多事情
import Image from 'next/image';

export default function Hero() {
  return (
    <Image
      src="/hero.jpg"
      alt="Product hero shot"
      width={1200}
      height={630}
      priority
      quality={80}
    />
  );
}

那個 priority 屬性所做的遠不止您想像的那樣。它將 fetchpriority="high" 添加到 HTML，禁用延遲載入，並在 <head> 中生成預載 <link> 標籤。我們稍後會回到為什麼這對 LCP 很重要。

大多數人從不接觸的配置

您的 next.config.js（如果您已遷移，則為 next.config.ts）有一個 images 鍵來控制一切：

// next.config.js
module.exports = {
  images: {
    formats: ['image/avif', 'image/webp'],
    deviceSizes: [640, 750, 828, 1080, 1200, 1920, 2048],
    imageSizes: [16, 32, 48, 64, 96, 128, 256, 384],
    minimumCacheTTL: 31536000, // 1 year in seconds
    dangerouslyAllowSVG: false,
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'your-cms.com',
        pathname: '/assets/**',
      },
    ],
  },
};

formats 陣列的順序很重要。Next.js 會先嘗試 AVIF，然後回退到 WebP。AVIF 編碼較慢但產生較小的檔案——這種權衡值得理解。

LCP 問題：為什麼您的主圖像會毀掉您的分數

這是我在幾乎每次審計中都看到的情況：一個漂亮的主圖像，在折線上方，需要 3 秒以上才能繪製。開發者使用了 next/image，認為已經完成，然後繼續了。但分數很糟糕。

常見的嫌疑人：

1. 缺少 `priority` 屬性

預設情況下，next/image 會延遲載入所有內容。這對於折線下方的圖片很好，但對您的 LCP 元素來說是災難性的。沒有 priority，瀏覽器會在 JavaScript 水合後才發現該圖片，之後交叉觀察器才開始工作。

// ❌ 這會延遲載入您的 LCP 圖像
<Image src="/hero.jpg" alt="Hero" width={1200} height={630} />

// ✅ 這會預載它
<Image src="/hero.jpg" alt="Hero" width={1200} height={630} priority />

2. 用低質量值過度壓縮

我看過團隊設定 quality={50}，認為較小 = 較快。但如果圖片看起來模糊，Chrome 的 LCP 演算法仍然必須等待它完全繪製。在高 DPI 螢幕上，質量低於 70 通常會觸發可見的瑕疵，使設計看起來很廉價。

我的經驗法則：照片質量 75-85，包含文字或銳邊的圖片質量 90 以上。

3. 沒有正確使用 `sizes`

sizes 屬性告訴瀏覽器在 CSS 被解析之前要請求哪個圖片寬度。沒有它，Next.js 預設為 100vw，這意味著行動設備下載桌面大小的圖片。

<Image
  src="/hero.jpg"
  alt="Hero"
  fill
  priority
  sizes="(max-width: 768px) 100vw, (max-width: 1200px) 80vw, 1200px"
/>

這個單一屬性變更給我帶來了最大的 LCP 改進——有時在行動裝置上達到 400-800ms。

Next.js Image Optimization for Core Web Vitals in 2026 - architecture

格式戰爭：2026 年的 AVIF vs WebP vs JPEG XL

格式景觀已經大幅穩定。以下是我們的現狀：

格式 瀏覽器支援（2026） 壓縮 編碼速度 最佳用途
AVIF 全球約 95% 優異（比 WebP 小 30-50%） 慢 照片、主圖像
WebP 全球約 98% 良好（比 JPEG 小 25-35%） 快 通用
JPEG XL 約 45%（Chrome 放棄了） 優異 中等 不建議用於網頁
JPEG 通用 基線 快 僅限回退
PNG 通用 照片質量不佳 快 透明度、螢幕截圖

JPEG XL 曾有一個有前景的規範，但 Chrome 在 2023 年末的決定有效地將其從網頁使用中淘汰了。Safari 添加了支援，Firefox 有部分支援，但您不能依賴它。

我的建議：設定 formats: ['image/avif', 'image/webp'] 並忘掉它。Next.js 通過 Accept 標頭自動處理內容協商。

AVIF 編碼成本

以下是文件中沒有充分強調的事情：AVIF 編碼是 CPU 密集型的。在對 Next.js 伺服器的首次請求時，編碼 1200px AVIF 圖片可能需要 2-5 秒在適度伺服器上。第一個訪客承擔成本。

緩解此問題的策略：

  • 在構建時預生成使用 next export 或自訂構建指令碼
  • 使用具有內置圖片優化功能的 CDN（Cloudflare Images、Imgix、Cloudinary）
  • 在部署後預熱快取使用一個指令碼來點擊所有關鍵圖片 URL
# 簡單的快取預熱指令碼
#!/bin/bash
URLs=("https://yoursite.com/_next/image?url=%2Fhero.jpg&w=1200&q=80"
      "https://yoursite.com/_next/image?url=%2Fhero.jpg&w=750&q=80")

for url in "${URLs[@]}"; do
  curl -s -o /dev/null -H "Accept: image/avif,image/webp" "$url"
  echo "Warmed: $url"
done

正確執行響應式圖片

Next.js 中的響應式圖片並不難，但它們確實需要理解 deviceSizes、imageSizes 和 sizes 屬性如何協同工作。

`fill` 版面配置模式

對於您在構建時不知道寬高比的圖片（CMS 內容、用戶上傳），使用 fill 屬性：

<div className="relative aspect-[16/9] w-full">
  <Image
    src={post.featuredImage}
    alt={post.title}
    fill
    className="object-cover"
    sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw"
  />
</div>

具有 relative 定位和寬高比的父 div 至關重要。沒有它，fill 圖片會折疊為零高度，您會獲得一個會讓您皺眉的 CLS 分數。

使用 `` 的美術指導

有時您需要針對不同的螢幕尺寸進行不同的裁切。next/image 本身不支援 <picture>，但您可以解決它：

// 美術指導解決方案
export function ResponsiveHero({ mobileSrc, desktopSrc, alt }) {
  return (
    <>
      <div className="block md:hidden relative aspect-[9/16] w-full">
        <Image src={mobileSrc} alt={alt} fill priority sizes="100vw" />
      </div>
      <div className="hidden md:block relative aspect-[16/9] w-full">
        <Image src={desktopSrc} alt={alt} fill priority sizes="100vw" />
      </div>
    </>
  );
}

是的，這會下載兩個圖片的 HTML，但只有一個呈現，隱藏的圖片由於延遲載入預設值不會載入（您只對與視埠匹配的圖片應用 priority）。

CDN 和邊緣優化策略

如果您自行託管 Next.js（很多團隊這樣做），您需要一個圖片的 CDN 策略。

選項 1：讓 Vercel 處理它

Vercel 的圖片優化在邊緣運行。對於大多數專案，這是最簡單的路徑。截至 2026 年，Vercel 的 Pro 方案包括 5,000 個具有優化的源圖片，每 1,000 個額外圖片收費 $5。企業方案有自訂定價。

選項 2：外部圖片優化服務

Cloudinary、Imgix 和 Cloudflare Images 都通過 loader 屬性或自訂載入器與 Next.js 一起工作：

// 具有 Cloudinary 的 next.config.js
module.exports = {
  images: {
    loader: 'custom',
    loaderFile: './lib/cloudinary-loader.js',
  },
};

// lib/cloudinary-loader.js
export default function cloudinaryLoader({ src, width, quality }) {
  const params = [
    `w_${width}`,
    `q_${quality || 'auto'}`,
    'f_auto',
    'c_limit',
  ];
  return `https://res.cloudinary.com/your-cloud/image/upload/${params.join(',')}${src}`;
}
服務 免費層 Pro 定價（2026） 邊緣節點 AVIF 支援
Cloudinary 25 積分/月 $89/月（25GB） 60+ 是
Imgix 無 $100/月（100GB） 全球 是
Cloudflare Images 無 $5/月（100K 變體） 310+ 是
Vercel（內置） 1,000 張圖片（Hobby） 包含在 Pro 中 邊緣 是

對於我們的 無頭 CMS 開發專案，我們通常使用 Cloudinary 或 CMS 的內置圖片管道（Sanity、Contentful 和 Hygraph 都有不錯的圖片 API）。

選項 3：Cloudflare Polish + Next.js

如果您已經在 Cloudflare 後面，他們的 Polish 功能可以在邊緣處理格式轉換。您將禁用 Next.js 圖片優化並讓 Cloudflare 完成工作：

module.exports = {
  images: {
    unoptimized: true, // 讓 Cloudflare 處理它
  },
};

我不太喜歡這種方法，因為您會失去 next/image 提供的響應式尺寸調整，但它適用於較簡單的設置。

測量重要指標：工具和基準

您無法改進您沒有測量的東西。以下是我的測試堆棧：

實驗工具

  • Chrome DevTools Lighthouse（截至 2026 年為 v12）：仍然是起點。在無痕模式下運行，不使用擴充功能。
  • WebPageTest：將其設定為杜勒斯、VA 上的 Moto G Power，4G。這代表一個現實的"慢"用戶。
  • Unlighthouse：批量掃描您的整個網站。非常適合捕捉您遺漏的頁面。

欄位資料

  • Chrome UX 報告（CrUX）：Google 用於排名訊號的實際資料。可在 PageSpeed Insights 和 BigQuery 中取得。
  • web-vitals.js：將其添加到您的應用以收集真實用戶指標：
// app/layout.tsx
import { onLCP, onINP, onCLS } from 'web-vitals';

if (typeof window !== 'undefined') {
  onLCP(console.log);
  onINP(console.log);
  onCLS(console.log);
}

在生產中，將這些發送到您的分析平台而不是 console.log。我們使用 Vercel Speed Insights 和一個寫入 BigQuery 的自訂端點的組合。

2026 年基準目標

根據我們今年審計的網站，以下是圖片豐富的 Next.js 網站的"良好"樣子：

  • 行動裝置 LCP（p75）：< 1.8 秒（給您 2.0 秒門檻下的緩衝區）
  • 折線上方的圖片總權重：< 200KB
  • 主圖像載入時間：4G 下 < 800ms
  • 圖片造成的 CLS：0

真正能改變局面的進階技術

使用 BlurHash 的模糊佔位符

Next.js 本身支援靜態匯入的 placeholder="blur"。對於動態圖片（來自 CMS），您需要生成模糊資料 URL：

import { getPlaiceholder } from 'plaiceholder';

export async function getStaticProps() {
  const { base64 } = await getPlaiceholder('/path/to/image.jpg');
  return {
    props: { blurDataURL: base64 },
  };
}

// 在元件中
<Image
  src={dynamicUrl}
  alt="Dynamic image"
  fill
  placeholder="blur"
  blurDataURL={blurDataURL}
/>

這不會直接改進 LCP，但它大大改善了感知性能並防止 CLS。

HTTP/3 和早期提示

如果您的 CDN 支援 HTTP/3（Cloudflare、Fastly 和 Vercel 都支援），您可以使用 103 Early Hints 在 HTML 文件完全生成之前開始發送 LCP 圖片：

// middleware.ts
import { NextResponse } from 'next/server';

export function middleware(request) {
  const response = NextResponse.next();
  
  if (request.nextUrl.pathname === '/') {
    response.headers.set(
      'Link',
      '</hero.avif>; rel=preload; as=image; type="image/avif"'
    );
  }
  
  return response;
}

使用 CSS `content-visibility` 的骨架載入

對於具有許多圖片的長頁面，content-visibility: auto 告訴瀏覽器完全跳過非螢幕外內容的呈現：

.image-grid-item {
  content-visibility: auto;
  contain-intrinsic-size: 300px 200px; /* 估計的大小 */
}

這在我們上季度優化的產品列表頁面上將 INP 減少了 30-40ms。

我在每次審計中看到的常見錯誤

  1. 將 next/image 用於裝飾性 SVG：只需使用 <img> 標籤或內嵌 SVG。優化管道增加開銷而沒有任何好處。

  2. 因為"圖片看起來模糊"全局設定 unoptimized：改為修正質量設定。unoptimized 會繞過所有內容。

  3. 忘記 alt 文字：這不僅是可訪問性——Google 的圖片搜尋帶來流量，它需要 alt 文字來索引您的圖片。

  4. 未設定 minimumCacheTTL：預設值是 60 秒。這意味著您的伺服器在負載下每分鐘重新優化相同的圖片。將其設定為至少 2592000（30 天）。

  5. 使用巨大的源圖片：上傳 6000x4000px 的 DSLR 照片並期望 Next.js 處理它。預先處理您的源圖片為最大顯示尺寸的 2 倍。

  6. 忽視網路標籤：打開 DevTools，篩選 Img，按大小排序。您將在 30 秒內發現問題。

如果您在生產網站上遇到這些問題，那正是我們解決的那類問題。查看我們的定價或直接聯繫——我們將性能審計作為獨立服務提供。

常見問題

next/image 會自動將圖片轉換為 AVIF 嗎？ 是的，如果您在 next.config.js 的 images.formats 陣列中有 'image/avif'（自 Next.js 14 起預設包含）。當瀏覽器發送包含 image/avif 的 Accept 標頭時，轉換會按需進行。第一個請求由於編碼較慢，但後續請求從快取提供。

AVIF 相比 WebP 實際上可以減少多少圖片檔案大小？ 在我們針對數百個生產圖片的測試中，在等效視覺質量下，AVIF 平均比 WebP 小 30-50%，比 JPEG 小 50-70%。對於攝影內容，收益最為戲劇性。對於螢幕截圖或包含文字的圖片，差異縮小至 15-25%。

我應該在多個圖片上使用 priority 嗎？ 謹慎使用它——只在真正在折線上方和初始載入時可見的圖片上使用。向超過 2-3 張圖片添加 priority 會打敗目的，因為瀏覽器無法同時優先考慮所有內容。對於您的主頁主圖和也許一個標誌，就這樣。

為什麼即使使用 next/image 和 priority，我的 LCP 仍然很慢？ 最常見的原因是您的伺服器回應時間（TTFB）佔用了您的預算。如果您的 Next.js 伺服器需要 800ms 才能回應，您只剩下 1.2 秒讓圖片載入和繪製。其他罪魁禍首：呈現阻止 CSS、大型 JavaScript 套件延遲水合，或圖片源在緩慢的源伺服器上。

我可以將 next/image 用於靜態匯出（next export）嗎？ 不能用於內置優化。靜態匯出需要 images.unoptimized: true 或指向 Cloudinary 或 Imgix 等外部服務的自訂載入器。這是我們有時為純靜態網站推薦 Astro 的原因之一——其圖片處理不需要執行伺服器。

如何使用 next/image 處理來自無頭 CMS 的圖片？ 在您的配置中將 CMS 的圖片網域添加到 images.remotePatterns。大多數無頭 CMS 平台（Sanity、Contentful、Storyblok、Hygraph）有自己的圖片轉換 API。您可以通過自訂載入器使用這些 API，或讓 Next.js 處理優化。對於 無頭 CMS 專案，我們通常更喜歡 CMS 的本機管道，因為它減少了伺服器負載。

圖片優化對核心網頁指標排名訊號的影響是什麼？ Google 在 2025 年確認核心網頁指標仍然是排名訊號，儘管內容相關性仍然佔主導。也就是說，對於頂部結果之間內容質量相似的競爭性查詢，CWV 可能是決勝手段。我們看到網站在修復主要由未優化圖片造成的 LCP 問題後移動了 3-8 個位置。

我應該延遲載入折線下方的所有圖片嗎？ 是的，而 Next.js 預設執行此操作（除非您添加 priority）。本機 loading="lazy" 屬性是 next/image 在幕後使用的。不再需要基於 JavaScript 的延遲載入庫了——瀏覽器本機延遲載入自 2022 年以來在所有主要瀏覽器中一直很穩定。