INP: das am häufigsten verfehlte Core Web Vital messen und beheben

Unter den drei Core Web Vitals ist Interaction to Next Paint (INP) das hartnäckigste. Rund 43 % der Websites verfehlen weiterhin die Schwelle von 200 Millisekunden, womit es das am häufigsten verfehlte Signal ist. Anders als sein Vorgänger bewertet INP die Reaktionsfähigkeit einer Seite über den gesamten Besuch hinweg, nicht nur beim ersten Klick — ein Methodenwechsel, der erklärt, warum so viele als „flüssig“ empfundene Oberflächen auf Rot springen.

#Was INP misst und warum es FID ablöste

First Input Delay maß nur die Verzögerung, bis die erste Interaktion angenommen wurde, und ignorierte die gesamte anschließende Arbeit. Die meisten Websites erzielten einen „guten“ FID, ohne dass er die reale Erfahrung widerspiegelte. INP korrigiert diese Verzerrung: Es beobachtet die Latenz aller Interaktionen eines Besuchs — Klicks, Tipp-Berührungen, Tastatureingaben — und behält einen Wert nahe dem schlechtesten. Eine Oberfläche kann daher einen tadellosen LCP und CLS aufweisen und trotzdem beim INP durchfallen.

Jede Interaktion gliedert sich in drei Phasen, die INP aufsummiert: die Eingabeverzögerung (die Zeit, in der der Hauptthread beschäftigt bleibt, bevor er das Ereignis verarbeiten kann), die Verarbeitungszeit (die Ausführung der Event-Handler) und die Präsentationsverzögerung (das Berechnen des Stils und das Zeichnen des nächsten Frames).

#Die anzustrebenden Schwellenwerte

Die Schwellenwerte werden am 75. Perzentil der realen Interaktionen gemessen, auf dem Gerät des 75. Perzentils. Ein Laborwert reicht nicht aus, um eine Website zu validieren.

INP wird nicht im Labor behoben: Es wird im Feld gemessen, am 75. Perzentil der realen Interaktionen.

#INP im Feld messen

Entscheidend sind die Felddaten, nicht ein synthetisches Audit. Die web-vitals-Bibliothek des Chrome-Teams stellt INP mit der Attribution des verantwortlichen Elements und der verantwortlichen Phase bereit, was aus einer abstrakten Zahl einen Handlungsansatz macht. Diese Werte lassen sich zur kontinuierlichen Überwachung an das Analysewerkzeug der Website senden.

import { onINP } from 'web-vitals/attribution';

onINP((metric) => {
  const a = metric.attribution;
  // Élément et phase responsables de la pire interaction
  console.log('INP', metric.value, a.interactionTarget, {
    inputDelay: a.inputDelay,
    processingDuration: a.processingDuration,
    presentationDelay: a.presentationDelay,
  });
  navigator.sendBeacon('/rum', JSON.stringify({ inp: metric.value }));
}, { reportAllChanges: false });

Die verantwortliche Phase weist den Weg zur Korrektur: ein hoher inputDelay deutet auf einen gesättigten Hauptthread, eine lange processingDuration auf einen zu schweren Handler und eine große presentationDelay auf ein teures Rendering hin.

#Lange Aufgaben aufteilen

Die häufigste Ursache für einen schlechten INP ist eine lange Aufgabe, die den Hauptthread blockiert und die Verarbeitung der Interaktion verzögert. Das Gegenmittel besteht darin, die Kontrolle zwischen den Arbeitsblöcken an den Browser zurückzugeben. Die API scheduler.yield() ermöglicht diese Aufteilung und erhält die Kontrolle bevorzugt zurück, während ein klassisches setTimeout die Aufgabe ans Ende der Warteschlange schickt.

async function handleClick() {
  updateUIImmediately();        // retour visuel instantané

  for (const chunk of workChunks) {
    processChunk(chunk);
    // Rend la main au navigateur pour traiter d'autres interactions
    if ('scheduler' in window && 'yield' in scheduler) {
      await scheduler.yield();
    } else {
      await new Promise((r) => setTimeout(r, 0));
    }
  }
}

Drei weitere Hebel ergänzen die Aufteilung: nicht wesentliche Arbeit mit requestIdleCallback auf die Zeit nach dem Zeichnen verschieben, Layout-Thrashing vermeiden, indem DOM-Lese- und -Schreibvorgänge getrennt werden, und die Rendering-Kosten senken, indem der Umfang der Stil-Neuberechnungen begrenzt wird. Die Menge des beim Start ausgeführten JavaScripts zu reduzieren — Code-Splitting, verzögerte Hydration — bleibt der grundlegende Hebel.

#Das Wichtigste in Kürze

INP misst die Reaktionsfähigkeit jeder Interaktion eines Besuchs mit einem Ziel von 200 ms am 75. Perzentil. Diagnostiziert wird es mit Felddaten und der Attribution von web-vitals, niemals mit einem einzigen Labor-Audit. Die Gewinne kommen vor allem aus dem Aufteilen langer Aufgaben und dem Reduzieren des auf dem Hauptthread ausgeführten JavaScripts. Es ist eine Grundlagenarbeit, aber es ist auch das Core Web Vital, bei dem sich der Aufwand am schnellsten in echten Daten zeigt.

Weiterführend: Die Referenzdokumentation „Interaction to Next Paint (INP)“ auf web.dev beschreibt die Phasen einer Interaktion und die Optimierungstechniken.