SEO & KI · Zusammenhang & Performance
LCP & INP gezielt optimieren
Die Core Web Vitals im Überblick zeigen, was LCP, INP und CLS messen. Diese Seite geht in die Tiefe bei den beiden, die in der Praxis am meisten Arbeit machen: LCP (Ladegefühl) und INP (Reaktionsfreude). CLS ist mit festen Bildmaßen meist schnell erledigt – diese zwei nicht immer.
LCP gezielt verbessern
Der Largest Contentful Paint misst, wann das größte sichtbare Element erscheint – meist ein Heldenbild oder eine große Überschrift. Der Wert zerfällt in vier Phasen, und an jeder kannst du ansetzen:
- Server-Antwort (TTFB): schnell ausliefern – Statik plus Kompression und gutes Caching schlagen fast jeden dynamischen Aufbau.
-
Verzögerung beim Laden: Das LCP-Bild nicht per
loading="lazy"bremsen. Stattdessen früh anstoßen:<link rel="preload" as="image" href="/img/held.webp" /> <img src="/img/held.webp" fetchpriority="high" width="1200" height="600" alt="…" /> - Ladezeit der Ressource: das Bild klein halten – modernes Format und passende Maße.
- Render-Verzögerung: kein Render-Blocking durch unnötiges CSS/JS; Schriften selbst hosten,
font-display: swap, das nötige Schriftfile vorladen.
Der häufigste Fehler ist das versehentliche Lazy-Loading des wichtigsten Bildes – oben geladene Bilder gehören nie auf „lazy“.
INP gezielt verbessern
Interaction to Next Paint misst, wie schnell die Seite sichtbar auf eine Eingabe reagiert – über alle Interaktionen hinweg. Der Bremsklotz ist fast immer JavaScript, das den Hauptthread blockiert.
-
Weniger JavaScript ausliefern. Der wirksamste Hebel ist der naheliegendste. Wer Verhalten nativ löst statt es nachzubauen – siehe erste Regel von ARIA und
details/summary– hat weniger Code, der hängen kann. - Lange Aufgaben zerteilen. Arbeit über 50 ms blockiert. Teile sie auf und gib dem Browser zwischendurch Luft (
await,requestIdleCallback, Aufteilen in kleine Häppchen). - Nicht-Dringendes verschieben: Analytics und Nebensächliches erst nach der Interaktion ausführen.
- Schwergewichte hinterfragen: Ein großes Karussell oder ein überladenes Skript-Bündel ist ein Klassiker für schlechtes INP.
Randnotiz – Statik gewinnt fast geschenkt. Eine Seite, die „Zero-JS by default“ ausliefert, hat kaum etwas, das den Hauptthread blockiert. Genau deshalb erreichen statische, semantische Seiten gute INP-Werte oft, ohne dass man eigens dafür kämpfen muss.
Messen: Feld vor Labor
Für die Bewertung zählen Felddaten echter Besucher (Chrome User Experience Report), nicht die Laborwerte aus Lighthouse. Nutze das Labor zum Finden der Ursache, das Feld als Wahrheit. INP lässt sich nur über echte Interaktionen verlässlich beurteilen – im Labor wird es lediglich geschätzt.
Häufige Fehler
-
LCP-Bild auf
loading="lazy"– verzögert genau das, was zählt. - Riesiges Held-Bild ohne Komprimierung.
- Alles JavaScript sofort laden, auch was warten könnte.
- Nur Lighthouse anschauen und die Felddaten ignorieren.
- Render-blockierende Schriften ohne Vorladen und
swap.
Häufige Fragen
Warum ist mein Lighthouse-LCP gut, der echte aber schlecht?
Lighthouse misst unter Idealbedingungen. Echte Besucher haben langsamere Geräte und Netze. Maßgeblich sind die Felddaten.
Was bringt bei INP am meisten?
Weniger und kleineres JavaScript sowie das Aufteilen langer Aufgaben. Beides wirkt direkt auf die Reaktionsfreude.
Zählt INP wirklich erst seit Kurzem?
INP hat 2024 die ältere Kennzahl FID abgelöst und misst strenger – die gesamte Interaktion statt nur die erste Reaktion.
Fazit
LCP verbesserst du, indem du das wichtigste Bild früh und klein lädst, schnell auslieferst und Render-Blocker beseitigst – und es nie auf „lazy“ setzt. INP verbesserst du vor allem durch weniger JavaScript und das Zerteilen langer Aufgaben. Gemessen wird im Feld. Eine statische, schlanke Seite bringt von beidem viel schon mit.