Lazy Loading für Bilder mit Claude Code sicher umsetzen

Lazy Loading für Bilder bedeutet nicht, überall loading="lazy" einzufügen. Wenn Claude Code auch das Hero-Bild verzögert, kann der Largest Contentful Paint schlechter werden, also der Zeitpunkt, an dem der wichtigste sichtbare Inhalt erscheint. Wenn dagegen alle Produktbilder, Galerie-Bilder und Related-Post-Thumbnails sofort laden, bezahlen mobile Nutzer für Bilder, die sie vielleicht nie sehen.

Dieser aktualisierte Leitfaden zeigt ein sicheres Muster für Einsteiger: natives Lazy Loading, eager für Hero oder LCP-Kandidat, decoding, fetchpriority, feste Abmessungen gegen CLS, responsive srcset und sizes, IntersectionObserver für Sonderfälle, Platzhalter, SEO- und UX-Fallen, Messung und sichere Claude-Code-Prompts. Geprüft habe ich die Empfehlungen gegen MDN zumimg-Element, Intersection Observer API, web.dev zuBrowser-Level Image Lazy Loading, Core Web Vitals und Chrome zuLCP request discovery.

Für das Gesamtbild passen dazuImage Optimization, Skeleton Loading undPerformance Optimization.

Die Grundregel

Lade nicht verzögert, was Nutzer sofort sehen. Bilder unterhalb des ersten Viewports können natives Lazy Loading verwenden. Für jedes Bild muss der Platz stabil reserviert sein, entweder mitwidth undheight oder einem passendenaspect-ratio.

Position	loading	fetchpriority	decoding	Schutzregel
Hero oder LCP-Kandidat	eager oder weglassen	high prüfen	sync oder async	Im initialen HTML auffindbar
Diagramm in der Artikelmitte	lazy	auto	async	Abmessungen behalten
Produktgrid nach dem ersten Screen	lazy	auto	async	srcset und sizes nutzen
Carousel oder Infinite Scroll	Kommt darauf an	auto	async	IntersectionObserver bei Bedarf

Der typische Anfängerfehler lautet: “Das Bild ist groß, also lazy.” Die bessere Frage ist, ob das Bild für den ersten sinnvollen Eindruck gebraucht wird. Die Chrome-Dokumentation zu LCP empfiehlt, das LCP-Bild früh auffindbar zu machen, angemessen zu priorisieren und nicht mitloading=lazy zu markieren.

HTML zum Kopieren

Das erste Bild ist das Hero-Bild, daher eager und hohe Priorität. Das zweite Bild steht weiter unten im Artikel oder in einer Liste und nutzt natives Lazy Loading mit asynchronem Decoding.

<img
  class="hero-image"
  src="/images/hero/product-dashboard-1200.webp"
  srcset="
    /images/hero/product-dashboard-640.webp 640w,
    /images/hero/product-dashboard-1200.webp 1200w
  "
  sizes="100vw"
  alt="Erste Ansicht eines Produkt-Dashboards"
  width="1200"
  height="675"
  loading="eager"
  fetchpriority="high"
  decoding="sync"
/>

<img
  class="article-image"
  src="/images/articles/setup-step-800.webp"
  srcset="
    /images/articles/setup-step-400.webp 400w,
    /images/articles/setup-step-800.webp 800w
  "
  sizes="(max-width: 720px) 100vw, 720px"
  alt="Screenshot eines Einrichtungsschritts"
  width="800"
  height="450"
  loading="lazy"
  decoding="async"
/>

decoding="async" ist ein Hinweis an den Browser. Er kann das Bild decodieren, ohne andere Rendering-Arbeit so stark zu blockieren. Für Artikelbilder und Thumbnails ist das ein sinnvoller Standard. Beim Hero-Bild sollte mansync gegenasync messen.

CLS mit CSS verhindern

CLS steht für Cumulative Layout Shift. Einfach gesagt misst es, wie stark die Seite springt, während Nutzer lesen oder klicken. Wenn ein Bild ohne reservierte Höhe erscheint, verschiebt es Text, Anzeigen, Formulare und CTAs. Das ist ein echtes UX- und Umsatzproblem.

.image-frame {
  aspect-ratio: 16 / 9;
  background: #f3f4f6;
  overflow: hidden;
}

