Core Web Vitals für B2B-Websites: Was wirklich optimiert werden sollte

Problem und Zielgruppe

Eine B2B-Website muss selten Millionen Besucher:innen bedienen – aber genau die wenigen, die zählen, verlässt sie am schnellsten, wenn sie langsam wirkt. Eine Produktseite mit trägem Ladeverhalten, ein Kontaktformular, das beim Absenden erst nach spürbarer Verzögerung reagiert, oder ein Inhaltsverzeichnis, das sich beim Scrollen verschiebt: Für Interessent:innen, die gerade zwischen drei Anbietern vergleichen, reicht das oft, um die Seite zu verlassen, bevor überhaupt ein Angebot gelesen wurde.

Core Web Vitals sind der Versuch, dieses Nutzungserlebnis in drei überprüfbare Zahlen zu fassen – nicht als akademische Übung, sondern weil Google sie laut eigener Dokumentation als Teil der Rankingsysteme für die Suche berücksichtigt, neben anderen Aspekten der Page Experience. Für B2B-Websites mit Fokus auf Leads und Termine kommt ein zweiter, oft wichtigerer Effekt dazu: schlechte Werte korrelieren erfahrungsgemäß mit höheren Absprungraten auf genau den Seiten, die eigentlich konvertieren sollen – Produktseiten, Formulare, Preis- und Kontaktseiten.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU, die entweder selbst über eine Website-Überarbeitung entscheiden oder eine Agentur beziehungsweise interne Entwicklung dazu briefen müssen. Er beantwortet: Welche Metriken gibt es, wie werden sie gemessen, welche Ursachen sind typisch, wie priorisiert man Maßnahmen, und wie verhindert man, dass die Werte nach der nächsten Änderung wieder kippen.

Begriffe kurz geklärt

Core Web Vitals sind laut web.dev drei Kennzahlen, mit denen Google Ladeperformance, Interaktivität und visuelle Stabilität einer Seite standardisiert misst: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS).

Feld- versus Labordaten ist die wichtigste Unterscheidung im gesamten Thema. Felddaten stammen von echten Besucher:innen mit ihren tatsächlichen Geräten, Netzverbindungen und Nutzungsmustern – erhoben über den Chrome UX Report (CrUX). Labordaten entstehen in einer simulierten, kontrollierten Umgebung wie Lighthouse, meist während der Entwicklung. Beide sind nützlich, beantworten aber unterschiedliche Fragen: Felddaten zeigen, was Nutzer:innen wirklich erleben; Labordaten zeigen, woran es liegen könnte.

Page Experience ist der übergeordnete Begriff, unter dem Google Core Web Vitals zusammen mit weiteren Signalen wie Mobilfreundlichkeit und sicherer Verbindung führt. Core Web Vitals sind ein Teil davon, nicht das Ganze.

Wichtig für die Erwartungshaltung: Core Web Vitals sind kein Freibrief für gutes Ranking und keine Garantie für mehr Anfragen. Sie sind ein technisches Mindestmaß, das eine gute Seite nicht automatisch schafft, aber dessen Fehlen eine ansonsten gute Seite ausbremst.

Welche Metriken gibt es?

Drei Kennzahlen bilden aktuell die Core Web Vitals, jeweils bewertet am 75. Perzentil der Seitenaufrufe – getrennt nach Mobilgeräten und Desktop, weil sich das Nutzungsverhalten deutlich unterscheidet.

Metrik	Was sie misst	Gut	Verbesserungswürdig	Schlecht
Largest Contentful Paint (LCP)	Wie schnell das größte sichtbare Element lädt (meist Hero-Bild oder Überschrift)	≤ 2,5 s	2,5–4,0 s	> 4,0 s
Interaction to Next Paint (INP)	Wie schnell die Seite auf Klicks, Taps und Tastatureingaben visuell reagiert	≤ 200 ms	200–500 ms	> 500 ms
Cumulative Layout Shift (CLS)	Wie stark sich sichtbare Elemente unerwartet verschieben	≤ 0,1	0,1–0,25	> 0,25

