20 Tipps, um den Largest Contentful Paint (LCP) bei WordPress zu verbessern

LCP (Largest Contentful Paint)

Der Largest Contenful Paint (LCP) gibt an, wie lange das größte sichtbare Element im Darstellungsbereich (above the fold, also ohne zu scrollen) einer Seite zum Laden braucht.

Er ist laut Google anderen Messwerten, wie z. B. der absoluten Ladezeit oder dem First Contentful Paint überlegen, weil er besser abbildet, wie Nutzer die Ladegeschwindigkeit einer Webseite wahrnehmen.

In diesem Artikel zeige ich dir, wie du den LCP deiner Seiten messen kannst und zeige dir 19 Tipps, wie du ihn optimierst.

Wie kann ich den LCP messen?

Um den LCP einer Seite zu messen, nimmst du am besten PageSpeed Insights. Das Tool zeigt dir sowohl Feld- als auch Labdaten zum LCP an:

FCP mit PageSpeed Insights messen

Der Wert sollte 2,5 Sekunden nicht überschreiten. Ab 4 Sekunden wird eine Webseite als schlecht eingestuft.

Wenn du zum Diagnose-Bereich herunterscrollst, kannst du dir auch das Element anzeigen lassen, das (bei den Labdaten) zur Berechnung des LCP herangezogen wird:

Largest Contentful Paint-Element in PageSpeed Insights
Wichtiger Hinweis: Es ist essenziell herauszufinden, welches das LCP-Element ist. Denn so weißt du, auf welche Elemente du dich bei der Optimierung konzentrieren solltest. Die Optimierungsschritte, die ich dir in diesem Artikel vorstelle, zielen alle entweder darauf ab, das LCP-Element zu verkleinern, es im Ladeverlauf zu priorisieren oder andere Elemente zu “entpriorisieren”.

Beim LCP-Element handelt es sich meist um ein Bild, Video, ein durch CSS eingefügtes Hintergrundbild oder ein Textelement. Bei meinem getesteten Blogartikel (siehe Screenshot) ist es z. B. die Haupt-Überschrift.

Bitte beachte, dass das LCP-Element je nach Bildschirmgröße von Nutzern ein anderes sein kann. Für mobile Nutzer kann es z. B. ein Bild sein, für Desktop-Nutzer eine Überschrift.

Ein Wasserfall-Diagramm ist ebenfalls für die Optimierung des LCP sehr nützlich. Denn dadurch kannst du sehen, wann das LCP-Element im Vergleich zu anderen Elementen geladen wird.

Ein solches Diagramm kannst du dir mit GTMetrix, WebPageTest oder mit Lighthouse in den Chrome DevTools anzeigen lassen (Element untersuchen > Lighthouse > Generate Report > View Original Trace):

LCP Element wird erst sehr spät geladen

So konnte ich bei unserem Familienblog Faminino z. B. sehen, dass die Titelbilder aller Blogposts recht spät geladen werden, obwohl sie potenzielle LCP-Elemente sind. Das konnte ich durch Ausschließen der Titelbilder vom Lazy Loading beheben.

1. Page-Caching verwenden

WordPress generiert an sich dynamische Websites, das heißt jedes Element auf einer Seite (z. B. Menüs, Widgets oder Beiträge) erzeugt eine Datenbankabfrage.

Und durch jede Datenbankabfrage verschlechtert sich die Ladezeit.

Ein Caching-Plugin schafft Abhilfe, indem es aus den dynamischen Inhalten statische Dateien generiert (so genanntes Page-Caching).

Dadurch verbessert sich die Erstreaktionszeit (TTFB) des Servers meist enorm. Hier siehst du zum Vergleich meine Startseite ohne Page-Caching:

TTFB ohne Page Caching

Und hier mit Page-Caching (mit WP Rocket):

TTFB mit Page Caching

Warum das wichtig ist?

Wenn du die TTFB verbesserst, verbessert du die Ladezeit aller Anfragen und somit auch die für den LCP.

Dazu kommt:

Page-Caching kann sich auch enorm auf die absolute Ladezeit auswirken. Hier eine meiner ehemaligen Kunden-Websites ohne Page-Caching:

Website ohne Cache Enabler

Und hier mit dem Caching-Plugin Cache Enabler:

Website mit Cache Enabler

Krasser Unterschied, oder?

2. Cache Preloading verwenden

Normalerweise ist es so, dass das Page-Caching für eine Seite erst dann aktiviert wird, nachdem sie einmal aufgerufen wurde.

