Core Web Vitals verbessern: die Reihenfolge, die wirklich hilft

Ein Caching-Plugin einzuschalten ist der erste Schritt und oft der einzige, der gemacht wird. Danach steht der Wert bei „verbesserungswürdig“ und bleibt dort. Der Grund: Die drei Kennzahlen messen drei verschiedene Dinge, und Caching hilft nur bei einer davon richtig.

Die drei Werte, in einem Satz je

Daraus folgt die Reihenfolge: Bilder zuerst, dann Skripte, dann Layout. Caching wirkt vor allem auf die Serverzeit — also auf einen Teil von LCP, und auf INP fast gar nicht.

Schritt 1: das größte Bild

Auf den meisten Seiten ist das Hero-Bild der LCP-Kandidat. Drei Dinge helfen sofort, in dieser Reihenfolge:

1. Auf die tatsächlich benötigte Größe verkleinern — ein 4000 Pixel breites Foto in einem 1200 Pixel breiten Bereich ist die häufigste Einzelursache.
2. In ein modernes Format umwandeln (WebP oder AVIF), mit einem Rückfall für alte Browser.
3. NICHT lazy-laden. Das Bild ganz oben soll sofort geladen werden — Lazy-Load verschlechtert hier den Wert, statt ihn zu verbessern.

Prüfe, wo die Umwandlung stattfindet. Manche Plugins schicken deine Bilder dafür an einen Dienst des Herstellers. Wer das nicht will, braucht ein Werkzeug, das lokal umwandelt — dann dauert der erste Durchgang länger, aber es verlässt nichts das Haus.

Schritt 2: das JavaScript

INP ist der Wert, bei dem Caching nicht hilft. Er misst, wie lange der Browser braucht, bis er auf einen Klick reagiert — und blockiert wird er von Skripten, die in genau diesem Moment arbeiten.

Der wirksamste Hebel ist Weglassen: ein Slider, den niemand bedient; ein Chat-Fenster auf jeder Seite; drei Schriftfamilien, von denen zwei nicht auffallen. Erst danach lohnen sich defer, das Zusammenfassen und das Verzögern bis zur ersten Interaktion.

Schritt 3: das Springen abstellen

• Jedes Bild braucht width und height im Markup — dann hält der Browser den Platz frei
• Eingebettete Inhalte in einen Rahmen mit fester Höhe setzen
• Schriften lokal ausliefern und mit font-display steuern, statt sie von außen nachzuladen
• Cookie-Banner und Hinweisleisten so einbauen, dass sie den Inhalt überlagern, statt ihn zu schieben

Erst dann: Caching, Minify, Preload

Ein Seiten-Cache spart die Erzeugung der Seite — das ist viel, wenn der Server langsam ist, und wenig, wenn er schnell ist. Minify spart Bytes und ist die häufigste Ursache für kaputte Seiten nach einer Optimierung. Preload ist eine Anweisung, keine Bitte: Zu viele davon verdrängen genau das, was zuerst gebraucht wird.

Schalte Minify einzeln ein und prüfe jeweils eine Formularseite, den Warenkorb und eine Seite mit Video. Wer alles auf einmal einschaltet, sucht im Fehlerfall unter zehn Schaltern.

Richtig messen

Zwei Messungen gehören auseinandergehalten. Ein Labortest misst unter festen Bedingungen und ist gut zum Vergleichen von vorher und nachher. Felddaten stammen von echten Besuchern mit echten Geräten und Verbindungen — sie entscheiden, wie Google die Seite einstuft.

Deshalb: immer mit denselben Bedingungen messen, dreimal statt einmal, und Felddaten brauchen Wochen, bis sich eine Änderung zeigt. Wer nach einer Stunde nachsieht und nichts merkt, hat nicht zu wenig optimiert, sondern zu früh geschaut.

Wann das Plugin nicht mehr hilft

Es gibt eine Grenze, an der kein Caching-Plugin mehr weiterkommt: ein überladener Seitenbauer mit dreißig Skripten, ein Hoster mit hoher Grundlast, ein Theme, das auf jeder Seite alles lädt. Wenn die Serverantwort schon ohne Inhalt langsam ist, liegt es nicht am Plugin.

Häufige Fragen