INP verbessern: So senken Sie die Interaktionslatenz Ihrer Website

In diesem Leitfaden zeigen wir, Talha Aslan und Team, die Reihenfolge, die wir in echten Audits nutzen, wenn wir INP verbessern. Zunächst klären wir, was die Kennzahl eigentlich misst. Danach gehen wir die typischen Ursachen einzeln durch: lange Aufgaben, schweres JavaScript, Drittanbieterskripte und Event Handler. Die allgemeine Einordnung der drei Kennzahlen finden Sie in unserem Beitrag Core Web Vitals erklärt. Hier konzentrieren wir uns allein auf die Interaktionslatenz.

Was genau misst INP?

INP beobachtet die Latenz aller Interaktionen während des gesamten Besuchs, nicht nur die erste. Laut der INP Dokumentation auf web.dev ist der gemeldete Wert die längste beobachtete Interaktion, wobei Ausreißer unberücksichtigt bleiben. Das heißt, ein einzelner schneller Klick rettet den Wert nicht; die schlechteste Erfahrung entscheidet.

Drei Arten von Interaktionen zählen:

• Mausklicks.
• Tippen auf einem Touchscreen.
• Tastendrücke auf einer physischen oder virtuellen Tastatur.

Andererseits zählen Hovern, Zoomen und Scrollen nicht zu INP. Die Dokumentation nennt zudem eine Regel für Ausreißer: Pro 50 Interaktionen ignoriert sie die höchste. Die meisten Seiten haben weniger als 50 Interaktionen, also bestimmt in der Praxis meist die schlechteste Interaktion den Wert. Deshalb kann ein einziger schwerer Menübutton die ganze Seite nach unten ziehen.

INP hat First Input Delay (FID) abgelöst. FID betrachtete nur die Eingabeverzögerung der ersten Interaktion. INP berücksichtigt dagegen alle Interaktionen und ihre gesamte Latenz. Folglich ist INP strenger, aber auch ehrlicher.

Welche Schwellenwerte gelten für gut, verbesserungswürdig und schlecht?

Google bewertet die Schwellenwerte am 75. Perzentil der Felddaten und trennt dabei Mobilgeräte und Desktop. Drei von vier Besuchen sollten also unter dem Ziel bleiben. Die folgende Tabelle fasst die Grenzen von web.dev zusammen.

Diese Grenzen können sich ändern. Wer INP verbessern will, braucht ein klares Ziel. Prüfen Sie daher die aktuellen Werte immer auf web.dev und in Google Search Central. Außerdem sollten Sie mobile und Desktopergebnisse getrennt betrachten. Eine Seite, die am Desktop gut aussieht, kann auf einem Smartphone der Mittelklasse schnell in den schlechten Bereich rutschen. Deshalb schauen wir in unseren Audits immer zuerst auf die mobile Zeile.

Aus welchen drei Phasen besteht eine Interaktion?

Jede Interaktionslatenz ist die Summe aus drei Teilen. Der Leitfaden zur INP Optimierung auf web.dev baut auf dieser Aufteilung auf, denn jeder Teil braucht eine andere Lösung.

1. Eingabeverzögerung (input delay): Die Wartezeit zwischen der Nutzeraktion und dem Start der Event Handler. Oft verursachen lange Aufgaben im Hauptthread diese Wartezeit.
2. Verarbeitungsdauer (processing duration): Die Zeit, die die Callbacks der Event Handler zum Ausführen brauchen.
3. Darstellungsverzögerung (presentation delay): Die Zeit vom Ende der Callbacks bis zum nächsten Frame auf dem Bildschirm.

Zum Beispiel: Wenn sich ein Warenkorbbutton langsam anfühlt, finden Sie zuerst heraus, welche Phase lang ist. Eine lange Eingabeverzögerung bedeutet, dass anderer Code den Hauptthread belegt. Ist die Verarbeitungsdauer lang, ist der Code des Buttons selbst schwer. Bei einer langen Darstellungsverzögerung kämpft der Browser damit, einen großen DOM Baum neu zu zeichnen. Kurz gesagt: Die richtige Diagnose verhindert, dass Sie an der falschen Stelle arbeiten.