Das ist aber aus dreierlei Hinsicht unvorteilhaft:

  1. Einigen Nutzern werden deine Seiten ungecached angezeigt, also mitunter sehr langsam.
  2. Deine Felddaten werden dadurch mitunter ein (winzigkleines) bisschen heruntergezogen.
  3. Vor dem Testen deiner Seiten mit PageSpeed Insights, Lighthouse etc. musst du diese erst einmal im Browser aufrufen, um korrekte Messungen zu bekommen.

Durch sogenanntes Cache Preloading (auch Cache Warming genannt) wird das verhindert. Dabei werden die Seiten einmal vom Plugin selbst aufgerufen, damit sie im Cache landen.

Bei WP Rocket kannst du Cache-Preloading unter Einstellungen > WP Rocket > Cache füllen aktivieren:

Cache Preloading bei WP Rocket
Tipp: Falls dein Caching-Plugin keine Preloading-Funktion hat oder du einen serverseitigen Cache verwendest, kannst du das Plugin Warm Cache installieren, das alle deiner Seiten auf deiner Website auf Basis einer XML-Sitemap vorladen kann.

3. Lazy-Loading bei Bildern above the fold ausstellen

Bilder, die “above the fold” angezeigt werden, das heißt in dem Bereich einer Seite, der für Nutzer beim Aufruf der Seite (ohne Herunterscrollen) sichtbar ist, sollten vom Lazy Loading ausgeschlossen werden.

Dazu zählen zum Beispiel:

  • das Logo
  • das Beitragsbild
  • Hintergrundbilder (z. B. im Page Hero)

Ansonsten muss der Browser erst auf die Ausführung des Lazy-Load-Scripts warten, bevor die Bilder angezeigt werden, wodurch sie langsamer laden.

Bei meinem Artikel zu Google-Ranking-Faktoren, bei dem das LCP-Element das Titelbild ist, kannst du den Effekt sehr deutlich sehen. Mit angeschaltetem Lazy Loading lädt das liegt der LCP bei 3,2 und das Titelbild ist erst im achten Frame des Filmstrips zu sehen:

LCP mit Lazy Loading

Ohne Lazy Loading lädt das Titelbild deutlich schneller und ist schon im zweiten Frame zu sehen. Der LCP liegt nur noch bei 2,8:

LCP ohne Lazy Loading

4. Textkomprimierung aktivieren

Textkomprimierung zu aktivieren ist eine der wichtigsten generellen Optimierungsmaßnahmen, um die Ladezeit deiner Website zu steigern und den LCP (und zusätzlich die FID) zu verbessern.

Denn durch Textkomprimierung sorgst du dafür, dass sich die Übertragungsgröße von JavaScript-, HTML- und CSS-Dateien um bis zu 70 % verringert.

Nicht umsonst gibt es unter Diagnose bei PageSpeed Insights einen eigenen Punkt dafür:

Textkomprimierung aktivieren

Textkomprierung kannst du auf deinem Server über die Module mod_deflate oder mod_gzip in der .htaccess aktivieren.

Wenn du WP Rocket nutzt, musst du dir darüber keine Gedanken machen, denn das Plugin aktiviert Textkomprimierung standardmäßig (du musst auch nichts extra dafür einstellen).

Es ist jedoch auch relativ simpel, Textkomprimierung selbst zu aktivieren.

Das geht in drei Schritten:

  1. Du loggst dich auf deinem FTP-Server ein (die Zugangsdaten solltest du bei Eröffnung deines Hosting-Pakets zugeschickt bekommen haben).
  2. Du öffnest die .htaccess-Datei deiner Website mit einem Nur-Text-Editor öffnen
  3. Du fügst folgenden Code an den Anfang der Datei ein:
<meta charset="utf-8"><IfModule mod_filter.c> AddOutputFilterByType DEFLATE application/atom+xml \ application/javascript \ application/json \ application/rss+xml \ application/vnd.ms-fontobject \ application/x-font-ttf \ application/xhtml+xml \ application/xml \ font/opentype \ image/svg+xml \ image/x-icon \ text/css \ text/html \ text/plain \ text/x-component \ text/xml </IfModule>
Code-Sprache: HTML, XML (xml)

Bei Webservern, die auf einer älteren Apache-Version basieren, kann es sein, dass es das Modul mod_deflate noch nicht gibt und du stattdessen das Modul mod_gzip ansprechen musst.

Dazu fügst du anstelle des oberen Codes einfach den folgenden ein:

