Schlechter INP durch Drittanbieter: Mit einer belastbaren Messung beginnen

Ein Chat-Widget, ein Werbeskript oder eine zusätzliche Analysebibliothek taucht bei langsamen Seiteninteraktionen auf. Das ist ein Anlass zur Untersuchung. Es beweist noch nicht, dass dieser Dienst den schlechten INP verursacht oder dass seine Entfernung das Problem zuverlässig beheben würde.

Für einen belastbaren Befund brauchst du eine Verbindung zwischen der betroffenen Interaktion und der Arbeit, die ihre sichtbare Reaktion verzögert. Anschließend prüfst du eine gezielte Änderung unter vergleichbaren Bedingungen. Der Ablauf beginnt bei echten Nutzerproblemen und endet bei einer überprüften Verbesserung mit funktionierender Anwendung.

Dieser Leitfaden enthält einen hypothetischen Testplan. Er berichtet keine Messresultate von Crawl Foundry oder einem Kunden und verspricht keinen Rankinggewinn durch einen einzelnen Performance-Fix.

Zuerst die Interaktion benennen

Interaction to Next Paint beschreibt die Reaktionsfähigkeit einer Seite bei qualifizierenden Klicks, Berührungen und Tastatureingaben. Gemessen wird die Verzögerung bis zur nächsten möglichen visuellen Reaktion. Die vollständige Dauer einer späteren Netzwerkanfrage ist damit nicht automatisch gemeint. Die INP-Definition auf web.dev erläutert diesen Umfang.

„Der Shop ist langsam“ reicht deshalb als Fehlerbeschreibung nicht aus. Notiere zum Beispiel: Der erste Klick auf den Produktfilter reagiert auf bestimmten Mobilgeräten verzögert, besonders kurz nach dem Laden. Das benennt eine Handlung und Bedingungen, die sich im Labor nachstellen lassen.

Für die Einordnung der Core Web Vitals zählt die Verteilung realer Seitenbesuche. Die Bewertung betrachtet das 75. Perzentil, getrennt nach Mobilgeräten und Desktop. Ein einzelner lokal gemessener Klick ist kein Ersatz für diese Verteilung. Ebenso lässt sich aus einem schlechten Seitenwert nicht unmittelbar ein verantwortlicher Anbieter ablesen.

Felddaten zeigen, wo die Suche beginnt

CrUX-Daten in PageSpeed Insights können zeigen, ob für eine URL oder den gesamten Ursprung ein INP-Problem beobachtet wird. Prüfe genau, welcher Umfang angezeigt wird. Ein Origin-Wert umfasst einen anderen Seitenbestand als der Wert einer einzelnen Produktseite.

Für die Ursachenanalyse fehlen in solchen Aggregaten oft die Details der konkreten Handlung. Eigene Real-User-Monitoring-Daten können diese ergänzen, sofern die Messung entsprechenden Kontext liefert. Die Anleitung zum Finden langsamer Interaktionen im Feld beschreibt unter anderem den Attribution-Build der Bibliothek web-vitals.

Erfasse für die Untersuchung eine begrenzte Auswahl nützlicher Merkmale: Seitentyp, Release, Gerät oder Browsergruppe, Zeitpunkt im Seitenbesuch und betroffene Interaktion. Eine beschreibende Kennung wie „Produktfilter öffnen“ ist meist hilfreicher als der vollständige Text einer persönlichen Formulareingabe. Halte auch Stichproben und nicht erfasste Besuche fest.

Teile die Daten nicht so fein auf, dass jede Gruppe nur noch einzelne Beobachtungen enthält. Eine scheinbar präzise Zuordnung auf Basis eines einzigen langsamen Klicks ist ein schwacher Ausgangspunkt. Suche nach einem wiederkehrenden Muster, das für das Produkt tatsächlich relevant ist.

Die Verzögerung in ihre Teile zerlegen

Die web.dev-Anleitung zur INP-Optimierung unterscheidet Eingabeverzögerung, Verarbeitung und Darstellungsverzögerung. Diese Teile helfen, den nächsten Prüfschritt zu wählen.

Ein externes Skript kann vor dem Klick laufen und dessen Verarbeitung verzögern. Es muss dafür nicht selbst den angeklickten Button verwalten. Umgekehrt kann der eigene Handler eine Bibliothek aufrufen, die zusätzliche Arbeit auslöst. Der sichtbare Button und der verantwortliche Code sind daher nicht zwangsläufig dasselbe.

Auch eine hohe Skript-Downloadzeit beantwortet diese Fragen noch nicht. Sie beschreibt einen Netzwerkvorgang. Für den INP-Verdacht musst du die Ausführung oder ihre Auswirkungen im zeitlichen Zusammenhang mit der Interaktion untersuchen.

