Core Web Vitals 2025 — was sich seit dem INP-Wechsel praktisch verändert hat

Am 12. März 2024 hat Google die Interaction to Next Paint (INP) zur offiziellen Core-Web-Vitals-Metric erklärt und damit den First Input Delay (FID) abgelöst. Was damals von vielen als „technische Verfeinerung” abgetan wurde, hat sich zwei Jahre später als eines der härtesten Performance-Audits der modernen Web-Entwicklung herausgestellt. Die Felddaten 2025 zeigen es deutlich: Während 2023 nur etwa 8 Prozent deutscher E-Commerce-Sites einen „schlechten” FID-Score hatten, liegen 2025 rund 35 Prozent derselben Sites bei INP im roten Bereich. Das ist kein Messfehler. Das ist die Wahrheit darüber, wie schlecht moderne Web-Apps mit Interaktionen umgehen.

Schauen wir hin, was sich konkret verändert hat — und welche Optimierungs-Strategien sich in 24 Monaten Praxis als tragfähig erwiesen haben.

Was INP misst, im Unterschied zu FID

Der entscheidende Punkt vorweg. FID maß nur die erste Interaktion einer Nutzersession — und zwar nur die Verzögerung zwischen Input-Event und Start der Event-Handler-Verarbeitung. Das hatte einen Geburtsfehler: FID war fast immer gut, weil moderne Browser den ersten Klick sehr schnell verarbeiten, bevor der JavaScript-Layer durch Hydration belastet wird.

INP misst alle Interaktionen einer Session und nimmt das 75. Perzentil der schlimmsten 1 Prozent dieser Interaktionen als Score. Gemessen wird die volle Latenz von Input-Event bis zum nächsten Paint — also inklusive Event-Handler-Ausführung, gegebenenfalls ausgelösten Re-Renders und Layout-/Paint-Phase.

Die Thresholds:

• Gut: INP ≤ 200 ms
• Verbesserungsbedürftig: INP 200–500 ms
• Schlecht: INP > 500 ms

FID hat gemessen, wie schnell der Browser auf den Knopfdruck reagiert. INP misst, wie schnell die App auf den Knopfdruck reagiert. Das ist ein gewaltiger Unterschied.

Was die CrUX-Daten 2025 zeigen

Die Felddaten aus dem Chrome User Experience Report (CrUX) ergeben für deutsche E-Commerce-Sites über 2025 hinweg ein konsistentes Bild. Die häufigsten Ursachen für schlechte INP-Werte sind, in absteigender Reihenfolge:

1. Long Tasks im Main Thread bei Filter- und Sort-Interaktionen — typisch in Shop-Listings mit komplexer Client-Side-Filterung. Ein Klick auf „nach Preis sortieren” löst 800 ms JavaScript-Berechnung aus.
2. Schlecht optimierte Hydration in React- und Next.js-Sites — Server-rendered HTML ist sofort sichtbar, aber Interaktionen sind blockiert, bis das gesamte JavaScript-Bundle gemountet ist.
3. Synchrone Layout-Berechnungen nach Klicks — Reflow-Storms durch DOM-Manipulationen ohne Batching, häufig in jQuery-Legacy-Code von Magento-Shops.
4. Cookie-Consent-Banner mit blockierender Hydration — der Consent-Manager lädt 200 KB JavaScript, das jeden ersten Klick blockiert.
5. Third-Party-Tag-Manager mit synchronem Initialisierungs-Code — typischerweise Tracking-Pixel, die im Main Thread laufen statt als Web Worker.

Die schmerzhafte Wahrheit ist: All das war auch unter FID schon ein Problem — es wurde nur nicht gemessen. INP macht sichtbar, was vorher unsichtbar war.

scheduler.yield() und das Long-Task-Splitting

Eine der wichtigsten praktischen Neuerungen seit Chrome 129 (Oktober 2024) ist das native scheduler.yield(). Vorher musste man mit setTimeout(fn, 0) oder requestIdleCallback improvisieren, um Long Tasks zu zerlegen. Heute geht das deklarativ:

async function processLargeList(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);
    // Alle 50 Items: Yield, damit der Browser Interaktionen verarbeiten kann
    if (i % 50 === 0 && 'scheduler' in window) {
      await scheduler.yield();
    }
  }
}

Für ältere Browser gibt es einen Polyfill, der MessageChannel und setTimeout kombiniert. In der Praxis 2025/26 hat sich folgende Wrapper-Implementierung als Standard etabliert:

async function yieldToMain() {
  if ('scheduler' in window && 'yield' in scheduler) {
    return scheduler.yield();
  }
  return new Promise(resolve => setTimeout(resolve, 0));
}

Das ist kein Trick, das ist die korrekte Art, lange synchrone Schleifen zu zerlegen. Wer eine Sortier- oder Filter-Funktion in seinem Shop hat, die mehr als 50 ms blockiert, sollte diese Wrapper-Funktion zur Standard-Vorgehensweise machen.

React 18+ und useTransition

Die zweite große Veränderung in der React-Welt ist useTransition und startTransition aus React 18, die seit der breiten Adoption 2024 in Next.js 14+ und Remix als Standard-Pattern für interaktive State-Updates gelten.

Das Prinzip: State-Updates innerhalb von startTransition werden als „nicht-dringend” markiert. Der Browser kann sie unterbrechen, wenn dringende Updates (Tastatureingaben, Klicks) auflaufen.

import { useState, useTransition } from 'react';