<meta charset="utf-8">mod_gzip_on Yes mod_gzip_dechunk Yes mod_gzip_item_include file .(html?|txt|css|js|php|pl)$ mod_gzip_item_include handler ^cgi-script$ mod_gzip_item_include mime ^text/.* mod_gzip_item_include mime ^application/x-javascript.* mod_gzip_item_exclude mime ^image/.* mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
Code-Sprache: HTML, XML (xml)
Tipp: Eine noch bessere Textkomprimierung als gzip oder Deflate bietet das von Google entwickelte Brotli, das es als Modul für NGINX-Server gibt und mittlerweile von den meisten modernen Browsern unterstützt wird. Es gibt auch mittlerweile immer mehr Hoster, die Brotli auf ihren Servern standardmäßig einsetzen, wie z. B. RAIDBOXES oder TimmeHosting.

5. Drittanbieter-Code reduzieren

Drittanbieter-Code (engl. third-party code) kann in vielerlei Hinsicht problematisch sein:

Network Requests an viele verschiedene Server, zu viel JavaScript, unnötig geladene JavaScript-Bibliotheken, unoptimierte Bilder und Videos oder fehlende Textkomprimierung können dafür sorgen, dass das LCP-Element langsamer geladen wird als nötig.

Drittanbieter-Code kommt z. B. zum Einsatz bei:

  • sozialen Netzwerken (Sharing-Buttons, Facebook Seiten-Plugin etc.)
  • Embeds (YouTube- oder Vimeo-Videos, Spotify, Instagram-Posts etc.)
  • extern geladenen Fonts (Google Fonts, Adobe Fonts etc.)
  • Werbeanzeigen (Google AdSense, Ezoic etc.)
  • Analyse- oder Split-Testing-Tools (Google Tag Manager, Hotjar etc.)

PageSpeed Insights zeigt Verbesserungsmöglichkeiten dazu unter Diagnose > Die Auswirkungen von Drittanbieter-Code minimieren an.

In folgendem Beispiel wird der FID durch automatische Anzeigen von Google AdSense und Google Fonts, die nicht vorgeladen werden, enorm in die Länge gezogen:

Die Auswirkungen von Drittanbieter-Code minimieren PageSpeed Insights

Bitte überlege dir bei jedem Drittanbieter-Code, ob du ihn wirklich brauchst oder ob du diesen auch lokal laden kannst. Google Fonts z. B. lassen sich recht einfach lokal einbinden. Und ja, dafür gibt es notfalls auch ein Plugin.

Falls du nicht auf den Code verzichten kannst, solltest du Drittanbieter-Code, wenn möglich, aus dem Content above the fold entfernen und nachladen. Das gilt vor allem für JavaScript:

6. JavaScript verzögert laden

Du solltest alles JavaScript, was nicht kritisch ist, also nicht für das Laden des Contents above the fold genutzt wird, verzögert laden. Das verbessert nicht nur deinen LCP, sondern auch deinen FID.

Umsetzen kannst du das, indem du in den <script>-Tags, durch die JavaScript-Dateien in HTML eingebettet werden, das Attribut defer ergänzt:

<script src="https://www.blogmojo.de/js/isotope.pkgd.min.js" <strong>defer</strong>></script>
Code-Sprache: JavaScript (javascript)

Damit sagst du dem Browser, dass er erst einmal das ganze HTML-Dokument parsen soll (das heißt analysieren und ein DOM-Modell davon erstellen) und dann erst das JavaScript ausführen soll.

Machst du das nicht, wird das JavaScript sofort ausgeführt und blockiert den Seitenaufbau. Dadurch verschlechtert sich dein FCP (First Contentful Paint), also die Zeit, die es braucht, damit überhaupt irgendetwas angezeigt wird, und damit auch dein LCP.

Hinweis: Alternativ kannst auf auch das Attribut async verwenden, dadurch wird JavaScript im Hintergrund geladen und das Anzeigen des Content ebenfalls nicht blockiert. async eignet sich vor allem gut für alleinstehende Scripte, die über Drittserver geladen werden. Mehr zu den Unterschieden zwischen asyncund defer erfährst du in diesem Artikel.

Und ja, das musst du nicht unbedingt per Hand machen. Dafür gibt es auch eine Option in WP Rocket.

Unter Einstellungen > WP Rocket > Datei-Optimierung > JavaScript-Dateien setzt du einfach einen Haken bei JavaScript verzögert laden:

JavaScript verzögert laden mit WP Rocket

perfmatters kann das ebenfalls (wenn du perfmatters und WP Rocket zusammen verwendest, solltest du diese Option jedoch nicht bei beiden aktiviert haben):

JavaScript verzögert laden mit perfmatters

Wenn du mehr Kontrolle darüber haben willst, welche Scripte mit welchem Attribut geladen werden, kannst du dafür Asset CleanUp Pro verwenden:

JavaScript verzögert laden mit Asset CleanUp Pro

