Next.js Bildoptimierung für Core Web Vitals 2026

Ich habe die letzten vier Jahre damit verbracht, Bilder in Next.js-Apps zu optimieren, und ehrlich gesagt – die Landschaft 2026 sieht ganz anders aus als damals, als next/image zum ersten Mal veröffentlicht wurde. Googles Core Web Vitals-Schwellenwerte sind strenger geworden, neue Bildformate haben sich bewährt, und die next/image-Komponente selbst hat mehrere Überarbeitungen durchlaufen. Wenn deine Bilder immer noch wie 2023 konfiguriert sind, verschenkst du Performance (und Rankings).

Das ist keine Zusammenfassung der Next.js-Docs. Das ist das, was ich aus dem Versand von Dutzenden Production-Sites gelernt habe, wo LCP-Scores wirklich zählen – wo ein 200-ms-Unterschied beim Laden von Bildern zwischen Seite eins und Seite drei entschied.

Inhaltsverzeichnis

Next.js Bildoptimierung für Core Web Vitals 2026

Core Web Vitals 2026: Was hat sich geändert

Google hat die Core Web Vitals-Schwellenwerte Ende 2025 aktualisiert, und die Änderungen waren erheblich. So ist die aktuelle Situation:

Metrik 2023 „Gut"-Schwellenwert 2026 „Gut"-Schwellenwert Was es misst
LCP ≤ 2,5s ≤ 2,0s Largest Contentful Paint
INP ≤ 200ms ≤ 150ms Interaction to Next Paint
CLS ≤ 0,1 ≤ 0,1 Cumulative Layout Shift
TTFB N/A (nicht CWV) Informell ≤ 600ms Time to First Byte

Der Rückgang des LCP-Schwellenwerts von 2,5 s auf 2,0 s traf bildreiche Sites am härtesten. Eine halbe Sekunde klingt nicht nach viel, bis man realisiert, dass bei 60%+ aller Seiten das LCP-Element ein Bild ist. Normalerweise ein Hero-Image, ein Produktfoto oder ein Featured-Article-Thumbnail.

INP ersetzte bereits FID, aber der verschärfte 150-ms-Schwellenwert bedeutet, dass schwere JavaScript-Bundles – einschließlich schlecht konfigurierter Image-Lazy-Loading-Skripte – deine Interaktivitäts-Scores ruinieren können.

CLS blieb unverändert, was gute Nachrichten sind. Aber Bilder bleiben die Nummer eins Ursache für Layout Shifts, wenn sie keine expliziten Dimensionen haben.

Warum das speziell für Next.js wichtig ist

Next.js-Apps sind von Natur aus JavaScript-schwer. Du versendest React, du versendest Framework-Code, und wenn du nicht aufpasst, versendest du auch Image-Optimierungslogik Client-seitig. Die Kombination aus einem strengerem LCP-Budget und dem JS-Overhead einer React-App bedeutet, dass du weniger Spielraum für Fehler hast als eine statische HTML-Site.

Genau deshalb konzentrieren wir uns stark auf Next.js-Entwicklung – das Framework bietet dir unglaubliche Tools, aber nur wenn du weißt, wie man sie konfiguriert.

So funktioniert next/image wirklich unter der Haube

Lass uns entmystifizieren, was passiert, wenn du <Image /> von next/image verwendest. Das Verständnis der Pipeline hilft dir, bessere Optimierungsentscheidungen zu treffen.

Der Request-Fluss

  1. Build-Zeit: Next.js generiert HTML mit einem <img>-Tag, das auf /_next/image?url=...&w=...&q=... verweist
  2. Erste Anfrage: Die Next.js Image-Optimierungs-API erhält die Anfrage, fetcht das Original-Image, ändert die Größe, konvertiert das Format und cacht das Ergebnis
  3. Nachfolgende Anfragen: Die gecachte Version wird direkt bereitgestellt

In Next.js 15 (das aktuelle Stable Stand Anfang 2026) nutzt der Image-Optimizer standardmäßig sharp in Node.js-Umgebungen. Bei Vercel wird sein Edge-basierter Image-Optimierungsservice verwendet. Auf anderen Plattformen fällt es auf sharp oder squoosh abhängig von deiner Konfiguration zurück.

