Bloggeschwindigkeit prüfen: LCP, INP, CLS und PageSpeed Insights

Um die Blog-Performance zu überprüfen, analysieren Sie eine öffentliche URL in PageSpeed Insights, vergleichen Sie Mobile und Desktop und verwenden Sie LCP, INP und CLS, um das Laden, die Reaktionsfähigkeit und die Layoutstabilität zu bewerten. Trennen Sie reale Nutzungsdaten von der Labordiagnostik und behandeln Sie dann die Ursache für eine schlechte Metrik, anstatt sich auf eine einzelne Leistungsbewertung zu konzentrieren.

Was sind LCP, INP und CLS?

Die Core Web Vitals sind Googles zentrale Messwerte zur Nutzererfahrung im Web. Der aktuelle Satz enthält die drei folgenden Metriken. Niedrigere Werte sind für alle drei besser, aber sie messen verschiedene Dinge und verwenden verschiedene Einheiten.

Messwert Was es misst Guter Schwellenwert
LCP: Largest Contentful Paint Zeitpunkt, zu dem das größte relevante Bild oder der größte Textblock sichtbar gerendert wird 2,5 Sekunden oder weniger
INP: Interaction to Next Paint Verzögerung, bevor die Seite visuell auf Klicks, Taps und Tastatureingaben reagiert 200 Millisekunden oder weniger
CLS: Cumulative Layout Shift Die Menge der unerwarteten Layout-Bewegung 0,1 oder weniger; einheitenlos

Googles Web-Vitals-Leitfaden verwendet das 75. Perzentil, das separat für Mobilgeräte und Desktops bewertet wird. Vereinfacht ist dies der Wert, den etwa 75 % der beobachteten Besuche erreichen oder unterschreiten. Es ist kein durchschnittlicher oder der schnellste Single Run. Wenn alle drei Metriken über ausreichende Daten verfügen, müssen alle drei für eine bestandene Bewertung gut sein; ein guter LCP allein genügt nicht.

Ein Beitrag könnte schnell erscheinen, aber langsam reagieren, wenn jemand sein Menü öffnet. Ein anderer könnte gut reagieren, aber den Artikel nach unten verschieben, wenn eine Anzeige nachgeladen wird. Identifizieren Sie, welche Erfahrung schlecht ist, bevor Sie Bilder wiederholt komprimieren, um ein undefiniertes "Geschwindigkeitsproblem" zu lösen.

Führen Sie einen PageSpeed Insights-Check aus

  1. Wählen Sie eine Artikel-URL, die sich öffnet, ohne sich anzumelden. Ausschließen von Editor- und Vorschauadressen.
  2. Geben Sie es in PageSpeed Insights ein und führen Sie die Analyse aus.
  3. Lesen Sie im mobilen Ergebnis die Real-User-Erfahrung getrennt von der Leistungsdiagnostik.
  4. Überprüfen Sie Desktop auch. Notieren Sie URL, Datum, Gerätekategorie, schlechte Metriken und Hauptergebnisse.

Anstatt nur den neuesten Artikel zu überprüfen, wählen Sie repräsentative Seitentypen aus. Ein gewöhnlicher Textartikel, ein bildlastiger Beitrag und eine Seite mit Tabellen oder Code können dazu beitragen, gemeinsame Vorlagenprobleme von inhaltsspezifischen zu unterscheiden. Verwenden Sie die Formate, die Ihr Blog tatsächlich enthält.

Überprüfen Sie, ob sich die analysierte URL von der von Ihnen eingegebenen unterscheidet. Wenn eine Umleitung den Test an anderer Stelle sendet, verwenden Sie dasselbe endgültige Ziel in späteren Vergleichen. Konsistente Datensätze sind nützlich, um Änderungen zu beurteilen, anstatt die Punktzahl besser aussehen zu lassen.

Felddaten von der Leistungsbewertung trennen

Real-User-Daten stammen aus dem Chrome User Experience Report oder CrUX in den letzten 28 Tagen. Bei unzureichenden Proben kann das Ergebnis Daten auf Ursprungsebene oder keine Felddaten zeigen. Die Labordiagnostik verwendet stattdessen Lighthouse in einer simulierten Umgebung. Die PageSpeed Insights Dokumentation erklärt die Unterscheidung.

Ein Performance-Score von 90 und ein Real-User Core Web Vitals Pass sind unterschiedliche Bewertungen. Prüfen Sie, ob Felddaten die spezifische URL oder den gesamten Ursprung darstellen. Fehlende Daten sind weder ein Zertifikat für eine gute Leistung noch ein Nachweis eines Problems.

Die rollende CrUX-Periode und der aktuelle Lighthouse-Lauf verwenden unterschiedliche Samples und Bedingungen. Das Diagramm trennt Datengrundlage und Zweck, damit Sie nach einer Änderung die passende Vergleichsbasis wählen können.