function ProductFilter({ products }) {
  const [filter, setFilter] = useState('');
  const [filteredProducts, setFilteredProducts] = useState(products);
  const [isPending, startTransition] = useTransition();

  const handleFilterChange = (e) => {
    const value = e.target.value;
    setFilter(value); // dringend — Input soll responsive sein

    startTransition(() => {
      // nicht-dringend — Liste darf später kommen
      setFilteredProducts(
        products.filter(p => p.name.toLowerCase().includes(value.toLowerCase()))
      );
    });
  };

  return (
    <>
      <input value={filter} onChange={handleFilterChange} />
      {isPending && <span>Filtere…</span>}
      <ProductList products={filteredProducts} />
    </>
  );
}

In Audits aus dem ersten Halbjahr 2025 hat dieser Pattern-Wechsel — von synchronem Filter-State zu useTransition — bei mehreren großen Shops INP-Werte von über 700 ms auf unter 250 ms reduziert. Das ist kein Marginal-Effekt. Das ist der Unterschied zwischen rot und grün im Search-Console-Report.

Warum Lighthouse-Lab-Daten nicht reichen

Ein wiederkehrender Fehler in der Praxis 2024/25 war die Annahme, dass Lighthouse-Audits für INP-Optimierung ausreichen. Tun sie nicht. Lighthouse misst im Lab — gesteuerte CPU-Drosselung, simulierte Netzwerk-Latenz, einzelne synthetische Interaktion. INP ist eine Felddaten-Metric. Sie wird über echte Nutzer-Interaktionen über viele Sessions hinweg gemessen.

Das praktische Werkzeug der Wahl 2026 ist die web-vitals-JavaScript-Library von Google, mit der man Real User Monitoring (RUM) selbst implementieren kann:

import { onINP, onLCP, onCLS } from 'web-vitals';

function sendToAnalytics(metric) {
  // An eigenen Analytics-Endpoint oder direkt an GA4
  navigator.sendBeacon('/analytics/vitals', JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    id: metric.id,
    navigationType: metric.navigationType
  }));
}

onINP(sendToAnalytics);
onLCP(sendToAnalytics);
onCLS(sendToAnalytics);

Wer 2026 ernsthaft INP optimieren will, kommt um eine eigene RUM-Pipeline nicht herum. CrUX-Daten sind aggregiert über 28 Tage und damit immer einen Monat veraltet — bei aktiven Optimierungs-Sprints brauchbar, aber nicht für die Tagesarbeit.

Konkrete Übeltäter aus E-Commerce-Audits 2025

Drei wiederkehrende Befunde aus Audits, die exemplarisch für die typischen INP-Probleme im DACH-E-Commerce stehen:

Erstens, der Produkt-Filter. Ein großer Mode-Shop hatte eine Filterleiste mit 15 Facetten (Größe, Farbe, Marke, Preis, etc.). Jeder Klick auf eine Facette löste eine clientseitige Neuberechnung des gesamten Produkt-Arrays aus (rund 4.000 Produkte). INP lag bei 980 ms. Die Lösung war eine Kombination aus drei Maßnahmen: Web Worker für die Filter-Berechnung, virtualisierte Liste mit react-virtual für das Rendering, und useTransition für den State-Update. Resultat: INP nach drei Wochen bei 180 ms.

Zweitens, das Cookie-Banner. Ein Verlagshaus mit modernem Next.js-Stack hatte einen Consent-Manager, der beim ersten Page-Load 280 KB JavaScript synchron in den Main Thread schob. Resultat: Der erste Klick auf irgendetwas — auch nicht-Banner-bezogen — wartete bis zur Banner-Initialisierung. INP bei 620 ms. Lösung: Defer-Loading des Consent-Managers nach dem ersten Idle-Frame, parallel zum Hauptcontent. INP nach Implementation bei 240 ms.

Drittens, die Live-Suche. Ein Möbelhändler hatte eine Autocomplete-Suche mit Debounce von 150 ms, die aber synchron einen lokalen Index durchsuchte. Jeder Tastenanschlag blockierte den Main Thread für 320 ms. Lösung: Verlagerung des Index in einen Web Worker, plus Wechsel auf requestIdleCallback für die Index-Aktualisierung. INP nach Refactor bei 140 ms.

Was alle drei Fälle gemeinsam haben: Das Problem war nie Bundle-Größe oder Server-Latenz. Das Problem war Main-Thread-Blocking durch synchrone Verarbeitung. INP zwingt das Engineering, diese Blocking-Pattern zu finden und aufzulösen.

Was du daraus mitnehmen solltest

Drei praktische Schlussfolgerungen für die eigene Vorbereitung:

Erstens, misst INP im Feld, nicht im Lab. Lighthouse-Scores sind ein notwendiger, aber nicht hinreichender Indikator. Wer 2026 keine RUM-Pipeline für Web Vitals hat, der optimiert blind.

Zweitens, Bundle-Splitting und Critical CSS sind notwendig, aber nicht hinreichend. Die Performance-Engineering-Disziplin der späten 2010er hat sich auf Initial Load konzentriert. INP zwingt zu einer zweiten Dimension: Interaction Engineering. Das sind andere Patterns, andere Tools, andere Code-Reviews.

Drittens, die alten Ausreden gelten nicht mehr. „Wir haben halt viel JavaScript” ist 2026 ein Engineering-Eingeständnis, kein technischer Sachzwang. Mit scheduler.yield(), useTransition, Web Workern und sauberer Hydration-Architektur lassen sich auch komplexe Apps unter 200 ms INP halten. Es kostet Aufwand. Aber es ist möglich, und es ist messbar.

Was sich also seit dem INP-Wechsel praktisch verändert hat? Die SEO-Welt hat endlich begriffen, dass „Performance” mehr ist als Ladezeit. Es ist auch die Frage, wie sich eine Webseite anfühlt, wenn man sie benutzt. Und diese Frage stellt INP jetzt unausweichlich. Wer sie nicht beantwortet, der verliert Ranking. Wer sie beantwortet, der gewinnt nicht nur Ranking — der gewinnt auch Nutzer.