Welche JavaScript-Dateien genau nachgeladen werden sollten, kannst du bei PageSpeed Insights sehen. Dort gibt es einen Punkt, der Ressourcen beseitigen, die das Rendering blockieren heißt:

JavaScript Ressourcen beseitigen, die das Rendering blockieren

Zu den JavaScript-Dateien, die problemlos nachgeladen werden können, gehören z. B. Pop-ups, Newsletter-Formulare im Footer oder Social-Sharing-Buttons am Ende von Blogartikeln.

7. Verbindungen zu Drittservern vorab aufbauen

Wenn du Ressourcen von Dritt-Servern lädst, solltest du die Verbindungen zu diesen Dritt-Servern vorab aufbauen. Das verbessert den TTFB und damit auch den LCP.

Das ist insbesondere dann wichtig, wenn diese Ressourcen benötigt werden, um den Content above the fold darzustellen.

Umsetzen kannst du das durch <link rel="preconnect"> und <link rel="dns-prefetch">. Letzteres empfiehlt sich als zusätzliche Fallback-Methode für ältere Browser.

Für Google Fonts würdest du z. B. folgenden Code in den <head>-Bereich deiner Seiten einbinden.

<link rel="preconnect" href="https://fonts.gstatic.com"> <link rel="dns-prefetch" href="https://fonts.gstatic.com">
Code-Sprache: HTML, XML (xml)

Umsetzen kannst du das z. B. mit dem Plugin CSS & JavaScript Toolbox oder durch Einfügen von folgendem Code in die functions.php deines Child-Themes:

/* Preconnect für Google Fonts */ add_action('wp_head', 'google_fonts_preconnect'); function <meta charset="utf-8">google_fonts_preconnect(){ ?> <meta charset="utf-8"><link rel="preconnect" href="https://fonts.gstatic.com"> <link rel="dns-prefetch" href="https://fonts.gstatic.com"> <?php };
Code-Sprache: PHP (php)

Bei WP Rocket kannst du vorzuladene Domains unter Einstellungen > WP Rocket > Cache füllen > DNS-Prefetching hinzufügen:

DNS Prefetching mit WP Rocket

8. Kritisches CSS vorab laden

CSS-Dateien enthalten meist viele CSS-Stile, die erst im späteren Ladeverlauf benötigt werden. Und das kann die Anzeige von Inhalten above the fold verzögern und damit den LCP erhöhen.

Deshalb solltest du kritisches CSS, also die CSS-Anweisungen, die zur Anzeige von Inhalten above the fold wichtig sind, vorab laden.

Zum Beispiel durch <link rel="preload"> einer CSS-Datei, die das kritische CSS enthält oder, besser noch, inline im <head>-Bereich deiner Webseiten.

Hinweis: Durch Einbindung von kritischem CSS verhinderst du auch hässlichen Flash of Unstyled Content (FOUC) und einen hohen CLS-Wert, den man oft bei “ladezeitoptimierten” Webseiten sieht.

Was kritisches CSS bringt, kannst du in folgenden beiden Filmstrips sehen. Der erste ist mit kritischem CSS und der zweite ohne:

Seite mit kritischem CSS vs Seite ohne kritisches CSS

Welches CSS auf deinen Webseiten kritisch ist, kannst du mit dem Critical Path CSS Generator von Pegasaas herausfinden:

Critical Path CSS Generator

Anschließend kannst du den Code manuell in die entsprechenden Webseiten einbinden, z. B. mit CSS & JavaScript Toolbox.

Einfacher geht es mit WP Rocket. Unter Einstellungen > WP Rocket > Datei-Optimierung > CSS-Dateien setzt du einfach einen Haken bei CSS-Darstellung optimieren.

Kritisches CSS mit WP Rocket generieren

Dadurch generiert WP Rocket automatisch kritisches CSS für deine Website.

Zusätzlich bietet WP Rocket die Möglichkeit seitenspezifisches kritisches CSS zu generieren. Das ist sinnvoll für alle Seiten, die “von der Norm” abweichen, also auf denen z. B. du im Gegensatz zum Rest deiner Website einen Page-Builder (oder keinen) verwendest.

Die Option findest du in den WP-Rocket-Optionen für einzelne Seiten bzw. Beiträge. Im Gutenberg-Editor ist diese rechts in der Sidebar in den Seiteneinstellungen. Dort klickst du auf den Button Spezifisches CPCSS erzeugen:

Spezifisches CPCSS mit WP Rocket generieren

9. HTTP/2 verwenden

