Unser neuer SEO-Kurs „New Level SEO“ kommt am 22. Oktober!Zur Warteliste

10 Tipps, um den First Input Delay (FID) bei WordPress zu verbessern

FID (First Input Delay) verbessern

Wenn eine Webseite langsam reagiert, ist das schlecht für die Nutzererfahrung.

Stell dir vor, du willst auf einer Seite herunterscrollen und es passiert nichts. Oder du willst deine E-Mail in ein Feld eintragen, und die Buchstaben kommen erst verzögert.

Um diese Interaktivität messen und optimieren zu können, hat Google den FID (First Input Delay) als Teil der Core Web Vitals eingeführt.

Er berechnet sich dadurch, wie lange eine Webseite braucht um auf die erste Interaktion eines Nutzers (z. B. Scrollen oder Klicken auf einen Button) zu reagieren.

Hohe FID-Werte (über 100 ms) entstehen dadurch, dass der Haupt-Thread des Browsers zu lange oder in zu langen Abständen beim Laden einer Webseite blockiert ist. Denn während der Haupt-Thread blockiert ist, ist keine Nutzerinteraktion möglich.

Die häufigste Ursache für lange Blockaden ist schlecht optimiertes oder schlichtweg zu viel JavaScript.

Wie kann ich den FID messen?

Wichtig zu wissen ist:

Im Gegensatz zum LCP und zum CLS kannst du dir zum FID keine Labdaten anschauen, er berechnet sich ausschließlich aus Felddaten. In PageSpeed Insights ist der FID entsprechend auch nur oben in den Felddaten aufgeführt (oder, falls keine Felddaten vorhanden sind, in der Origin Summary):

FID in PageSpeed Insights

Wundere dich also nicht, dass sich der Wert nicht sofort verändert, wenn du eine Veränderung an einer Seite vornimmst. Erst nach 28 Tagen kannst du den vollen Effekt deiner Optimierungmaßnahmen sehen.

Google empfiehlt zur Verbesserung des FIDs die TBT (Total Blocking Time) zu optimieren. Diese misst, wie lange der Hauptthread des Browsers insgesamt blockiert ist.

Damit misst sie zwar etwas anderes als der FID, Verbesserungen der TBT wirken sich jedoch meist auch positiv auf den FID aus. Denn solange Hauptthread blockiert ist, ist keine Interaktion durch den Nutzer möglich.

Zweites Ziel der Optimierung der FID besteht darin Long Tasks zu finden und zu eliminieren, das heißt lange Blockierungsblöcke.

Denn, wenn die erste Interaktion eines Nutzers am Anfang eines langen Blockierungsblocks (der pinke Balken in der Grafik) liegt, ist der FID genauso lang wie der Blockierungsblock:

FID vs FCP vs TTI

Zum Testen der TBT kannst du sehr gut PageSpeed Insights nehmen:

TBT in PageSpeed Insights

Die Diagnose weiter unten zeigt dir auch lange Hauptthread-Aufgaben (Long Tasks) an:

Lange Hauptthread-Aufgaben vermeiden in PageSpeed Insights

Zusätzlich kannst du in der Diagnose sehen, durch welche Arten von Aufgaben der Haupt-Thread blockiert ist, was ebenfalls nützlich sein kann, um die Ursachen für einen hohen FID zu finden:

Auch Lighthouse in den Chrome DevTools kann sinnvoll zum Testen sein, denn es hebt Long Tasks im Wasserfall-Diagramm hervor:

Long Tasks in Lighthouse

Ein weiteres nützliches Tool, um den FID zu testen, ist die Core Web Vitals Extension für Chrome. Die ermöglicht dir den FID live zu messen und mit verschiedenen Interaktionsszenarien herumzuspielen (unterschiedliche Nutzer brauchen unterschiedlich lange bis zur ersten Interaktion):

Chrome Web Vitals Chrome Extension
Hinweis: Bitte beachte, dass beim First Input Delay nur dann ein Wert angezeigt wird, nachdem du mit der getesteten Seite interagiert hast (geklickt, gescrollt etc.).

Folgende Maßnahmen helfen dir, deinen FID zu verbessern:

1. Unnötiges JavaScript entfernen

Je weniger JavaScript auf deinen Seiten geladen wird, desto besser für deinen FID.

Das Problem ist:

Viele WordPress-Plugins und -Themes laden ihre JavaScript-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 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
Um die unnötigen Dateien ausfindig zu machen, solltest du temporär die Minifizierung und Zusammenfassung von JS-Dateien in deinem Caching- oder Optimierungs-Plugin ausschalten.

Auch der Coverage-Report der Chrome DevTools eignet sich sehr gut, um nicht benötige 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- und JS-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- oder JS-Dateien deaktivieren, wie du weiter oben bei Gutenberg sehen kannst. Dazu musst du einfach nur die Schalter bei den jeweiligen Dateien auf AUS stellen.

2. 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 deine LCP, FID und deine generelle Ladezeit in den Keller zieht.

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 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.

3. 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 JS-Dateien mitunter stark verringern, was nicht nur den FID, sondern auch den LCP verbessern kann.

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 JS-Dateien aktivieren, indem du unter Einstellungen > WP Rocket > Dateioptimierung > 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.

4. Textkomprimierung aktivieren

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

Denn durch Textkomprimierung sorgst du dafür, dass sich die Übertragungsgröße von JavaScript-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:
<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:

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.*
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. Unnötige Plugins deaktivieren

