Seit 2021 flie\u00dfen Core Web Vitals als offizieller Rankingfaktor in Googles Algorithmus ein. Das bedeutet: Zwei Artikel mit gleichem Inhalt, gleichen Backlinks und gleichem E-E-A-T k\u00f6nnen unterschiedlich ranken \u2013 weil einer schneller l\u00e4dt, stabiler dargestellt wird und besser auf Interaktion reagiert als der andere.<\/p>\n
<\/p>\n
Core Web Vitals sind keine abstrakten Technik-Kennzahlen. Sie messen, wie sich deine Website f\u00fcr echte Besucher anf\u00fchlt. Und Google wertet das als Qualit\u00e4tssignal \u2013 zu Recht.<\/p>\n
Dieser Artikel erkl\u00e4rt, was die drei Metriken bedeuten, wie du sie f\u00fcr deine WordPress-Website misst und was du konkret tun kannst, wenn die Werte im roten Bereich liegen.<\/p>\n
LCP misst, wie lange es dauert, bis das gr\u00f6\u00dfte sichtbare Element im Viewport geladen ist \u2013 in der Regel ein Hero-Bild, ein gro\u00dfes Textblock oder ein Video-Poster. Es ist der Moment, in dem ein Besucher das Gef\u00fchl bekommt: \u201eDie Seite ist da.“<\/p>\n
Ein schlechter LCP-Wert ist der h\u00e4ufigste Core-Web-Vitals-Fehler auf WordPress-Websites \u2013 meistens verursacht durch unkomprimierte Bilder, langsames Hosting oder fehlende Caching-Konfiguration.<\/p>\n
INP (seit M\u00e4rz 2024 offiziell, Nachfolger von FID) misst die Reaktionszeit der Website auf alle Nutzerinteraktionen w\u00e4hrend des gesamten Seitenbesuchs \u2013 Klicks, Tastatureingaben, Touch-Events. Es ist die Antwort auf die Frage: F\u00fchlt sich diese Website reaktionsschnell an?<\/p>\n
Auf typischen WordPress-Websites ist ein schlechter INP-Wert fast immer auf zu viel JavaScript zur\u00fcckzuf\u00fchren \u2013 oft durch Plugins, die Scripts laden, die auf der jeweiligen Seite gar nicht gebraucht werden.<\/p>\n
CLS misst, wie stark sich sichtbare Elemente w\u00e4hrend des Ladevorgangs unerwartet verschieben. Das klassische Beispiel: Du willst auf einen Button klicken, ein Bild l\u00e4dt nach, verschiebt den Button \u2013 und du klickst auf die Werbeanzeige darunter. Frustrierend f\u00fcr Nutzer, schlecht f\u00fcr Google.<\/p>\n
CLS-Probleme auf WordPress entstehen fast immer durch Bilder ohne definierte Breite und H\u00f6he, nachladende Schriftarten oder eingebettete Werbeanzeigen ohne feste Dimensionen.<\/p>\n
Es gibt zwei Arten von Daten: Lab-Daten (simulierte Messung) und Field-Daten (echte Nutzerdaten). F\u00fcr Google z\u00e4hlen prim\u00e4r die Field-Daten \u2013 also was echte Besucher auf deiner Website erleben. Lab-Daten sind trotzdem n\u00fctzlich zur Diagnose.<\/p>\n
Der einfachste Einstieg. In der Search Console findest du unter \u201eNutzererfahrung“ den Bericht \u201eCore Web Vitals“ \u2013 aufgeteilt nach Desktop und Mobil, mit einer Liste aller URLs, die im roten oder gelben Bereich liegen. Das sind echte Field-Daten aus dem Chrome User Experience Report.<\/p>\n
Wichtig: Die Search Console zeigt nur Seiten mit ausreichend Traffic. Neue oder wenig besuchte Seiten tauchen dort nicht auf.<\/p>\n
Unter pagespeed.web.dev<\/a> gibst du eine beliebige URL ein und bekommst sofort Lab-Daten (Lighthouse-Analyse) und \u2013 sofern vorhanden \u2013 Field-Daten aus dem CrUX-Bericht. Zus\u00e4tzlich gibt es konkrete Verbesserungsvorschl\u00e4ge, priorisiert nach Auswirkung auf den Score.<\/p>\n Immer auf Mobil testen. Google bewertet Mobile-First \u2013 und mobile Scores sind fast immer schlechter als Desktop-Scores.<\/p>\n Wer tiefer einsteigen will: Im Chrome-Browser unter \u201eEntwicklertools“ \u2192 \u201eLighthouse“ l\u00e4sst sich eine detaillierte Analyse direkt im Browser durchf\u00fchren. Unter \u201ePerformance“ siehst du, welche Ressourcen den Ladevorgang blockieren und wie lange einzelne Elemente zum Laden brauchen.<\/p>\n Die meisten Core-Web-Vitals-Probleme auf WordPress-Websites lassen sich auf f\u00fcnf Ursachen zur\u00fcckf\u00fchren \u2013 mit bekannten L\u00f6sungen.<\/p>\n Problem: Unkomprimierte Bilder.<\/strong> Das Hero-Bild einer typischen WordPress-Website ist ein JPEG oder PNG, das direkt aus dem Fotobearbeitungsprogramm hochgeladen wurde \u2013 3 MB, keine Komprimierung, kein modernes Format.<\/p>\n L\u00f6sung: Bilder in WebP konvertieren (deutlich kleinere Dateigr\u00f6\u00dfe bei gleicher Qualit\u00e4t) und mit einem Caching-Plugin wie WP Rocket, W3 Total Cache oder dem kostenlosen LiteSpeed Cache automatisch komprimieren lassen. Das WordPress-Plugin Imagify oder ShortPixel erledigt das f\u00fcr bestehende Bilder im Medien-Archiv.<\/p>\n Problem: Kein Caching.<\/strong> Ohne Caching baut WordPress bei jeder Anfrage die Seite aus der Datenbank zusammen. Das kostet Zeit \u2013 jedes Mal.<\/p>\n L\u00f6sung: Ein Caching-Plugin aktivieren. WP Rocket ist die umfangreichste L\u00f6sung, aber kostenpflichtig. W3 Total Cache und LiteSpeed Cache sind kostenlose Alternativen mit vergleichbarer Grundfunktionalit\u00e4t.<\/p>\n Problem: Langsames Hosting.<\/strong> Shared Hosting mit schwacher Server-Performance ist f\u00fcr viele WordPress-Websites der gr\u00f6\u00dfte Flaschenhals \u2013 und der, der sich am schwersten durch Plugin-Optimierung ausgleichen l\u00e4sst.<\/p>\n L\u00f6sung: Zu einem Managed WordPress Hosting wechseln (Kinsta, WP Engine, Raidboxes f\u00fcr Deutschland) oder zumindest zu einem Anbieter mit modernen Servern und PHP 8.x.<\/p>\n Problem: Zu viele JavaScript-Dateien.<\/strong> Jedes Plugin, das JavaScript l\u00e4dt, erh\u00f6ht die Verarbeitungslast im Browser. Viele Plugins laden ihre Scripts auf allen Seiten \u2013 auch dort, wo sie nicht gebraucht werden.<\/p>\n L\u00f6sung: Mit WP Rocket oder Asset CleanUp Pro Scripts und Styles seitenspezifisch deaktivieren. Ein Kontaktformular-Script hat auf der Startseite nichts verloren. Ein Slider-Script auf einer Seite ohne Slider auch nicht.<\/p>\n Problem: Render-blockierende Ressourcen.<\/strong> JavaScript-Dateien, die im L\u00f6sung: In WP Rocket unter \u201eDateioptimierung“ JavaScript verz\u00f6gert laden aktivieren. Achtung: Das kann in Einzelf\u00e4llen Darstellungsfehler verursachen \u2013 nach Aktivierung alle wichtigen Seiten pr\u00fcfen.<\/p>\n Problem: Bilder ohne definierte Dimensionen.<\/strong> Wenn WordPress-Bilder ohne L\u00f6sung: In modernen WordPress-Versionen (ab 5.5) werden Dimensionen automatisch eingetragen \u2013 wenn du die Standardfunktionen nutzt. Problematisch sind Bilder, die \u00fcber Page Builder oder alten Code ohne diese Attribute eingebunden wurden. Pr\u00fcfen l\u00e4sst sich das in PageSpeed Insights unter \u201eAvoid large layout shifts“.<\/p>\n Problem: Google Fonts laden asynchron.<\/strong> Schriften, die von Google Fonts nachgeladen werden, k\u00f6nnen beim Einblenden einen Layout-Shift verursachen \u2013 weil der Browser zun\u00e4chst eine Fallback-Schrift anzeigt und dann auf die geladene Schrift umschaltet.<\/p>\n L\u00f6sung: Google Fonts lokal hosten (Plugin: OMGF \u2013 Host Google Fonts Locally) und Chrome DevTools \u2013 f\u00fcr die technische Diagnose<\/h3>\n
Was du tust, wenn die Werte schlecht sind<\/h2>\n
LCP verbessern<\/h3>\n
INP verbessern<\/h3>\n
<head><\/code> ohne defer<\/code> oder async<\/code> eingebunden sind, blockieren das Rendern der Seite, bis sie vollst\u00e4ndig geladen sind.<\/p>\nCLS verbessern<\/h3>\n
width<\/code>– und height<\/code>-Attribut eingebunden werden, wei\u00df der Browser beim Laden nicht, wie viel Platz er reservieren soll. Das Bild l\u00e4dt nach \u2013 und verschiebt alles darunter.<\/p>\nfont-display: swap<\/code> in der CSS-Einbindung setzen, damit der Browser die Fallback-Schrift auch nach dem Laden beibeh\u00e4lt.<\/p>\nDie wichtigsten WordPress-Plugins f\u00fcr Core Web Vitals<\/h2>\n