Die drei Kennzahlen und was jede einfängt
Jede Kennzahl deckt eine andere Art ab, auf die sich eine Seite falsch anfühlen kann, und sie scheitern unabhängig voneinander. Eine Seite kann schnell laden und trotzdem unter dem Daumen des Lesers verrutschen; eine Seite kann vollkommen stabil sein und vier Sekunden brauchen, bis überhaupt etwas erscheint.
| Kennzahl | Deckt ab | Gut | Handlungsbedarf über |
|---|---|---|---|
| LCP | Laden | ≤ 2,5 s | 4,0 s |
| INP | Reaktion | ≤ 200 ms | 500 ms |
| CLS | Visuelle Stabilität | ≤ 0,1 | 0,25 |
Largest Contentful Paint markiert den Moment, in dem das größte Element im sichtbaren Bereich fertig gerendert ist — meist ein Hero-Bild oder ein Überschriftenblock. Es ist der Stellvertreter für „die Seite sieht aus, als wäre sie da“, und genau deshalb schlägt es ältere Marken wie das erste Rendering: Ein schnell gezeichnetes leeres Bild ist keine schnell ladende Seite.
Interaction to Next Paint hat First Input Delay im März 2024 als stabilen Core Web Vital abgelöst, und diese Ablösung war bedeutsam. FID maß nur die Verzögerung bis zur Verarbeitung der ersten Interaktion und schmeichelte damit Seiten, die auf den ersten Tipp flott antworteten und danach zäh wurden. INP betrachtet die vollständige Latenz der Interaktionen über den Besuch hinweg und meldet einen Wert nahe der schlechtesten.
Cumulative Layout Shift misst Inhalte, die sich bewegen, nachdem sie gezeichnet wurden. Es ist die Kennzahl hinter der allseits bekannten Erfahrung, nach einem Link zu greifen und eine Anzeige zu treffen, die darunter eingetroffen ist. Weil es ein Score und keine Dauer ist, kann ein einzelnes schlimmes Verrutschen spät auf der Seite die Zahl dominieren.
Bewertet am 75. Perzentil, auf Felddaten
Das ist der Teil, der Teams kalt erwischt. Bewertet wird das 75. Perzentil der Seitenaufrufe über ein rollierendes 28-Tage-Fenster, getrennt für Mobil und Desktop. Ein bequemer Median mit langsamem Ausläufer fällt trotzdem durch — und zwar absichtlich. Die Kennzahl handelt von dem Viertel der Besucher mit der schlechtesten Erfahrung, nicht vom typischen Besucher.
Es bedeutet auch, dass die Daten Felddaten sind, aus echten Besuchen gesammelt, kein Labordurchlauf. Laborwerkzeuge sind Diagnoseinstrumente: Sie sagen Ihnen, welche Ressource das Rendering aufhält, und dafür sind sie das richtige Werkzeug. Sie sind nicht die Bewertung, und ein grüner Laborwert neben einer durchgefallenen Feldbewertung ist kein Widerspruch — er heißt, dass Ihre echten Besucher nicht auf der Maschine sitzen, von der aus Sie getestet haben.
Was jede Kennzahl tatsächlich bewegt
Die Ursachen sind unspektakulär und wiederholen sich über Sites hinweg. Die meiste Arbeit besteht darin, zu entscheiden, was der Browser vor dem ersten bedeutungsvollen Rendering haben muss, und allem anderen den Platz in dieser Warteschlange zu verweigern.
| Kennzahl | Übliche Ursache | Übliche Lösung |
|---|---|---|
| LCP | Langsame Serverantwort | Dokument cachen, Weiterleitungsketten kürzen |
| LCP | Hero-Bild wird spät entdeckt | Vorladen, niemals lazy laden |
| LCP | Render-blockierendes CSS oder Schriften | Kritisches CSS inline, font-display nutzen |
| INP | Lange JavaScript-Aufgaben im Hauptthread | Aufteilen, Unwesentliches verschieben |
| INP | Schwere Drittanbieter-Skripte | Spät laden — oder streichen |
| CLS | Bilder und Einbettungen ohne Maße | width und height oder aspect-ratio setzen |
| CLS | Schriftwechsel, der den Text umbricht | Fallback-Metriken angleichen, Schrift vorladen |
| CLS | Banner, die über dem Inhalt eingefügt werden | Platz reservieren, bevor er gefüllt wird |
Drittanbieter-Skripte verdienen eine gesonderte Erwähnung, denn sie sind die häufigste Ursache eines INP-Problems und diejenige, für die sich niemand zuständig fühlt. Jedes Tag für Analytics, Chat, Tests oder Einwilligung konkurriert um denselben Hauptthread, den der Tipp des Lesers braucht. Die lohnende Audit-Frage ist nicht, ob jedes nützlich ist, sondern was es am 75. Perzentil kostet.
Wo Page Experience unter den Signalen steht
Google gibt an, dass seine zentralen Ranking-Systeme Core Web Vitals verwenden, es gibt jedoch kein einzelnes „Page Experience Signal“. Relevanz steht immer noch an erster Stelle und gute Core Web Vitals garantieren noch lange kein Top-Ranking.
Priorisieren Sie echte Nutzerprobleme, besonders auf wichtigen Vorlagen, ohne einen bestandenen Schwellenwert als Ranking-Garantie zu behandeln. Eine relevante Seite mit schwacher Nutzererfahrung kann weiterhin ranken; eine schnelle Seite, die an der Suchanfrage vorbeigeht, wird durch ihre Geschwindigkeit nicht relevanter.
Eine praktische Reihenfolge
Wenn Sie von einer durchgefallenen Bewertung ausgehen, vermeidet diese Reihenfolge die häufigsten vergeudeten Anstrengungen — das Feintunen von etwas, das bereits besteht, oder das Reparieren einer Seite ohne Traffic.
- Lesen Sie zuerst die Felddaten, getrennt nach Mobil und Desktop. Meist fällt nur Mobil durch, und Desktop zu reparieren ändert nichts.
- Finden Sie heraus, welche Kennzahl scheitert und bei welchen Seitengruppen. Templates scheitern gemeinsam; eine einzelne URL sagt selten viel.
- Reproduzieren Sie die Ursache im Labor, auf gedrosselter Verbindung. Das Labor sagt Ihnen, was langsam ist; das Feld hat gesagt, dass es zählt.
- Beheben Sie den größten Einzelbeitrag und liefern Sie aus. Teilverbesserungen sind der Weg, auf dem sich das bewegt — den einen Schalter gibt es selten.
- Warten Sie das 28-Tage-Fenster ab, bevor Sie urteilen. Die Bewertung ist ein nachlaufender Mittelwert, eine heute gelieferte Verbesserung zeigt sich allmählich.