Was sind Core Web Vitals?

Kurzantwort: Core Web Vitals sind drei Google-Metriken: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS). Sie messen, wie schnell, reaktionsfähig und visuell stabil sich eine Webseite für echte Besucher anfühlt. Google nutzt sie als Teil seiner Ranking-Signale zur Seitenerfahrung. Für SaaS-Marketing-Websites sind sie wichtig, weil langsame, ruckelnde Seiten sowohl Sichtbarkeit in der Suche als auch Trial-Anmeldungen verlieren. Eine Seite besteht, wenn mindestens 75 % der realen Besuche bei allen drei Metriken als „gut“ bewertet werden.

Google hat die Core Web Vitals eingeführt, um etwas zu quantifizieren, das früher subjektiv war: ob sich eine Seite tatsächlich gut nutzen lässt. Für SaaS-Teams, die mit G2, Capterra und einem Dutzend gut finanzierter Wettbewerber um organische Sichtbarkeit konkurrieren, ist technische Performance kein Backoffice-Thema mehr. Sie zeigt sich direkt in Rankings, Absprungraten und dem Vertrauen, das ein Interessent Ihrem Produkt entgegenbringt, noch bevor er eine Demo bucht.

Was sind die drei Core-Web-Vitals-Metriken?

Core Web Vitals sind eine Reihe von Metriken, die die reale Nutzererfahrung in Bezug auf Ladeleistung, Interaktivität und visuelle Stabilität der Seite messen. Jede Metrik betrifft einen anderen Moment im Erlebnis des Besuchers und hat einen eigenen Schwellenwert für „bestanden“ oder „nicht bestanden“.

Largest Contentful Paint (LCP)

Largest Contentful Paint misst die Ladeleistung. Für eine gute Nutzererfahrung sollte der LCP innerhalb der ersten 2,5 Sekunden nach Beginn des Seitenaufbaus erfolgen. Auf einer SaaS-Marketing-Website ist das größte Element meist ein Hero-Bild, ein Produkt-Screenshot oder eine große Überschrift. Alles, was dieses Rendering verzögert, etwa ein nicht optimiertes Bild, ein langsamer Server oder Render-blockierende Skripte, schiebt den LCP in den Bereich „verbesserungsbedürftig“ oder „schlecht“.

Interaction to Next Paint (INP)

Interaction to Next Paint misst die Reaktionsfähigkeit. Für eine gute Nutzererfahrung sollte der INP unter 200 Millisekunden liegen. INP ist die neueste der drei Metriken. INP hat First Input Delay (FID) im März 2024 vollständig abgelöst, daher ist jeder Leitfaden, der noch FID aufführt, veraltet. Anders als FID, das nur den ersten Klick oder Tap erfasste, bewertet INP die Latenz aller Interaktionen auf der Seite und ist damit ein deutlich strengeres und aussagekräftigeres Maß für die Reaktionsfähigkeit. Das ist wichtig für SaaS-Websites mit vielen Chat-Widgets, Preisrechnern und interaktiven Demos, denn jedes dieser Elemente verschlechtert den INP-Wert.

Cumulative Layout Shift (CLS)

Cumulative Layout Shift misst die visuelle Stabilität. Für eine gute Nutzererfahrung sollte der CLS-Wert unter 0,1 liegen. Der CLS steigt, wenn Bilder ohne Größenangaben laden, wenn Cookie-Banner oder Drittanbieter-Einbettungen nach dem ersten Rendering Inhalte einfügen oder wenn Webfonts nachgeladen werden und die Seite neu umbrechen. Eine einzige starke Verschiebung, etwa wenn eine Preistabelle springt, weil ein Chat-Widget lädt, kann den Wert für eine ganze Sitzung ruinieren.

Wie wirken sich die Core Web Vitals auf Google-Rankings aus?

Es gibt kein einzelnes Signal. Unsere zentralen Ranking-Systeme berücksichtigen eine Vielzahl von Signalen, die zur gesamten Seitenerfahrung passen. Unsere Ranking-Systeme nutzen die Core Web Vitals als Teil dieser Bewertung. In der Praxis fungieren die Core Web Vitals eher als Tiebreaker denn als Trumpf. Die Core Web Vitals sind zwar ein Ranking-Faktor, doch relevante Inhalte sind für die Suchmaschinenoptimierung natürlich entscheidend. Google kann die Core Web Vitals aber als „Tiebreaker“ zwischen Seiten mit ähnlicher Inhaltsqualität heranziehen.

Diese Unterscheidung ist wichtig dafür, wie SaaS-Teams ihre Zeit priorisieren. Eine wunderbar schnelle Seite mit dünnen, wenig hilfreichen Inhalten verliert gegen eine langsamere Seite, die die Frage des Suchenden besser beantwortet. Veröffentlichen aber zwei Wettbewerber zum selben Vergleichs-Keyword Inhalte von ähnlicher Tiefe, gewinnt meist die Seite, die schneller und stabiler ist. Genau diesen Vorteil hilft Seedling SaaS-Content-Teams zu erkennen: Inhalte, die stark genug sind, um bei der Relevanz zu bestehen, und auf einem technischen Fundament stehen, das sie im Grenzfall nicht den Ranking-Vorsprung kostet.

Der Business Case geht über Rankings hinaus. In einer aktuellen Studie mit Millionen von Seitenaufrufen stellte Google fest, dass bei Websites, die die Schwellenwerte der Core Web Vitals erfüllen, die Wahrscheinlichkeit eines Abbruchs vor dem vollständigen Laden der Seite um 24 % geringer war. Wenn eine SaaS-Website bezahlten und organischen Traffic auf dieselben Landingpages lenkt, bedeutet diese Abbruchlücke unmittelbar verschwendetes Budget und verlorene Pipeline.

