Page-Speed verbessern: LCP, INP und CLS konkret optimieren

48 Prozent. Mehr Statistik brauchst du für den nächsten Kundentermin kaum: Nur 48 Prozent aller Websites bestehen auf dem Smartphone alle drei Core Web Vitals, auf dem Desktop sind es 56 Prozent (Web Almanac 2025, CrUX-Felddaten von Juli 2025). Anders gesagt: Ungefähr jede zweite Website, die du anfasst, hat messbaren Speed-Handlungsbedarf. Die Frage ist nur, wo du zuerst ansetzt. Dieser Guide sortiert die Maßnahmen nach Metrik: LCP, INP und CLS, jeweils mit den Hebeln, die in Kundenprojekten wirklich Punkte bringen.

Die Grenzwerte, an denen Google dich misst

Google bewertet jede Website an drei Felddaten-Metriken, gemessen am 75. Perzentil der echten Nutzer. LCP (Largest Contentful Paint) bis 2,5 Sekunden: Wie schnell ist das größte sichtbare Element da, meist das Hero-Bild oder die Hauptüberschrift? INP (Interaction to Next Paint) bis 200 Millisekunden: Wie schnell reagiert die Seite auf Klicks, Taps und Eingaben, gemessen über den gesamten Besuch? CLS (Cumulative Layout Shift) bis 0,1: Wie stark springt das Layout, während die Seite lädt und nachlädt?

Wichtig ist das Wort Felddaten: „Bestanden“ heißt, dass alle drei Metriken bei den echten Besuchern der letzten 28 Tage im grünen Bereich liegen. Ein grüner Lighthouse-Score aus dem Labor ist ein gutes Zeichen, aber kein Beweis, denn er misst einen simulierten Einzelaufruf, nicht die Realität aus Funklöchern, alten Geräten und vollen Tabs. Das 75. Perzentil bedeutet dabei: Drei Viertel der Besuche müssen die Grenzwerte einhalten. Es reicht also nicht, dass die Seite im Durchschnitt schnell ist, sie muss auch auf den langsameren Geräten und Verbindungen deiner Zielgruppe funktionieren.

Womit du misst: drei Werkzeuge reichen

PageSpeed Insights ist die erste Anlaufstelle: oben die Felddaten aus dem Chrome UX Report, darunter die Labor-Diagnose mit konkreten Empfehlungen. Für die Detailarbeit nimmst du die Chrome-DevTools: Der Performance-Tab zeichnet den Ladevorgang auf, markiert das LCP-Element und listet lange Tasks, und mit gedrosselter CPU plus langsamem Netz simulierst du das Mittelklasse-Handy deiner echten Besucher. Der dritte Fall ist der häufigste bei kleinen Kundenwebsites: Es gibt gar keine Felddaten, weil der Traffic für den Chrome UX Report nicht reicht. Dann ist das Labor deine einzige Quelle. Dokumentiere in dem Fall sauber, unter welchen Bedingungen du gemessen hast, damit Vorher und Nachher vergleichbar bleiben.

Mobil ist der Engpass, nicht der Desktop

Die Felddaten aus dem Web Almanac 2025 zeigen, wo die Arbeit liegt. Beim LCP klafft eine deutliche Lücke: 62 Prozent der Websites sind mobil gut, 74 Prozent auf dem Desktop. Beim INP ist der Abstand dramatisch: 97 Prozent reagieren auf dem Desktop schnell genug, mobil sind es nur 77 Prozent. Der Grund ist banal: Dasselbe JavaScript, das auf deinem Entwickler-Notebook fliegt, quält sich auf einem drei Jahre alten Mittelklasse-Android. Nur beim CLS ist mobil sogar besser (81 gegen 72 Prozent), einspaltige Layouts springen schlicht weniger.

Die praktische Konsequenz: Teste zuerst mobil, optimiere zuerst mobil, und drossele dabei in den DevTools die CPU, um realistische Bedingungen zu simulieren. Warum diese Denkrichtung ohnehin die richtige ist, liest du im Artikel über Mobile-First-Webdesign.

LCP verbessern: das größte Element zuerst

LCP zerfällt in vier Phasen: Serverzeit bis zum ersten Byte, Ladeverzögerung der LCP-Ressource, deren Ladezeit und die Renderzeit. Die Almanac-Analyse 2025 kommt zu einem Befund, der viele überrascht: Das größte Potenzial steckt in der Serverzeit und in der Ladeverzögerung, also der Zeit, bis der Browser überhaupt anfängt, das entscheidende Bild zu laden. Noch kleinere Bilddateien allein reißen es dagegen selten raus.

