INP Bestraft Schwere Analytics: Warum Dein Tracker im Main Thread Läuft
Interaction to Next Paint ist der Core Web Vital, an dem die meisten Seiten scheitern, und Felddaten zeigen, dass Verhaltens-Tracking-Skripte eine Hauptursache sind. Die Lösung: weniger Arbeit an den Main Thread schicken.
Interaction to Next Paint (INP) ist der Core Web Vital, an dem Entwickler am häufigsten scheitern, und die Ursache steckt in deinem <head>. INP wurde 2024 zu einem stabilen Core Web Vital und ersetzte First Input Delay. Es misst etwas, das FID nie konnte: wie reaktionsschnell eine Seite über jeden Klick, Tap und Tastendruck während ihrer gesamten Lebensdauer bleibt.
Die Metrik ist gnadenlos gegenüber der Art von JavaScript, die Überwachungs-Analytics ausliefert. Wenn dein Tracker nennenswerte Arbeit im Main Thread erledigt, erbt jede Interaktion deiner Nutzer diese Kosten.
Was INP Tatsächlich Misst
INP meldet die Latenz von Interaktionen am 75. Perzentil aller Klicks, Taps und Tastendrücke auf einer Seite. Ein Wert von 200 ms oder weniger ist "gut"; 200–500 ms "verbesserungsbedürftig"; über 500 ms "schlecht".
Jede Interaktion zerfällt in drei Phasen:
- Input Delay — die Zeit, bis deine Event-Handler überhaupt starten können, weil der Main Thread beschäftigt ist.
- Processing Duration — die Zeit, die die Callbacks deiner Event-Handler zur Ausführung brauchen.
- Presentation Delay — die Zeit vom Ende des Callbacks bis der Browser den nächsten Frame zeichnet.
Schwere Analytics schadet allen drei Phasen. Ein Tracker, der ein großes Bundle parst, Consent-Logik auswertet, eine Tag-Manager-Queue bündelt oder das Layout ausliest, um einen Fingerprint zu erstellen, belegt den Main Thread genau dann, wenn ein Nutzer interagieren will.
Long Tasks Sind der Mechanismus
Der Browser kann eine Interaktion nicht verarbeiten, während eine Task läuft. Jede Task, die länger als 50 ms dauert, ist ein Long Task, und der Anteil über 50 ms ist tote Zeit, in der sich Klicks in der Queue stauen.
Ein Tag Manager, der synchron ein Dutzend Vendor-Skripte lädt und ausführt, erzeugt eine Kaskade von Long Tasks. Der Nutzer klickt, nichts passiert, er klickt erneut — und wenn der Main Thread endlich frei wird, feuern die aufgestauten Eingaben alle auf einmal.
Das ist nicht theoretisch. Das Web Almanac 2024 des HTTP Archive ergab, dass Seiten mit Verhaltens-Tracking-Skripten — Session Replay, Heatmaps, Verhaltensanalyse — nur in 37 % der Fälle auf Mobilgeräten ein gutes INP erreichten, gegenüber 60 % auf Desktop. Consent-Management-Skripte, die Banner, die diese Tools verlangen, bestanden das INP auf nur 53 % der mobilen Seiten. Die Instrumentierung, die "Nutzer verstehen" soll, verschlechtert aktiv deren Erlebnis.
Die Architektur, Die Das Vermeidet
Die Lösung ist strukturell, kein Schalter, den du umlegst. Liefere weniger Code aus und halte ihn vom kritischen Pfad fern.
Ein Privacy-First-Tracker kann klein genug sein, sodass sein Parsen und Ausführen nie als Long Task registriert wird. Der Tracker von Monoid ist rund 2 KB groß, hat keine Abhängigkeiten, setzt keine Cookies und liest kein Layout — es gibt also nichts zu fingerprinten und nichts Schweres auszuführen. Er erfasst einen Pageview mit einem einzigen keepalive-Request und bleibt ansonsten untätig:
fetch('/collect', {
method: 'POST',
keepalive: true,
body: JSON.stringify({ site_id, path: location.pathname })
})
keepalive: true lässt den Request die Seite überleben, ohne den Main Thread festzuhalten, sodass Navigation und Unload nie blockiert auf ein Beacon warten.
Wenn du eigene Skripte ausführst, gib den Main Thread zwischen Arbeitsblöcken frei, damit aufgestaute Interaktionen laufen können:
async function processQueue(items) {
for (const item of items) {
handle(item)
if (navigator.scheduling?.isInputPending?.()) {
await scheduler.yield()
}
}
}
scheduler.yield() zerlegt einen Long Task in Stücke und setzt mit Priorität fort, sodass ein Drittanbieter-Skript sich nicht vor deiner Fortsetzung in die Queue drängen kann.
Miss Es im Feld, Nicht im Labor
Lighthouse kann INP nicht melden, weil INP erst existiert, sobald eine echte Person interagiert. Laborwerkzeuge schätzen; sie messen keine Reaktionsschnelligkeit.
Nutze Felddaten. Der Chrome User Experience Report (CrUX) aggregiert echte Interaktionen von Chrome-Nutzern, die zugestimmt haben, und der Core-Web-Vitals-Bericht der Search Console zeigt dieselben Daten pro URL-Gruppe. Ist dein CrUX-INP gut, aber deine Labor-Total-Blocking-Time hoch, hast du Spielraum; ist das CrUX-INP schlecht, spüren deine Nutzer es bereits.
Das Datenschutz- und das Performance-Argument laufen hier zusammen. Ein Tracker, der keinen Speicher liest, keinen Fingerprint baut und keine Vendor-Kaskade ausliefert, hat im Main Thread fast nichts zu tun — und genau deshalb taucht er nie in deinem INP auf. Überwachung ist teuer in Millisekunden, nicht nur an Vertrauen.
Comments
Loading comments…