Warum weichen Felddaten und Labordaten voneinander ab?

Felddaten stammen von echten Nutzern. Labordaten stammen aus einem Test auf einem Gerät und in einem Netzwerk. Der Artikel über Unterschiede zwischen Labor und Felddaten auf web.dev erklärt das ausführlich. Für INP ist ein Punkt entscheidend: Ein Labortest weiß nicht, wann ein Nutzer klickt.

Laut diesem Artikel ist Total Blocking Time (TBT) ein Stellvertreter und kein Ersatz für INP. Zudem kann eine Seite trotz sehr guter TBT Werte einen schlechten INP haben. Wenn Sie INP verbessern möchten, geben Sie daher den Felddaten Vorrang und nutzen Sie das Labor nur für die Diagnose.

Wie messen Sie INP bei Ihren eigenen Besuchern?

CrUX Daten sind wertvoll, allerdings verraten sie nicht, welcher Button langsam ist. Deshalb sieht der Leitfaden auf web.dev ein Real User Monitoring (RUM) als besten Ausgangspunkt. Mit eigenem Monitoring können Sie festhalten, an welchem Element jede langsame Interaktion passiert ist.

In der Praxis empfehlen wir, drei Informationen zu sammeln:

• Das betroffene Element, zum Beispiel ein Filterfeld oder ein Menübutton.
• Die Art der Interaktion: Klick, Tippen oder Tastendruck.
• Die Verteilung der Latenz auf Eingabeverzögerung, Verarbeitungsdauer und Darstellungsverzögerung.

Beispielszenario: Auf example.com zeigen die Monitoringdaten, dass die meisten schlechten Interaktionen im mobilen Menü auftreten. Statt die ganze Website zu prüfen, konzentriert sich das Team also auf eine einzige Komponente. Achten Sie außerdem darauf, beim Einrichten keine personenbezogenen Daten zu sammeln. Ziel ist es, die Interaktion zu verstehen, nicht die Person. Ohne eigenes Monitoring füllen die CrUX Daten in PageSpeed Insights einen Teil der Lücke.

Wie finden Sie INP Probleme in der Search Console?

Der Bericht zu den Core Web Vitals in der Search Console zeigt echte Nutzerdaten getrennt für Mobilgeräte und Desktop. Laut der Hilfe zur Search Console fasst der Bericht ähnliche Seiten zu Gruppen zusammen und vergibt pro Gruppe einen Status: Poor (schlecht), Need improvement (verbesserungswürdig) oder Good (gut).

Den Status einer Gruppe bestimmt die schlechteste Kennzahl unter LCP, INP und CLS. Die Daten stammen aus dem CrUX Bericht und spiegeln die letzten 28 Tage wider. Folglich erscheint eine Korrektur von heute nicht sofort im Bericht. Außerdem zeigt der Bericht nur eine Stichprobe indexierter Seiten, keine vollständige Liste.

Wenn Sie den Bericht zum ersten Mal öffnen, beginnen Sie mit unserer Anleitung zur Google Search Console. Ist Ihre Property neu oder der Traffic gering, bleibt die Datenansicht eventuell leer; diesen Fall behandeln wir im Beitrag nicht genügend Nutzungsdaten. Öffnen Sie eine URL Gruppe, sehen Sie Beispieladressen. Diese Beispiele sind der beste Hinweis darauf, welche Seite Sie im Labor testen sollten.

Warum ist INP auf Mobilgeräten meist schlechter?

Mobilgeräte haben in der Regel weniger Rechenleistung als Desktoprechner. Derselbe JavaScript Code braucht auf dem Smartphone länger, also steigt die Zahl langer Aufgaben. Deshalb sieht die mobile Zeile in der Search Console oft schlechter aus als die Desktopzeile.

Der Artikel über Labor und Felddaten auf web.dev nennt zudem ein interessantes Detail. Auf Seiten, die nicht für Mobilgeräte optimiert sind, kann der Browser zwischen dem Tippen und dem Event Handler eine zusätzliche Verzögerung einfügen. Diese Verzögerung ist keine lange Aufgabe, daher erfasst TBT sie nicht, trotzdem erhöht sie INP. Laut dem Artikel vermeiden Sie diese Verzögerung mit einem korrekt gesetzten mobilen Viewport.