Schwellenwerte nach web.dev (Google), Stand Juli 2026.

Eine kurze Geschichte gehört zur Einordnung dazu: Bis März 2024 war First Input Delay (FID) die dritte Kennzahl statt INP. FID maß nur die Verzögerung bis zur ersten Reaktion auf eine Interaktion; INP bewertet alle Interaktionen über die gesamte Seitensitzung und deckt damit Probleme auf, die FID systematisch übersehen hat – etwa eine Seite, die beim ersten Klick flott reagiert, aber beim zweiten oder dritten spürbar hakt, weil im Hintergrund noch Skripte laufen. Für B2B-Seiten mit mehrstufigen Formularen oder Konfiguratoren ist das relevant: genau dort passiert die zweite und dritte Interaktion, nicht nur die erste.

Wie werden sie gemessen?

Zwei Datenquellen, zwei Zwecke:

Felddaten (CrUX) stammen laut Chrome-Developers-Dokumentation aus echten Chrome-Browsern weltweit und bilden die tatsächliche Nutzungserfahrung ab – vorausgesetzt, eine Seite hat genug Traffic, um statistisch belastbare Werte zu liefern. Diese Daten fließen in die Search-Console-Rubrik „Core Web Vitals” und in den Feldbericht von PageSpeed Insights ein. Für Google ist CrUX laut eigener Dokumentation die Datenbasis, die in die Page-Experience-Bewertung für die Suche einfließt.

Labordaten (Lighthouse & Co.) entstehen in einer simulierten Umgebung ohne echte Nutzerinteraktion. Das macht sie ideal zum Debuggen vor dem Livegang – aber mit einer wichtigen Einschränkung, die web.dev ausdrücklich benennt: Tools wie Lighthouse können INP nicht messen, weil dafür eine tatsächliche Interaktion einer echten Person nötig ist. Für INP brauchst du zwingend Felddaten oder ein manuelles, interaktives Testtool.

Für die Praxis heißt das: Labordaten eignen sich, um eine Vermutung zu bestätigen oder zu verwerfen, bevor du etwas veröffentlichst. Felddaten sagen dir, ob es bei den Menschen ankommt, die deine Seite tatsächlich nutzen – inklusive ihrer oft schlechteren Endgeräte und Mobilfunkverbindungen, die im Büro-WLAN der Entwicklung selten auffallen.

Welche Ursachen sind typisch?

Die drei Metriken haben unterschiedliche typische Ursachen. Wer das nicht unterscheidet, optimiert oft am falschen Ende.

LCP. Laut web.dev zerfällt LCP in vier Teilabschnitte: Time to First Byte (TTFB, oft rund 40 Prozent des Gesamtwerts), Verzögerung bis das LCP-Element zu laden beginnt (Resource Load Delay), die eigentliche Ladezeit dieses Elements (Resource Load Duration, ebenfalls oft rund 40 Prozent) und die Verzögerung bis zum tatsächlichen Rendern (Element Render Delay). Auf B2B-Seiten sind die häufigsten Übeltäter ein zu großes, nicht optimiertes Hero-Bild, ein Hero-Element, das erst per JavaScript nachgeladen wird statt direkt im HTML zu stehen, und ein langsamer Server oder Hosting-Anbieter, der bereits die TTFB in die Höhe treibt.

INP. Laut web.dev ist JavaScript der häufigste Treiber schlechter Interaktivität – konkret lange Aufgaben (Long Tasks), die den Hauptthread des Browsers blockieren, sodass Klicks und Eingaben erst mit Verzögerung verarbeitet werden. Auf B2B-Seiten sind das in der Praxis oft nicht die eigenen Skripte, sondern Drittanbieter: Tracking- und Analytics-Snippets, eingebettete Chat-Widgets, Cookie-Consent-Layer und Video-Embeds, die beim Laden alle gleichzeitig um Rechenzeit konkurrieren.

