Die meisten WordPress-Seiten bestehen zwar die Ladezeit-Tests, scheitern dann aber still und leise beim INP-Test, da der INP-Test nicht misst, wie schnell Ihre Seite angezeigt wird, sondern wie schnell Ihre Seite reagiert, wenn jemand tatsächlich darauf klickt, darauf tippt oder etwas eingibt. Das ist ein anderes Problem, das fast ausschließlich in Ihrem JavaScript liegt.
Dieser Leitfaden ist eine Anleitung zur Fehlerdiagnose und keine weitere Liste von Plugins, die Sie installieren sollen. Ich werde Ihnen zeigen, woraus INP wirklich besteht, wie Sie die genaue Interaktion finden, die zu Verzögerungen führt, welche WordPress-Gewohnheiten dies verursachen und welche JavaScript-Maßnahmen tatsächlich zu einer Verbesserung führen.
Wichtigste Erkenntnisse
- INP hat im März 2024 „First Input Delay“ als „Core Web Vital“ abgelöst und ist mittlerweile die Kennzahl, bei der die meisten WordPress-Seiten durchfallen, da sie die tatsächliche Reaktionsfähigkeit bei Interaktionen misst und nicht die Geschwindigkeit beim ersten Laden.
- Ein guter INP-Wert liegt bei 200 ms oder weniger; Werte zwischen 200 und 500 ms sind verbesserungswürdig; Werte über 500 ms sind schlecht, gemessen am 75. Perzentil der tatsächlichen Besuche.
- INP besteht aus drei Komponenten: Eingabeverzögerung, Verarbeitungszeit und Darstellungsverzögerung; wenn man weiß, welche davon langsam ist, weiß man genau, was man beheben muss.
- Bei WordPress sind die üblichen Übeltäter Page-Builder, Live-Chat-Widgets, ressourcenintensive Tags von Drittanbietern und Plugins, die auf jeder Seite JavaScript laden.
- Die Lösung ist eine „JavaScript-Diät“: Skripte verzögern und aufschieben, ressourcenintensive Widgets hinter einer Fassade laden und Plugins deaktivieren, die JavaScript ausführen, das Sie nicht benötigen – es gibt kein einziges „Wunder-Plugin“.
Warum INP der „Core Web Vital“-Wert ist, bei dem die meisten WordPress-Seiten versagen
Google hat „First Input Delay“ durch Interaktion mit „Next Paint“ im März 2024, und genau dieser Wechsel ist der Grund dafür, dass viele Websites, die früher die Schwelle überschritten haben, dies nun nicht mehr tun. FID hat lediglich die Verzögerung gemessen, bevor der Browser mit der Verarbeitung Ihrer allerersten Interaktion begann; daher konnte eine Website zwar gut abschneiden, sich aber bei jedem weiteren Klick dennoch träge anfühlen.
INP ist strenger, da es jede Interaktion während des gesamten Besuchs berücksichtigt und einen Wert angibt, der nahe am schlechtesten Ergebnis liegt. Ein gutes Ergebnis ist 200 ms oder weniger, 200 bis 500 ms sind verbesserungswürdig, und alles über 500 ms ist schlecht – gemessen am 75. Perzentil Ihrer tatsächlichen Besucher.
WordPress schneidet in diesem Punkt aus einem Grund schlechter ab als die meisten anderen Plattformen: Es enthält sehr viel JavaScript. Durch den Page Builder, einige Plugins, die jeweils ihre eigenen Skripte in die Warteschlange stellen, und ein paar Tags von Drittanbietern ist der Hauptthread schließlich ausgelastet – und genau das führt dazu, dass die Interaktion ins Stocken gerät. Der Wert für „Largest Contentful Paint“ sagt darüber nichts aus, weshalb ich INP in meinem Leitfaden zu den Core Web Vitals.
Was INP tatsächlich misst: Eingabeverzögerung, Verarbeitung und Darstellung
Hier kommt der Teil, den die meisten Anleitungen auslassen – und genau dieser Teil macht die Behebung von INP zu einer einfachen Angelegenheit, statt zu einem Rätsel. Jede Interaktion besteht eigentlich aus drei Zeitabschnitten, die addiert werden, und der Grund für die Verzögerung liegt fast immer in nur einem davon.
Eingangsverzögerung ist die Wartezeit, bevor Ihr Code überhaupt ausgeführt wird – in der Regel, weil der Hauptthread gerade mit der Ausführung einer anderen Aufgabe beschäftigt ist. Bearbeitungszeit Erfüllen Ihre Ereignisbehandler tatsächlich ihre Aufgabe?. Verzögerung bei der Präsentation Rendert der Browser das Ergebnis und zeichnet es auf dem Bildschirm? Finden Sie heraus, welcher Abschnitt besonders lange dauert, und Sie wissen, ob das Problem in zu viel JavaScript im Hintergrund, einem ressourcenintensiven Handler oder einem überladenen Layout liegt.
| Die drei Teile von INP | Was es ist | Häufige Ursache bei WordPress | Die Lösung |
|---|---|---|---|
| Eingangsverzögerung | Die Wartezeit, bevor Ihr Handler startet, während der Hauptthread beschäftigt ist | Skripte von Plugins, Tag-Managern und Buildern, die alle gleichzeitig ausgeführt werden | Nicht kritisches JavaScript verzögern und zurückstellen, damit der Thread frei ist, wenn der Benutzer eine Aktion ausführt |
| Bearbeitungszeit | Ihre Ereignisbehandler erfüllen ihre Aufgabe | Ein ressourcenintensives Widget oder ein Handler, der beim Klicken zu viele Aufgaben ausführt | Teilen Sie die Arbeit auf oder laden Sie das Widget hinter einer Fassade, bis es benötigt wird |
| Verzögerung bei der Präsentation | Der Browser rendert und zeichnet das nächste Bild | Ein übergroßes DOM aus einem Page-Builder mit tief verschachtelten Elementen | Vereinfachen Sie das Layout und reduzieren Sie die Anzahl der Elemente in komplexen Vorlagen |
So ermitteln Sie anhand von Echtfelddaten Ihre langsamste Interaktion
Man kann eine Wechselwirkung nicht beheben, die man nicht identifiziert hat; beginnen Sie also mit Felddaten und nicht mit einer Vermutung aus dem Labor. Die Bericht zur Chrome-Benutzererfahrung Enthält den INP, den Ihre tatsächlichen Besucher erlebt haben, und PageSpeed Insights zeigt ihn ganz oben bei jeder URL an, die Sie testen. Anhand dieser Zahl bewertet Google Ihre Website, daher fange ich immer damit an.
Der Haken daran ist, dass Felddaten erst dann vorliegen, wenn eine Seite genügend Traffic hat; daher wird für eine neue oder wenig frequentierte Website oft noch kein INP-Bericht angezeigt. In solchen Fällen und zur Reproduktion eines bestimmten langsamen Klicks nutzen Sie das Leistungsfenster in den Chrome DevTools mit der aufgezeichneten Interaktion; es unterteilt eine einzelne Interaktion in die drei oben genannten Teile, sodass Sie erkennen können, welcher davon besonders lange dauert. Auf diese Unterscheidung zwischen Feld- und Labormessungen bin ich in meiner Analyse von CrUX Vis im Vergleich zu PageSpeed Insights, denn das Richtige zu lesen ist schon die halbe Miete.
Die WordPress-Plugins und -Widgets, die den INP beeinträchtigen
In der Praxis taucht bei fast jedem WordPress-Audit immer wieder dieselbe Handvoll Problemfälle auf. An erster Stelle stehen ressourcenintensive Page-Builder, da ein Builder wie Divi umfangreiche Skripte und tief verschachtelte Markups hinzufügt, die sowohl die Verarbeitung als auch die Darstellung verlangsamen. Ein Live-Chat-Widget ist oft der größte Einzelverursacher; ein einziges Chat-Skript kann allein schon Hunderte von Millisekunden an Verarbeitungszeit verursachen.
Danach kommen die unauffälligeren Faktoren: Analytics- und Tag-Manager-Einstellungen, die mehrere Skripte von Drittanbietern laden, Slider- und Popup-Plugins sowie die allgemeine Anhäufung von Plugins, die jeweils JavaScript siteweit in die Warteschlange stellen – selbst auf Seiten, auf denen es nie verwendet wird. Keines davon ist für sich genommen fatal, aber zusammen halten sie den Hauptthread auf Trab – und ein ausgelasteter Thread ist es, der einen Klick in eine Wartezeit verwandelt. Auch hier hilft ein schlankeres Theme, was mit ein Grund dafür ist, warum ich weiter darauf dränge Ob Ihr Theme Ihre SEO beeinträchtigt.
Die JavaScript-Diät: INP bei WordPress Schritt für Schritt beheben
Das Ziel dieser Maßnahme lässt sich einfach formulieren: Der Hauptthread soll frei bleiben, damit der Browser sofort reagieren kann, wenn ein Nutzer interagiert. Dies lässt sich erreichen, indem man weniger JavaScript lädt, es erst später lädt und die ressourcenintensiven Teile erst dann ausführt, wenn sie tatsächlich benötigt werden.
WordPress-INP beheben – in der Reihenfolge, die am schnellsten zum Erfolg führt
- Überprüfen Sie, welche Elemente in den einzelnen Vorlagen JavaScript laden, und entfernen Sie nicht benötigte Plugins.
- Nicht kritische Skripte verzögern und zurückstellen, damit der Hauptthread beim Laden frei ist
- Platzieren Sie ressourcenintensive Widgets (Chat, Video, Karten) hinter einer Fassade, die beim Klicken geladen wird
- Plugin-Skripte nur bedingt auf den Seiten laden, auf denen sie verwendet werden
- INP vor Ort erneut messen und sicherstellen, dass sich die ungünstigste Wechselwirkung verbessert hat
Prüfen Sie zunächst, was jede Vorlage tatsächlich lädt, denn die kostengünstigste Millisekunde ist die, die Sie gar nicht erst ausliefern. Deaktivieren Sie Plugins, die Sie nicht mehr verwenden, und prüfen Sie bei denjenigen, die Sie behalten, ob sie Skripte auf jeder Seite einreihen oder nur dort, wo sie benötigt werden.
Verzögern und verschieben Sie dann die nicht kritischen Skripte. Die meisten Caching-Plugins, darunter auch LiteSpeed Cache, verfügen über eine Option “JavaScript verzögern”, die Skripte bis zur ersten Benutzerinteraktion zurückhält, wodurch der Thread in den entscheidenden ersten Augenblicken entlastet wird. Seien Sie hier jedoch etwas vorsichtig, denn das Verzögern eines Skripts, von dem Ihre Inhalte im Bereich „above the fold“ abhängen, kann zu Fehlern führen. Testen Sie daher die Funktion, nachdem Sie sie aktiviert haben.
Die Fassadenmuster ist für die meisten Websites die effektivste Einzelmaßnahme. Anstatt beim Laden der Seite ein Live-Chat- oder Video-Widget zu laden, zeigen Sie eine schlanke Attrappe an: eine statische Schaltfläche oder ein Miniaturbild, das wie das Original aussieht, und das ressourcenintensive Skript wird erst geladen, wenn der Nutzer darauf klickt. Ein Chat-Widget, das bisher bei jeder Interaktion 300 ms Verarbeitungszeit verursachte, hat nun keinerlei Einfluss mehr auf Ihren INP, bis jemand den Chat tatsächlich öffnet.
Laden Sie schließlich Plugin-Skripte bedingt, sodass ein Kontaktformular- oder Slider-Skript nur auf den Seiten erscheint, auf denen es verwendet wird, und nicht auf der gesamten Website. Das ist zwar aufwändiger als das Umlegen eines Schalters, macht aber oft den Unterschied zwischen einer Website, die immer wieder durchfällt, und einer, die endlich die Prüfung besteht – denn so wird das Problem der sich anhäufenden Eingabeverzögerungen an der Wurzel gepackt.
So überprüfen Sie, ob sich Ihr INP tatsächlich verbessert hat
Beurteilen Sie das Ergebnis nicht allein anhand eines Laborwerts. Labor-Tools simulieren einen einzelnen Durchlauf, während INP eine Feldmetrik ist, die auf Ihren tatsächlichen Besuchern basiert. Daher wird der relevante Wert in CrUX nur langsam aktualisiert, sobald neue Daten eingehen. Rechnen Sie damit, dass es nach einer Änderung einige Wochen dauern kann, bis sich diese vollständig im Feld-INP widerspiegelt.
Überprüfen Sie in der Zwischenzeit im Labor, ob die von Ihnen behobene spezifische Interaktion nun schneller abläuft: Zeichnen Sie dies erneut im Leistungsfenster auf und vergewissern Sie sich, dass der von Ihnen angepeilte Bereich – Eingabeverzögerung, Verarbeitung oder Darstellung – tatsächlich schneller geworden ist. Wenn das Labor zeigt, dass die Korrektur funktioniert, und die Feldzahl in den folgenden Wochen sinkt, wissen Sie, dass die Korrektur von Dauer ist.
Wie schwierig ist es denn nun wirklich, das INP-Problem in WordPress zu beheben?
Ehrlich gesagt ist das Problem leichter in den Griff zu bekommen, als sein Ruf vermuten lässt – vorausgesetzt, man betrachtet es nicht länger als ein Problem der Ladegeschwindigkeit. Fast jeder von mir diagnostizierte INP-Fehler lässt sich auf JavaScript zurückführen, das zu diesem Zeitpunkt gar nicht hätte ausgeführt werden müssen, und das Facade-Muster in Kombination mit einem ordnungsgemäßen „Delay-JS“-Durchlauf beseitigt auf den meisten Websites den Großteil dieser Probleme.
Gehen Sie also nicht einfach auf Plug-in-Jagd, um das Problem zu beheben; stellen Sie zunächst fest, welcher der drei Teile langsam ist, und schaffen Sie sich dann durch Kürzungen, Verzögerungen und Aufschübe wieder einen freien Hauptthread. Ja, der Schritt des bedingten Ladens erfordert echten Aufwand, aber genau das ist in der Regel der entscheidende Schritt, der ein hartnäckiges “verbesserungsbedürftig” in ein „bestanden“ verwandelt, und es lohnt sich, ihn ordentlich zu erledigen.
Immer noch unzufrieden mit einem unzureichenden INP-Ergebnis?
Zögern Sie nicht kontaktieren Sie uns oder E-Mail Und ich werde dir dabei helfen, die Interaktion aufzuspüren, die das Ganze verlangsamt. Denk daran: INP ist in erster Linie ein JavaScript-Problem, daher liegt die Lösung fast immer näher, als es den Anschein hat.
Möchtest du, dass unsere Beiträge öfter bei Google erscheinen?
Ein Schritt – und Google zeigt diese Seite in Ihren „Top Stories“ an.
WordPress-Kategorien vs. Tags: Wie man sich entscheidet und welche Rolle Ihre Archivseiten bei der Suche spielen
So korrigieren Sie eine alternative Seite mit dem richtigen Canonical-Tag – und welche URLs sind in Ordnung?
Duplikate ohne vom Nutzer ausgewählte kanonische URL: Wie Google die kanonische URL auswählt – und wann man sie besser unverändert lässt
