Web-Performance
Core Web Vitals 2025: INP, Schwellenwerte und Lösungen
INP ersetzte FID im März 2024. Was das für Ihre Website bedeutet, welche Schwellenwerte aktuell gelten und wo Performance typischerweise versagt.
Kurz gefasst
- Google ersetzte First Input Delay (FID) offiziell durch Interaction to Next Paint (INP) als Core Web Vital im März 2024. FID ist kein Rankingsignal mehr.
- Die drei aktuellen Core Web Vitals sind: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS). Alle drei werden als Rankingsignale verwendet.
- Gut-Schwellenwerte: LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1. Auf allen dreien "gut" zu erreichen ist wichtig für Ranking und Nutzererfahrung.
- INP misst die Worst-Case-Interaktionsverzögerung über den gesamten Seitenbesuch, nicht nur die erste Interaktion. Das macht es schwerer zu bestehen als FID, das nur den ersten Klick maß.
- Sehen Sie, wie wir Website-Performance für geschäftskritische Sites angehen, und unseren Performance-Budget-Guide für die Durchsetzungsschicht.
Warum INP FID ersetzte
FID maß das Falsche. INP misst <em>jede Interaktion</em>.
First Input Delay maß, wie lange der Browser brauchte, um auf die erste Nutzerinteraktion auf einer Seite zu reagieren (typischerweise der erste Klick oder Tap). Das Problem mit FID war, dass nur dieses einzelne erste Ereignis erfasst wurde. Eine Seite, die gut lud, FID bestand und dann beim Scrollen und Klicken tiefer in den Inhalt unresponsiv wurde, konnte bei FID noch immer "gut" erzielen, obwohl die Nutzererfahrung tatsächlich schlecht war.
Interaction to Next Paint misst die Verzögerung zwischen einer beliebigen Nutzerinteraktion (Klick, Tap, Tastatureingabe) und dem Zeitpunkt, an dem der Browser den nächsten Frame als Reaktion zeichnet. Es zeichnet alle Interaktionen während des Seitenbesuchs auf und meldet das Worst-Case-Ergebnis. **Eine Seite muss während der gesamten Sitzung reaktionsfähige Interaktionen aufrechterhalten, nicht nur beim ersten Tap, um INP zu bestehen.**
Für die meisten Production-Sites, die für FID optimiert worden waren, deckte INP neue Fehlermodi auf: Drittanbieter-Scripts, die beim Scrollen ausgelöst werden, schweres JavaScript, das durch Filter-Klicks ausgelöst wird, Warenkorb-Updates mit langen Verarbeitungsketten. FID verbarg diese, weil sie nach der ersten Interaktion auftraten. INP macht sie sichtbar.
Die drei Metriken
Gut-, Verbesserungsbedürftig- und Schlecht-Schwellenwerte für jedes Core Web Vital.
| Metrik | Was sie misst | Gut | Verbesserungsbedürftig | Schlecht |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Zeit bis das größte sichtbare Element (Bild oder Textblock) lädt | Unter 2,5 s | 2,5 s bis 4,0 s | Über 4,0 s |
| INP (Interaction to Next Paint) | Worst-Case-Verzögerung zwischen einer Nutzerinteraktion und dem nächsten gezeichneten Frame | Unter 200 ms | 200 ms bis 500 ms | Über 500 ms |
| CLS (Cumulative Layout Shift) | Gesamte unerwartete visuelle Bewegung von Elementen während des Ladens und der Nutzung | Unter 0,1 | 0,1 bis 0,25 | Über 0,25 |
Häufige Fehlerquellen
Wo Core Web Vitals am häufigsten scheitern.
01
Lange Haupt-Thread-Aufgaben blockieren INP
Die häufigste Ursache für schlechten INP ist eine lange JavaScript-Aufgabe, die auf dem Haupt-Thread läuft, wenn der Nutzer zu interagieren versucht. Wenn der Haupt-Thread beschäftigt ist (JavaScript parsen, einen großen Event-Handler ausführen, einen komplexen React-Baum aktualisieren), kann der Browser die Reaktion auf einen Klick nicht zeichnen, bis die Aufgabe abgeschlossen ist. Die Lösung: Lange Aufgaben in kleinere Abschnitte aufteilen, nicht-kritisches JavaScript zurückstellen und Web Workers für DOM-unabhängige Berechnungen verwenden.
02
Drittanbieter-Scripts verschlechtern LCP und INP
Tag-Manager, Analytics, Chat-Widgets, A/B-Test-Scripts und Ad-Tech sind die häufigsten Quellen für Performance-Degradierung bei Sites, die Core Web Vitals im Labor bestehen, aber bei Felddaten scheitern. Diese Scripts laufen auf echten Nutzersitzungen, konkurrieren um Haupt-Thread-Zeit und laden oft nach dem ersten Laden weitere Scripts asynchron. Drittanbieter-Scripts mit passenden defer/async-Attributen laden, nicht-essentielle Widgets lazy-loaden und prüfen, was der Tag-Manager tatsächlich auslöst.
03
Unoptimierte Bilder verursachen LCP-Fehler
Das Largest-Contentful-Paint-Element ist meistens ein Hero-Bild oder ein Produktbild above the fold. Häufige LCP-Fehler: Das Bild wird nicht vorgeladen (kein link rel preload), es wird in JPEG oder PNG statt WebP oder AVIF geliefert, es ist für Desktop auf mobilen Viewports dimensioniert oder es sitzt hinter einem Lazy-Load-Attribut, das den Abruf verzögert. Für Bilder, die bei den meisten Sitzungen LCP-Kandidat sind, sind Eager-Loading, modernes Format und korrekte Dimensionierung nicht verhandelbar.
04
Layout-Shifts durch spät ladende Fonts und eingefügten Content
CLS-Fehler werden meistens durch eines von drei Dingen verursacht: Schriften, die nach dem initialen Text-Render eingewechselt werden (was einen Text-Reflow verursacht), Bilder ohne explizite Breiten- und Höhenattribute (was den Browser zwingt, Layout neu zu berechnen, wenn sie laden) oder Content, der über dem Seitenrand durch Anzeigen, Cookie-Banner oder dynamische Personalisierung eingefügt wird. Die Korrekturen sind je nach Ursache spezifisch.
Häufige Fragen
Was Teams fragen, wenn sie ein Core-Web-Vitals-Verbesserungsprojekt starten.
Nutzt Google Core Web Vitals wirklich als Rankingfaktor?
Ja. Google bestätigte Core Web Vitals als Rankingsignal im Page-Experience-Update (2021). Das Gewicht des Signals im Vergleich zur inhaltlichen Relevanz wird nicht offengelegt, aber Google hat klargemacht, dass Page Experience (einschließlich Core Web Vitals) zu Ranking-Entscheidungen beiträgt. Praktisch: Bei zwei Seiten mit ähnlicher thematischer Relevanz wird die mit besseren Core Web Vitals tendenziell höher ranken.
Mein Lighthouse-Score ist gut, aber meine CrUX-Daten sind schlecht. Warum?
Lighthouse misst unter kontrollierten Lab-Bedingungen: eine einzelne headless-Chrome-Instanz, keine Drittanbieter-Scripts, die Authentifizierung erfordern, kein Tag-Manager, der auslöst, sauberes Netzwerk. CrUX erfasst echte Nutzersitzungen: langsame Geräte, variable Netzwerkbedingungen, Drittanbieter-Scripts, die auslösen, Nutzersitzungen, die schwere Interaktionen auslösen. Lab-Tools sagen, was möglich ist. Felddaten sagen, was Nutzer tatsächlich erleben. Beides ist notwendig; Felddaten sind das, was Google für Rankings verwendet.
Wir sind auf WordPress. Was verursacht wahrscheinlich schlechte Core Web Vitals?
Für WordPress-Sites sind die häufigsten Ursachen nach Häufigkeit: Ein Hero-Bild, das nicht vorgeladen oder in modernem Format geliefert wird (LCP), ein Page-Builder, der übermäßiges DOM und CSS generiert (LCP und INP), ein Tag-Manager, der mehrere Drittanbieter-Scripts beim Laden auslöst (INP), und ein Cookie-Consent-Banner, der Content verschiebt, wenn er erscheint (CLS). Ein Performance-Audit, das LCP-Element, lange Aufgaben und CLS-Quellen misst, identifiziert die Prioritätselemente.
Was hat FID in Tools und Berichten ersetzt?
INP ersetzte FID als Core Web Vital im März 2024. Im Chrome User Experience Report (CrUX) ersetzte INP-Daten FID-Daten. In der Google Search Console zeigt der Core-Web-Vitals-Bericht jetzt INP statt FID. In Lighthouse erscheint INP im Performance-Diagnose-Bereich. In Feldmesstools wie web-vitals.js ersetzt die INP-Metrik FID. Jeder Performance-Bericht, der FID noch als Core Web Vital zeigt, verwendet veraltete Daten.
Ist ein guter INP-Score bei einer komplexen Single-Page-App möglich?
Ja, aber es erfordert bewusste Architektur. React-schwere SPAs gehören zu den häufigsten Quellen für schlechten INP, weil große Komponenten-Re-Renders den Haupt-Thread während Interaktionen blockieren. Die Korrekturen: Concurrent-Rendering-Features nutzen (React 18 Transitions), große Komponenten in kleinere, memoized Einheiten aufteilen, schwere Berechnung in Web Workers verschieben und Interaktionen in Chrome DevTools profilieren. Guter INP auf einer komplexen SPA ist erreichbar; er erfordert Performance als Design-Constraint, nicht als Nachrüstung.
Wie wir Core Web Vitals angehen
Zuerst Felddaten, dann gezielte Korrekturen, dann ein Budget zur Regressionsvermeidung.
Wir beginnen mit Felddaten, nicht mit Lighthouse. CrUX-Daten zeigen, was echte Nutzer auf Ihren tatsächlichen Seiten erleben. Wir identifizieren das spezifische LCP-Element, die Interaktionen, die hohen INP verursachen, und die Quellen von Layout-Shift, bevor wir Code anfassen. Das gibt uns eine Prioritätsliste, bei der die Top-3-Punkte typischerweise 80% der Performance-Lücke ausmachen. **Sehen Sie, wie wir Website-Performance für Sites angehen, wo Performance eine Geschäftsmetrik ist, keine Eitelkeitszahl.**
Nachdem Korrekturen deployt wurden, setzen wir ein Performance-Budget: automatisierte Checks, die nach jedem Deployment laufen und eine Veröffentlichung blockieren, wenn Core Web Vitals regressieren. Ein Budget ist der einzige zuverlässige Weg, um zu verhindern, dass eine Site beim Hinzufügen neuer Features wieder langsamer wird. Sehen Sie den Performance-Budget-Guide dafür, wie man eines einrichtet.
Konkrete Lösung
Bringen Sie das operative Risiko.Sie erhalten eine klare Diagnose und den nächsten Schritt.
Passend, wenn Sie ein Team wollen, das widerspricht, wenn es zählt. Ergebnisse und Kennzahlen →
Erst prüfen?
Belege auf der Site.
Ergebnisse unter Referenzen. Team und Arbeitsweise unter Über uns. Nichts zum Download. Prüfen Sie, bevor Sie ein Gespräch buchen. Offen zur Prüfung. Commit, wenn es passt.