Long Animation Frames liefern Hinweise, kein Schuldspruch

Die Long Animation Frames API, kurz LoAF, erfasst Frames über 50 Millisekunden und kann zusätzliche Skriptinformationen liefern. Mehrere kürzere Aufgaben können zusammen einen langen Frame bilden, selbst wenn keine einzelne Aufgabe als Long Task erscheint. Die Chrome-Dokumentation zur LoAF-API erklärt, wie sich diese Einträge mit betroffenen INP-Interaktionen verbinden lassen.

Entscheidend ist diese Verbindung. Ein langer Frame irgendwo im Seitenbesuch muss nicht die von dir untersuchte Interaktion verzögert haben. Vergleiche die Zeitbereiche oder nutze eine geeignete Attributionsbibliothek, die zugehörige Einträge bereitstellt. Die Anzahl sämtlicher langer Frames ist keine direkte Umrechnung in einen INP-Wert.

Skriptangaben können eine Quell-URL und den Einstiegspunkt zeigen. Dieser Einstiegspunkt ist jedoch nicht automatisch die teuerste Funktion innerhalb der gesamten Aufrufkette. Ein eigener Event-Handler kann beispielsweise eine andere Bibliothek aufrufen. Ebenso ist der Host einer Datei nicht immer identisch mit der organisatorischen Zuständigkeit für den enthaltenen Code.

Lege deshalb eine nachvollziehbare Zuordnung an: beobachtete Ressource, Einbindung im Shop, verantwortliches Team oder Anbieter und betroffene Funktion. Die Liste soll einen Kandidaten überprüfbar machen. Sie darf nicht aus jedem sichtbaren fremden Host automatisch einen verursachenden Drittanbieter machen.

Was die Messung nicht sehen kann

Prüfe die Unterstützung im tatsächlich verwendeten Browser, bevor du LoAF-Daten erwartest. Ein einfacher lokaler Check lautet:

javascriptconst supportsLoAF = typeof PerformanceObserver !== 'undefined' &&
  PerformanceObserver.supportedEntryTypes.includes('long-animation-frame')

console.log({ supportsLoAF })

Das Ergebnis prüft nur die Verfügbarkeit des Eintragstyps. Es führt keine vollständige INP-Messung durch. Die Chrome-Dokumentation beschreibt die Auslieferung der API ab Chrome 123. Daraus folgt keine Unterstützung aller Browser und aller zusätzlichen Felder. Protokolliere verfügbare Funktionen und Messlücken getrennt.

Bei eingebetteten iframes kommt eine weitere Grenze hinzu. Das reale Seitenerlebnis kann Interaktionen im eingebetteten Inhalt einschließen, während eine JavaScript-Messung im Hauptdokument diese nicht vollständig erfasst. Gerade fremde Origins schränken den Einblick ein. Dadurch können CrUX und eigenes RUM voneinander abweichen.

Der W3C-Arbeitsentwurf zur LoAF-API beschreibt außerdem Grenzen der Quellinformationen bei abgeschirmten Skripten und Origin-Übergängen. Behandle ihn als weiterentwickelte Spezifikationsarbeit, nicht als Zusicherung, dass jedes darin genannte Feld bereits im eingesetzten Browser verfügbar ist.

Ein leerer Attributionswert bedeutet daher nicht „kein Drittanbieter beteiligt“. Er bedeutet zunächst, dass die gewählte Messung an dieser Stelle keine entsprechende Information liefert. Prüfe diese Grenze, bevor ein Dashboard fehlende Angaben als null Aufwand ausgibt.

Den Kandidaten im Labor eingrenzen

Stelle nun die beobachtete Handlung nach. Die Performance-Referenz der Chrome DevTools beschreibt Aufzeichnungen während tatsächlicher Interaktionen. Ein reiner Seitenladetest kann den späteren Klick auf Filter, Warenkorb oder Chat verpassen.

Bewahre Browser- und Gerätekonfiguration, Netzwerkbedingungen, Sitzungszustand und Release auf. Wiederhole dieselbe Handlung in einer frischen Sitzung und nach einer bereits geladenen Seite. Erscheint das Problem nur kurz nach dem Start, muss der Vergleich genau dieses Zeitfenster berücksichtigen.

Im Trace suchst du den relevanten Interaktionsbereich. Prüfe, welche Aufgaben davor und danach die nächste Darstellung verzögern. Bei JavaScript-Rendering gehören auch Layout und Darstellung zum Ablauf. Ein langer eigener Handler bleibt ein Kandidat, selbst wenn gleichzeitig ein externer Dienst geladen wird.

Lokales Blockieren einer Ressource kann die Hypothese eingrenzen. Es beweist aber nicht, dass eine produktive Entfernung dieselbe Wirkung hätte. Der Test kann zugleich weitere Funktionen, Aufrufwege oder den Inhalt der Seite verändern. Diese Unterschiede musst du im Vergleich sichtbar halten.