Testen Sie in der Praxis also auf einem Smartphone der Mittelklasse, wie Ihre Zielgruppe es nutzt, und nicht auf dem schnellen Laptop Ihres Teams. Prüfen Sie außerdem das mobile Verhalten insgesamt. Messen Sie konkret, wie viel Arbeit Menüs, ausklappbare Panels und fixierte Leisten im Moment der Interaktion verursachen. So trennen Sie Gerätegrenzen klarer von Codeproblemen.

Wie stellen Sie eine langsame Interaktion im Labor nach?

Felddaten zeigen Ihnen, welche Seitengruppe ein Problem hat. Allerdings sagen sie selten, welcher Button langsam ist. Der zweite Schritt besteht deshalb darin, das Problem im eigenen Browser nachzustellen. Der Leitfaden auf web.dev empfiehlt, häufige Nutzerabläufe von Hand zu testen.

• Öffnen Sie das Menü, wählen Sie Filter, füllen Sie das Formular aus und legen Sie ein Produkt in den Warenkorb.
• Probieren Sie diese Interaktionen auch, während die Seite noch lädt; dann ist der Hauptthread oft am stärksten ausgelastet.
• Testen Sie auf einem Smartphone der Mittelklasse oder mit Drosselung der CPU im Browser.
• Zeichnen Sie in den Entwicklertools eine Performanceaufnahme auf und prüfen Sie lange Aufgaben und die Interaktionsspur.

Beispielszenario: Ein Onlineshop auf example.com zeigt einen schlechten mobilen INP. Das Team startet eine Aufnahme und tippt auf einer Kategorieseite auf das Filterfeld. Die Aufnahme zeigt, dass der Filter die gesamte Produktliste neu zeichnet. Somit schrumpft das Problem von „die Seite ist langsam“ auf eine einzige Funktion. Zur allgemeinen Nutzung von Labortools lesen Sie unseren Beitrag zum Lighthouse Performancetest.

Welche Fehler passieren am häufigsten, wenn Teams INP verbessern wollen?

Wenn Teams INP verbessern wollen, sehen wir immer wieder dieselben Fehler. Der erste ist, nur auf den Laborwert zu schauen. Der Lighthouse Wert steigt, das Team hält die Arbeit für erledigt, aber die Felddaten bewegen sich nicht. Denn der Moment, in dem ein echter Nutzer klickt, kam im Test nie vor.

Der zweite Fehler ist der Versuch, die ganze Website auf einmal zu reparieren. Dieser Ansatz verbraucht Entwicklerzeit. Zudem verdeckt er, welche Änderung tatsächlich geholfen hat. Wählen Sie stattdessen die Vorlage mit dem meisten Traffic, belegen Sie dort das Ergebnis und gehen Sie dann zur nächsten Vorlage über.

Drittens verlassen sich viele auf Desktopergebnisse. Schnelle Laptops im Team verbergen das Problem. Viertens schalten Teams Trackingtags blind ab, was die Marketingdaten zerstört. Schließlich vergessen viele, nach dem Livegang die Validierung zu starten. Zusammengefasst: Planung, Messung und Nachverfolgung müssen zusammen laufen.

Wie senken Sie die Eingabeverzögerung?

Die Eingabeverzögerung ist die Zeit, in der ein Klick in der Warteschlange steht. Ist der Browser gerade mit einer anderen Aufgabe beschäftigt, muss Ihr Klick warten. Die Lösung lautet daher: Halten Sie den Hauptthread frei. Der Leitfaden auf web.dev empfiehlt, die Skriptauswertung beim Start zu begrenzen und lange Aufgaben zu reduzieren.

In der Praxis stellen wir einige Fragen. Lädt die Seite Code, den sie nicht sofort braucht? Holt sich ein unsichtbarer Bereich seine Skripte schon am Anfang? Läuft ein Timer, der den Hauptthread ständig beschäftigt? Und erledigen Analyse und Werbetags im Moment eines Klicks zusätzliche Arbeit?

