← Zurück zum Blog
Zusammenfassen in: ChatGPT Google AI Claude Perplexity

Core Web Vitals auf Kundenwebsites: So verfolgen Sie Labor- und Felddaten

· · Mit KI entworfen, geprüft von Pavol Bincik · Wie wir schreiben

TL;DR

Core Web Vitals ändern sich, sobald sich ein Plugin, ein Theme oder ein Tag ändert, deshalb veraltet ein Audit vom Launch-Tag schnell. Lighthouse liefert eine wiederholbare Labormessung, die eine Verschlechterung beim nächsten Lauf zeigt. CrUX zeigt, was echte Chrome-Nutzer erlebt haben, als gleitenden Durchschnitt über 28 Tage, und reagiert daher in beide Richtungen langsam. Google nutzt Core Web Vitals für das Ranking, sagt aber, dass Relevanz Vorrang hat. Verfolgen Sie beides auf den Seiten, auf die es ankommt. Ein Uptime-Check leistet keines von beidem: Er misst, wie schnell der Server antwortet, nicht wie die Seite gerendert wird.

Die meisten Kundenwebsites bekommen beim Launch einen Lauf in PageSpeed Insights, und danach sieht niemand mehr hin. Dann fügt ein Plugin-Update ein Skript hinzu, der Kunde lädt ein großes Hero-Bild hoch, das Marketing baut über den Tag Manager ein Chat-Widget ein. Nichts davon löst einen Uptime-Alarm aus, und all das kann die Seite verlangsamen.

Die drei Core Web Vitals und ihre Grenzwerte

  • Largest Contentful Paint (LCP): wann das größte Bild oder der größte Textblock erscheint. Gut: 2,5 Sekunden oder weniger.
  • Interaction to Next Paint (INP): wie schnell die Seite auf Klicks, Tippen und Tastendrücke reagiert. Gut: 200 Millisekunden oder weniger; schlecht: mehr als 500. INP hat First Input Delay am 12. März 2024 als Core Web Vital abgelöst.
  • Cumulative Layout Shift (CLS): wie stark das Layout beim Laden springt. Gut: 0,1 oder weniger.

Eine Seite erfüllt einen Grenzwert, wenn mindestens 75 % der Seitenaufrufe ihn erfüllen, getrennt gemessen für Mobilgeräte und Desktop.

Wie viel sie für das Ranking bedeuten

Google erklärt, dass seine Ranking-Systeme Core Web Vitals verwenden. Google sagt aber auch, dass die Suche weiterhin die relevanteste Seite zeigt, selbst wenn deren Nutzererfahrung (Page Experience) schlecht ist, und dass gute Werte in den eigenen Berichten keine Top-Positionen garantieren. Für eine Kundenwebsite heißt das: Geschwindigkeit rettet keinen schwachen Inhalt, aber eine langsame Seite verschenkt einen Vorteil, den sie nicht hätte verlieren müssen.

Labordaten und Felddaten sind unterschiedliche Messungen

Labordaten stammen aus Lighthouse, der Engine hinter PageSpeed Insights. Lighthouse lädt die Seite einmal in einer kontrollierten, simulierten Umgebung. Dadurch ist die Messung wiederholbar, gut für die Fehlersuche und gut, um eine Verschlechterung direkt nach einer Änderung zu erkennen. Die Messung hat allerdings Grenzen:

  • Labordaten können INP nicht messen, weil niemand mit der Seite interagiert. Total Blocking Time (TBT) ist ein brauchbarer Anhaltspunkt, aber kein Ersatz.
  • Die Werte schwanken zwischen den Läufen, etwa durch Werbung, A/B-Tests oder das Netzwerk-Routing. Achten Sie deshalb auf den Trend, nicht auf eine einzelne Zahl.
  • Der Performance-Score hat drei Bereiche: 0 bis 49 schlecht, 50 bis 89 verbesserungsbedürftig, 90 bis 100 gut.

Felddaten stammen aus dem Chrome UX Report (CrUX): von echten Chrome-Nutzern, die der Übermittlung von Nutzungsstatistiken zugestimmt und die Synchronisierung des Verlaufs aktiviert haben. Sie stammen nicht von Crawlern. Zwei Eigenschaften sind wichtig:

  • Es handelt sich um einen gleitenden Durchschnitt über 28 Tage, der täglich aktualisiert wird. Eine heute ausgelieferte Verschlechterung zeigt sich schrittweise über die nächsten Wochen, und eine Korrektur braucht genauso lange, bis sie sichtbar wird.
  • Eine Seite braucht genug Chrome-Traffic für eigene Daten. Fehlen sie, greift PageSpeed Insights auf den gesamten Origin zurück, und eine kleine Website hat unter Umständen gar keine Felddaten.