Aus dem Befund den nächsten Schritt ableiten

Beginnt die Verzögerung schon vor dem Handler, untersuchst du zuerst die Arbeit in diesem Zeitfenster. Ein Umbau des Buttons löst eine unabhängig laufende Initialisierung möglicherweise nicht. Liegt die lange Phase dagegen im Handler, folgst du dessen Aufrufkette. Bei einer späten Darstellung prüfst du auch, ob die Interaktion große Teile der Oberfläche neu berechnen lässt.

Wiederholt sich der vermutete Zusammenhang nicht, erweitere zunächst die Beobachtung um den fehlenden Kontext. Vielleicht wurde der Klick im Labor erst nach vollständiger Initialisierung ausgeführt. Vielleicht tritt die Situation nur mit einer bestimmten Einwilligung oder einem bereits geöffneten Widget auf. Ohne diese Bedingung misst der Vergleich einen anderen Bedienweg.

Fehlt wegen einer Origin-Grenze die Zuordnung, lautet die nächste Aufgabe zunächst Instrumentierung oder Abstimmung mit dem Anbieter. Schreibe keinen vermeintlich präzisen Performance-Fix auf Grundlage eines leeren Feldes. Der Arbeitsauftrag sollte festhalten, welche Information fehlt und mit welchem zusätzlichen Beleg sich die Hypothese prüfen ließe. So kann auch eine noch offene Untersuchung einen brauchbaren nächsten Schritt liefern.

Ein hypothetischer, kontrollierter Testplan

Angenommen, das Team vermutet die Initialisierung eines Chat-Widgets als Mitursache beim ersten Filterklick. Der folgende Plan ist nicht ausgeführt worden. Er soll zeigen, welche Belege eine solche Behauptung tragen müssten.

Zunächst wird die bisherige Fassung in einer geeigneten Testumgebung mit den definierten Interaktionsfällen aufgezeichnet. Danach verändert das Team nur den untersuchten Einbindungsschritt, etwa den Zeitpunkt der Widget-Initialisierung. Es hält die übrige Anwendung und den Inhalt so weit wie möglich gleich.

Vergleiche mehrere Durchläufe und ihre Streuung. Prüfe Funktionsfähigkeit und Fehlerzustände zusätzlich zur Reaktionszeit. Ein verschwundenes Widget kann schneller aussehen, beantwortet aber nicht die ursprüngliche Produktanforderung.

Consent-, Zahlungs- oder andere notwendige Funktionen werden nicht pauschal auf der Produktionsseite abgeschaltet. Wähle eine freigegebene Testkonfiguration mit klarer Zuständigkeit und Rückweg. Ein vorhandener Supportvertrag oder eine technische Empfehlung ist noch kein Ersatz für die Abnahme der eigenen Anwendung.

Erst den Mechanismus prüfen, dann den Feldeffekt

Wiederholt sich die Verbesserung nur im kontrollierten Test, ist zunächst dieser Ablauf belegt. Für eine Aussage über reale Nutzer muss die freigegebene Änderung anschließend in vergleichbaren Felddaten beobachtet werden. Halte den Ausrollzeitpunkt und die betroffenen Varianten fest.

Vergleiche passende Gruppen und Zeiträume. Ein anderer Anteil mobiler Geräte, kürzere Besuche oder weniger Nutzung des betroffenen Elements kann den Gesamtwert verändern. Auch die Messung selbst darf zwischen den Fassungen nicht unbemerkt wechseln. Fehlende Messwerte sind keine automatisch verbesserten Werte.

Für Page Speed ist ein schöner Gesamtwert deshalb nur ein Teil der Bewertung. Dokumentiere, welche konkrete Bedienung besser reagiert und welche Funktion dabei erhalten bleibt. Die technische Performance-Analyse muss diese Unterschiede sichtbar machen.

Im Site Audit von Crawl Foundry kannst du den untersuchten URL-Umfang in den technischen Arbeitsablauf einordnen. Ergänze für den INP-Befund die passenden Interaktions- und RUM-Belege. Unser Beitrag zur Priorisierung von Audit-Befunden hilft bei der Übergabe einer begründeten Aufgabe. Nach einem größeren technischen Umbau gehört auch die Prüfung des Relaunchs dazu.

Ein belastbarer Abschluss benennt die Interaktion, den beobachteten Verzögerungsanteil, die geänderte Einbindung und die Grenzen der Messung. Ob der Drittanbieter insgesamt entfallen sollte, ist eine weitere Produktentscheidung. Die technische Arbeit liefert dafür einen überprüften Zusammenhang anstelle einer Vermutung aufgrund eines fremden Skriptnamens.