Zum Beispiel muss ein Kommentarwidget am Seitenende nicht sofort laden. Laden Sie es erst, wenn sich der Nutzer diesem Bereich nähert, sinkt die Startlast. Dann müssen die ersten Klicks nicht warten. Die allgemeinen Techniken wie Code Splitting und verzögertes Laden beschreiben wir im Beitrag JavaScript Ladezeit optimieren. Hier geht es nur darum, den Moment der Interaktion zu entlasten; genau so lässt sich INP verbessern, ohne die ganze Seite umzubauen.

Warum schaden lange Aufgaben dem INP?

Laut dem Artikel zu langen Aufgaben auf web.dev gilt jede Aufgabe, die länger als 50 Millisekunden dauert, als lange Aufgabe. Der Hauptthread kann immer nur eine Aufgabe gleichzeitig verarbeiten. Ein Klick, der während einer Aufgabe von 300 Millisekunden eintrifft, wartet also, bis diese Aufgabe endet.

Lange Aufgaben entstehen meist aus diesen Quellen:

• Parsen und Ausführen großer JavaScript Bundles.
• Listen und Tabellencode, der Hunderte Elemente auf einmal erzeugt.
• Analyse, Werbe und Chatskripte, die alle beim Laden der Seite starten.
• Oberflächenframeworks, die bei jedem Klick den gesamten Zustand neu berechnen.

Allerdings ist eine lange Aufgabe für sich genommen kein Fehler. Das Problem beginnt erst, wenn sie mit einer Nutzerinteraktion zusammenfällt. Das Ziel lautet deshalb: Große Aufgaben in kleinere Stücke teilen und dem Browser dazwischen Luft geben. Wer INP verbessern will, landet fast immer bei diesem Punkt. Der nächste Abschnitt zeigt, wie das geht.

Wie geben Sie den Hauptthread frei?

Freigeben (yielding) heißt, Ihre Arbeit kurz zu unterbrechen, damit der Browser wichtigere Aufgaben erledigen kann. Der wartende Klick läuft, der Bildschirm aktualisiert sich, dann setzt Ihr Code dort fort, wo er aufgehört hat. Laut web.dev gehört diese Technik zu den wichtigsten Wegen, um INP zu verbessern.

Die Dokumentation beschreibt zwei Ansätze. Zunächst können Sie mit setTimeout den Rest der Arbeit in eine neue Aufgabe verschieben. Allerdings landet verschobene Arbeit am Ende der Warteschlange, also laufen andere wartende Aufgaben zuerst. Als Alternative gibt es scheduler.yield(). Laut Dokumentation erhält die Fortsetzung dabei Vorrang. Somit können Skripte aus anderen Quellen, etwa von Drittanbietern, die Reihenfolge Ihres Codes nicht unterbrechen.

Für Browser ohne Unterstützung nennt die Dokumentation einen Ersatz auf Basis von setTimeout oder ein fertiges Polyfill Paket. Außerdem schreibt sie klar, dass sie den Ansatz mit isInputPending() nicht mehr empfiehlt. Ein Satz aus dem Leitfaden hilft im Alltag besonders: Wahllos freizugeben ist besser, als gar nicht freizugeben. Warten Sie also nicht auf das perfekte Timing; schon das Aufteilen einer langen Schleife bringt etwas.

Wie machen Sie Event Handler leichter?

Ist die Verarbeitungsdauer lang, liegt das Problem im Code des angeklickten Elements. Die Empfehlung von web.dev ist eindeutig: Erledigen Sie zuerst die sichtbare Änderung und verschieben Sie den Rest. Nutzer sollen sofort sehen, dass der Klick funktioniert hat.

Denken Sie zum Beispiel an einen Favoritenbutton. Idealerweise füllt sich das Herz sofort. Die Speicheranfrage an den Server, das Analyseereignis und die Aktualisierung einer Empfehlungsliste können einige hundert Millisekunden später laufen. Der Leitfaden beschreibt dafür ein setTimeout innerhalb eines requestAnimationFrame Callbacks. Dadurch zeichnet der Browser die sichtbare Änderung im nächsten Frame, und die schwere Arbeit folgt danach.

