
INP-Diagnose · Quellen geprüft am 29. Juli 2026
Search Console meldet schlechten INP. Finden Sie die langsame Nutzeraktion
Machen Sie aus einer mobilen INP-URL-Gruppe einen prüfbaren Auftrag. Halten Sie Nutzeraktion, langsame Phase, Script, Korrektur und Nachweis fest.

Hier beginnen
- Search Console meldet INP aus echten Chrome-Besuchen. Ähnliche URLs werden gruppiert. Der Bericht zeigt das 75. Perzentil aus einem laufenden Zeitraum von 28 Tagen. Eine Beispiel-URL steht für eine Gruppe. Mehr dazu in der Search-Console-Hilfe.
- Ein grüner Lighthouse-Ladetest entkräftet ein INP-Problem aus Felddaten nicht. Der Test öffnet vielleicht nie das langsame Menü, den Filter, das Formular, den Consent-Dialog, den Chat oder den Warenkorb.
- Spielen Sie wahrscheinliche Aktionen auf einem typischen Seitentemplate nach. Teilen Sie die langsame Interaktion im Performance-Panel von Chrome in Eingabewartezeit, Verarbeitung und Darstellungswartezeit.
- Halten Sie Element, Ereignis, Script, Zuständigkeit, Messung vorher, geplante Änderung, Messung nachher, Umfang der Veröffentlichung und Rückkehrbedingung fest.
- Beobachten Sie nach der Veröffentlichung die betroffene Template-Gruppe. Die Validierung in Search Console prüft Felddaten. Sie stößt keine neue Indexierung an.
Meldung richtig lesen
Search Console findet eine langsame Gruppe. Die langsame Aktion bleibt offen.
Öffnen Sie den Bericht für Mobilgeräte oder Desktop und danach das INP-Problem. Speichern Sie Gruppenwert, Status, Berichtsdatum, Beispiel-URL und weitere URLs der Gruppe. Prüfen Sie das gemeinsame Seitentemplate, die Komponente, das Script eines Lieferanten und die typischen Nutzeraktionen.
Search Console nutzt CrUX-Felddaten und gruppiert Seiten mit ähnlicher Nutzererfahrung. Eine Beispiel-URL kann schneller oder langsamer als ihre Gruppe sein. Für Seiten mit wenig Traffic fehlen oft URL-Daten; Google kann dann Daten der gesamten Domain zeigen. Die offizielle Berichtshilfe erklärt diese Grenzen.
Der Bericht belegt ein Problem bei echten Besuchen. Er nennt keinen Button, Event-Handler, Timer, Render-Vorgang oder eingebetteten Inhalt als Ursache. Dafür brauchen Sie eine Aufzeichnung der Nutzeraktion oder genauere Felddaten.
Arbeitsblatt für den INP-Vorfall
Geben Sie der Entwicklung einen nachstellbaren Fall.
✓
**Meldung:** Gerät, Gruppen-INP, Status, Beobachtungsdatum und Link oder Bildschirmfoto aus Search Console.
✓
**URL-Gruppe:** Beispiel-URL, weitere URLs, gemeinsames Template, gemeinsame Komponente und Bedeutung für Traffic oder Geschäft.
✓
**Wahrscheinliche Aktionen:** Menü, Filter, Formularfeld, Consent-Auswahl, Chat, Produktvariante, Warenkorb oder andere echte Aktion. Nach Nutzung und Folge ordnen.
✓
**Testbedingungen:** Geräteklasse, CPU- und Netz-Einstellung, Browser, Ansichtsgröße, Login, Consent, Cache und aktive Drittanbieter-Tools.
✓
**Aufzeichnung der Interaktion:** Ziel-Element, Art der Aktion, Gesamtdauer, Eingabewartezeit, Verarbeitung, Darstellungswartezeit und gespeicherte Aufzeichnung.
✓
**Verantwortlicher Code:** eigenes Bundle, Erweiterung, Tag-Manager-Eintrag, Lieferanten-Widget, eingebetteter Inhalt, Event-Handler, Timer oder Render-Pfad.
✓
**Geplante Änderung:** kleinste Änderung passend zur langsamen Phase sowie zuständiges Team oder Lieferant.
✓
**Nachweis:** gleiche Aktion vorher und nachher, benachbarte Aktionen geprüft, akzeptiertes Ergebnis und verbleibende Grenze.
✓
**Veröffentlichung und Felddaten:** betroffene Templates, Datum, Rückkehrbedingung, Feldmessung und Start der Search-Console-Validierung.
Drei Phasen
Die langsamste Phase bestimmt die nächste Untersuchung.
| Phase | Worauf der Nutzer wartet | Zu prüfender Nachweis | Mögliche Änderung im Test |
|---|---|---|---|
| Eingabewartezeit | Der Browser hat die Aktion erhalten, kann aber die Verarbeitung noch nicht beginnen | Arbeit im Hauptprozess vor dem Ereignis, Laden oder Ausführen von Scripts, Timer, überlappende Aktionen und Drittanbieter | Andere Arbeit verkürzen oder verschieben; optionale Start-Scripts später laden; zwischen Aufgaben Zeit freigeben |
| Verarbeitung | Der Code für die Nutzeraktion läuft | Aufrufbaum, synchrone Berechnungen, Wiederholungen, Aktualisierungen, Verarbeitung von Antworten und Rückrufe von Lieferanten | Weniger Arbeit im Handler; Arbeit teilen; Wiederholungen zwischenspeichern; geeignete Berechnung aus dem Hauptprozess verschieben |
| Darstellungswartezeit | Der Code ist fertig, die sichtbare Änderung wurde noch nicht gezeichnet | Größe und Änderung des DOM, Styles, Layout, Rendering, Observer, Animationsschritte und erneute Darstellung von Komponenten | Weniger DOM- und Style-Arbeit; kleineren Bereich ändern; unnötige Layoutwechsel vermeiden; unsichtbare Arbeit verschieben |
Problem nachstellen
Zeichnen Sie die Aktion auf, die Nutzer wirklich ausführen.
01
Beginnen Sie beim Template
Starten Sie mit der betroffenen URL-Gruppe. Wählen Sie eine typische Seite mit gemeinsamem Menü, Formular, Filter, Produktbedienung oder Lieferanten-Script. Prüfen Sie eine zweite URL, um die gemeinsame Ursache zu bestätigen.
02
Listen Sie echte Nutzeraktionen
Ein Ladetest klickt die Website nicht. Erfassen Sie Aktionen nach dem Laden: erster Menütap, Consent-Auswahl, Formulareingabe, Filter, Variante, Chat und Warenkorb. Beginnen Sie mit häufigen oder umsatzrelevanten Aktionen.