Plugins laden oft unnötig viele 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!

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

Und wenn nein, dann weg damit! Falls du es 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 FID-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

6. Drittserver-Code reduzieren

Eine der Ursachen für einen schlechten FID kann Code sein, der von Drittservern geladen wird, wie z. B. von:

  • 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, Taboola 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 die TBT (Total Blocking Time) durch automatische Anzeigen von Google AdSense und Google Fonts, die nicht vorgeladen werden, enorm erhöht:

Die Auswirkungen von Drittanbieter-Code minimieren in PageSpeed Insights

Bitte überlege dir bei jedem Drittserver-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 Drittserver-Code zumindest aus dem Content above the fold entfernen und nachladen:

7. 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 gilt vor allem für Drittserver-Code.

Dadurch verringert sich nicht nur dein FID, sondern mitunter auch dein LCP.

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 async und defer erfährst du in diesem Artikel

Und ja, 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.

8. Drittservern-Verbindungen vorab aufbauen

Wenn du Ressourcen von Drittservern lädst, solltest du die Verbindungen zu diesen Drittservern vorab aufbauen. Das kann sich sowohl positiv auf den FID als auch den LCP auswirken.

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 extern geladene 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 google_fonts_preconnect(){ ?> <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

9. Übermäßige DOM-Größe vermeiden

Auch eine übermäßige DOM-Größe kann sich negativ auf den FID auswirken.

Denn die Verarbeitung des DOM ist eine der Aufgaben, die der Haupt-Thread eines Browsers übernimmt. Und je mehr wir den Haupt-Thread entlasten, desto besser ist das für die Interaktivität.

Google empfiehlt ein DOM mit:

  • maximal 1.500 Elementen insgesamt
  • einer Tiefe von weniger als 32 Elementen
  • maximal 60 untergeordneten Elementen

Folgender Blogartikel von mir hat durch ca. 450 Kommentare eine DOM-Größe von 10.713 Elementen. Das führt zu einer TBT von 260 ms:

TBT ohne Lazy-Loading for comments

Der selbe Blogartikel mit dem aktiviertem Plugin Lazy Load for Comments, durch das die Kommentare nachgeladen werden, hat lediglich eine DOM-Größe von 1.453 Elementen, wodurch sich die TBT auf 60 ms reduziert:

TBT mit Lazy Loading for comments

Hier findest du diverse Ideen, um die DOM-Größe deiner Blogartikel oder Seiten zu reduzieren:

1. Teile lange Seiten in mehrere kürzere auf

Je länger deine Seiten oder Blogartikel sind, desto größer ist auch dein DOM. Überlege deshalb, diese aufzuteilen.

2. Verwende Lazy-Loading oder Pagination (für alles, was geht)

  • Nutze Links statt Embeds (du verlinkst auf ein YouTube-Video anstatt es in deinen Blogartikel einzubetten)
  • Lazy Loading oder Content Blocking von YouTube-Videos und anderer iframes (das geht mit WP Rocket, WP YouTube Lyte oder mit diversen Cookie-Plugins, wie z. B. Borlabs Cookie).
  • Lazy Loading für Kommentare (z. B. mit Lazy Load for Comments) oder andere HTML-Elemente, die erst später gebraucht werden
  • Pagination für Kommentare einstellen (in WordPress unter Einstellungen > Diskussion > Weitere Kommentareinstellungen > Kommentare in Seiten umbrechen)
  • Die Anzahl der angezeigten Posts auf Blog-Seiten reduzieren (in WordPress unter Einstellungen > Lesen > Blogseiten zeigen maximal X Beiträge).
  • Infinite Scroll oder nachladen per Button für neue Posts/Produkte (z. B. mit Ajax Load More)

3. Verwende ein sauber programmiertes Theme

Habe ich schon weiter oben erwähnt. Dazu gehören zum Beispiel GeneratePress oder das Astra-Theme.

4. Vermeide Page-Builder

Page-Builder wie Elementor oder WPBakery verwenden sehr viele unnötige HTML-Elemente. Da gibt es <div> um <div> um <div>:

Viele divs in Elementor

Das muss nicht sein.

Nutze stattdessen lieber Gutenberg (z. B. in Kombination mit GenerateBlocks) oder den Oxygen-Builder.

5. Vermeide display:none

Versuche anstatt display: none zu verwenden, ganz auf die HTML-Elemente zu verzichten, die du nicht anzeigen möchtest.

10. Long Tasks aufteilen

Insbesondere während langer Hauptthread-Aufgaben (Long Tasks), kann es sein, dass eine Webseite nicht ansprechbar ist und auf Nutzeraktionen nicht reagiert:

Für Google sind Long Tasks alle Aufgaben, die den Hauptthread länger als 50 ms in Anspruch nehmen. Warum gerade 50 ms und nicht 100 oder 743 ms, kannst du in Googles RAIL-Modell nachlesen.

Solltest du nicht auf das JavaScript komplett verzichten können, das Long Tasks verursacht, besteht die Möglichkeit mit Code Splitting diese in kleinere Aufgaben aufzuteilen.

Allerdings:

Bei JavaScript, das durch dein Theme oder deine WordPress-Plugins geladen wird, ist es meist nicht sinnvoll selbst Hand anzulegen (auch, wenn du die entsprechenden Programmierkenntnisse mitbringst).

Am besten ist es, Theme- bzw. Plugin-Entwickler anzuschreiben und sie darum zu bitten, ihre Scripte zu optimieren.