PageSpeed Insights trennt CrUX-Felddaten aus realen Nutzungen über 28 Tage von einem aktuellen Lighthouse-Labortest zur Diagnose. Datenumfang und Zweck sind verschieden.

Zum Beispiel könnte das Ersetzen eines Bildes ein Laborergebnis sofort verbessern, während der rollende Felddatenzeitraum noch Besuche von vor der Änderung enthält. Überprüfen Sie zunächst, ob die neue Ressource korrekt lädt und dass vergleichbare Tests Anzeichen einer Verbesserung zeigen. Überprüfen Sie den Real-User-Trend im Laufe der Zeit separat.

Ein fehlender INP-Wert bedeutet nicht Null Millisekunden. PSI kann eine Bewertung mit unzureichenden INP-Daten bestehen, wenn sowohl LCP als auch CLS gute 75. Perzentile haben; unzureichende LCP- oder CLS-Daten verhindern eine Bewertung. Die PSI-Bewertungsregeln beschreiben diese Ausnahme. Lesen Sie, welche Daten neben dem Pass-Label tatsächlich verfügbar sind.

Für schlechtes LCP finden Sie heraus, was den Hauptinhalt verzögert

Beginnen Sie mit der Identifizierung des Elements, das als größter Inhalt gemeldet wird. Es kann das obere Bild des Artikels, ein großer Textblock oder etwas anderes sein. Wenden Sie nicht überall die gleiche Bildeinstellung an, ohne das eigentliche Element zu überprüfen.

  • Wenn es sich um ein Bild handelt, vergleichen Sie die gelieferten Dimensionen mit der angezeigten Größe.
  • Verwenden Sie geeignete Abmessungen, Kompression und Format, während Sie die erforderlichen Details und die Klarheit des Textes überprüfen.
  • Überprüfen Sie, ob das LCP-Bild des ersten Bildschirms verzögert geladen wird (Lazy Loading). Eine Einstellung, die für Bilder weiter unten im Artikel nützlich ist, kann das Hauptbild verzögern.
  • Wenn die Diagnose Server-Response oder Render-Blocking-Ressourcen identifiziert, untersuchen Sie auch diese Ursachen.

Das LCP-Optimierungshandbuch trennt Verzögerungen beim Erkennen, Übertragen und Anzeigen von Inhalten. Wenn eine Formatänderung angemessen ist, siehe Wie konvertiert man Bilder in WebP (englisch). Wenn Besucher danach immer noch die alte Datei erhalten, überprüfen Sie das Caching und die tatsächlich angeforderte Ressource.

Erweitern Sie die LCP-Aufgliederung in der Diagnose, um festzustellen, wo die Zeit verbracht wird. Beginnen Sie mit der größten oder vermeidbaren Verzögerung, anstatt bei jedem Teil die gleiche Behandlung anzuwenden:

  1. Time to First Byte (TTFB): Navigation bis zum ersten HTML-Antwortbyte. Überprüfen Sie die Serverantwort, Redirect Chains und Cache-Nutzung.
  2. Ressourcenladeverzögerung: das Warten nach dieser Antwort, bevor das Hauptbild oder eine andere LCP-Ressource mit dem Herunterladen beginnt. Überprüfen Sie verzögertes Laden oder späte Entdeckung.
  3. Ressourcenladedauer: Herunterladen der Ressource selbst. Entsprechende Abmessungen und Kompression zielen direkt auf diesen Teil ab.
  4. Verzögerung beim Rendern des Elements: wartet darauf, das Element nach dem Eintreffen der Datei anzuzeigen. Skripte oder Anzeigebedingungen können es immer noch blockieren, so dass ein kleineres Bild allein möglicherweise nicht das gesamte LCP verbessert.

Ein Text-LCP-Element, das keinen separaten Ressourcendownload benötigt, hat möglicherweise kein Ressourcenladeintervall. Die Untergliederung ist auf das bei der Prüfung ermittelte tatsächliche Element anzuwenden.

Für schlechtes INP, inspizieren Sie die Arbeit nach der Interaktion

INP bewertet die Reaktionsfähigkeit durch das nächste visuelle Update nach einer Interaktion. Lange JavaScript-Aufgaben können den Hauptthread des Browsers besetzen, der die Skript- und Bildschirmarbeit übernimmt und die Eingabeverarbeitung verzögert. Das INP-Optimierungshandbuch untersucht Eingabeverzögerung, Ereignisverarbeitung und Präsentationsverzögerung.

Reproduzieren Sie als Blog-Betreiber zunächst praktische Aktionen auf dem Handy: Öffnen des Menüs, Suchen und Befolgen eines Inhaltsverzeichnis-Links. Notieren Sie, welche Aktion sich verzögert anfühlt, und überprüfen Sie dann unnötige oder doppelte Plugins, Widgets und externe Skripte, die auf dieser Seite aktiv sind.