• Entfernen Sie überflüssige Handler am selben Ereignis.
• Lassen Sie Suchfelder, die bei jedem Tastendruck suchen, erst nach einer kurzen Pause anfragen.
• Aktualisieren Sie beim Klick nur den geänderten Bereich, nicht den Zustand der ganzen Seite.
• Verlagern Sie schwere Berechnungen nach Möglichkeit in einen Web Worker.

Dadurch sinkt die Verarbeitungsdauer, und Nutzer erhalten eine Rückmeldung. Zudem lassen diese Änderungen das Design meist unberührt.

Wie beeinflusst schweres JavaScript den Versuch, INP zu verbessern?

Schweres JavaScript ist das häufigste Hindernis, wenn wir INP verbessern. Je größer das Bundle, desto länger braucht der Browser im Hauptthread zum Parsen, Kompilieren und Ausführen. Jeder Klick in dieser Zeit muss warten.

Im Audit suchen wir zunächst nach ungenutztem Code. Die Coverageansicht in den Entwicklertools zeigt Code, der beim Start lädt, aber nie läuft. Danach suchen wir nach Möglichkeiten, Bundles pro Seite aufzuteilen. Der Code für den Checkout muss zum Beispiel nicht auf der Startseite laden.

Andererseits ist es ebenfalls riskant, große Mengen HTML im Client zu erzeugen. Der Leitfaden auf web.dev warnt, dass viel per JavaScript gerendertes HTML die Darstellungsverzögerung erhöhen kann. Inhalte, die der Server vorbereiten kann, sollten Sie daher nicht dem Browser überlassen. Das hilft beim Laden und bei der Interaktion. Den größeren Zusammenhang zwischen Tempo und Rankings beschreibt unser Beitrag wie die Ladezeit SEO beeinflusst.

Wie bremsen Drittanbieterskripte Interaktionen aus?

Werkzeuge für Analyse, Werbung, Chatfenster, Heatmaps und Cookiehinweise bringen Code auf die Seite, den Sie nicht geschrieben haben. Diese Skripte teilen sich denselben Hauptthread. Folglich kann ein Drittanbieterskript im Moment eines Klicks eine lange Aufgabe starten, selbst wenn Ihr eigener Code schlank ist.

Wir betrachten das Thema hier nur aus Sicht von INP. Unsere praktische Checkliste sieht so aus:

1. Listen Sie alle Tags im Tag Manager auf und entfernen Sie ungenutzte.
2. Entscheiden Sie, auf welchen Seiten jeder Tag wirklich nötig ist.
3. Laden Sie Werkzeuge wie Chatfenster erst nach der ersten Nutzerinteraktion.
4. Messen Sie in einer Performanceaufnahme, wie viel Arbeit Klicklistener bei jedem Klick erzeugen.
5. Prüfen Sie bei Skripten, die bleiben müssen, ob der Anbieter eine leichtere Ladeoption hat.

Allerdings ist es keine Lösung, das Conversiontracking abzuschalten. Es geht nicht darum, auf Messung zu verzichten. Stattdessen soll die Messung Nutzer nicht warten lassen. Für diese Balance müssen Marketing und Entwicklung an einem Tisch sitzen.

Wie reduzieren Sie die Darstellungsverzögerung?

Die Darstellungsverzögerung ist die Zeit, die der Browser nach dem Ende Ihres Codes für den nächsten Frame braucht. Er berechnet Stile, ermittelt das Layout und malt den Bildschirm. Eine komplexere Seite bedeutet eine längere Wartezeit.

Der Leitfaden auf web.dev gibt für diese Phase zwei zentrale Tipps. Erstens: Halten Sie das DOM klein. Zweitens: Nutzen Sie eine CSS Eigenschaft, mit der der Browser Elemente außerhalb des sichtbaren Bereichs erst später rendert. Dann kümmert sich der Browser nur um den sichtbaren Teil.

Zum Beispiel können Sie sich in einer langen Produktliste auf die sichtbaren Karten konzentrieren, statt Hunderte auf einmal zu zeichnen. Außerdem erhöhen Animationen über große Flächen sowie schwere Schatten und Unschärfeeffekte die Malkosten. Designentscheidungen beeinflussen also ebenfalls den INP. Deshalb teilen wir Performancebefunde auch mit dem Designteam, wenn wir für Kunden INP verbessern.