// Basis-Nutzung -- aber hier passiert viel hinter den Kulissen
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}
    />
  );
}

Dieses priority-Prop macht mehr als du denkst. Es fügt fetchpriority="high" zum HTML hinzu, deaktiviert Lazy Loading und generiert ein Preload-<link>-Tag im <head>. Wir werden später zurückkommen, warum das für LCP wichtig ist.

Die Config, die die meisten nie anfassen

Deine next.config.js (oder next.config.ts wenn du migriert hast) hat einen images-Schlüssel, der alles kontrolliert:

// 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 Jahr in Sekunden
    dangerouslyAllowSVG: false,
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'your-cms.com',
        pathname: '/assets/**',
      },
    ],
  },
};

Die Reihenfolge des formats-Arrays ist wichtig. Next.js wird zuerst AVIF versuchen, dann zu WebP fallback. AVIF-Kodierung ist langsamer, produziert aber kleinere Dateien – dieser Trade-off ist wichtig zu verstehen.

Das LCP-Problem: Warum dein Hero-Image deinen Score zerstört

Hier ist das Szenario, das ich bei fast jedem Audit sehe: ein wunderschönes Hero-Image, above the fold, das 3+ Sekunden zum Rendern braucht. Der Entwickler verwendete next/image, dachte, er wäre fertig, und machte weiter. Aber der Score ist furchtbar.

Die üblichen Verdächtigen:

1. Das `priority`-Prop fehlt

Standardmäßig lazy-loadt next/image alles. Das ist großartig für Below-the-fold-Images, aber katastrophal für dein LCP-Element. Ohne priority entdeckt der Browser das Image spät, nachdem JavaScript hydratisiert hat und der Intersection Observer startet.

// ❌ Dies lazy-loadt dein LCP-Image
<Image src="/hero.jpg" alt="Hero" width={1200} height={630} />

// ✅ Dies preloadt es
<Image src="/hero.jpg" alt="Hero" width={1200} height={630} priority />

2. Überkompressionierung mit niedrigen Quality-Werten

Ich habe Teams gesehen, die quality={50} setzen und denken, dass kleiner = schneller. Aber wenn das Image verschwommen aussieht, muss Chromes LCP-Algorithmus immer noch warten, bis es vollständig gemalt ist. Und auf High-DPI-Screens lösen Quality-Werte unter 70 oft sichtbare Artefakte aus, die die Grafik billig aussehen lassen.

Meine Faustregel: Quality 75-85 für Fotos, Quality 90+ für Bilder mit Text oder scharfen Kanten.

3. `sizes` nicht korrekt verwenden

Das sizes-Attribut teilt dem Browser mit, welche Image-Breite anforderbar ist, bevor CSS geparst wird. Ohne es greift Next.js auf 100vw zurück, was bedeutet, dass Mobile-Geräte Desktop-große Images herunterladen.

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

Dieses einzelne Prop hat mir die größten LCP-Verbesserungen gebracht – manchmal 400-800ms auf Mobile.

Next.js Bildoptimierung für Core Web Vitals 2026 - Architektur

Format-Kriege: AVIF vs WebP vs JPEG XL 2026

Die Format-Landschaft hat sich erheblich beruhigt. So sieht die Situation aus:

Format Browser-Unterstützung (2026) Komprimierung Kodierungsgeschwindigkeit Beste Verwendung
AVIF ~95% weltweit Ausgezeichnet (30-50% kleiner als WebP) Langsam Fotos, Hero-Images
WebP ~98% weltweit Gut (25-35% kleiner als JPEG) Schnell Allgemeine Verwendung
JPEG XL ~45% (Chrome hat es entfernt) Ausgezeichnet Mittel Nicht empfohlen für Web
JPEG Universal Baseline Schnell Nur Fallback
PNG Universal Schlecht für Fotos Schnell Transparenz, Screenshots

JPEG XL hatte eine vielversprechende Spezifikation, aber Chromes Entscheidung, Unterstützung Ende 2023 zu entfernen, tötete es praktisch für Web-Einsatz. Safari hat Unterstützung hinzugefügt, Firefox hat teilweise Unterstützung, aber du kannst nicht darauf rechnen.