Total Blocking Time (TBT) in einem grundlegenden Lighthouse-Seitenladetest kann lange Aufgaben anzeigen, aber es ist nicht INP. INP benötigt Klick-, Tipp- oder Tastaturinteraktionen; ein Besuch, der nur scrollt oder niemals interagiert, hat möglicherweise keinen Wert. Unterscheiden Sie auch das nächste visuelle Feedback nach dem Drücken der Suche, z. B. eine Ladeanzeige, vom Abschluss der gesamten Serversuche. Die INP Definition und Messumfang erklären diese Grenzen.

Vermeiden Sie es, viele Plugins gleichzeitig zu deaktivieren. Bereiten Sie eine Backup- oder Testumgebung vor und nehmen Sie jeweils eine Änderung vor, damit Sie ihre Auswirkungen identifizieren können. Wenn Sie die verzögerte JavaScript-Ausführung aktivieren, prüfen Sie neben der Bewertung auch, ob Menüs, Suche und Einwilligungsfelder weiterhin funktionieren.

Für schlechtes CLS, reservieren Sie Platz für bewegliche Inhalte

Späte Bilder, Anzeigen und Einbettungen können den Artikel schieben oder einen Link, auf den jemand tippen möchte. Das CLS-Optimierungshandbuch hebt Bilddimensionen hervor und reserviert Platz für spätes Laden von Inhalten.

  • Geben Sie das Bild width und height oder ein geeignetes reserviertes Seitenverhältnis an.
  • Reservieren Sie ausreichend Platz für Anzeigen und Video-Embeds bei jeder Gerätegröße.
  • Verhindern Sie, dass ein nicht belegter Werbeplatz plötzlich einklappt und dadurch eine weitere Verschiebung verursacht.
  • Achten Sie auf Text und Buttons, die sich bewegen, wenn Schriftarten oder Banner erscheinen.

Das in einer Layout-Shift-Diagnose aufgeführte Element ist nicht unbedingt der Schuldige. Das Einfügen einer Anzeige über dem Artikel kann dazu führen, dass der verschobene Artikel unten aufgezeichnet wird. Prüfen Sie benachbarte Inhalte und nachträglich eingefügte Elemente direkt darüber. Ein Test des ersten Ladens kann Verschiebungen durch Anzeigen oder Bilder übersehen, die erst nach dem Scrollen erscheinen. Lesen Sie deshalb den öffentlichen Artikel durch und testen Sie auch Menüs und Einwilligungsfelder.

Die Reduzierung des Leerraums und die Stabilität des Layouts können einen Kompromiss erfordern. Gehen Sie nicht davon aus, dass eine Desktop-Werbehöhe für Mobilgeräte geeignet ist. Öffnen Sie echte Artikel und prüfen Sie Bewegungen in der Nähe der Oberseite, Mitte und Unterseite des Bildschirms.

Unter vergleichbaren Bedingungen erneut prüfen

  1. Speichern Sie die Originaleinstellungen, Dateien und Testergebnisse.
  2. Wählen Sie eine wichtige Ursache und nehmen Sie eine gezielte Änderung vor.
  3. Aktualisieren Sie relevante Caches und überprüfen Sie die geänderte Ressource auf der öffentlichen Seite.
  4. Testen Sie die gleiche URL und Gerätekategorie erneut und überprüfen Sie dann Menüs, Bilder, Anzeigen und Artikellayout.
  5. Wenn die Funktionalität bricht oder sich andere Metriken verschlechtern, nehmen Sie die Änderung zurück und verengen Sie die Ursache erneut.

Wenn Sie die Cache-Einstellungen ändern, unterscheiden Sie die Bereitstellung von gespeicherten Ressourcen von der Verzögerung der Skriptausführung. Siehe was WordPress-Cache-Plugins tun und wie man eines auswählt (englisch), und führen Sie eine Aufzeichnung der Einstellungen zur Wiederherstellung, anstatt mehrere Optimierungen gleichzeitig zu aktivieren.

Erklären Sie den Erfolg nicht aus einem kleinen Unterschied in einem Lauf. Vergleichen Sie Ihre Aufzeichnungen und wiederkehrende Probleme, bevor Sie die nächste Änderung vornehmen. Eine höhere Punktzahl, die durch das Brechen von etwas erreicht wird, was die Leser brauchen, ist keine nützliche Verbesserung.

Ein Speed-Score allein bestimmt nicht die Sichtbarkeit der Suche. Googles Leitfaden zur Nutzerfreundlichkeit von Seiten sagt, dass Core Web Vitals von Ranking-Systemen verwendet werden, während gute Ergebnisse keine Top-Rankings garantieren. Verbessern Sie die Lesbarkeit des Artikels und die Möglichkeit, wichtige Aktionen auf der Website auszuführen.