Wie werden die Core Web Vitals gemessen?

Google zieht eine klare Grenze zwischen zwei Arten von Daten, und sie zu vermischen ist einer der häufigsten Fehler im technischen SEO.

Felddaten sind die für das Ranking relevante Ebene. Google erhebt globale Felddaten zum 75. Perzentil der tatsächlichen Nutzer, die in den letzten 28 Tagen mit dem Chrome-Browser auf Ihre Anwendung zugegriffen haben. Diese Daten liegen im Chrome User Experience Report (CrUX) und erscheinen im Core-Web-Vitals-Bericht der Google Search Console.

Labordaten, die von Tools wie PageSpeed Insights oder Lighthouse erzeugt werden, sind für das Debugging nützlich, bestimmen aber nicht das Ranking. Lighthouse-Werte wirken sich nicht direkt auf Google-Rankings aus. Ein niedriger Performance-Wert in einem Labortest bedeutet nicht, dass Ihre Website bei den realen Core-Web-Vitals-Nutzerdaten schlecht abschneidet. Labordaten weichen häufig stark von echten Nutzerdaten ab.

Google legt die Grenze zwischen bestanden und nicht bestanden an einem bestimmten Perzentil fest, nicht an einem Durchschnitt. Um die Core Web Vitals zu bestehen, müssen mindestens 75 % Ihrer Besucher im Google-CrUX-Datensatz auf URL-Ebene einen „guten“ LCP-, INP- und CLS-Wert haben. Es reicht nicht, dass die Seite auf Ihrem High-End-Laptop mit Glasfaseranschluss schnell ist: Sie muss auch für den viertlangsamsten von je vier Nutzern schnell sein, typischerweise jemand mit einem Mittelklasse-Smartphone und einer wackeligen Mobilfunkverbindung. Dieses eine Grundprinzip erklärt, warum so viele SaaS-Marketing-Websites ihre eigenen internen QA-Prüfungen bestehen und in der Search Console trotzdem „schlecht“ anzeigen.

Welche typischen Fehler beeinträchtigen die Core Web Vitals von SaaS-Websites?

SaaS-Marketing-Websites scheitern bei den Core Web Vitals nach anderen Mustern als E-Commerce- oder Publisher-Websites, vor allem wegen des Tool-Stacks, auf den Marketing-Teams setzen.

• Zu viele Drittanbieter-Widgets. Chat-Tools, Software für Produkttouren und Marketing-Automation-Skripte blockieren den Main Thread und verschlechtern den INP. Jedes von ihnen erhöht die Latenz jeder Interaktion auf der Seite messbar.
• Dashboard- oder Produkt-Einbettungen auf Marketingseiten. Live-Produktvorschauen, oft der Kern eines Homepage-Hero-Bereichs, sind häufig der größte einzelne LCP-Verursacher, weil sie langsamer laden als ein statisches Bild oder Video.
• Cookie- und Einwilligungs-Modals. Sie werden spät im Rendering-Zyklus eingefügt und sind eine der Hauptursachen für CLS-Probleme auf B2B-Websites, die unter der DSGVO oder ähnlichen Einwilligungsvorgaben arbeiten.
• Nur die Startseite testen. Die Startseite besteht meist. Bei stark besuchten Blogbeiträgen, Vergleichsseiten und bezahlten Landingpages konzentrieren sich die CWV-Probleme tatsächlich, und genau diese Seiten tragen den größten Teil des organischen und bezahlten Traffics.
• Laborwerten mehr vertrauen als Felddaten. Ein grüner Lighthouse-Wert vermittelt falsche Sicherheit. Nur die CrUX-Felddaten spiegeln wider, was Google tatsächlich zur Bewertung der Seitenerfahrung verwendet.

Wie können Sie die Core Web Vitals verbessern?

LCP zu beheben ist meist der einfachste Erfolg: Hero-Bilder in WebP oder AVIF umwandeln, explizite Breiten- und Höhenattribute ergänzen, kritische Ressourcen vorab laden und nicht essenzielle Skripte zurückstellen. INP ist schwieriger und erfordert oft ein Umdenken bei der JavaScript-Architektur: lange Tasks aufteilen, Drittanbieter-Widgets zurückstellen und alles per Lazy Loading laden, was für die erste Interaktion nicht benötigt wird. CLS lösen Sie, indem Sie für jedes Bild, jede Anzeige und jede Einbettung Platz reservieren, bevor sie laden, und mit font-display swap einen Textumbruch vermeiden.

Entscheidend ist nicht eine einzelne Korrektur. Entscheidend ist, Felddaten aus CrUX oder einem Real-User-Monitoring-Tool in dasselbe Dashboard zu leiten, in dem auch Ihre Content- und Traffic-Metriken liegen, damit sich eine Verschlechterung in Tagen zeigt statt in dem 28-Tage-Zeitfenster, das CrUX standardmäßig verwendet. Für SaaS-Teams, die Seedling bereits zur Steuerung der Content-Produktion und zur Verfolgung der organischen Sichtbarkeit nutzen, schließt die Kombination dieses Workflows mit einem Core-Web-Vitals-Monitor den Kreis zwischen dem, was Sie veröffentlichen, und der tatsächlichen Performance, sobald echte Besucher die Seite auf echten Geräten laden.

Die Core Web Vitals werden sich weiterentwickeln, während Google präzisiert, was in der Praxis eine „gute Erfahrung“ ist. Sie als einmaliges Audit statt als fortlaufende Aufgabe zu behandeln, ist der Fehler, der SaaS-Websites unbemerkt Rankings und Conversions kostet, lange nachdem die erste Korrektur ausgeliefert wurde.