Labordaten zeigen Ihnen also schnell, dass sich etwas geändert hat; Felddaten zeigen, was Besucher tatsächlich erlebt haben.

Warum ein Uptime-Check hier nicht hilft

Ein Uptime-Check misst, wie schnell der Server auf die Anfrage antwortet. Er rendert die Seite nicht, lädt keine Bilder und führt keine Skripte aus, deshalb sieht er weder LCP noch INP noch CLS.

Eine Eingangsgröße sieht er aber: die Antwortzeit des Servers. Time to First Byte kommt vor First Contentful Paint und LCP, ein langsamer werdender Server bremst also alles, was danach kommt. Eine gute TTFB liegt bei 0,8 Sekunden oder weniger. Steigt die Antwortzeit nach einem Hosting-Wechsel, lohnt sich ein Lighthouse-Lauf.

Was Kundenwebsites meistens verlangsamt

Das sind die üblichen Verdächtigen, keine Messwerte:

  • Plugin- und Theme-Updates, die Skripte, Stylesheets oder Webfonts hinzufügen.
  • Neue Tags im Tag Manager: Chat-Widgets, Pixel, Heatmaps.
  • Bilder und Videos, die der Kunde in voller Größe hochlädt.
  • Slider und Page Builder, die auf jeder Seite laden.
  • Hosting-Änderungen: ein günstigerer Tarif, ein neuer Server, ein fehlender Cache.

Eine Routine, die Schritt hält

  1. Wählen Sie pro Kunde zwei oder drei Seiten aus: die Startseite und die Seiten, die Anfragen oder Verkäufe bringen.
  2. Halten Sie in PageSpeed Insights einen Ausgangswert fest: den Labor-Score, LCP, TBT und CLS sowie die Felddaten, falls vorhanden.
  3. Führen Sie Lighthouse nach jedem Update erneut aus und zwischendurch nach einem festen Zeitplan.
  4. Prüfen Sie die Felddaten einmal im Monat. Denken Sie daran, dass sie Änderungen um Wochen hinterherhinken.
  5. Gehen Sie alle paar Monate mit dem Kunden den Tag Manager durch und entfernen Sie, was niemand nutzt.

So verfolgt Baromio das

  • Lighthouse nach Zeitplan: Aktivieren Sie Page Speed überwachen bei einem HTTP- oder Keyword-Monitor. Baromio führt Lighthouse über Google PageSpeed Insights aus (mobil) und speichert den Performance-Score, LCP, FCP, TBT, CLS, Speed Index und das Seitengewicht nach Ressourcentyp. Free: 1 URL, wöchentlich. Pro (9 EUR pro Monat): 5 URLs, täglich. Business (29 EUR pro Monat): 15 URLs, täglich. Der Verlauf wird je nach Plan 7, 30 oder 90 Tage aufbewahrt.
  • Alarme: Sie werden benachrichtigt, wenn der Score unter 50 fällt, also in den Lighthouse-Bereich "schlecht", und danach nur dann erneut, wenn er um weitere 15 Punkte sinkt. Eine Entwarnung folgt, wenn der Score wieder bei 50 oder höher liegt und mindestens 15 Punkte höher ist.
  • CrUX-Felddaten: Für dieselben Monitore speichert Baromio täglich einen CrUX-Snapshot für genau diese URL, für Smartphones, Desktops und alle Geräte zusammen: p75 von LCP, FCP, CLS, INP und TTFB, jeweils mit der Verteilung gut / verbesserungsbedürftig / schlecht. Hat CrUX keine Daten für die URL, wird kein Snapshot gespeichert, und der Tab Seitengeschwindigkeit weist darauf hin; bei Seiten mit wenig Traffic ist das normal.
  • Aus einem KI-Assistenten: Dieselben Felddaten sind über den MCP-Server von Baromio verfügbar (get-crux-data).

Quellen

Wir verwenden Cookies, um zu verstehen, wie Baromio genutzt wird, und um das Produkt zu verbessern. Sie können Analyse-Cookies jederzeit akzeptieren oder ablehnen. Mehr erfahren