.image-frame > img {
  display: block;
  width: 100%;
  height: 100%;
  object-fit: cover;
}

@media (prefers-reduced-motion: no-preference) {
  .image-frame > img {
    transition: opacity 180ms ease-out;
  }
}

Wenn das CMS die Originalmaße kennt, speichere sie und reiche sie an das Template weiter. Bei unbekannten externen Bildern ist ein stabiler Container mitaspect-ratio die pragmatische Lösung.

Eine kleine React-Komponente

Wenn Claude Code ein React-Projekt anpasst, sollte die Regel in einer Komponente landen. Priorisierte Bilder sind eager, normale Inhaltsbilder lazy, und alle behalten ihre Abmessungen.

type SmartImageProps = {
  src: string;
  srcSet?: string;
  sizes?: string;
  alt: string;
  width: number;
  height: number;
  priority?: boolean;
  className?: string;
};

export function SmartImage({
  src,
  srcSet,
  sizes,
  alt,
  width,
  height,
  priority = false,
  className,
}: SmartImageProps) {
  const loading = priority ? "eager" : "lazy";
  const fetchPriority = priority ? "high" : "auto";
  const decoding = priority ? "sync" : "async";

  return (
    <span
      className={`image-frame ${className ?? ""}`}
      style={{ aspectRatio: `${width} / ${height}` }}
    >
      <img
        src={src}
        srcSet={srcSet}
        sizes={sizes}
        alt={alt}
        width={width}
        height={height}
        loading={loading}
        fetchPriority={fetchPriority}
        decoding={decoding}
      />
    </span>
  );
}

Die Komponente bleibt bewusst unspektakulär. Sie versteckt wichtige Bilder nicht hinter JavaScript und kann in Next.js, Astro oder CMS-Komponenten übertragen werden.

Praktische Produktfälle

Erster Fall: ein Ecommerce-Produktgrid. Die ersten Produkte können im ersten Viewport liegen, also nicht alles blind lazy setzen. Empfehlungen, Reviews, Verlauf und die zweite sichtbare Reihe sind bessere Kandidaten. Ein konkreter Fehler istfetchpriority="high" auf jeder Miniatur. Dann kann der Browser nicht mehr unterscheiden, was wirklich dringend ist.

Zweiter Fall: ein Tutorial oder Medienartikel. Das Cover ist oft LCP-Kandidat und bleibt eager. Screenshots weiter unten, Diagramme nach Codeblöcken und Related Cards können lazy sein. Ein Fehler ist ein verschwommener Placeholder als Hintergrund, während das echte Bild leerenalt-Text hat. Bedeutungsvolle Bilder brauchen Text für SEO und Screenreader.

Dritter Fall: ein SaaS-Dashboard. Avatare, Kundenlogos, Report-Thumbnails und Audit-Screenshots können in langen Listen vorkommen. Offscreen-Zeilen lazy zu laden hilft. Das obere Hauptdiagramm, Onboarding-Bild oder CTA-nahe Bild sollte aber nicht verzögert werden. Für CTA- und Umsatzmessung passt dazuAnalytics Implementation.

Vierter Fall: Galerie oder horizontales Carousel. Natives Lazy Loading reicht oft. IntersectionObserver lohnt sich bei eigenen Scroll-Containern, versteckten Slides oder genauer Vorlade-Distanz.

Wann IntersectionObserver sinnvoll ist

Natives Lazy Loading ist die erste Wahl. IntersectionObserver kommt dazu, wenn du 300px vor Sichtbarkeit laden,data-src ersetzen, Placeholder-Klassen entfernen oder einen bestimmten Scroll-Container beobachten willst.

<img
  class="js-lazy-image"
  src="/images/placeholders/report-thumb.svg"
  data-src="/images/reports/report-2026.webp"
  data-srcset="/images/reports/report-2026.webp 1x"
  alt="Miniatur eines Monatsreports"
  width="640"
  height="360"
/>

const lazyImages = document.querySelectorAll("img[data-src]");

function loadImage(img) {
  img.src = img.dataset.src;

  if (img.dataset.srcset) {
    img.srcset = img.dataset.srcset;
  }

  img.removeAttribute("data-src");
  img.removeAttribute("data-srcset");
}