HTTP/2 ist der Nachfolger von HTTP/1.1 und bietet deutliche Geschwindigkeitsvorteile gegenüber der älteren Version des Hypertext Transfer Protocols, die über 16 Jahre der Übertragungsstandard im WWW war.

Der große Vorteil:

Mit HTTP/1.1 werden alle Requests noch nacheinander abgearbeitet, mit HTTP/2 können jetzt mehrere Requests parallel verarbeitet werden (wodurch es z. B. nicht mehr nötig ist Bild-Dateien in CSS-Sprites einzubinden oder JS- und CSS-Dateien zusammenzufassen).

Du kannst dir das Ganze in etwa so vorstellen:

HTTP vs HTTP2

Zudem werden Header komprimiert übertragen und dank Server Push kann der Server die Dateien priorisieren, die für Browser-Nutzer am wichtigsten sind.

Mit diesem Tool von KeyCDN kannst du testen, ob dein Server HTTP/2 unterstützt:

HTTP2 Test von KeyCDN

Wenn das nicht der Fall ist, bitte deinen Host darum, dies zu implementieren, oder nimm es als Anlass gleich den Hoster zu wechseln.

Welche Hoster HTTP/2 unterstützen, habe ich dir in meinem Webhosting-Vergleich zusammengestellt.

Hinweis: Bitte beachte, dass HTTP/2 von den meisten Browsern nur in Kombination mit HTTPS unterstützt wird, was die Umstellung auf HTTPS nicht nur zu einer Sicherheits- sondern auch Ladezeitmaßnahme macht.

10. Bilder komprimieren

JPG-, PNG- oder auch SVG-Bilder haben oft eine zu große Dateigröße.

Egal, ob sie aus Photoshop kommen, direkt aus deiner Kamera, von einem Stockphoto-Dienst oder von Canva.

Durch Bildkomprimierung lässt sich die Übertragungsgröße in der Regel noch einmal um 30 bis 40 %, in manchen Fällen sogar um 80 % bis 90 % verringern, was sich wiederum positiv auf den LCP auswirkt (sofern es sich beim LCP um ein Bild handelt, versteht sich).

Für die Komprimierung von JPG- oder PNG-Bildern empfehle ich dir folgende WordPress-Plugins:

  • EWWW Image Optimizer (dort werden die Bilder lokal auf deinem Server komprimiert, was jedoch nicht jeder Hosting-Anbieter unterstützt)
  • Shortpixel Image Optimizer (als cloudbasierte Alternative, bei der Bilder auf einem Dritt-Server komprimiert werden)
  • Imagify (ebenfalls cloudbasiert, von den Machern von WP Rocket)

Zusätzlich kannst du deine Bilder vor dem Upload in die WordPress-Mediathek noch auf dem Rechner mit dem Tool ImageOptim (Mac, kostenlos) optimieren. Damit lassen sich noch einmal ein paar KB mehr herausholen:

Bilder komprimieren mit ImageOptim

11. Bildqualität verringern

Um die Übertragungsgröße von Bildern noch weiter zu verringern, kann es auch helfen, die Bildqualität zu reduzieren.

Wie die Komprimierung lässt sich diese an verschiedenen Stellen justieren.

Zum Beispiel in Photoshop beim Speichern:

JPEG-Optionen in Photoshop

Die Qualitätsstufe 8 oder 9 statt 12 zu nehmen, verringert die Größe oft um über 50 %. Bei den meisten Bildern ist der Qualitätsverlust mit bloßem Auge nicht zu erkennen.

Auch in diversen anderen Tools, wie z. B. ImageOptim oder Bildkomprimierungs-Plugins kannst du die Bildqualität herabsetzen (die sogenannte verlustbehaftete Kompression). Ist die Angabe in Prozent, empfehle ich zwischen 80 und 90.

Achtung: Bevor du deine Bilder verlustbehaftest komprimierst, teste inwiefern das die Qualität der Bilder beeinträchtigt. Denke zudem unbedingt daran, vor einer Massenoptimierung ein Backup aller Bild-Dateien zu machen.

12. Moderne Bildformate verwenden

Eine weitere Stellschraube zur Verringerung der Dateigröße von Bildern (und damit dem LCP) ist die Verwendung von modernen Dateiformaten.

Vielleicht hast du bei PageSpeed Insights diesen Punkt schon einmal gesehen:

Bilder in modernen Formaten bereitstellen

Ich empfehle dabei die Verwendung von WebP-Dateien, da diese laut einer Google-Studie höhere Kompressionsraten als z. B. JPEG-2000 erreichen und von den meisten modernen Browsern unterstützt werden.

