Core Web Vitals verbessern: die 5 häufigsten Bremsen

Drei Metriken, fünf Ursachen, eine Priorisierung nach Wirkung. So findest du die Bremse, statt an allem gleichzeitig zu drehen.

Core Web Vitals sind drei Messwerte, mit denen Google die Nutzererfahrung bewertet: Ladezeit, Reaktionszeit, visuelle Stabilität. Google nennt klare Schwellen. Eine Seite gilt als gut, wenn 75 Prozent der echten Aufrufe darunter liegen (web.dev, 2026). Die Werte sind öffentlich und für jede URL abrufbar. Damit sind sie zugleich Ranking-Signal und Conversion-Hebel.

Die drei Metriken, in Zahlen

Jede Metrik misst einen anderen Teil des Seitenerlebnisses. Die Schwellen kommen direkt von Google.

• LCP (Largest Contentful Paint): wann das größte sichtbare Element steht. Gut: unter 2,5 Sekunden.
• INP (Interaction to Next Paint): wie schnell die Seite auf einen Klick oder Tipp reagiert. Gut: unter 200 Millisekunden.
• CLS (Cumulative Layout Shift): wie stark das Layout beim Laden verrutscht. Gut: unter 0,1.

INP ist die jüngste der drei. Seit März 2024 ersetzt sie den alten FID-Wert (web.dev, 2024). Gemessen wird am 75. Perzentil aller Aufrufe, getrennt nach Mobil und Desktop (web.dev, 2026). Ein guter Laborwert reicht also nicht. Die Mehrheit deiner echten Besucher muss die Schwelle halten.

Ranking-Faktor? Ja, aber kein Hauptschalter

Hier lohnt Präzision. Core Web Vitals fließen in Googles Ranking ein, aber sie sind kein dominanter Faktor. Google selbst formuliert es zurückhaltend:

Es gibt kein einzelnes Signal. Unsere Kern-Ranking-Systeme betrachten eine Vielzahl von Signalen, die zur gesamten Page Experience passen. (Google Search Central, 2026)

Relevanz schlägt Geschwindigkeit. Eine langsame Seite mit dem besten Inhalt rankt trotzdem. Bei Anfragen mit vielen gleich guten Ergebnissen aber kippt die Page Experience das Rennen. Und der zweite Hebel wirkt sofort: Tempo verkauft. Vodafone verbesserte den LCP um 31 Prozent und verzeichnete 8 Prozent mehr Verkäufe (web.dev Case Study, 2026). Das Ranking ist die eine Hälfte. Die Absprungrate ist die andere.

Die fünf üblichen Verdächtigen

Die meisten schlechten Werte haben dieselben Ursachen. Fünf tauchen immer wieder auf.

• Schwere Bilder ohne modernes Format. Ein unkomprimiertes Hero-Bild drückt den LCP über 2,5 Sekunden. Fix: WebP oder AVIF, feste Breite und Höhe. (LCP)
• Render-blockierendes CSS und JavaScript. Der Browser wartet, bevor er die Seite zeichnet. Fix: kritisches CSS inline, den Rest verzögert laden. (LCP)
• Langsame Serverantwort. Kein Caching, überladenes CMS, träges Hosting. Fix: Seiten-Cache aktivieren, die Antwortzeit spürbar drücken. (LCP)
• Third-Party-Skripte. Chat-Widget, Cookie-Banner und Tracking-Tags blockieren den Hauptthread. Fix: jedes Skript prüfen, Überflüssiges raus, den Rest verzögert laden. (INP)
• Nachgeladene Elemente ohne reservierten Platz. Banner, Webfonts und Bilder ohne Größenangabe schieben das Layout. Fix: feste Maße setzen, Platz vorab reservieren. (CLS)

Ordne jeden Fund einer Metrik zu. Dann weißt du, welche Zahl ein Fix bewegt.

Messen: Labor gegen Feld

Es gibt zwei Arten von Daten, und sie widersprechen sich oft. Lighthouse liefert Labordaten. Ein Testlauf unter festen Bedingungen, gut zum Debuggen, reproduzierbar. Felddaten wie der Chrome UX Report messen echte Besucher auf echten Geräten. Google bewertet nach Felddaten, nicht nach Labor.

Der Unterschied ist praktisch. Lighthouse zeigt 95 auf deinem Laptop, während Nutzer im 4G-Netz an INP scheitern. web.dev ist eindeutig: Liegen beide Datenquellen vor, priorisierst du nach Feld (web.dev, 2026). Zwei Werkzeuge zeigen beides. PageSpeed Insights stellt Labor- und Felddaten nebeneinander. Der Core-Web-Vitals-Bericht der Search Console gruppiert die Felddaten nach URL-Typ.

Nach Wirkung priorisieren

Wer die PageSpeed optimieren will, jagt gern jeden roten Wert. Das ist der falsche Reflex. Drei Fragen sortieren die Liste.

Welche Metrik reißt am 75. Perzentil die Schwelle? Nur die zählt. Wie viele Nutzer trifft es, mobil oder Desktop? Und wie teuer ist der Fix? Ein Bild komprimieren dauert Minuten. Ein Third-Party-Skript entfernen kostet eine Freigabe. Zieh den billigsten Fix mit der größten Feld-Wirkung nach vorn. Der Rest wartet.

Ein Beispiel. Mobil reißt CLS die Schwelle, verursacht durch ein Banner ohne feste Höhe. Ein Attribut im Template, fünf Minuten Arbeit, sichtbarer Effekt am 75. Perzentil. Das kommt zuerst. Der schlechte Desktop-LCP durch ein zweitrangiges Skript wartet, bis das erledigt ist.

Was ein Agent davon abnimmt

Der Ablauf ist immer gleich: messen, zuordnen, priorisieren, fixen. Genau das lässt sich an einen KI-Agenten übergeben. Über einen MCP-Connector greift der Agent auf deine echten Marketing-Konten zu. Modell-agnostisch, nach dem Prinzip Bring Your Own Agent.

Konkret: Der Agent zieht den Lighthouse-Wert per DataForSEO. Er gleicht ihn gegen die Felddaten aus Search Console und Microsoft Clarity ab. Dann legt er dir eine Quick-Win-Liste hin, sortiert nach Wirkung. Fixes am CMS, etwa Bildgrößen in WordPress oder Strapi, schreibt er erst nach deiner Freigabe. Jede Schreibaktion landet im Audit-Log, nachvollziehbar bis zur Zeile. So ersetzt der laufende Check das manuelle Tool-Hopping, ohne dass jemand ungefragt an der Live-Seite dreht.

Eine grüne Zahl im Labor beweist nichts. Erst das Feld entscheidet.

Willst du den Lighthouse-Check und die Quick-Win-Liste automatisch? Der seo-audit-Skill des Honeyfield Marketing MCP zieht die Daten selbst und schlägt die Fixes vor. Testen auf marketing-mcp.honeyfield.at.