if ("IntersectionObserver" in window) {
  const observer = new IntersectionObserver((entries, currentObserver) => {
    entries.forEach((entry) => {
      if (!entry.isIntersecting) return;

      loadImage(entry.target);
      currentObserver.unobserve(entry.target);
    });
  }, {
    rootMargin: "300px 0px",
    threshold: 0.01,
  });

  lazyImages.forEach((image) => observer.observe(image));
} else {
  lazyImages.forEach(loadImage);
}

Auch hier bleiben die Dimensionen erhalten. Eindata-src-Bild lädt bei JavaScript-Fehlern eventuell nie. Nutze dieses Muster nicht für das Hauptproduktbild, Hero-Bild oder SEO-zentrale Bilder.

Messen statt raten

Core Web Vitals betrachten LCP, INP und CLS. Gute Richtwerte sind LCP bis 2,5 Sekunden, INP bis 200 ms und CLS bis 0,1. Bei Lazy Loading für Bilder bewegen sich vor allem LCP und CLS.

npm install web-vitals

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

onLCP((metric) => {
  const lastEntry = metric.entries.at(-1);
  console.log("LCP", metric.value, lastEntry?.element);
});

onCLS((metric) => {
  console.log("CLS", metric.value, metric.entries);
});

onINP((metric) => {
  console.log("INP", metric.value, metric.entries);
});

In Chrome DevTools prüfst du, ob das LCP-Element das erwartete Hero-Bild ist, ob die Anfrage früh im HTML entdeckt wird und ob Bilder Layout Shifts verursachen. Nach dem Veröffentlichen gehören PageSpeed Insights, Search Console und eigene Analytics dazu.

Sicherer Claude-Code-Prompt

Claude Code kann viele Dateien schnell ändern. Deshalb braucht es Scope, Regeln und Prüfung vorab.

{
  "goal": "Sicheres Lazy Loading für Bilder hinzufügen",
  "scope": [
    "Nur Artikelbilder und Produktlistenbilder ändern",
    "Keine First-Viewport- oder LCP-Kandidaten lazy laden"
  ],
  "rules": [
    "alt, width und height an jedem img behalten",
    "Unterhalb des Fold loading=\"lazy\" und decoding=\"async\" verwenden",
    "Für Hero loading=\"eager\" nutzen oder loading weglassen",
    "fetchpriority=\"high\" höchstens für einen LCP-Kandidaten verwenden"
  ],
  "verification": [
    "MDX und Code-Fences prüfen",
    "LCP und CLS in DevTools kontrollieren",
    "Mobile Breite auf Bild-, Text- und CTA-Überlappung prüfen"
  ]
}

Claude Code soll außerdem melden, welche Bilder nicht lazy wurden und warum. Gute Optimierung enthält bewusst ausgelassene Änderungen.

Fehlerliste

• Hero, Hauptproduktbild oder oberes CTA-Bild wurde lazy.
• width undheight wurden entfernt.
• Alle Bilder habenfetchpriority="high".
• srcset-Varianten haben ohne Art Direction verschiedene Seitenverhältnisse.
• Ein CSS-Hintergrundbild wurde wie einimg behandelt.
• Ein sinnvolles Diagramm hat leerenalt-Text.
• Wichtige Bilder hängen komplett von JavaScript ab.
• Der Placeholder wirkt wichtiger als der echte Inhalt.

CTA und Prüfnotiz

Lazy Loading ist nicht nur ein Score-Trick. Es beeinflusst Lesetiefe, CTA-Sichtbarkeit, Produktnavigation und die erste Aktion in einer App. Einzelpersonen starten mit demkostenlosen Claude-Code-Cheatsheet. Wiederverwendbare Prompts und Review-Vorlagen stehen auf derProduktseite. Teams, die Performance, SEO, Analytics und Monetarisierung verbinden wollen, nutzenClaude Code Training und Beratung.

Für diese Aktualisierung habe ich die offiziellen Quellen oben erneut geprüft und die Beispiele um eine praktische Regel gebaut: zuerst entscheiden, welche Bilder nicht lazy sein dürfen. In Masas Workflow war die stabile Kombination: Hero eager, spätere Screenshots lazy, Dimensionen überall, mobilessrcset und ein Claude-Code-Prompt mit Fehlerfällen und Messaufgaben.