
LCP unter 2,5 Sekunden: Bildformate AVIF und WebP, passende Bildgrößen, Lazy Loading ohne Fehler, Hero-Bild priorisieren und next/image-Grundlagen – verständlich für Unternehmer und Entwickler.
Wenn eine Website langsam wirkt, liegt es in den meisten Fällen nicht an „zu wenig Technik“, sondern an einem einzigen Foto: dem großen Bild ganz oben. Es ist zu groß, im falschen Format oder wird zu spät geladen. Die gute Nachricht: Bilder sind der Performance-Hebel mit dem besten Verhältnis von Aufwand und Wirkung, und die wichtigsten Regeln lassen sich in einer Stunde umsetzen.
Du bekommst:
- eine Kurzantwort, wie du den LCP unter 2,5 Sekunden bringst
- eine Anleitung, wie du das Element findest, das wirklich bremst
- Bildformate im Vergleich mit klarer Empfehlung, wann AVIF, WebP, SVG oder JPEG
- Tabellen zu Bildgrößen und Lazy Loading, die du direkt anwenden kannst
- die Grundlagen von next/image für alle, die mit Next.js arbeiten
- einen Workflow für WordPress, Shopify und Next.js sowie eine Checkliste
Der Artikel richtet sich an Inhaber, die verstehen wollen, was ihre Agentur meint, und an alle, die Bilder selbst hochladen. Die technischen Abschnitte sind gekennzeichnet und lassen sich überspringen.
Kurzantwort: So bekommst du den LCP unter 2,5 Sekunden
Der LCP (Largest Contentful Paint) ist die Zeit, bis das größte sichtbare Element fertig gezeichnet ist, und Google stuft bis 2,5 Sekunden als gut ein. Auf den meisten Unternehmenswebsites ist dieses Element das Hero-Bild im Kopfbereich. Um den LCP zu senken, brauchst du vier Dinge: Das Bild wird in der Größe ausgeliefert, in der es angezeigt wird, nicht in Kamera-Auflösung. Es kommt als WebP oder AVIF, nicht als JPEG oder PNG. Es wird mit hoher Priorität und ohne Lazy Loading geladen, während alle Bilder weiter unten verzögert laden dürfen. Und es hat feste Breite und Höhe, damit die Seite nicht springt. Wer diese vier Punkte umsetzt und einen Server hat, der in unter 0,8 Sekunden antwortet, erreicht in vielen Projekten einen LCP im grünen Bereich, ohne die Website neu zu bauen.
Was ein langsames Hero-Bild dein Unternehmen kostet
Ein Besucher tippt auf dein Google-Ergebnis. Logo und Menü erscheinen, darunter bleibt eine graue Fläche. Eine Sekunde, zwei, drei. In dieser Zeit hat er dein Angebot nicht gesehen, keinen Text gelesen und keine Telefonnummer gefunden. Auf dem Handy, im Mobilfunknetz, unterwegs, ist der Rückweg zu Google ein einziger Wisch.
Genau diesen Moment misst der LCP. Er ist einer der drei Core Web Vitals, mit denen Google die Nutzererfahrung bewertet, und derjenige, den Besucher am direktesten spüren. Ein Überblick über alle drei Werte und ihre Schwellen steht im Artikel Core Web Vitals erklärt.
Für dein Unternehmen heißt das konkret:
- Anfragen: Wer die Seite nicht sieht, ruft nicht an. Das gilt für die Praxis in Stadtfeld genauso wie für den Onlineshop.
- Werbebudget: Jede Anzeige, die auf eine langsame Seite führt, bezahlt Klicks, die vor dem Laden abbrechen.
- Sichtbarkeit: Core Web Vitals sind ein Ranking-Signal, ein kleines, aber bei vergleichbaren Anbietern ein Unterschied.
- Kosten: Zu große Bilder verbrauchen Speicher, Bandbreite und bei manchen Hosting-Tarifen bares Geld.
Das LCP-Element finden: Welches Bild wirklich bremst
Bevor du irgendetwas optimierst, musst du wissen, welches Element den LCP bestimmt. Es ist nicht immer das, was du erwartest, und es unterscheidet sich oft zwischen Handy und Desktop.
- Öffne PageSpeed Insights, gib die URL ein und wähle den Reiter „Mobil“.
- Scrolle zur Diagnose und öffne „Largest Contentful Paint-Element“. Dort siehst du das Element mit Vorschau: ein Bild, ein Textblock oder ein Video-Vorschaubild.
- Wiederhole das für „Desktop“. Häufig ist mobil ein Bild das größte Element, auf dem Desktop eine Überschrift.
- Prüfe neben der Startseite auch die Seiten, die Anfragen bringen: Leistungsseiten, Kontaktseite, wichtige Produktseiten.
Für Entwickler ist das Performance-Panel der Chrome DevTools der genauere Weg: Aufzeichnung starten, Seite laden, in der Zeitleiste den Eintrag „LCP“ anklicken, das Element wird markiert. Dort siehst du auch, wann das Bild angefordert wurde, wann es ankam und ob es auf etwas gewartet hat.
Als LCP-Element kommen Bilder, Vorschaubilder von Videos, per CSS gesetzte Hintergrundbilder und Textblöcke in Frage. Wenn dein LCP-Element ein Bild ist, hast du Glück: Das ist der Fall, der sich am schnellsten lösen lässt.
Tipp: Wenn das LCP-Element ein Slider ist, ist die beste Optimierung, den Slider zu entfernen. Ein Slider lädt mehrere große Bilder plus ein Skript, und die meisten Besucher sehen ohnehin nur das erste Bild. Ein statisches Hero-Bild mit klarer Aussage bringt mehr Anfragen und einen besseren LCP.
Bildformate im Vergleich: AVIF, WebP, JPEG, PNG, SVG
Das Format entscheidet über die Dateigröße bei gleicher sichtbarer Qualität. Alle aktuellen Browser zeigen WebP und AVIF an, alte Ausreden gelten nicht mehr.
| Format | Geeignet für | Dateigröße | Empfehlung |
|---|---|---|---|
| AVIF | Fotos, große Hero-Bilder, Produktbilder | Kleinste Dateien bei gleicher Qualität, meist noch unter WebP | Erste Wahl für Fotos, wenn dein System es erzeugt; Kompression kostet beim Erstellen etwas mehr Rechenzeit |
| WebP | Fotos, Grafiken, Bilder mit Transparenz | Deutlich kleiner als JPEG und PNG | Solider Standard, überall unterstützt, sichere Wahl |
| JPEG | Fotos | Größer als WebP und AVIF | Nur noch als Quelle oder wenn das System kein modernes Format erzeugt |
| PNG | Grafiken mit Transparenz, Screenshots mit Text | Sehr groß bei Fotos | Nie für Fotos; für Grafiken durch SVG oder WebP ersetzen |
| SVG | Logos, Icons, einfache Illustrationen | Winzig, verlustfrei skalierbar | Immer für Logos und Icons; nicht für Fotos |
| GIF | Kurze Animationen | Riesig | Durch kurze Videos oder animierte WebP ersetzen |
Zwei Regeln reichen für den Alltag: Fotos als WebP oder AVIF, Logos und Icons als SVG. Die Qualitätsstufe liegt bei Fotos sinnvoll zwischen 70 und 85 Prozent; darüber wächst die Datei, ohne dass man einen Unterschied sieht. Bei einer Praxis-Website mit Team-Fotos oder einem Shop mit Produktbildern macht allein der Formatwechsel oft den Unterschied zwischen mehreren Megabyte und wenigen hundert Kilobyte pro Seite.
Formate ersetzen aber nicht die richtige Größe. Ein AVIF in 5.000 Pixel Breite ist immer noch zu groß, wenn es in 400 Pixel angezeigt wird.
Bildgrößen: Wie groß ein Bild wirklich sein muss
Der häufigste Fehler ist ein Foto direkt aus der Kamera oder vom Fotografen: 6.000 Pixel breit, mehrere Megabyte, und der Browser verkleinert es auf Handybreite. Die Regel: Ein Bild ist so groß, wie es angezeigt wird, mal zwei für hochauflösende Bildschirme.
| Einsatz | Angezeigte Breite | Sinnvolle Bildbreite | Zieldateigröße als Faustregel |
|---|---|---|---|
| Hero-Bild über volle Breite, Desktop | bis 1.920 Pixel | 1.600 bis 1.920 Pixel | unter 200 KB |
| Hero-Bild, Handy | 360 bis 430 Pixel | 750 bis 850 Pixel | unter 100 KB |
| Inhaltsbild in Textspalte | 600 bis 800 Pixel | 1.200 bis 1.600 Pixel | unter 120 KB |
| Produktbild im Raster | 250 bis 400 Pixel | 500 bis 800 Pixel | unter 60 KB |
| Team-Foto, Vorschaubild | 150 bis 300 Pixel | 300 bis 600 Pixel | unter 40 KB |
| Logo | 100 bis 250 Pixel | als SVG unabhängig von der Größe | unter 20 KB |
Die entscheidende Technik dahinter heißt responsive Bilder: Der Server hält mehrere Größen desselben Bildes bereit, und der Browser wählt die passende für den Bildschirm. Der Handy-Besucher bekommt die 800-Pixel-Version, der Desktop-Besucher die 1.920-Pixel-Version. Moderne Systeme erledigen das automatisch, wenn sie richtig eingestellt sind: WordPress erzeugt beim Upload mehrere Größen, Shopify skaliert auf dem CDN, Next.js über next/image.
Damit das funktioniert, muss das System wissen, wie breit das Bild im Layout tatsächlich ist. In HTML ist das das Attribut sizes. Fehlt es oder ist es falsch, lädt der Browser im Zweifel die größte Variante, und die ganze Optimierung verpufft.
Das Hero-Bild priorisieren
Der Browser lädt beim Öffnen einer Seite dutzende Dateien: Schriften, Stylesheets, Skripte, Bilder. Ohne Hinweis behandelt er das Hero-Bild wie jedes andere Bild und stellt es hinter Skripte an. Zwei Techniken ändern das:
- Hohe Ladepriorität: Das Attribut
fetchpriority="high"sagt dem Browser, dass dieses Bild wichtiger ist als andere Ressourcen. - Vorladen: Ein Preload-Hinweis im Kopf der Seite sorgt dafür, dass der Browser das Bild anfordert, bevor er das Layout überhaupt berechnet hat.
In Next.js erledigt das Attribut priority beides auf einmal. In WordPress setzen Performance-Plugins den Hinweis für das erste Bild, manche Themes bieten eine Option dafür. Wichtig ist die Beschränkung: Nur das eine Hero-Bild bekommt Priorität. Wer fünf Bildern hohe Priorität gibt, hat wieder keine Priorität, weil sie sich gegenseitig die Bandbreite streitig machen.
Ein Sonderfall sind Hintergrundbilder, die per CSS gesetzt werden. Sie entdeckt der Browser erst, nachdem er das Stylesheet verarbeitet hat, und sie lassen sich nicht responsiv ausliefern. Wenn das LCP-Element ein CSS-Hintergrund ist, ist der Umbau auf ein echtes Bild-Element fast immer die richtige Lösung.
Lazy Loading richtig einsetzen
Lazy Loading heißt: Ein Bild wird erst geladen, wenn der Besucher in seine Nähe scrollt. Das spart Datenvolumen und beschleunigt den Start, weil der Browser nicht dreißig Bilder gleichzeitig anfordert. Der Fehler passiert, wenn Lazy Loading auf das Hero-Bild angewendet wird: Der Browser wartet, prüft, ob das Bild sichtbar ist, und lädt dann erst, und der LCP steigt.
| Element | Lazy Loading | Begründung |
|---|---|---|
| Hero-Bild im Kopfbereich | Nein, im Gegenteil: priorisieren | Ist das LCP-Element, muss so früh wie möglich kommen |
| Logo im Header | Nein | Klein, sofort sichtbar, meist SVG |
| Erstes Bild unter der Überschrift, noch im sichtbaren Bereich | Nein | Alles, was ohne Scrollen sichtbar ist, lädt sofort |
| Bilder in Abschnitten weiter unten | Ja | Werden erst gebraucht, wenn gescrollt wird |
| Galerie, Team-Fotos, Referenzen | Ja | Viele Bilder, die nicht alle gleichzeitig nötig sind |
| Bilder im Footer | Ja | Sieht nur, wer ganz nach unten scrollt |
| Eingebettete Karten und Videos | Ja, besser: Vorschaubild mit Klick | Sparen Skripte und Datenvolumen, oft auch Datenschutz-relevant |
Die Faustregel lautet: Alles, was beim Öffnen der Seite ohne Scrollen sichtbar ist, lädt sofort. Alles darunter lädt verzögert. Browser unterstützen das nativ über das Attribut loading="lazy", WordPress setzt es seit Version 5.5 automatisch, Next.js macht es zum Standard und schaltet es nur bei priority ab.
Tipp: Manche Themes und Plugins setzen Lazy Loading pauschal auf alle Bilder, inklusive Hero. Das erkennst du in PageSpeed Insights an der Meldung „Das LCP-Bild wurde verzögert geladen“. Dann hilft eine Ausnahme für das erste Bild oder das Abschalten des Plugin-Lazy-Loadings zugunsten der Browser-Funktion.
next/image in Kürze
Dieser Abschnitt ist für alle, die mit Next.js arbeiten oder ein Angebot dafür bewerten. Die Komponente next/image übernimmt automatisch, was oben beschrieben ist: Sie erzeugt mehrere Größen, liefert standardmäßig WebP aus (AVIF nach Konfiguration), setzt Lazy Loading als Standard und reserviert den Platz für das Bild.
Ein Hero-Bild sieht damit so aus:
import Image from "next/image";
<Image
src="/bilder/werkstatt-magdeburg.jpg"
alt="Werkstatt von Elektro Müller in Magdeburg"
width="1600"
height="900"
priority
sizes="(max-width: 768px) 100vw, (max-width: 1280px) 90vw, 1200px"
/>
Die Attribute im Einzelnen:
widthundheightgeben das Seitenverhältnis an und reservieren Platz, damit nichts springt.priorityschaltet Lazy Loading ab, setzt hohe Ladepriorität und erzeugt den Preload-Hinweis. Nur für das Hero-Bild.sizesbeschreibt, wie breit das Bild in den verschiedenen Bildschirmgrößen tatsächlich angezeigt wird. Hier: auf dem Handy volle Breite, auf mittleren Bildschirmen 90 Prozent, darüber maximal 1.200 Pixel. Ohnesizesgeht der Browser von voller Bildschirmbreite aus und lädt zu viel.altbeschreibt das Bild für Screenreader und Suchmaschinen, mit Bezug zu Unternehmen und Ort, wenn es passt.
Bilder unterhalb des sichtbaren Bereichs bekommen dieselbe Komponente ohne priority. Externe Bilder, etwa aus einem CMS, müssen in der Konfiguration unter remotePatterns freigegeben werden. Die Standardqualität liegt bei 75 und ist für Fotos ein guter Wert.
Wie next/image mit Server-Rendering und Metadaten zusammenspielt, steht im Artikel zu Next.js SEO im App Router.
Wenn das Bild nicht schuld ist: Server, Schriften, Skripte
Manchmal ist das Bild bereits klein und priorisiert, und der LCP bleibt trotzdem über 2,5 Sekunden. Dann liegt die Ursache davor oder daneben:
- Langsame Server-Antwort (TTFB): Der Browser kann das Bild erst anfordern, wenn das HTML da ist. Antwortet der Server nach 1,5 Sekunden, ist der LCP schon fast verloren, bevor das Bild überhaupt beginnt. Abhilfe schaffen Seiten-Caching, ein CDN oder ein besseres Hosting, mehr dazu im Artikel zu TTFB, CDN und Caching.
- Blockierende Skripte und Stylesheets: Wenn der Browser erst drei Skripte und fünf Stylesheets verarbeiten muss, bevor er zeichnet, verzögert sich alles. Skripte gehören ans Ende oder werden asynchron geladen.
- Webfonts: Ist das LCP-Element eine Überschrift und die Schrift kommt spät, zählt der Moment, in dem die Schrift gerendert ist. Hier hilft ein Ersatz-Font, der sofort sichtbar ist.
- Consent-Banner und Widgets: Manche Cookie-Banner blockieren das Rendern, bis ihr Skript geladen ist. Wie du das vermeidest, steht im Artikel zu Cookie-Banner und Tracking.
Der Netzwerk-Wasserfall in den DevTools zeigt die Reihenfolge: Wenn das Hero-Bild erst nach einem Dutzend anderer Dateien angefordert wird, ist die Reihenfolge das Problem, nicht das Bild.
CLS: Bilder ohne Layout-Sprünge
LCP und CLS hängen eng zusammen. Wenn das Hero-Bild ohne festgelegte Maße lädt, ist der Bereich zunächst null Pixel hoch. Kommt das Bild, drückt es den gesamten Inhalt nach unten. Das ist ein Layout-Sprung, den Google als CLS misst, und der Besucher, der gerade den Button antippen wollte, landet daneben.
Die Lösung ist simpel: Jedes Bild bekommt Breite und Höhe, entweder als Attribute oder über ein festes Seitenverhältnis im CSS. Der Browser reserviert dann den Platz, bevor das Bild da ist. Prüfen kannst du das in PageSpeed Insights unter „Bildelemente haben keine explizite Breite und Höhe“. Mit next/image ist das Pflicht, in WordPress setzt der Editor die Maße automatisch, sofern das Theme sie nicht überschreibt.
Workflow für WordPress, Shopify und Next.js
Das Prinzip ist bei allen Systemen gleich, die Handgriffe unterscheiden sich.
| Schritt | WordPress | Shopify | Next.js |
|---|---|---|---|
| Richtige Größe | Vor dem Upload auf maximal 1.920 Pixel Breite verkleinern; WordPress erzeugt Zwischengrößen; Plugin wie ShortPixel oder Imagify für Nachbearbeitung | Originale hochladen, das Theme fordert über image_url mit width die passende Größe an; sizes-Attribut im Theme prüfen | next/image erzeugt die Größen automatisch; sizes korrekt setzen |
| Modernes Format | WebP seit 5.8, AVIF seit 6.5 beim Upload möglich; Plugins wandeln Bestand um | CDN liefert automatisch moderne Formate aus | Standard WebP; AVIF über formats in der Konfiguration |
| Hero priorisieren | Performance-Plugin oder Theme-Option für das erste Bild; Lazy Loading für Hero ausschließen | Im Theme das erste Slide oder Hero-Bild mit loading=eager und fetchpriority=high versehen; Slideshow-Sektionen kritisch prüfen | priority auf dem Hero-Bild |
| Lazy Loading | Seit 5.5 automatisch für Bilder außerhalb des sichtbaren Bereichs | Theme-abhängig, meist eingebaut | Standard, außer bei priority |
| Maße setzen | Editor setzt Breite und Höhe; Theme-CSS prüfen | Theme setzt width und height; bei eigenen Sektionen prüfen | Pflicht über width, height oder fill |
| Messen | PageSpeed Insights mobil, Startseite und Leistungsseiten | PageSpeed Insights, Startseite, Kollektion, Produktseite | PageSpeed Insights plus DevTools |
Bei WordPress lohnt sich zusätzlich ein Blick in die Mediathek: Viele Websites haben dort hunderte Fotos in Originalgröße aus fünf Jahren. Ein Optimierungs-Plugin räumt den Bestand auf, ohne dass jemand Bilder einzeln anfassen muss. Bei Shopify sind die Slideshow-Sektionen der üblichen Themes ein häufiger Grund für schlechten LCP, mehr zu typischen Shop-Fehlern steht im Shopify Shop erstellen Guide.
Häufige Fehler
- Kamera-Originale hochladen. 6.000 Pixel, mehrere Megabyte, und der Browser verkleinert. Vor dem Upload verkleinern oder ein Plugin das erledigen lassen.
- Hero-Bild lazy laden. Der Klassiker, der den LCP um Sekunden verschlechtert.
- Alles priorisieren. Fünf Bilder mit hoher Priorität sind fünf Bilder ohne Priorität.
- Kein oder falsches sizes-Attribut. Der Browser lädt die größte Variante, obwohl eine kleine reichen würde.
- Hero als CSS-Hintergrund. Nicht responsiv, spät entdeckt, schwer zu priorisieren.
- Bilder ohne Maße. Layout-Sprünge und schlechter CLS.
- PNG für Fotos. Vier- bis zehnmal so groß wie nötig.
- Slider im Kopfbereich. Mehrere große Bilder plus Skript für ein Element, das die meisten Besucher nicht anschauen.
- Text im Bild. Nicht lesbar für Google und Screenreader, schlecht skalierbar, oft unnötig groß. Text gehört als Text auf die Seite.
- Einmal optimiert, nie wieder geprüft. Jeder neue Upload kann die Regeln brechen. Einmal im Quartal nachmessen.
Checkliste: Bilder in 15 Minuten prüfen
- PageSpeed Insights mobil: Welches Element ist das LCP-Element?
- Ist das Hero-Bild kleiner als 200 KB und maximal 1.920 Pixel breit?
- Wird es als WebP oder AVIF ausgeliefert? Im Netzwerk-Tab der DevTools unter Typ nachsehen.
- Hat das Hero-Bild hohe Priorität und kein Lazy Loading?
- Haben alle Bilder Breite und Höhe?
- Laden Bilder unterhalb des sichtbaren Bereichs verzögert?
- Sind Logo und Icons SVG?
- Liegt die Server-Antwortzeit unter 0,8 Sekunden?
- Sind Karten und Videos als Vorschaubild mit Klick eingebunden?
- Werte notiert, um in vier Wochen die Felddaten zu vergleichen?
Nächster Schritt
Wenn du selbst umsetzen willst: Finde das LCP-Element, verkleinere und konvertiere das Hero-Bild, gib ihm Priorität, schalte Lazy Loading für alles darunter ein und setze überall Maße. Danach einmal in PageSpeed Insights nachmessen. Die meisten Websites kommen damit deutlich näher an die 2,5 Sekunden, viele darunter.
Wenn du lieber wissen willst, wo deine Website tatsächlich steht: Unser kostenloser Website-Check zeigt dir LCP, INP und CLS, das verantwortliche Element und die Maßnahmen mit Aufwand. Wir bauen Websites aus Magdeburg, bei denen Bildoptimierung, Priorisierung und Lazy Loading von Anfang an eingebaut sind, ob als Starter-Website ab 1.499 € netto oder als Hero-Website ab 3.900 € netto.