Warum zählen DOM Größe und Layout Thrashing?

Layout Thrashing entsteht, wenn Code den Stil eines Elements ändert und direkt danach in derselben Aufgabe dessen Größe oder Position ausliest. Dann muss der Browser das Layout sofort neu berechnen. Der Leitfaden auf web.dev nennt das erzwungenes synchrones Layout und rät davon ab.

Meist zeigt sich das Problem in einer Schleife. Code, der etwa für jede Karte erst eine Höhe liest und dann eine neue Höhe schreibt, erzwingt bei jedem Schritt ein frisches Layout. Fassen Sie dagegen alle Lesezugriffe und alle Schreibzugriffe zusammen, braucht der Browser nur eine Berechnung.

Ein großer DOM Baum erhöht zudem die Kosten jeder Stiländerung. Menüs, versteckte Tabs und ungenutzte Modalfenster sammeln überflüssige Knoten an. Schauen Sie beim Aufräumen daher nicht nur auf sichtbare Inhalte, sondern auch auf versteckte Strukturen. Kurz gesagt: Eine schlankere Seite zeichnet schneller und bringt weniger Überraschungen.

Wie können Sie INP verbessern, wenn Ihre Website ein fertiges Theme nutzt?

Auf Websites mit fertigen Themes und Pagebuildern läuft die Arbeit, um INP zu verbessern, etwas anders. Ein großer Teil des problematischen Codes gehört nicht Ihnen; er stammt aus dem Theme, einem Plugin oder dem Pagebuilder. Statt Code Zeile für Zeile neu zu schreiben, erstellen Sie deshalb zuerst ein Inventar.

Wir gehen in dieser Reihenfolge vor. Zunächst listen wir die aktiven Plugins auf und prüfen, auf welchen Seiten jedes davon Skripte lädt. Danach testen wir interaktive Komponenten wie Slider, Tabs und Popups in einer Performanceaufnahme. Dann entfernen wir unnötige Komponenten und laden die übrigen nur dort, wo sie gebraucht werden.

Außerdem helfen Cache und Minifizierungsplugins oft bei Ladekennzahlen, lösen INP aber selten allein. INP hängt nicht davon ab, wie schnell Code herunterlädt. Stattdessen zählt, wie viel Arbeit der Code im Moment eines Klicks verrichtet. Installieren Sie also kein Plugin in der Annahme, das Problem sei damit erledigt; bestätigen Sie das Ergebnis immer mit Felddaten.

Wie sieht ein Schritt für Schritt Plan aus, um INP zu verbessern?

Unseren in der Praxis erprobten Plan haben wir in einer Liste zusammengefasst. Die Reihenfolge zählt, denn jeder Schritt grenzt das Ziel des nächsten ein.

1. Ermitteln Sie im Core Web Vitals Bericht der Search Console die mobilen URL Gruppen mit INP Problemen.
2. Wählen Sie aus jeder Gruppe Beispieladressen und ordnen Sie sie nach Trafficwert.
3. Listen Sie die häufigen Interaktionen auf diesen Seiten auf: Menü, Filter, Formulare, Warenkorb.
4. Stellen Sie diese Interaktionen in einer Performanceaufnahme mit gedrosselter CPU nach.
5. Notieren Sie für jede langsame Interaktion den Anteil von Eingabeverzögerung, Verarbeitungsdauer und Darstellungsverzögerung.
6. Teilen Sie lange Aufgaben und ziehen Sie die sichtbare Änderung in den Event Handlern nach vorn.
7. Entfernen oder verzögern Sie Drittanbieterskripte, die Sie nicht brauchen.
8. Verkleinern Sie das DOM und beheben Sie Code, der Layout Thrashing verursacht.
9. Bringen Sie die Änderungen live und starten Sie die Validierung im Bericht.
10. Beobachten Sie die Felddaten in den folgenden 28 Tagen und dokumentieren Sie Rückschritte.