CLS. Laut web.dev entstehen Layoutverschiebungen vor allem durch Bilder und Videos ohne festgelegte Breiten- und Höhenangaben, durch Web-Fonts, die größer oder kleiner als ihre Fallback-Schrift rendern, durch Drittanbieter-Werbung und -Widgets, die sich nachträglich in ihrer Größe verändern, und durch dynamisch nachgeladenen Inhalt – etwa ein Cookie-Banner oder ein Newsletter-Hinweis, der sich erst nach dem ersten Rendern über den Seiteninhalt schiebt.

Ein Muster zieht sich durch alle drei: Vieles, was auf den ersten Blick wie ein Content- oder Design-Problem aussieht, ist technisch betrachtet ein Problem fehlender Größenangaben, fehlender Priorisierung oder unkontrollierter Drittanbieter-Skripte.

Wie priorisiert man Maßnahmen?

Der klassische Fehler ist, eine lange Liste von Lighthouse-Warnungen von oben nach unten abzuarbeiten. Das kostet Zeit und bewegt die Felddaten oft kaum, weil Lighthouse-Punktzahl und tatsächliche Nutzererfahrung nicht linear zusammenhängen. Sinnvoller ist eine Priorisierung nach zwei Achsen: wie stark eine Maßnahme die Metrik am 75. Perzentil bewegt, und wie aufwändig sie umzusetzen ist.

Wirkung \ Aufwand	Gering (Stunden)	Mittel (Tage)	Hoch (Wochen, strukturelle Änderung)
Hoch (bewegt LCP/INP/CLS deutlich)	Sofort umsetzen – meist der größte Hebel im Verhältnis zum Aufwand	Für nächsten Sprint einplanen	Nur mit klarem Business-Case und Ressourcenfreigabe
Mittel	Bei Gelegenheit mit erledigen	Bündeln mit anderen Maßnahmen im gleichen Bereich	Meist nicht priorisieren, außer als Nebeneffekt eines größeren Umbaus
Gering	Ignorieren, wenn Zeit knapp ist	Ignorieren	Nie priorisieren

Eigene Priorisierungsmatrix Philogic Labs, aus Website-Projekten abgeleitet.

Typische Beispiele für „hohe Wirkung, geringer Aufwand”: das LCP-Bild mit fetchpriority="high" markieren und aus dem Lazy-Loading ausnehmen, feste width- und height-Attribute auf Bilder setzen, ein einzelnes blockierendes Drittanbieter-Skript verzögert statt sofort laden. Typische Beispiele für „hohe Wirkung, hoher Aufwand”: ein clientseitig gerendertes Frontend auf serverseitiges Rendering umstellen, ein komplett neues Hosting-Setup. Diese gehören auf die Roadmap, nicht auf die Liste für diese Woche.

In meiner Arbeit fahre ich damit am besten: erst mit den Felddaten aus Search Console oder PageSpeed Insights die Seiten identifizieren, die tatsächlich schlecht abschneiden und gleichzeitig viel Traffic oder hohen Conversion-Wert haben – eine Landingpage mit zehn Besuchen im Monat ist selten die erste Priorität, egal wie schlecht ihr LCP ist. Danach pro betroffener Seite mit Labordaten (Lighthouse, Chrome DevTools Performance-Panel) die konkrete Ursache eingrenzen, und erst dann die Matrix anwenden.

Wie verhindert man Regressionen?

Der häufigste Fehler nach einer erfolgreichen Optimierung: Sie hält drei Monate, bis das nächste Marketing-Tool, das nächste große Hero-Bild oder das nächste Cookie-Consent-Update die Werte wieder verschlechtert – und das fällt oft erst auf, wenn im Search-Console-Bericht plötzlich wieder rote Zahlen stehen.

Drei Bausteine haben sich in der Praxis bewährt, um das zu verhindern:

• Performance-Budgets in der Build-Pipeline. Feste Obergrenzen für Bildgrößen, JavaScript-Bundle-Größe oder Lighthouse-Score, die den Build fehlschlagen lassen, wenn sie überschritten werden. Das verhindert, dass Regressionen überhaupt live gehen.
• Automatisierte Lighthouse-Läufe pro Deployment. Ein automatischer Check bei jedem neuen Release macht Verschlechterungen sofort sichtbar, statt sie erst Wochen später in den Felddaten zu entdecken.
• Regelmäßiger Blick in echte Felddaten. Labortests allein reichen nicht – sie messen unter Idealbedingungen. Ein monatlicher Blick in den Search-Console-Bericht (basierend auf CrUX) zeigt, was bei echten Nutzer:innen wirklich ankommt, inklusive der schlechteren Mobilgeräte und Verbindungen, die im Büro selten getestet werden.

Ein vierter, oft unterschätzter Punkt: jede neue Drittanbieter-Integration – ein neues Analytics-Tool, ein Chat-Widget, ein Marketing-Pixel – verdient vor dem Livegang eine kurze Performance-Prüfung. Genau solche Snippets sind in meiner Erfahrung die häufigste Ursache für schleichend schlechter werdende INP-Werte, weil sie einzeln kaum auffallen, sich aber summieren.

Umsetzung: So gehe ich in Projekten konkret vor

Ohne konkrete Zahlen zu erfinden, lässt sich das Vorgehen als reproduzierbare Methode beschreiben, die sich auf jede reale B2B-Website anwenden lässt:

1. Ist-Zustand mit Felddaten erfassen. PageSpeed Insights oder die Search-Console-Rubrik „Core Web Vitals” für die wichtigsten Seiten prüfen – Startseite, Produkt- oder Leistungsseiten, Kontakt- und Formularseiten. Wo liegen LCP, INP und CLS am 75. Perzentil, mobil und Desktop getrennt?
2. Ursache pro auffälliger Seite mit Labordaten eingrenzen. Lighthouse oder das Chrome-DevTools-Performance-Panel zeigen, welcher LCP-Teilabschnitt (TTFB, Resource Load Delay, Resource Load Duration, Render Delay) den größten Anteil hat, welche Skripte den Hauptthread blockieren und welche Elemente für Layoutverschiebungen verantwortlich sind.
3. Maßnahmen mit der Priorisierungsmatrix sortieren (siehe oben) und die Maßnahmen mit hoher Wirkung und geringem Aufwand zuerst umsetzen.
4. Nachmessen, mit Feld- und Labordaten. Labordaten sofort nach dem Deployment, Felddaten erst nach einigen Tagen bis Wochen – CrUX-Daten sind rollierende Durchschnittswerte, keine Momentaufnahme.
5. Budgets und automatisierte Checks einrichten, damit der erreichte Zustand nicht in den Wochen danach wieder verfällt.

Dieses Vorgehen ist bewusst kein einmaliges Projekt, sondern ein wiederkehrender Zyklus – genau wie eine echte SEO- oder Content-Pflege. Wer Core Web Vitals einmal optimiert und dann nie wieder anschaut, hat in aller Regel nach einem Jahr wieder den Ausgangszustand.

Risiken und Grenzen

Ein paar ehrliche Einschränkungen gehören zu diesem Thema dazu:

• Core Web Vitals sind kein Rankinggarant. Google selbst ordnet sie als einen von mehreren Page-Experience-Aspekten ein, die in die Kernrankingsysteme einfließen – nicht als isolierten, dominanten Faktor. Eine Seite mit perfekten Vitals-Werten, aber schwachem Inhalt, rankt trotzdem nicht automatisch gut.
• Felddaten brauchen ausreichend Traffic. Sehr traffic-arme Nischenseiten – bei vielen B2B-Websites die Mehrzahl der Unterseiten – liefern oft keine ausreichenden CrUX-Daten für belastbare Werte. Dort bleiben Labordaten die einzige Orientierung.
• Nicht jede Verbesserung lohnt den Aufwand. Eine strukturelle Änderung wie ein Wechsel des Rendering-Ansatzes ist teuer und riskant. Sie lohnt sich nur, wenn die betroffenen Seiten tatsächlich geschäftlich relevant sind – nicht, weil eine Kennzahl schlecht aussieht.
• Drittanbieter-Abhängigkeiten lassen sich selten vollständig kontrollieren. Ein Marketing- oder Vertriebstool, auf das das Unternehmen angewiesen ist, bringt oft eigene Performance-Kosten mit, die sich nur begrenzt wegoptimieren lassen. Hier hilft meist nur eine bewusste Abwägung, welche Tools den Aufwand wirklich wert sind.

