Die drei Core Web Vitals beschreiben verschiedene Engpässe. Largest Contentful Paint, kurz LCP, misst den Zeitpunkt, an dem das größte sichtbare Inhaltselement gerendert wurde. Interaction to Next Paint, kurz INP, bewertet die Reaktionsfähigkeit über Interaktionen hinweg. Cumulative Layout Shift, kurz CLS, misst unerwartete visuelle Verschiebungen.
Google stuft am 75. Perzentil LCP bis 2,5 Sekunden, INP bis 200 Millisekunden und CLS bis 0,1 als „gut“ ein. Diese Schwellen sind Orientierungen für reale Erfahrung, keine Garantie für Anfragen oder Rankings. Eine Landingpage kann alle Schwellen erfüllen und trotzdem ein unverständliches Angebot haben.
Darum bleibt die Performance-Arbeit an der konkreten Ursache. Ein Messwert zeigt die Richtung. Das Element und sein Ablauf zeigen, was geändert werden kann.
Feldwerte
1. Lies CrUX als Verteilung, nicht als Momentaufnahme
PageSpeed Insights zeigt reale Erfahrungen in den Kategorien gut, verbesserungswürdig und schlecht. Der hervorgehobene Wert ist das 75. Perzentil. Er bedeutet nicht, dass jeder Aufruf genau so schnell war. Er beschreibt einen Punkt in der Verteilung.
Vergleiche Mobil und Desktop getrennt. Eine Landingpage kann am Desktop unauffällig sein und auf mobilen Geräten durch schwächere Prozessoren, langsamere Netze oder andere Hero-Elemente auffallen. Mische diese Situationen nicht in einer einzigen Aussage.
Prüfe außerdem den Umfang. URL-Daten sind näher an der Landingpage; Origin-Daten fassen viele Seitentypen zusammen. Wenn nur Origin-Daten vorliegen, darfst du daraus keine sichere Ursache für die Zielseite ableiten. Nutze den Wert als Priorisierungshinweis und sammle bei Bedarf eigene Felddaten.
Ein rollierendes 28-Tage-Fenster reagiert langsam auf Änderungen. Nach einer Veröffentlichung enthält der Wert zunächst viele frühere Aufrufe. Dokumentiere deshalb Veröffentlichungsdatum und beobachte die Verteilung über mehrere Aktualisierungen.
Labordaten
2. Nutze Lighthouse zur Diagnose, nicht als alleinige Erfolgsmessung
Lighthouse lädt die URL unter simulierten Bedingungen und erzeugt reproduzierbare Hinweise. Das ist nützlich, um Wasserfälle, Renderblockaden, ungenutzte Ressourcen oder große Hauptthread-Aufgaben zu untersuchen. Es ist keine Stichprobe realer Kundinnen.
Ein einzelner Lauf kann schwanken. Google nennt unter anderem Netzwerk, Hardwareverfügbarkeit und Ressourcenkonflikte als Variabilitätsquellen. Führe deshalb mehrere Läufe mit unveränderter Umgebung aus und notiere einen typischen Bereich statt nur den besten Wert.
Wenn Feld und Labor widersprechen, suche nach Szenarien: Cookie-Banner, personalisierte Inhalte, wiederkehrende Nutzung mit Cache, unterschiedliche Bildschirmgrößen, eingebetteter Kalender oder Interaktionen nach dem ersten Laden. Das Labor wird so angepasst, dass es die reale Auffälligkeit besser reproduziert.
Bewerte nicht zuerst den Performance-Score. Öffne die betroffene Metrik, ihre Teilzeiten und das zugeordnete Element. Der Score fasst mehrere Dinge zusammen und kann sich ändern, obwohl die konkrete Ursache noch besteht.
LCP
3. Finde das tatsächliche LCP-Element
Das LCP-Element ist häufig ein Hero-Bild, eine große Überschrift, ein Posterbild oder ein großer Textblock. Es ist nicht automatisch die Datei mit den meisten Kilobytes. „Schwerstes Element“ muss deshalb zweifach geprüft werden: Welches Element bestimmt LCP, und welche Ressource verursacht den größten Transfer oder die längste Verzögerung?
Chrome DevTools und Lighthouse zeigen das LCP-Element für den jeweiligen Lauf. Kontrolliere Mobil- und Desktop-Viewport, weil sich das Element ändern kann. Ein Portrait kann mobil LCP sein, während am Desktop eine Überschrift oder ein anderes Bild den größten sichtbaren Bereich einnimmt.
Notiere Element, Ressource, Dateigröße, Startzeit der Anfrage und Renderzeit. Wenn das LCP-Element Text ist, liegt die Ursache möglicherweise bei Schriftladen, Stylesheets oder Renderverzögerung. Wenn es ein Bild ist, kann die Ursache vor dem Download, während des Downloads oder beim Rendern liegen.
Erst diese Zuordnung macht eine Änderung präzise. Ein pauschales „alle Bilder komprimieren“ kann viel Arbeit erzeugen und das eigentliche LCP-Element unberührt lassen.
LCP-Protokoll:
- Element und CSS-Selektor
- zugehörige URL oder Textressource
- Mobil- und Desktop-Unterschied
- Transfergröße und Priorität
- LCP-Teilzeit mit größtem Anteil
- geplante Einzeländerung
LCP-Ursache
4. Zerlege LCP in die Ursache vor dem Fix
LCP lässt sich gedanklich in Serverantwort, Verzögerung bis zum Ressourcenstart, Ressourcendauer und Renderverzögerung zerlegen. Dieselbe Gesamtzeit kann dadurch völlig verschiedene Ursachen haben.
Startet ein Hero-Bild spät, prüfe, ob es erst über JavaScript oder CSS entdeckt wird, ob Lazy Loading fälschlich aktiv ist oder ob wichtige Ressourcen vorher konkurrieren. Lädt es lange, prüfe Dimension, Format, responsive Varianten, Komprimierung und Cache. Ist es früh geladen, erscheint aber spät, untersuche Styles, Schrift, Animation oder Hauptthread-Arbeit.
Ändere nur den dominanten Teil. Bei einer späten Entdeckung kann höhere Priorität oder direkter HTML-Verweis sinnvoll sein. Bei zu großem Transfer hilft die passende Bildvariante. Bei Renderverzögerung bringt zusätzliche Komprimierung kaum etwas.
Nach dem Fix kontrollierst du nicht nur die Gesamtzeit. Prüfe, ob genau die adressierte Teilzeit gesunken ist und ob das LCP-Element gleich geblieben ist. Sonst vergleichst du möglicherweise zwei unterschiedliche Engpässe.
INP
5. Reproduziere die langsame Interaktion für INP
INP entsteht nicht beim passiven Laden allein. Die Metrik beobachtet Interaktionen wie Klick, Tap oder Tastatureingabe und bewertet deren Verzögerung bis zur nächsten sichtbaren Darstellung. Ein Button, ein Akkordeon, ein Formular oder ein Kalender kann deshalb relevant sein.
CrUX zeigt, ob reale Interaktionen auffällig sind, nennt aber ohne zusätzliche Felddiagnose nicht automatisch das verantwortliche Element. Eigene Real-User-Messung mit Attribution kann Interaktionstyp und Ziel ergänzen. Im Labor nutzt du Chrome DevTools, öffnest das Live-Metrics- oder Performance-Panel und führst denselben Ablauf bewusst aus.
Zerlege die Interaktion in Eingabeverzögerung, Ausführungszeit der Event-Callbacks und Darstellungsverzögerung. Lange JavaScript-Aufgaben vor dem Klick erhöhen die Eingabeverzögerung. Umfangreiche Event-Logik verlängert die Verarbeitung. Ein sehr großer DOM oder aufwendige Styles können die Darstellung verzögern.
Bei Landingpages sind Drittanbieter-Skripte besonders verdächtig: Kalender, Video, Consent, Chat oder Tracking können Hauptthread-Arbeit erzeugen. Entferne nicht blind jedes Tool. Deaktiviere oder verschiebe testweise genau einen Verursacher und wiederhole die betroffene Interaktion.
INP-Testfälle:
- erster CTA-Tap kurz nach Seitenaufruf
- Öffnen eines FAQ-Akkordeons
- Eingabe und Absenden im Formular
- Öffnen eines eingebetteten Kalenders
- Interaktion nach Laden von Video oder Consent-Tool
CLS
6. Finde den konkreten Layout-Shift – auch nach dem Laden
CLS misst unerwartete Verschiebungen sichtbarer Inhalte. Häufige Ursachen sind Bilder ohne reservierte Abmessungen, Embeds und iframes ohne festen Platz, dynamisch eingefügte Banner sowie Schriftwechsel. Ein ruhiger erster Screenshot schließt spätere Verschiebungen nicht aus.
Chrome DevTools zeigt Layout-Shift-Einträge und betroffene Elemente. Klicke einen Eintrag an und prüfe, was sich bewegt hat und was die Bewegung ausgelöst hat. Das verschobene Element ist nicht immer der Verursacher; oft wird oberhalb später Inhalt eingefügt.
Reproduziere Scrollen, Öffnen von Akkordeons, Consent-Änderung, Kalenderladen und Formularfehler. web.dev weist darauf hin, dass Unterschiede zwischen CrUX und Lighthouse auf Layout-Shifts nach dem ersten Laden hindeuten können. Gerade solche Verschiebungen brauchen Interaktion im Labor.
Reserviere Platz mit korrekten Bildabmessungen, aspect-ratio oder stabilen Containern. Prüfe danach denselben Ablauf. Ein Fix ist erst belegt, wenn der konkrete Shift-Eintrag nicht mehr oder deutlich kleiner auftritt.
Drittanbieter
7. Ordne Kalender, Video, Consent und Tracking nach tatsächlicher Last
Drittanbieter werden schnell pauschal verantwortlich gemacht. Miss stattdessen, wann ihre Ressourcen starten, wie viel sie übertragen, welche Hauptthread-Arbeit entsteht und ob sie das LCP-Element, eine Interaktion oder Layout-Stabilität beeinflussen.
Ein Video kann durch ein statisches Vorschaubild später geladen werden. Ein Kalender kann erst nach einer bewussten Handlung initialisieren. Ein Chat kann auf Seiten ohne Beratungsbedarf entfallen. Diese Entscheidungen verändern jedoch Funktion und Messung; sie brauchen deshalb einen dokumentierten Nutzwert, nicht nur eine kleinere Dateiliste.
Beziehe den Weg zur Seite ein. Nach einer Anzeige erwartet eine Interessentin einen schnellen Anschluss an das Versprechen; nach einem YouTube-Video bringt sie oft schon mehr Kontext mit. Google-Suche und E-Mail erzeugen wieder andere Einstiege. Gerade bei bezahlten Klicks ist unnötige Wartezeit auch ein Budgetthema.
Consent ist keine Performance-Abkürzung. Tags und eingebettete Dienste müssen entsprechend der tatsächlichen Consent- und Datenschutzentscheidung arbeiten. Teste die Landingpage mit Zustimmung und Ablehnung, weil sich Ressourcen, Layout und Interaktionen unterscheiden können.
Vermerke Grenzen. Ein schnellerer Labortest ohne das produktive Consent- oder Buchungsszenario beweist nicht, dass reale Nutzerinnen denselben Vorteil erhalten.
Bilder
8. Optimiere die verantwortliche Bildressource, nicht die ganze Mediathek
Wenn ein Bild LCP oder Transfer dominiert, prüfe zuerst die tatsächlich ausgelieferte Variante. Das dargestellte Bild kann klein sein und trotzdem eine unnötig große Quelldatei laden. Responsive srcset- und sizes-Angaben sollen dem Browser eine passende Auswahl ermöglichen.
Moderne Formate und Komprimierung helfen, aber sichtbare Qualität bleibt Teil der Entscheidung. Ein unscharfes Portrait kann Vertrauen beschädigen, obwohl die Datei kleiner ist. Teste eine konkrete Größen- und Qualitätsstufe und vergleiche Transfer, Darstellung und LCP-Teilzeit.
Hero-Bilder oberhalb des sichtbaren Starts sollten nicht automatisch lazy geladen werden, wenn dadurch ihre Entdeckung verzögert wird. Bilder weiter unten dürfen dagegen später laden, solange Abmessungen reserviert sind und kein CLS entsteht.
Dokumentiere Original und neue Ressource. Ohne Dateiname, Abmessung, Transfergröße und Testlauf lässt sich später nicht mehr erklären, welche Änderung tatsächlich wirkte.
Änderung
9. Formuliere eine Performance-Hypothese mit nur einer Ursache
Eine gute Performance-Hypothese ist technisch prüfbar: „Das mobile Hero-Bild startet spät, weil es lazy geladen wird. Wenn wir es früh entdecken lassen, sinkt die LCP-Ressourcenverzögerung im gleichen Laborszenario.“ Sie verspricht keine Conversion-Steigerung.
Verändere nicht gleichzeitig Bildformat, Größe, Ladepriorität, Hero-Layout und Schrift. Sonst weißt du zwar, dass der Gesamtwert anders ist, aber nicht, welche Ursache entfernt wurde. Kleine isolierte Eingriffe sind leichter zu prüfen und sicherer zurückzunehmen.
Lege vorab fest, was du erwartest: betroffene Teilzeit, Element, Testgerät und tolerierter Bereich über mehrere Läufe. Wenn der Wert nicht reagiert, war die Hypothese unvollständig oder die Änderung erreichte die Ursache nicht.
Danach kann die nächste Ursache folgen. Performance-Optimierung ist eine Reihe belegter Diagnosen, kein einmaliges Aufräumen aller Dateien.
Retest
10. Wiederhole den Labortest unter vergleichbaren Bedingungen
Nutze dieselbe URL-Variante, denselben Viewport, denselben Consent-Zustand und denselben Ablauf. Führe mehrere Läufe aus, weil einzelne Messungen schwanken. Vergleiche nicht den besten Vorher-Lauf mit dem schlechtesten Nachher-Lauf.
Kontrolliere neben der Zielmetrik mögliche Nebenwirkungen. Ein priorisiertes Hero-Bild kann andere Ressourcen verdrängen. Weniger JavaScript kann ein Tracking- oder Formularereignis beschädigen. Reservierter Platz kann mobil zu unnötigem Leerraum führen. Performance bleibt Teil einer funktionierenden Landingpage.
Teste den sichtbaren CTA, das Formular und die Terminbuchung als echte Abläufe. Ein schnell geladener Einstieg hilft wenig, wenn das externe Formular erst spät erscheint oder auf dem Smartphone unruhig reagiert. Wie viele Felder fachlich nötig sind, ist eine Conversion-Frage; ob der gewählte Buchungsweg zügig und stabil funktioniert, gehört in diese technische Prüfung.
Speichere Testdatum, Umgebung, betroffene Version und Ergebnisbereich. Ein Screenshot mit einer Punktzahl reicht nicht, weil er weder Änderung noch reproduzierten Ablauf erklärt.
Wenn das Labor die Ursache nicht bestätigt, veröffentliche nicht allein aus Hoffnung. Kehre zur Diagnose zurück und prüfe, ob Element, Teilzeit oder Interaktion falsch eingegrenzt wurden.
Feldwirkung
11. Beobachte nach der Veröffentlichung erneut reale Erfahrungen
Nach dem technischen Retest beginnt die Wirkungskontrolle. Eigene Real-User-Messung kann neue Aufrufe zeitnah zeigen. CrUX und PageSpeed Insights arbeiten mit einem rollierenden 28-Tage-Zeitraum, sodass alte und neue Erfahrungen zunächst gemischt bleiben.
Vergleiche dasselbe Gerät und denselben Umfang. Wenn vor dem Fix nur Origin-Daten verfügbar waren, kann weiterhin keine URL-spezifische Aussage möglich sein. Dokumentiere diese Grenze statt eine Verbesserung zu behaupten, die der Datensatz nicht isoliert zeigt.
Achte auf die Verteilung, nicht nur auf eine Zahl. Eine Änderung kann schwache Geräte stärker verbessern als schnelle Geräte oder umgekehrt. Das 75. Perzentil hilft, die Mehrheit abzudecken, verdeckt aber nicht jede Untergruppe.
Lege daneben die Verhaltensmessung, ohne beides zu vermischen. Abbrüche im Einstieg, vor dem Video oder am Formular können zeigen, wo eine nähere Prüfung lohnt. Sie beweisen für sich allein nicht, dass die Ladezeit den Abbruch verursacht hat.
Erst eine konsistente Feldbewegung stützt die Aussage, dass reale Erfahrung besser wurde. Eine bessere Anfragequote wäre eine weitere, getrennte Geschäftshypothese und braucht eine eigene Messung.
Abgrenzung
12. Was diese Ladezeit-Diagnose bewusst nicht entscheidet
Core Web Vitals bewerten Ladeleistung, Reaktionsfähigkeit und visuelle Stabilität. Sie sagen nicht, ob die Headline die richtige Zielgruppe anspricht, ob der Preis erklärt ist oder ob der CTA zur Reifestufe passt.
Wenn die Landingpage technisch stabil ist, aber keine passenden Anfragen entstehen, führt der nächste Weg zur Angebots-, Text- oder CTA-Analyse. Verändere Performance und Botschaft nicht gleichzeitig, wenn du die Wirkung beider Entscheidungen verstehen willst.
Auch ein auffälliger Wert bedeutet nicht automatisch, dass genau er der größte geschäftliche Engpass ist. Priorisiere nach realer Betroffenheit, technischer Reproduzierbarkeit, Aufwand und Bedeutung des betroffenen Schritts.
Diese Abgrenzung verhindert, dass eine technische Punktzahl zur Universaldiagnose wird. Schnelligkeit schützt Nutzung. Die Landingpage muss trotzdem inhaltlich überzeugen.
