Core Web Vitals sind seit 2021 offizieller Google-Ranking-Faktor. Seit März 2024 hat INP FID als dritte Metrik abgelöst – wer noch auf FID optimiert, hat Nachholbedarf. Ich gehe bei jedem Kundenprojekt die drei Metriken systematisch durch, weil die Ursachen fast immer dieselben sind.
LCP – Das größte Element muss schnell laden
LCP (Largest Contentful Paint) misst, wie lange das größte sichtbare Element im Viewport braucht. Ziel: unter 2,5 Sekunden. In den meisten WordPress-Projekten ist das ein Hero-Bild oder ein großes Hintergrundbild im Header.
Das häufigste Problem dabei: WordPress setzt seit Version 5.5 automatisch loading="lazy" auf alle Bilder. Für alles unterhalb des Folds ist das richtig – aber das erste sichtbare Bild sollte nie lazy geladen werden.
Fetchpriority und Lazy Loading steuern
Das LCP-Bild braucht fetchpriority="high" und explizit kein loading="lazy". Wer das Bild über wp_get_attachment_image() einbindet, kann das direkt als Argument übergeben:
echo wp_get_attachment_image(
$attachment_id,
'full',
false,
[
'fetchpriority' => 'high',
'loading' => 'eager',
'class' => 'hero-image',
]
);
Preload im <head> ankündigen
Noch wirkungsvoller ist ein Preload-Link im <head> – der Browser bekommt frühzeitig Bescheid, bevor das CSS oder der HTML-Parser das Bild überhaupt entdeckt hat:
add_action( 'wp_head', function() {
if ( is_front_page() ) {
$hero_url = get_template_directory_uri() . '/img/hero.webp';
echo '<link rel="preload" as="image" href="' . esc_url( $hero_url ) . '" type="image/webp">' . "\n";
}
}, 1 );
Die Priorität 1 sorgt dafür, dass der Preload ganz oben im <head> landet – vor Stylesheets und Scripts. Bei einem Kunden hat das den LCP auf der Startseite von 3,8 auf 1,9 Sekunden gedrückt.
CLS – Kein Layout-Sprung beim Laden
CLS (Cumulative Layout Shift) misst, wie stark sich das Layout während des Ladens verschiebt. Ziel: unter 0,1. Typische Übeltäter in WordPress: Bilder ohne feste Dimensionen, spät ladende Webfonts und iframes, die nachträglich Platz einnehmen.
Bildabmessungen immer angeben
WordPress setzt width und height automatisch – aber nur bei Bildern aus der Mediathek, die über die WordPress-Funktionen eingebunden werden. Bilder aus Page Buildern oder manuell im HTML eingefügte Bilder haben das oft nicht. Der Browser berechnet das Seitenverhältnis aus den Attributen und reserviert den Platz, bevor das Bild geladen ist. Fehlen die Attribute, springt das Layout.
Prüfen lässt sich das am schnellsten im Chrome DevTools Performance-Tab – CLS-Ursachen werden in der Timeline markiert, und der Layout Instability API-Eintrag zeigt genau welches Element verschoben wurde.
Font-Display richtig setzen
Webfonts verursachen CLS, wenn sie spät laden und den Text verschieben. font-display: swap zeigt zuerst den Fallback-Font und tauscht ihn aus – das verursacht einen kurzen visuellen Wechsel, aber keinen messbaren Layout-Shift:
@font-face {
font-family: 'MeinFont';
src: url('/fonts/mein-font.woff2') format('woff2');
font-weight: 400;
font-style: normal;
font-display: swap;
}
Wer Google Fonts per URL einbindet, hängt &display=swap an die Fonts-URL an. Noch besser: Fonts self-hosten und den externen Request komplett vermeiden.
Platz für iframes reservieren
YouTube-Embeds, Karten und ähnliche iframes laden verzögert und verschieben alles darunter. Der klassische Padding-Trick reserviert den Platz im richtigen Seitenverhältnis:
.embed-container {
position: relative;
padding-bottom: 56.25%; /* 16:9 */
height: 0;
overflow: hidden;
}
.embed-container iframe {
position: absolute;
top: 0;
left: 0;
width: 100%;
height: 100%;
}
INP – Reaktionszeit auf Interaktionen
INP (Interaction to Next Paint) misst die Zeit zwischen einer Nutzerinteraktion – Klick, Tastendruck, Touch – und dem nächsten visuellen Update. Ziel: unter 200 ms. Der entscheidende Unterschied zu FID: INP misst alle Interaktionen während der gesamten Sitzung, nicht nur den ersten Klick.
Der häufigste Grund für schlechte INP-Werte ist zu viel JavaScript, das den Main Thread blockiert.
Scripts defer oder async laden
Mit dem script_loader_tag-Filter lässt sich gezielt steuern, welche Scripts defer oder async bekommen:
add_filter( 'script_loader_tag', function( $tag, $handle, $src ) {
$defer_handles = [ 'mein-slider', 'cookie-banner' ];
if ( in_array( $handle, $defer_handles, true ) ) {
return '<script src="' . esc_url( $src ) . '" defer></script>' . "\n";
}
return $tag;
}, 10, 3 );
defer lädt parallel zum HTML-Parsing, führt aber in der richtigen Reihenfolge aus. async ist nur für Scripts ohne Abhängigkeiten geeignet – es führt sofort nach dem Download aus, egal wo der Parser gerade steht.
Ungenutztes JavaScript seitenweise entfernen
Viele Plugins laden ihre Scripts auf jeder Seite, auch wenn sie nur auf einer einzigen gebraucht werden. Das lässt sich gezielt abschalten:
add_action( 'wp_enqueue_scripts', function() {
if ( ! is_page( 'kontakt' ) ) {
wp_dequeue_script( 'kontaktformular-js' );
wp_deregister_script( 'kontaktformular-js' );
}
} );
Welche Scripts auf einer Seite geladen werden, sehe ich am schnellsten im Network-Tab der DevTools – nach JS filtern, Initiator anschauen, dann entscheiden was wirklich gebraucht wird.
Messen: Lab-Daten und Felddaten
Ich nutze immer zwei Quellen parallel. PageSpeed Insights liefert Lab-Daten – reproduzierbar, gut für die Entwicklung. Die Google Search Console liefert Felddaten – wie echte Nutzer die Seite tatsächlich erleben.
Mein Workflow: Search Console → Core Web Vitals-Bericht → URLs mit „Verbesserungsbedarf“ identifizieren → PageSpeed Insights für die konkrete Ursache. Felddaten brauchen Verkehr, um belastbar zu sein – bei kleinen Seiten fehlen die Daten manchmal komplett. Dann zählen nur die Lab-Daten.
Ein häufiger Fallstrick: PageSpeed Insights testet Desktop und Mobile getrennt. Mobile-Werte sind fast immer schlechter – und Google gewichtet Mobile stärker.
Fazit
Die größten Gewinne kommen von drei Stellen: das LCP-Bild mit fetchpriority="high" und einem Preload-Link richtig ausliefern, Bildabmessungen konsequent setzen und ungenutztes JavaScript seitenweise entfernen. Wer das sauber umsetzt, landet bei den meisten WordPress-Projekten schon im grünen Bereich – ohne komplexe Infrastruktur oder teure Tools.