Durch die steigende Beliebtheit von WebP bieten mittlerweile viele bekannte Bildoptimierungs-Plugins (EWWW Image Optimizer, ShortPixel, Imagify etc.) eine automatische Umwandlung von PNG- und JPG-Bildern in WebP an.

Beim EWWW Image Optimizer z. B. musst du in den Einstellungen im Tab WebP einfach nur ein Häkchen bei JPG/PNG nach WebP setzen und danach auf Änderungen speichern klicken.

WebP beim EWWW Image Optimizer

Danach erscheint unten ein Formularfeld mit den passenden Rewrite-Regeln, damit die WebP-Bilder auch im Browser ausgeliefert werden können. Dort klickst du auf Setze Rewrite-Regeln ein.

WebP rewrite Regeln

Sollte das Einsetzen über das Plugin nicht funktionieren, dann setze die Rewrite-Regeln einfach manuell in deine .htaccess ein.

Easy, oder?

Hinweis: Solltest du den EWWW Image Optimizer schon vorher zur Optimierung deiner Bilder benutzt haben, musst du einmal alle deine Bilder neu optimieren, damit die entsprechenden WebP-Dateien erzeugt werden.

13. Bild-Abmessungen auf verfügbaren Platz anpassen

Durch Änderung des Dateiformats, Verringerung der Bildqualität und Komprimierung kannst du schon sehr viel erreichen.

Diese Maßnahmen sind jedoch nicht allzu effektiv, wenn deine Bilder in einer deutlich höheren Auflösung angezeigt werden als nötig.

Vielleicht sind sie durch Komprimierung anstatt 5 MB nur noch 2 MB groß. 2 MB sind allerdings immer noch viel zu viel pro Bild.

Bilder im Internet brauchen (maximal!) eine Auflösung von 2000 x 2000 Pixel. Denn die wenigsten Internet-Nutzer sind mit einer höheren Auflösung unterwegs.

Die Entwickler bei WordPress waren sich dieses Problems bewusst, weshalb in WordPress 5.3 eingeführt wurde, dass alle Bilder, die größer als 2560 Pixel in der Länge oder Breite sind, herunterskaliert werden.

Dennoch erfordert die Anpassung der Bildgrößen weitere Maßnahmen:

1. Bildgrößen in den Medien-Einstellungen anpassen

Die Auflösung von Bildern innerhalb deiner Seiten oder Blogartikel kannst du in WordPress unter Einstellungen > Medien-Einstellungen festlegen.

Idealerweise sollte die Maximale Breite der größten Bildgröße (Groß) nicht höher sein als deine Artikelbreite.

Wenn also deine Artikel 800 Pixel breit sind, sollte das in den Medien-Einstellungen so aussehen:

In Medien-Einstellungen Bildgröße festlegen

2. Bildgrößen von Plugins- und Theme-Bildern anpassen

Deine WordPress-Themes und -Plugin erzeugen auch diverse Bildgrößen, die höher auflösend sind, als sie sein müssten.

Die erzeugten Bildgrößen lassen sich jedoch leider nicht immer in den Plugin- oder Themeeinstellungen anpassen.

Um diese trotzdem ändern zu können, eignet sich das Plugin Simple Image Sizes sehr gut:

Bildgräßen mit Simple Image Sizes festlegen

14. Bildgrößen regenerieren

Bilder werden oft in zu hoher Auflösung angezeigt, weil WordPress die passenden Bildgrößen nicht generiert hat.

Das kann in folgenden Situationen passieren:

  1. Du hast die Bildgrößen in den Medien-Einstellungen in WordPress geändert
  2. Du hast Bildgrößen in Theme- oder Plugin-Einstellungen geändert
  3. Du hast dein WordPress-Theme, dein Layout oder deinen Page-Builder gewechselt

Sollte einer der vier Punkte auf dich zutreffen, solltest einmal alle Bildgrößen neu generieren. Das ist einfach und schnell mit dem Plugin Regenerate Thumbnails möglich:

Vorschaubilder mit Regenerate Thumbnails neu generieren

Einfach einmal durchlaufen lassen und fertig!

Hinweis: Falls du ein Bildoptimierungs-Plugin verwendest, solltest du die die regenerierten Vorschaubilder noch einmal komprimieren.

15. Videoformate für animierte Bilder verwenden

Du kannst die Größe von GIF-Bildern erheblich reduzieren, indem du diese in ein MP4- oder, noch besser, ein WebM-Video umwandelst.

Hier kannst du einen kleinen Größenvergleich zwischen einer GIF, MP4 und WebM-Datei sehen:

webm vs mp4 vs gif

Selbst nach Komprimierung (verlustbehaftet, 90 %) ist die GIF-Datei mit 332 KB noch mehr als doppelt so groß als die 140 KB große WebM-Datei.