Meine Empfehlung: Setze formats: ['image/avif', 'image/webp'] und vergiss es. Next.js handhabt Content-Negotiation durch den Accept-Header automatisch.

Die AVIF-Kodierungskosten

Hier ist etwas, das die Docs nicht genug betonen: AVIF-Kodierung ist CPU-intensiv. Bei einer ersten Anfrage an deinen Next.js-Server kann die Kodierung eines 1200px AVIF-Images 2-5 Sekunden auf einem bescheidenen Server dauern. Das erste Besuch zahlt dafür.

Strategien zur Minderung:

  • Vorher bei Build-Zeit generieren mit next export oder benutzerdefinierten Build-Skripten
  • Einen CDN mit eingebauter Image-Optimierung verwenden (Cloudflare Images, Imgix, Cloudinary)
  • Deinen Cache aufwärmen nach Deployment mit einem Skript, das alle kritischen Image-URLs trifft
# Einfaches Cache-Warming-Skript
#!/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

Responsive Images richtig gemacht

Responsive Images in Next.js sind nicht schwer, aber sie erfordern Verständnis für wie deviceSizes, imageSizes und das sizes-Prop zusammenwirken.

Das `fill`-Layout-Muster

Für Images, bei denen du das Seitenverhältnis zur Build-Zeit nicht kennst (CMS-Inhalte, Benutzer-Uploads), verwende das fill-Prop:

<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>

Das Parent-div mit relative-Positionierung und einem Seitenverhältnis ist kritisch. Ohne es brechen fill-Images auf null Höhe zusammen und du bekommst einen CLS-Score, der dich zusammenzucken lässt.

Art Direction mit ``

Manchmal brauchst du unterschiedliche Beschneidungen für unterschiedliche Bildschirmgrößen. next/image unterstützt <picture> nativ nicht, aber du kannst eine Workaround machen:

// Art Direction Workaround
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>
    </>
  );
}

Ja, das lädt beide Images' HTML, aber nur eines rendert, und das versteckte lädt nicht dank Lazy-Loading-Standards (du würdest priority nur auf das anwenden, das dem Viewport entspricht).

CDN- und Edge-Optimierungsstrategien

Wenn du Next.js selbst hostest (und viele Teams tun das), brauchst du eine CDN-Strategie für Images.

Option 1: Lass Vercel es handhaben

Vercels Image-Optimierung läuft am Edge. Für die meisten Projekte ist das der einfachste Weg. Stand 2026 enthält Vercels Pro-Plan 5.000 Source-Images mit Optimierung, mit zusätzlichen Images zu $5 pro 1.000. Enterprise-Pläne haben maßgeschneidertes Pricing.

Option 2: Externer Image-Optimierungsservice

Cloudinary, Imgix und Cloudflare Images funktionieren alle mit Next.js über das loader-Prop oder einen benutzerdefinierten Loader:

