Ein Klick, der spürbar hängt, ein Menü, das erst nach einer Gedenksekunde aufklappt, ein Formular, das beim Tippen stockt -- solche Momente misst das Core Web Vital INP, die Interaction to Next Paint. Es erfasst, wie lange eine Seite braucht, um auf eine Eingabe sichtbar zu reagieren, und löste im Frühjahr 2024 den älteren First Input Delay als eines der drei zentralen Nutzererlebnis-Signale ab (web.dev). Das Problem: Ein schlechter INP-Wert sagt, dass es hakt, aber nicht, welches Skript den Frame blockiert. Genau diese Lücke schließt die Long-Animation-Frames-API, kurz LoAF. Seit Chrome 123 ausgeliefert, benennt sie den langen Frame hinter einer trägen Interaktion samt der Skripte, die ihn verursacht haben -- mit Dateiname, Dauer und aufrufender Funktion (Chrome for Developers). Zusammen mit der quelloffenen web-vitals-Bibliothek in Version 4 lässt sich diese Frame-Analyse direkt an die langsamste gemessene Interaktion hängen. Dieser Beitrag zeigt, wie aus einem anonymen INP-Wert eine konkrete Datei wird, an der man ansetzen kann -- der 2026 entscheidende Diagnoseschritt, weil INP das am häufigsten verfehlte der drei Core Web Vitals ist. In unserer Core-Web-Vitals-Optimierung steht diese Attribution am Anfang, bevor wir eine einzige Zeile JavaScript anfassen.
Warum INP so schwer zu fassen ist
Von den drei Core Web Vitals ist INP dasjenige, an dem die meisten Seiten scheitern. Während Ladezeit und visuelle Stabilität auf vielen Websites im grünen Bereich liegen, verfehlen rund 23 Prozent (Web Almanac 2025) der Sites die INP-Schwelle von 200 Millisekunden am 75. Perzentil. Ein INP gilt als gut, wenn die nahezu langsamste Interaktion einer Sitzung innerhalb von 200 ms sichtbar beantwortet wird; zwischen 200 und 500 ms spricht die Skala von Verbesserungsbedarf, darüber von schlecht (web.dev). Gemessen wird also nicht der Durchschnitt, sondern der Ausreißer -- die eine hakelige Interaktion, die dem Nutzer im Gedächtnis bleibt. Was INP genau misst und welche Grundhebel es gibt, fasst unser Leitfaden zur INP-Optimierung zusammen.
Der Grund für die Sperrigkeit liegt in der Natur der Metrik. INP entsteht nicht beim Laden, sondern während der Nutzung -- bei jedem Klick, Tippen oder Tastendruck über die gesamte Verweildauer hinweg (web.dev). Es hängt von der Menge und Verteilung des JavaScripts ab, von Event-Handlern, von eingebetteten Drittanbieter-Skripten und davon, wie stark der Hauptthread des Browsers ausgelastet ist. Anders als beim Largest Contentful Paint, den wir in der Subpart-Analyse in vier Phasen zerlegen, lässt sich INP nicht an einer einzelnen Ressource festmachen. Die Ursache kann in jedem der vielen Skripte stecken, die während einer Interaktion laufen -- und lange fehlte ein Werkzeug, das sie eindeutig benennt.
Die drei Phasen einer Interaktion
Jede Interaktion, die INP misst, zerfällt in drei aufeinanderfolgende Phasen -- ähnlich wie das LCP in seine Subparts. Zuerst die Eingabeverzögerung: die Zeit vom Antippen bis der zugehörige Event-Handler tatsächlich startet. Sie ist oft groß, wenn der Hauptthread noch mit einer anderen Aufgabe beschäftigt ist. Dann die Verarbeitungszeit: die Dauer, in der die Event-Handler laufen und ihre Arbeit erledigen. Schließlich die Darstellungsverzögerung: die Zeit, bis der Browser das Ergebnis als nächsten Frame auf den Bildschirm zeichnet (web.dev). Zusammengezählt ergeben die drei Phasen die Latenz, die INP für diese Interaktion festhält.
Für die Diagnose ist entscheidend, in welcher Phase die Zeit verloren geht. Eine hohe Eingabeverzögerung deutet auf einen überlasteten Hauptthread hin -- häufig durch Skripte, die zur Interaktionszeit noch abgearbeitet werden, etwa spät geladene Drittanbieter-Skripte, die die Seite ausbremsen. Eine hohe Verarbeitungszeit zeigt schwere Event-Handler, die zu viel auf einmal tun. Eine hohe Darstellungsverzögerung verweist auf teure Layout- oder Renderarbeit nach dem Handler. Die Long-Animation-Frames-API setzt genau dort an, wo die meiste Zeit vergeht: bei den Skripten, die den Frame lang machen.
Eingabeverzögerung
Die Zeit vom Antippen bis der Event-Handler startet. Ist sie hoch, blockiert eine andere Aufgabe den Hauptthread -- die Reaktion beginnt verspätet.
Verarbeitungszeit
Die Dauer, in der die Event-Handler laufen. Schwere Handler, die zu viel auf einmal erledigen, treiben diese Phase in die Höhe.
Darstellungsverzögerung
Die Zeit, bis der nächste Frame gezeichnet ist. Teure Layout- und Renderarbeit nach dem Handler verlängert sie spürbar.
Was ein Long Animation Frame ist
Ein Long Animation Frame ist ein Renderzyklus des Browsers, der länger als 50 Millisekunden gedauert hat (Chrome for Developers). Der Browser versucht, in kurzen Abständen ein neues Bild zu zeichnen; braucht ein Frame deutlich länger, ruckelt die Oberfläche und Interaktionen reagieren träge. Die Long-Animation-Frames-API meldet jeden solchen langen Frame als Eintrag mit einer Reihe von Zeitmarken: dem Startzeitpunkt, der Gesamtdauer, dem Beginn der Render- und Layoutphase und -- am wichtigsten -- einer blockierenden Dauer, die angibt, wie lange der Hauptthread in diesem Frame für andere Arbeit blockiert war (Chrome for Developers).
Der eigentliche Fortschritt steckt aber im Feld scripts: Für jeden langen Frame liefert die API eine Liste der Skripte, die zu seiner Länge beigetragen haben -- jeweils mit Quell-URL, Dauer, aufrufender Funktion und der Art des Aufrufs, etwa ein Event-Handler oder ein Timer (Chrome for Developers). Erstmals lässt sich damit von außen, ohne aufwendiges Profiling, sagen: Dieser Frame war lang, und diese konkrete Datei ist dafür verantwortlich. Die API erfasst zudem, ob im Frame eine Nutzerinteraktion stattfand -- so verbindet sie den langen Frame mit genau der Reaktion, die der Besucher als hakelig erlebt hat.
Was die LoAF-API pro langem Frame liefert
Warum die alte Long-Tasks-API nicht reichte
Ein Werkzeug für lange Aufgaben gab es schon vorher: die Long-Tasks-API. Auch sie meldet jede Aufgabe auf dem Hauptthread, die länger als 50 Millisekunden dauert (MDN Web Docs). Doch sie hatte eine entscheidende Schwäche bei der Ursachensuche: Sie sagte, dass eine lange Aufgabe lief und wie lange, aber praktisch nichts darüber, welcher Code sie ausgelöst hatte. Als Attribution lieferte sie meist nur einen groben Container-Hinweis -- etwa dass die Aufgabe von einem Skript gleicher Herkunft stammte -- ohne Dateiname und ohne Funktion. Für die Praxis hieß das: Man wusste, dass es klemmt, aber nicht wo.
Die Long-Animation-Frames-API schließt diese Lücke gleich doppelt. Erstens betrachtet sie nicht einzelne Aufgaben, sondern den ganzen Frame -- also auch das Zusammenspiel mehrerer kurzer Aufgaben, Layout und Rendering, das in Summe einen Frame lang macht, obwohl keine einzelne Aufgabe die 50-Millisekunden-Grenze reißt. Zweitens liefert sie die Skript-Attribution, die der Long-Tasks-API fehlte. Damit ist sie das genauere Werkzeug, um dem INP auf den Grund zu gehen -- gerade weil INP oft nicht an einer einzelnen langen Aufgabe hängt, sondern an vielen kleinen, die sich zu einem trägen Frame summieren.
| Merkmal | Long-Tasks-API | Long-Animation-Frames-API |
|---|---|---|
| Erfassungseinheit | Einzelne Aufgabe über 50 ms | Ganzer Frame über 50 ms |
| Skript-Attribution | Nur grober Herkunftshinweis | Quell-URL, Funktion und Dauer je Skript |
| Render- und Layoutzeit | nicht enthalten | Als eigene Zeitmarke enthalten |
| Bezug zur Interaktion | Kein direkter | Interaktion im Frame wird markiert |
| Verfügbarkeit | Breit unterstützt | Chromium-basierte Browser (ab Chrome 123) |
web-vitals v4 hängt LoAF an die Interaktion
Die rohe LoAF-API zu nutzen ist mächtig, aber umständlich. Hier kommt die quelloffene web-vitals-Bibliothek ins Spiel: Ihre Attribution-Variante misst das INP einer echten Nutzersitzung und hängt seit Version 4 die passenden Long-Animation-Frame-Einträge direkt an die gemessene Interaktion (web-vitals-Dokumentation). Man erhält also nicht nur die Zahl, sondern das Element, das angetippt wurde, die Aufteilung in Eingabeverzögerung, Verarbeitung und Darstellung -- und die Skripte des zugehörigen langen Frames. Das ist die Brücke von der Labormessung zur echten Nutzererfahrung: Die Attribution kommt aus dem Feld, von realen Geräten und Netzen.
import { onINP } from 'web-vitals/attribution';
onINP((metric) => {
const a = metric.attribution;
// interaction target and the three phases
console.log(a.interactionTarget); // e.g. button#buy
console.log(a.inputDelay); // input delay in ms
console.log(a.processingDuration); // processing time in ms
console.log(a.presentationDelay); // presentation delay in ms
// long animation frames around the interaction, with scripts
for (const frame of a.longAnimationFrameEntries) {
for (const s of frame.scripts) {
console.log(s.sourceURL, Math.round(s.duration), s.invoker);
}
}
});In der Praxis bedeutet das: Für jede langsame Interaktion, die im Feld auftritt, landet im Analyse-Datenstrom die Ziel-Schaltfläche, die Phasenaufteilung und die Liste der beteiligten Skript-URLs. Wer diese Daten sammelt -- etwa über ein eigenes Real-User-Monitoring, wie wir es beim Verhältnis von Felddaten aus RUM und CrUX zu Performance-Budgets beschreiben -- sieht nicht nur, dass das INP auf bestimmten Seiten schlecht ist, sondern welche Datei dort regelmäßig den langen Frame verursacht. Aus einem anonymen Perzentilwert wird eine benennbare Aufgabe.
So lesen Sie die LoAF-Daten in der Praxis
Für die manuelle Diagnose genügt ein kurzer PerformanceObserver in der Browserkonsole. Er abonniert die langen Frames und gibt für jeden die blockierende Dauer und die beteiligten Skripte aus -- ideal, um auf einer verdächtigen Seite gezielt eine Interaktion nachzustellen und zu sehen, was im Frame passiert.
const obs = new PerformanceObserver((list) => {
for (const frame of list.getEntries()) {
if (frame.blockingDuration > 0) {
console.log('Frame', Math.round(frame.duration) + ' ms',
'blocking', Math.round(frame.blockingDuration) + ' ms');
for (const s of frame.scripts) {
console.log(' -', s.sourceURL, Math.round(s.duration) + ' ms', s.invoker);
}
}
}
});
obs.observe({ type: 'long-animation-frame', buffered: true });Ergänzend zeigt das Leistungs-Panel der Chrome-Entwicklerwerkzeuge lange Frames inzwischen visuell im Zeitstrahl an, und der Diagnosebericht von Lighthouse markiert lange Hauptthread-Aufgaben mitsamt der verursachenden Skripte. Welche Befunde dort auf ein INP-Problem hindeuten und wie man die Liste sinnvoll ordnet, behandeln wir im Beitrag zum Lesen und Priorisieren des Lighthouse-Reports. Wichtig bleibt: Im Labor mit realistischer Drosselung messen, denn ein schnelles Büro-Notebook verbirgt genau die langen Frames, die auf einem durchschnittlichen Smartphone am stärksten wehtun.
LoAF ist ein Chromium-Werkzeug
Vom Frame zur priorisierten Maßnahme
Der Wert der Attribution liegt in der Reihenfolge, die sie erzwingt. Statt pauschal 'weniger JavaScript' zu fordern, benennt sie die eine Datei, die in den langen Frames der langsamsten Interaktionen regelmäßig auftaucht. Kommt sie von einem eingebetteten Drittanbieter, ist die Frage: Braucht die Seite dieses Skript an dieser Stelle, lässt es sich verzögern oder gegen eine leichtere Einbindung tauschen? Stammt sie aus dem eigenen Code, ist der Hebel meist, den schweren Event-Handler zu entlasten -- weniger Arbeit synchron zu erledigen und den Rest aufzuschieben.
Die wirksamste Technik gegen eine hohe Verarbeitungszeit ist, lange Aufgaben aktiv in kleinere Häppchen zu zerlegen, damit der Browser zwischendurch auf Eingaben reagieren kann. Wie sich das mit modernen Bordmitteln umsetzen lässt, zeigt unser Beitrag dazu, lange Tasks mit scheduler.yield aufzuteilen. Damit ein einmal erreichter guter Wert nicht beim nächsten Deployment wieder kippt, gehört eine Obergrenze für Skriptzeit und lange Frames in die Auslieferungskette -- wie ein Performance-Budget im CI Regressionen automatisch stoppt, beschreiben wir gesondert.
- Das INP im Feld messen und die Seiten mit den schlechtesten Werten herausfiltern
- Über die web-vitals-Attribution die langsamste Interaktion je Seite samt Phasenaufteilung erfassen
- Aus den zugehörigen Long Animation Frames das Skript mit dem größten Zeitanteil bestimmen
- Prüfen, in welcher Phase die Zeit verloren geht -- Eingabe, Verarbeitung oder Darstellung
- Nur diese eine Ursache angehen: Drittskript zähmen, Handler entlasten oder Aufgabe aufteilen
- Nach der Änderung erneut im Feld messen -- taucht ein anderes Skript als neuer Engpass auf?
Der Kern in einem Satz
Vor der LoAF-API haben wir bei INP-Problemen im Nebel gestochert und Skript für Skript ausprobiert. Heute lesen wir das verursachende Skript direkt aus dem Frame und wissen vor dem ersten Eingriff, wo der Hebel liegt.
Genau so gehen wir in einem strukturierten Performance-Audit vor: INP im Feld erheben, die langsamsten Interaktionen über die Long-Animation-Frames-API auf ihre Skripte zurückführen und eine nach Wirkung sortierte Maßnahmenliste erstellen -- statt eines pauschalen Umbaus der Frontend-Auslieferung. Häufig verschiebt sich der Engpass nach dem ersten Eingriff auf das nächste Skript, weshalb die Messung wiederholt wird, bis die Interaktionen zuverlässig unter der Schwelle bleiben. Welche Schritte dazugehören, zeigt unsere Übersicht der Performance-Leistungen; wie INP im Zusammenspiel der drei Kennzahlen einzuordnen ist, vertieft der Beitrag zu den Core Web Vitals 2026.