Tipp: Wenn dein LCP-Element ein sehr langes oder hochauflösendes Video ist, solltest du es lieber in den nicht sichtbaren Bereich (below the fold) schieben.

16. Deinen Server optimieren

Eine hohe TTFB (Time to First Byte) wirkt sich negativ auf den LCP aus.

Eine hohe TTFB wiederum kann ein Hinweis auf eine schlechte Server-Konfiguration (fehlende oder schlecht konfigurierte Caching-Mechanismen, veraltete PHP-Version etc.) oder einen schlichtweg überlasteten Server sein.

Was du tun kannst, um die Server-Performance zu verbessern und Bottlenecks zu finden, erfährt du z. B. in diesem Guide von Google.

Das Problem ist:

Bei vielen Shared-Hosting-Paketen kannst du nur bedingt in die Server-Konfiguration eingreifen (und wenn du keine Ahnung davon hast, solltest du auch eher die Finger davon lassen).

Deshalb kann ein Wechsel auf einen ein besser ausgestattetes Hosting-Paket oder einen vServer Sinn ergeben, bei denen die Vorkonfiguration besser ist, du an mehr Stellschrauben drehen kannst oder bei denen einfach mehr Ressourcen zur Verfügung stehen.

Auch ein Wechsel des Hosting-Anbieters kann deine TTFB mitunter enorm verbessern. In meinem Webhosting-Vergleich habe ich die TTFB von 15 verschiedenen deutschen Hostern miteinander verglichen (mit Hosting-Paketen für jeweils ca. 10 €/Monat).

Und die Unterschiede dabei waren riesig:

Die Bandbreite bei der TTFB reichte in meinen Tests von 38 ms bis 472 ms! Selbst, wenn man die Latenzen durch unterschiedliche Entfernungen zum Teststandort herausrechnet, ist das ein sehr breites Spektrum:

TTFB aller Webhoster im Vergleich

17. Unnötiges CSS und JavaScript entfernen

Viele WordPress-Plugins und -Themes laden ihre CSS- und JS-Dateien global, das heißt auf jeder einzelnen Seite deiner Website.

Das ist meist unnötig, denn viele Plugin- bzw. Theme-Funktionen kommen nur auf einigen wenigen Seiten oder bestimmten Seiten-Typen (Beiträge, Seiten, Kategorien, Schlagwörter, Produkte etc.) zum Einsatz.

Ein prominentes Beispiel dafür ist Contact Form 7, das seine CSS- und JS-Dateien global lädt, obwohl das Kontaktformular meist nur auf einer einzigen Seite eingebunden ist.

Welche Dateien auf einer Seite unnötig geladen werden, kannst du z. B. bei PageSpeed Insights unter dem Punkt Nicht genutztes JavaScript entfernen sehen:

Nicht genutztes JavaScript entfernen

Welche Dateien auf einer Seite unnötig geladen werden, kannst du z. B. bei PageSpeed Insights unter dem Punkt Nicht verwendete CSS entfernen sehen:

Nicht verwendetes CSS entfernen

Auch der Coverage-Report der Chrome DevTools eignet sich sehr gut, um nicht benötigte CSS- und JS-Dateien zu finden. Du kannst ihn öffen, indem du oben rechts auf die drei senkrechten Punkte klickst und dann More Tools > Coverage auswählst:

Coverage Report in Chrome Devtools öffnen

Im Report wird dir angezeigt, wie viele Bytes der geladenen CSS- und JS-Dateien tatsächlich auf einer Seite verwendet werden:

Coverage Report in Chrome Devtools

Zur Entfernung der jeweiligen CSS-Dateien und um weitere nicht benötigte Dateien zu finden, empfehle ich das Plugin perfmatters.

Mit dem Skript-Manager des Plugins kannst du CSS- und JS-Dateien nur für bestimmte Seiten aktivieren oder deaktivieren. Wenn du z. B. Contact Form 7 überall deaktivieren willst außer auf deiner Kontakt-Seite, würdest den Skript-Manager für die Kontakt-Seite öffnen:

Den Skript Manager über QuickEdit öffnen

Anschließend wird dir eine Liste aller Dateien (gruppiert nach Theme und Plugin) gezeigt, die auf der Kontakt-Seite geladen werden:

Skript Manager von perfmatters

Dort kannst du auswählen, dass Contact Form 7 überall deaktiviert werden soll außer auf der aktuellen URL.

Wahlweise kannst du auch nur einzelne CSS- und JS-Dateien deaktivieren, wie du weiter oben beim Punkt Gutenberg sehen kannst. Dazu musst du einfach nur die Schalter bei den jeweiligen Dateien auf AUS stellen.