Möchten Sie diesen Plan von einem Team umsetzen lassen, übernehmen wir in unserer SEO Beratung das technische Audit, die Aufgabenliste für Ihre Entwickler und die anschließende Nachverfolgung. So bleibt die Korrektur kein einmaliges Ereignis.

Wie validieren Sie die Korrektur in der Search Console?

Nach dem Livegang starten Sie die Validierung in der passenden Problemzeile des Berichts. Laut der Hilfe zur Search Console beginnt mit einem Klick auf Start Tracking ein Beobachtungszeitraum von 28 Tagen. Taucht das Problem in dieser Zeit bei keiner URL auf, gilt es als behoben.

Zu den Validierungsstatus gehören Started, Passed und Failed. Ein fehlgeschlagenes Ergebnis bedeutet, dass das Problem bei einigen Adressen weiter besteht. Gehen Sie dann zu den Beispieladressen zurück und testen Sie erneut, welche Interaktion noch langsam ist.

Setzen Sie außerdem realistische Erwartungen. Da die Daten die letzten 28 Tage abbilden, zeigt sich die Verbesserung schrittweise. In den ersten Tagen wirken ältere Besuche noch nach. Machen Sie also eine Korrektur nicht rückgängig, nur weil sich nach einer Woche nichts verändert hat. Beobachten Sie geduldig, bis die im Labor bestätigte Verbesserung auch im Feld ankommt.

Garantiert ein guter INP bessere Rankings?

Nein. Die Seite zu Core Web Vitals in Google Search Central empfiehlt Websitebetreibern ausdrücklich gute Core Web Vitals. Sie schreibt, dass dies zusammen mit weiteren Aspekten der Nutzererfahrung dem entspricht, was die Rankingsysteme belohnen wollen. Trotzdem ist die Nutzererfahrung nur eines von vielen Signalen.

Das heißt: Sind Inhaltsqualität, Passung zur Suchintention und Vertrauenssignale schwach, steigt eine schnelle Seite nicht von allein nach oben. Andererseits ist von zwei gleich guten Seiten diejenige klar besser für Besucher, die niemanden warten lässt. Deshalb empfehlen wir INP Arbeit wegen der Nutzererfahrung und der Conversiongesundheit, nicht als Rankingversprechen.

Wo Geschwindigkeit im technischen SEO insgesamt steht, zeigen unsere Tipps zum technischen SEO. Für die Ladeseite lesen Sie unseren LCP Leitfaden; dieses Thema wiederholen wir hier nicht.

Wann sollten Sie für diese Arbeit ein Team hinzuziehen?

Externe Unterstützung lohnt sich, wenn ein Plugin das INP Problem nicht löst, wenn es sich über mehrere Vorlagen zieht oder wenn Ihre Entwickler nicht wissen, was sie beheben sollen. Gerade in Onlineshops kann eine Verzögerung bei Filtern, Warenkorb und Checkout verlorene Nutzer bedeuten.

Wir erledigen in dieser Arbeit drei Dinge. Zunächst erstellen wir aus Felddaten eine Prioritätenliste. Danach schreiben wir für jede langsame Interaktion eine konkrete Aufgabe, mit der Ihr Entwickler arbeiten kann. Schließlich begleiten wir die Änderungen durch den Validierungszeitraum und melden Rückschritte. Ein neues Plugin, ein Kampagnentag oder ein Themeupdate kann INP erneut verschlechtern. Daher empfehlen wir eine monatliche Kontrolle statt einer einmaligen Korrektur, damit Sie Probleme erkennen, bevor Nutzer sie bemerken.

Rankings versprechen wir nicht, allerdings verfolgen wir das Problem messbar. Wenn Sie INP auf Ihrer Website lösen und regelmäßig im Blick behalten möchten, fordern Sie auf unserer Seite zur SEO Beratung ein Angebot an. Wir klären dann den Umfang anhand Ihrer Websitestruktur und schicken Ihnen einen passenden Arbeitsplan. Im Angebot steht, welche Vorlagen wir prüfen, welche Aufgabenliste Ihr Entwickler erhält und wie wir die Nachverfolgung berichten.

Grundlagen: Was ist Online Marketing? Arten, Beispiele und Vorgehen auf einer Seite, mit einem interaktiven Film durch das Gehirn.