Daraus ergibt sich die Reihenfolge der Hebel. Erstens Hosting und Caching: Ein Page-Cache, der fertiges HTML ausliefert, entlastet jede weitere Phase, ein träger Server frisst das Budget, bevor das erste Byte ankommt. Zweitens das LCP-Element nicht verstecken: kein Lazy-Loading auf dem Hero-Bild, kein Nachladen per JavaScript, kein Verstecken im CSS-Background. Drittens Prioritäten setzen: fetchpriority auf dem Hero-Bild signalisiert dem Browser, was zuerst zählt. Und erst viertens die Bild-Basics: moderne Formate und passende Größen bleiben Pflicht, sind aber laut Felddaten der kleinere Hebel.

INP verbessern: JavaScript zähmen

INP misst die langsamste relevante Reaktion der Seite, und die wird fast immer von JavaScript blockiert. Beginne mit einer Inventur der Third-Party-Skripte: Tag-Manager, Chat-Widgets, Tracking-Pixel, Karten, alles, was „mal eben“ eingebaut wurde und seitdem auf jeder Seite lädt. Alles Ungenutzte fliegt raus, der Rest lädt erst nach der ersten Interaktion oder nur auf den Seiten, die es brauchen. Danach die eigenen Skripte: Lange Tasks in kleinere Häppchen aufteilen, schwere Berechnungen aus dem Klick-Handler heraushalten, und bei WordPress mit Pagebuilder kritisch prüfen, welche Plugins auf jeder einzelnen Seite JavaScript einschleusen, obwohl nur eine Unterseite sie nutzt.

Ein typisches Beispiel ist das mobile Menü: Der Tap aufs Burger-Icon ist auf vielen Websites die häufigste Interaktion überhaupt. Wenn genau dort ein schweres Skript im Weg steht, erlebt jeder einzelne Besucher die Verzögerung. INP setzt sich aus Eingabeverzögerung, Verarbeitung und Darstellung zusammen, und in der Praxis dominiert fast immer die Verarbeitung, also das JavaScript, das zwischen Klick und sichtbarer Reaktion läuft.

CLS verbessern: Platz reservieren

Layout springt immer dann, wenn Inhalte ohne reservierten Platz nachladen. Die Klassiker: Bilder ohne width- und height-Attribute (mit ihnen reserviert der Browser das Seitenverhältnis automatisch), Webfonts, die spät laden und den Text umbrechen (font-display: swap plus metrisch passende Fallback-Schrift), Embeds und Karten ohne feste Container, und Banner, die sich nachträglich von oben ins Layout schieben. Auch das Cookie-Banner gehört auf die Liste: Wenn es das Layout verschiebt, statt es zu überlagern, produziert es Layout-Shift auf jeder einzelnen Seite des Kunden.

Zum Aufspüren stellst du in den DevTools die Netzwerk-Drosselung an und lädst die Seite mehrfach neu: Sprünge, die im schnellen Büro-WLAN unsichtbar bleiben, werden auf langsamer Verbindung offensichtlich. Der Performance-Tab listet anschließend jede einzelne Verschiebung samt Verursacher auf, damit du gezielt reparierst statt zu raten.

Der Vorher-nachher-Workflow, der Aufträge bringt

Speed-Optimierung verkauft sich über Beweise, nicht über Fachbegriffe. Der Workflow dazu: Erstens den Ist-Zustand dokumentieren, mit Screenshots der Felddaten und der Labor-Diagnose aus PageSpeed Insights. Zweitens genau drei Maßnahmen umsetzen statt zehn: erst die LCP-Kette, dann die schwersten Skripte, dann die Layout-Reserven. Drittens sofort im Labor nachmessen und das Ergebnis zeigen.

Viertens übersetzt du das Ergebnis in Kundensprache: nicht „LCP von 4,1 auf 2,3 Sekunden“, sondern „deine Seite ist da, bevor der Besucher wegklickt“. Speed ist dabei selten Selbstzweck: Schnellere Seiten stützen Sichtbarkeit und vor allem die Abschlussquote, wie der Guide zur Conversion-Optimierung zeigt. Und manchmal ist die ehrlichste Empfehlung eine andere: Wenn ein uralter Pagebuilder, 15 Plugins und ein überladenes Theme zusammenkommen, optimierst du ein strukturelles Problem. Woran du erkennst, dass statt Feintuning ein Neuaufbau ansteht, liest du unter Website-Relaunch erkennen.

Page-Speed ist keine Tool-Disziplin: Es gewinnt, wer das größte Element schneller zeigt, das längste Skript kürzt und dem Layout das Springen abgewöhnt.