18. CSS- und JS-Dateien komprimieren

Durch Komprimierung (engl. Minification) werden unnötige Zeichen (z. B. Kommentare oder Leerzeichen) aus dem Quellcode entfernt.

Dadurch lässt sich die Übertragungsgröße bei vielen CSS- und JS-Dateien mitunter stark verringern, was nicht nur den LCP, sondern auch den FID verbessert.

Hier ein kleines Beispiel anhand der jQuery-Bibliothek (Version 3.6.0). Die unkomprimierte Variante der JavaScript-Datei hat 289 KB und die komprimierte Variante nur 89 KB. Das entspricht einer Reduktion von knapp 70 %:

Komprimierte vs unkomprimierte JS Datei

Wenn du WP Rocket nutzt, kannst du die Komprimierung von CSS-Dateien aktivieren, indem du unter Einstellungen > WP Rocket > Dateioptimierung > CSS-Dateien ein Häkchen bei CSS minifizieren setzt:

CSS minifizieren mit WP Rocket

JS-Dateien kannst du komprimieren, indem du auf der selben Seite weiter unten im Abschnitt JavaScript-Dateien ein Häkchen bei JavaScript minifizieren setzt:

JavaScript minifizieren mit WP Rocket
Tipp: Die Häkchen bei CSS zusammenfassen bzw. JavaScript zusammenfassen solltest du nur dann setzen, wenn dein Server kein HTTP/2 unterstützt, ansonsten kann sich deine Ladezeit verschlechtern. Ob dein Server HTTP/2 unterstützt, kannst du hier testen.

19. Unnötige Plugins deaktivieren

Plugins laden oft unnötig viele CSS- oder JS-Dateien oder verlangsamen WordPress durch zu viele Datenbankabfragen. Zudem stellen Plugins immer ein Sicherheitsrisiko dar (vor allem diejenigen, die nicht regelmäßig gewartet werden).

Deswegen gilt: Je weniger Plugins, desto besser!

Gehe regelmäßig die Liste deiner Plugins durch und frag dich: Brauche ich das wirklich?

Und wenn nein, dann weg damit! Falls du ein Plugin brauchst, aber nur sporadisch nutzt, empfehle ich dir, es nur dann zu aktivieren, wenn du es nutzt und danach direkt wieder zu deaktivieren und zu löschen.

Zu den größten Ladezeit-Killern gehören zum Beispiel:

  • Social-Media-Plugins (Twitter- oder Instagram-Feed, Facebook-Like-Box, Share-Buttons ohne Caching etc.)
  • Page-Builder (z. B. Visual Composer)
  • Kommentar-Plugins
  • Kontaktformulare
  • Foren-Plugins (Simple:Press, bbPress etc.)
  • Woocommerce und andere E-Commerce-Plugins

20. Ein schlankes WordPress-Theme verwenden

Dein WordPress-Theme spielt eine enorme Rolle für die Core Web Vitals.

All-in-One-Themes, wie z. B. Avada, X Theme, Enfold, The 7 oder Divi, bieten zwar viele Einstellungs- und Gestaltungsmöglichkeiten, ein schickes Design, zahlreiche Integrationen und einen eigenen Page-Builder. Aber so toll dieses Baukasten-Prinzip auch ist, bringt es auch Nachteile mit sich:

Solche Themes laden oft unnötig viele oder große CSS- und JavaScript-Dateien, was deinen LCP, die FID und deine generelle Ladezeit in den Keller ziehen kann.

Zudem bringen sie oft die Installation vieler weiterer Plugins mit sich (z. B. Slider, Kontaktformulare, WooCommerce, bbPress, Widgets):

Bundled Plugins von Avada

Bitte schau, ob du diese Zusatz-Plugins auch wirklich verwendest. Auch wenn das Theme die Installation eines Plugins empfiehlt, kommst du in vielen Fällen auch ohne aus.

Bei manchen Themes, wie z. B. Avada, lassen sich auch einzelne Funktionen komplett ausschalten, sodass entsprechende CSS- und JS-Dateien nicht mehr geladen werden:

AVADA Theme Funktionen ausschalten

Letzten Endes ist es jedoch besser, ein Theme zu verwenden, das an sich schlank ist und nicht mehr “abgespeckt” werden muss.

Ich empfehle die Verwendung von:

Achtung: Ein Theme-Wechsel kann sehr nervig und aufwändig sein, bitte überlege ganz genau, ob sich das wirklich lohnt. Die Core Web Vitals sind letzten Endes nur einer von 200+ Google-Ranking-Faktoren.