// next.config.js mit Cloudinary
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}`;
}
Service Free Tier Pro Pricing (2026) Edge Nodes AVIF-Unterstützung
Cloudinary 25 Credits/Monat $89/Monat (25GB) 60+ Ja
Imgix Keine $100/Monat (100GB) Global Ja
Cloudflare Images Keine $5/Monat (100K Varianten) 310+ Ja
Vercel (eingebaut) 1.000 Images (Hobby) In Pro enthalten Edge Ja

Für unsere Headless CMS-Entwicklung verwenden wir typischerweise Cloudinary oder die eingebaute Image-Pipeline des CMS (Sanity, Contentful und Hygraph haben alle anständige Image-APIs).

Option 3: Cloudflare Polish + Next.js

Wenn du bereits hinter Cloudflare bist, kann ihr Polish-Feature Format-Konvertierung am Edge handhaben. Du würdest Next.js Image-Optimierung deaktivieren und Cloudflare die Arbeit machen lassen:

module.exports = {
  images: {
    unoptimized: true, // Lass Cloudflare das machen
  },
};

Ich bin kein großer Fan dieses Ansatzes, weil du die responsive Größenanpassung verlierst, die next/image bietet, aber es funktioniert für einfachere Setups.

Messung, die zählt: Tools und Benchmarks

Du kannst nicht verbessern, was du nicht misst. Hier ist mein Test-Stack:

Lab-Tools

  • Chrome DevTools Lighthouse (v12 Stand 2026): Immer noch der Ausgangspunkt. Führe es im Incognito mit keinen Erweiterungen aus.
  • WebPageTest: Stelle es auf Dulles, VA mit einem Moto G Power und 4G ein. Das repräsentiert einen realistischen „langsamen" Benutzer.
  • Unlighthouse: Bulk-scannt deine ganze Website. Fantastisch zum Erfassen von Seiten, die du vergessen hast.

Field Data

  • Chrome UX Report (CrUX): Die echten Daten, die Google für Ranking-Signale nutzt. Verfügbar in PageSpeed Insights und BigQuery.
  • web-vitals.js: Füge es zu deiner App hinzu, um echte Benutzer-Metriken zu sammeln:
// app/layout.tsx
import { onLCP, onINP, onCLS } from 'web-vitals';

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

In Production würdest du diese statt console.log an deine Analytics-Plattform senden. Wir verwenden eine Kombination aus Vercel Speed Insights und einen benutzerdefinierten Endpoint, der in BigQuery schreibt.

Benchmark-Ziele für 2026

Basierend auf den Sites, die wir dieses Jahr auditiert haben, so sieht „gut" für bildreiche Next.js-Sites aus:

  • LCP auf Mobile (p75): < 1,8s (gibt dir Puffer unter dem 2,0s-Schwellenwert)
  • Gesamtbildgewicht above the fold: < 200KB
  • Hero-Image-Ladezeit: < 800ms auf 4G
  • CLS von Images: 0

Fortgeschrittene Techniken, die tatsächlich Ergebnisse bringen

Blur Placeholders mit BlurHash

Next.js unterstützt placeholder="blur" nativ für statische Importe. Für dynamische Images (von einem CMS) musst du Blur-Data-URLs generieren:

import { getPlaiceholder } from 'plaiceholder';

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

// In Komponente
<Image
  src={dynamicUrl}
  alt="Dynamic image"
  fill
  placeholder="blur"
  blurDataURL={blurDataURL}
/>

Das verbessert LCP nicht direkt, aber es verbessert dramatisch wahrgenommene Performance und verhindert CLS.

HTTP/3 und Early Hints

Wenn dein CDN HTTP/3 unterstützt (Cloudflare, Fastly und Vercel tun alle), kannst du 103 Early Hints verwenden, um das LCP-Image zu senden, bevor das HTML-Dokument überhaupt vollständig generiert ist:

// 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;
}

Skeleton Loading mit CSS `content-visibility`

Für lange Seiten mit vielen Images teilt content-visibility: auto dem Browser mit, komplett Off-Screen-Content zu überspringen:

.image-grid-item {
  content-visibility: auto;
  contain-intrinsic-size: 300px 200px; /* Geschätzte Größe */
}

Das reduzierte INP um 30-40ms auf einer Product-Listing-Seite, die wir letztes Quartal optimiert haben.

Häufige Fehler, die ich bei jedem Audit sehe

  1. next/image für dekorative SVGs verwenden: Verwende einfach ein <img>-Tag oder inline das SVG. Die Optimierungs-Pipeline fügt Overhead für null Gewinn hinzu.

  2. unoptimized global setzen, weil „Images sehen verschwommen aus": Behebt stattdessen die Quality-Einstellung. unoptimized umgeht alles.

  3. alt-Text vergessen: Das ist nicht nur Accessibility – Googles Image-Suche bringt Traffic, und sie braucht Alt-Text zum Indexieren deiner Images.

  4. minimumCacheTTL nicht setzen: Standard ist 60 Sekunden. Das bedeutet dein Server optimiert dasselbe Image jede Minute unter Last neu. Setze es auf mindestens 2592000 (30 Tage).

  5. Massive Source-Images verwenden: Ein 6000x4000px DSLR-Foto hochladen und erwartet, dass Next.js es handhaben kann. Vorverarbeite deine Source-Images zu maximal 2x deiner größten Display-Größe.

  6. Den Network-Tab ignorieren: Öffne DevTools, filtere nach Img, sortiere nach Größe. Du findest Probleme in 30 Sekunden.

Wenn du mit diesen Problemen auf einer Production-Site kämpfst, ist das genau die Art Problem, die wir lösen. Schau dir unser Pricing an oder kontaktiere uns direkt – wir führen Performance-Audits als eigenständige Engagements durch.

FAQ

Konvertiert next/image Bilder automatisch zu AVIF?

Ja, wenn du 'image/avif' in deinem images.formats-Array in next.config.js hast (das ist seit Next.js 14 enthalten). Die Konvertierung passiert on-demand, wenn ein Browser einen Accept-Header sendet, der image/avif enthält. Die erste Anfrage ist langsamer aufgrund der Kodierung, aber nachfolgende Anfragen werden aus dem Cache bereitgestellt.

Wie sehr reduziert AVIF tatsächlich Image-Dateigröße im Vergleich zu WebP?

In unserem Test über Hunderte von Production-Images ist AVIF durchschnittlich 30-50% kleiner als WebP bei gleichwertiger visueller Qualität und 50-70% kleiner als JPEG. Die Gewinne sind am dramatischsten bei fotografischem Content. Für Screenshots oder Bilder mit Text verengt sich der Unterschied auf 15-25%.

Sollte ich priority auf mehreren Images verwenden? Verwende es sparsam – nur auf Images, die wirklich above the fold sind und beim initialen Load sichtbar sind. Das Hinzufügen von priority zu mehr als 2-3 Images besiegt den Zweck, weil der Browser nicht alles gleichzeitig priorisieren kann. Für dein Homepage-Hero und vielleicht ein Logo, das ist es.

Warum ist mein LCP immer noch langsam, auch mit next/image und priority?

Der häufigste Grund ist, dass deine Server-Response-Zeit (TTFB) in dein Budget frisst. Wenn dein Next.js-Server 800ms braucht zu antworten, hast du nur noch 1,2 Sekunden für das Image zum Laden und Rendern. Andere Schuldige: Render-blocking CSS, große JavaScript-Bundles, die Hydratisierung verzögern, oder das Image-Source auf einem langsamen Origin-Server.

Kann ich next/image mit Static Exports verwenden (next export)?

Nicht mit der eingebauten Optimierung. Static Exports erfordern images.unoptimized: true oder einen benutzerdefinierten Loader, der auf einen externen Service wie Cloudinary oder Imgix verweist. Das ist ein Grund, warum wir manchmal Astro für rein statische Sites empfehlen – die Image-Behandlung braucht keinen Running Server.

Wie handhabe ich Images von einem Headless CMS mit next/image?

Füge die CMS-Image-Domain zu images.remotePatterns in deiner Config hinzu. Die meisten Headless CMS-Plattformen (Sanity, Contentful, Storyblok, Hygraph) haben ihre eigenen Image-Transformations-APIs. Du kannst entweder derer nutzen über einen benutzerdefinierten Loader oder Next.js die Optimierung handhaben lassen. Wir bevorzugen normalerweise die native Pipeline des CMS für Headless CMS-Projekte, weil sie Server-Last reduziert.

Welche Auswirkung hat Image-Optimierung auf Core Web Vitals Ranking-Signale?

Google bestätigte 2025, dass Core Web Vitals ein Ranking-Signal bleiben, obwohl Inhaltsrelevanz immer noch dominiert. Aber für kompetitive Anfragen, wo Inhaltsqualität ähnlich ist über die Top-Ergebnisse, kann CWV der Tiebreak sein. Wir haben Sites 3-8 Positionen bewegt, nach dem Fixen von LCP-Problemen, die hauptsächlich von unoptimierten Images verursacht wurden.

Sollte ich alle Images below the fold lazy-loaden?

Ja, und Next.js macht das standardmäßig (außer du fügst priority hinzu). Das native loading="lazy"-Attribut ist das, das next/image unter der Haube nutzt. Es gibt keinen Grund mehr für eine JavaScript-basierte Lazy-Loading-Bibliothek – Browser-natives Lazy Loading ist seit 2022 stabil über alle Major Browser.