Kosten und Aufwand: grobe Einordnung

Auch hier gilt: nur Bandbreiten mit klar genannten Annahmen, keine Zusagen. Für eine bestehende B2B-Website mit überschaubarer technischer Komplexität (kein eigenes komplexes Frontend-Framework, Standard-CMS oder vergleichbarer Stack) lassen sich die „hohe Wirkung, geringer bis mittlerer Aufwand”-Maßnahmen aus der Matrix oben erfahrungsgemäß in wenigen Personentagen umsetzen: Bildoptimierung, Größenangaben ergänzen, einzelne Skripte verzögert laden, Fonts sauber einbinden. Strukturelle Maßnahmen – etwa ein Wechsel des Rendering-Ansatzes oder ein Hosting-Wechsel – bewegen sich je nach bestehender Architektur in einer deutlich größeren Bandbreite von mehreren Wochen und sind ohne vorherige Analyse seriös nicht bezifferbar.

Der laufende Aufwand für Monitoring und Regressionsschutz ist meist kleiner als die einmalige Erstoptimierung, aber er darf nicht bei null eingeplant werden – ein monatlicher Blick in die Felddaten und die Prüfung neuer Integrationen vor dem Livegang lassen sich mit wenig Zeit pro Monat abdecken, sofern die Budgets und automatisierten Checks aus dem Abschnitt oben einmal eingerichtet sind.

Checkliste: Core Web Vitals für B2B-Websites

1. Wir kennen unsere aktuellen LCP-, INP- und CLS-Werte aus echten Felddaten (Search Console oder PageSpeed Insights), nicht nur aus einem einmaligen Labortest.
2. Wir haben die Werte getrennt für Mobil und Desktop geprüft, nicht nur einen Durchschnitt.
3. Wir kennen für unsere schwächsten Seiten die konkrete Ursache (LCP-Teilabschnitt, blockierendes Skript, Layoutverschiebung) statt nur die Symptomzahl.
4. Wir haben Maßnahmen nach Wirkung und Aufwand priorisiert, nicht nach der Reihenfolge einer Warnungsliste.
5. Die Seiten mit echtem Geschäftswert (Formulare, Produkt- und Kontaktseiten) haben Priorität vor traffic-armen Nischenseiten.
6. Wir haben Performance-Budgets oder zumindest automatisierte Lighthouse-Checks in der Build- oder Deployment-Pipeline.
7. Jede neue Drittanbieter-Integration wird vor dem Livegang auf ihre Performance-Auswirkung geprüft.
8. Wir prüfen die Felddaten regelmäßig (mindestens monatlich), nicht nur einmalig nach einem Relaunch.
9. Uns ist bewusst, dass gute Core Web Vitals ein Baustein unter mehreren sind – kein Ersatz für gute Inhalte und keine Ranking-Garantie.

Wer diese Punkte für die eigene Website nicht sicher beantworten kann, findet im Themen-Cluster Web, SEO & GEO weitere Hintergründe zu technischer SEO und KI-gestützter Website-Entwicklung. Für eine gemeinsame Einordnung der eigenen Seite eignet sich ein kostenloses Erstgespräch; wer die Umsetzung selbst im Team stemmen will, findet in unseren Schulungen das nötige Handwerkszeug, und unser Beratungsangebot unterstützt, wenn eine strukturelle Überarbeitung ansteht.