INP verstehen und verbessern: Der neue Core Web Vital

Im März 2024 ersetzte Interaction to Next Paint (INP) den bisherigen First Input Delay (FID) als dritten Core Web Vital. Das neue Vital ist bedeutsam – wer INP verstehen und verbessern will: Während FID nur die erste Interaktion maß, misst INP alle Interaktionen während des Seitenbesuchs und ist deutlich anspruchsvoller.

Was INP misst

INP misst die Zeit zwischen einer Nutzerinteraktion (Klick, Tippen, Tastendruck) und dem nächsten visuellen Update der Seite – dem „Next Paint”. Es wird über alle Interaktionen während eines Seitenbesuchs gemessen, und der schlechteste Wert (mit einigen Ausnahmen) wird als INP-Score verwendet.

Googles Grenzwerte:

• Unter 200ms: Gut (grün)
• 200–500ms: Verbesserungsbedarf (orange)
• Über 500ms: Schlecht (rot)

FID hatte als Core Web Vital eine Bestehensrate von über 95 % – fast alle Seiten waren automatisch grün. INP hat eine Bestehensrate von nur ca. 65–70 %. Ein Drittel aller Websites besteht INP nicht – darunter viele WordPress-Sites mit JavaScript-intensiven Plugins.

Warum INP schwieriger ist als FID

FID maß nur die Verarbeitungszeit bis zum Beginn der Event-Handler-Ausführung der ersten Interaktion. Es ignorierte das Rendering nach der Interaktion und alle Folge-Interaktionen.

INP misst den vollständigen Zyklus:

1. Eingabe vom Nutzer
2. Event-Handler werden ausgeführt
3. Browser rendert das nächste Frame

Das schließt alle Arbeit ein die JavaScript nach einer Interaktion erledigt – und das kann viel sein.

Die INP-Komponenten

Ein INP-Score setzt sich zusammen aus:

Input Delay: Zeit zwischen Nutzereingabe und Beginn der Event-Handler-Ausführung. Verursacht durch anderen JavaScript-Code der gerade läuft (Main Thread blockiert).

Processing Time: Zeit für die Event-Handler selbst. Komplexe JavaScript-Operationen verlängern diese Phase.

Presentation Delay: Zeit vom Ende der Event-Handler bis zum nächsten Frame. Verursacht durch aufwändige Layout- und Rendering-Berechnungen.

INP = Input Delay + Processing Time + Presentation Delay

Häufige INP-Probleme

Langer Main Thread: Schwere JavaScript-Bundles blockieren den Browser-Thread. Während JavaScript ausgeführt wird, können Eingaben nicht verarbeitet werden.

Synchrone DOM-Manipulationen: Code der viele DOM-Elemente gleichzeitig ändert, erzwingt Layout-Neuberechnungen.

Event-Handler ohne Optimierung: Klick-Handler die synchron viel Arbeit erledigen statt die Arbeit in Tasks aufzuteilen.

Drittanbieter-Scripts: Tracking-Pixel, Chat-Widgets und andere externe Scripts blockieren den Main Thread.

INP verbessern: Konkrete Techniken

Long Tasks aufbrechen

// Schlecht: Alles synchron in einem Task
button.addEventListener('click', () => {
    processLargeDataSet(); // 400ms
    updateUI();            // 100ms
    // INP = 500ms+
});

// Besser: Arbeit aufteilen mit scheduler.yield()
button.addEventListener('click', async () => {
    updateUI(); // Wichtige UI-Änderung sofort
    await scheduler.yield(); // Browser kann rendern
    processLargeDataSet(); // Rest danach
});

scheduler.yield() und requestIdleCallback

// scheduler.yield() – gibt dem Browser Zeit zu rendern
async function processItems(items) {
    for (const item of items) {
        processItem(item);
        if (/* jede N-te Iteration */) {
            await scheduler.yield();
        }
    }
}

// requestIdleCallback – für nicht-kritische Arbeit
requestIdleCallback(() => {
    sendAnalyticsEvent();
    updateNonCriticalUI();
});

Event-Handler-Optimierung

// Debounce für häufig ausgelöste Events
function debounce(fn, delay) {
    let timeoutId;
    return function(...args) {
        clearTimeout(timeoutId);
        timeoutId = setTimeout(() => fn.apply(this, args), delay);
    };
}

// Passive Event Listeners für Touch/Scroll
document.addEventListener('touchstart', handler, { passive: true });

Websites die Long Tasks durch scheduler.yield() aufteilen und Event-Handler für nicht-kritische Arbeit optimieren, reduzieren ihren INP-Score im Median um 40–60 %. Der größte Hebel ist meist die Identifikation der schlechtesten 3–5 Interaktionen per Chrome DevTools.

WordPress-spezifische Maßnahmen

Unnötige Plugins deaktivieren: Jedes aktive Plugin kann JavaScript zum Front-End hinzufügen. Tools wie Query Monitor zeigen welche Plugins wie viel JS laden.

Script-Loading optimieren: Scripts defer oder async laden, non-critical Scripts lazy initialisieren.

// In WordPress: Scripts mit defer laden
function add_defer_attribute($tag, $handle) {
    $scripts_to_defer = ['slider-script', 'analytics-init'];
    if (in_array($handle, $scripts_to_defer)) {
        return str_replace(' src', ' defer src', $tag);
    }
    return $tag;
}
add_filter('script_loader_tag', 'add_defer_attribute', 10, 2);

WooCommerce: Add-to-Cart-Buttons haben oft schlechte INP-Werte wegen synchroner AJAX-Calls. Optimierung durch optimistische UI-Updates (Button sofort deaktivieren, dann AJAX).

INP in der Search Console

Google Search Console zeigt INP-Daten unter „Core Web Vitals” basierend auf CrUX-Felddaten. Diese Daten kommen von echten Chrome-Nutzern und können von Lighthouse-Werten abweichen.

Wichtig: INP-Daten in der Search Console haben eine Verzögerung von 28 Tagen. Verbesserungen sind nicht sofort sichtbar.

Mehr zu Core Web Vitals finden Sie in unserem Artikel über WordPress Core Web Vitals verbessern.