03
Zeichnen Sie eine Aktion auf
Starten Sie im Performance-Panel von Chrome eine Aufzeichnung. Führen Sie genau eine Aktion aus und stoppen Sie. Suchen Sie die Aktion in der Interaktionsspur. Die DevTools-Hilfe zeigt Eingabe, Verarbeitung und Darstellung.

04
Ändern Sie eine Ursache
Deaktivieren oder ändern Sie genau ein verdächtiges Script oder einen Codepfad. Wiederholen Sie die gleiche Aktion unter gleichen Bedingungen. Behalten Sie die Änderung, wenn die Aufzeichnung besser wird und benachbarte Aktionen funktionieren.
Typische Nutzeraktionen
Prüfen Sie die Aktion, bevor Sie die Plattform verantwortlich machen.
| Aktion | Was Sie erfassen | Wo die Zuständigkeit liegen kann |
|---|---|---|
| Mobiles Menü öffnet | Erster Tap nach dem Laden, Änderung des Menüs, Animation, Fokus und noch startende Scripts | Theme oder Frontend, Page Builder, Consent oder Analytics beim Start |
| B2B-Formular reagiert | Fokus, Prüfung, Formatierung, bedingte Felder, CRM- oder Analytics-Listener und Fehleranzeige | Formular-Erweiterung, eigene Prüfung, Tag Manager, CRM-Einbettung oder Anwendung |
| WooCommerce-Variante wechselt | Auswahl, Preis- und Lageranzeige, Galerie, Ereigniskette und Warenkorb-Fragmente | Theme, WooCommerce-Erweiterung, eigenes Script, Empfehlung oder Analytics |
| Filter oder Suche aktualisiert | Eingabe, Verzögerungslogik, Anfrage, Antwortverarbeitung, Austausch der Ergebnisse und Trefferzahl | Anwendung, Suchanbieter, Darstellung im Framework oder große Ergebnisliste |
| Consent oder Chat öffnet | Erster Tap, Start des Lieferanten-Bundles, eingebetteter Inhalt, Layoutänderung und Rückrufe anderer Tags | Consent-Plattform, Chat-Anbieter, Tag Manager oder Anbindung |
| Warenkorb oder Checkout geht weiter | Klick, Preis- oder Lagerarbeit, Netzantwort, Statusänderung, Fehlerpfad und nächste Darstellung | Shop-Code, Zahlung oder Steuer, Theme, Analytics oder Empfehlungen |
Wenn das Labor schnell bleibt
Nutzen Sie genauere Felddaten nur bei einer echten Beweislücke.
CrUX belegt das Problem im Feld, nennt aber die Aktion nicht. Googles Leitfaden für langsame Interaktionen im Feld beschreibt die Attributionsversion der Bibliothek web-vitals. Sie kann Ziel und Art der Aktion, die drei Zeitphasen und Script-Daten aus langen Animationsframes erfassen.
Eine eigene Feldmessung verändert die Datenerhebung der Website. Legen Sie Felder, Stichprobe, Aufbewahrung, Zugriff und Löschung vorab fest. Erfassen Sie keine eingegebenen Werte oder personenbezogenen Daten. Lassen Sie Consent oder Rechtsgrundlage vor der Veröffentlichung prüfen.
Sammeln Sie nur genug Daten, um eine wiederkehrende Aktion und ein Template zu finden. Stellen Sie diesen Fall danach im Labor nach. Eine dauerhafte detaillierte Erfassung braucht einen eigenen betrieblichen Grund.
Nächster Schritt: Technik
Technische Einschätzung zu: INP-Problem untersuchen
Schicken Sie Ihre URL und das Problem, das Sie sehen. Wir antworten mit dem, was diesen Monat machbar ist, und was einen größeren Umfang braucht.
Korrektur belegen und veröffentlichen
Eine schnellere Aufzeichnung ist der erste Nachweis.
Wiederholen Sie dieselbe Nutzeraktion unter gleichen Bedingungen. Speichern Sie beide Aufzeichnungen. Prüfen Sie benachbarte Aktionen, mobile Ansicht, Tastaturbedienung, Fehler, Analytics und Lieferantenanbindung. Googles Anleitung zur manuellen Diagnose zeigt die drei Phasen.
Veröffentlichen Sie die Änderung auf allen betroffenen Template-Seiten oder dokumentieren Sie die Grenze. Beobachten Sie vorhandene Felddaten. Starten Sie die Validierung, wenn die Änderung für die URL-Gruppe live ist. Die Search-Console-Hilfe zur Validierung beschreibt den Prüfzeitraum von 28 Tagen. Der Start löst keine Indexierung aus.
Legen Sie eine Rückkehrbedingung fest. Ein niedrigerer INP rechtfertigt kein kaputtes Formular, fehlendes Analytics-Ereignis, unbedienbares Menü oder einen falschen Preis.
Fragen für den Auftrag
Antworten für Website-Verantwortliche und Lieferanten.
Warum ist Lighthouse grün, während Search Console schlechten INP meldet?
Beide zeigen andere Nachweise. Search Console nutzt echte Nutzerdaten für eine URL-Gruppe über einen laufenden Zeitraum von 28 Tagen. Ein üblicher Lighthouse-Ladetest ist eine einzelne Labormessung und führt die langsame Aktion vielleicht nie aus. Stellen Sie Menü, Formular, Filter, Consent, Chat, Variante oder Warenkorb des betroffenen Templates nach.
Verursacht die Beispiel-URL das gesamte Problem?
Die Beispiel-URL steht für eine Gruppe ähnlicher Seiten. Sie kann schneller oder langsamer als die Gruppe sein. Prüfen Sie weitere Gruppenmitglieder sowie gemeinsames Template, Komponenten und Scripts. Testen Sie mindestens eine zweite URL, bevor Sie die Korrektur auf eine Seite begrenzen.
Was bedeutet ein INP über 200 Millisekunden?
Google bewertet INP bis 200 Millisekunden am 75. Perzentil als gut. 200 bis 500 Millisekunden benötigen Verbesserung; über 500 Millisekunden gilt als langsam. Der Gruppenwert nennt weder Aktion noch Code. Untersuchen Sie beides vor einem allgemeinen Performance-Auftrag.
Kann ein WordPress-Performance-Plugin INP beheben?
Ein Plugin kann Caching, Ladezeitpunkt oder Script-Ausführung ändern und bei einer gemessenen Ursache helfen. Es kann erforderlichen Code verzögern oder den langsamen Handler unverändert lassen. Erfassen Sie Aktion und Phase zuerst. Testen Sie die Einstellung danach gegen Aufzeichnung, Formular, Menü, Shop, Consent und Analytics.
Wann zeigt Search Console die Korrektur?
Die Validierung beobachtet ein Felddatenfenster von 28 Tagen. Traffic, Gruppierung und verbleibende betroffene URLs beeinflussen das Ergebnis. Der Start indexiert die Seiten nicht neu und beschleunigt die Datenerhebung nicht. Aufzeichnungen und vorhandene eigene Felddaten liefern frühere Hinweise.
Was sollen wir für eine INP-Diagnose senden?
Senden Sie Bildschirmfoto, Gerät, Gruppen-INP, Beispiel- und Gruppen-URLs, gemeinsames Template, vermutete Nutzeraktionen, letzte Veröffentlichungen, Tag-Manager-Export, Consent- und Chat-Tools, WordPress-Theme und Erweiterungsliste sowie vorhandene Aufzeichnungen oder Felddaten.
Performance-Arbeit
Machen Sie aus der Meldung eine prüfbare Korrektur.
Some Tech Work ordnet die URL-Gruppe, zeichnet die betroffenen Aktionen auf, trennt die drei Zeitphasen und findet die Grenze zwischen eigenem Code und Lieferant. Der Auftrag enthält Aufzeichnungen vorher und nachher, Umfang der Veröffentlichung, Rückkehrbedingungen und Prüfung der Felddaten.
Nutzen Sie die Core-Web-Vitals-Checkliste 2026 für breite LCP-, INP- und CLS-Arbeit. Der Leitfaden zu Performance-Budgets deckt Freigabekontrollen ab. Für Diagnose und Umsetzung fragen Sie eine Website-Performance-Prüfung an.
Verfasst von
Vineet Talwar
Co-Founder, Tech & Operations bei Some Tech Work. WordCamp-Speaker in Europa und Asien und Host des WP-Shoutout-Podcasts.
Hier starten
Bereit fürs Gespräch.Buchen Sie eine kurze Diagnose.
Sagen Sie uns, was nicht läuft
Wir lesen jedes Briefing und antworten innerhalb eines Werktags.
Lieber erst sprechen?oder Tech-Stack-Audit anfragen →oder direkt per E-Mail →
Unklar, wo Sie anfangen sollen? Schicken Sie die hängende Entscheidung, den Workflow oder die Seite. Wir sagen, ob ein Diagnosegespräch, ein Tech-Stack-Audit oder ein anderer erster Schritt passt.