Interaction to Next Paint (INP) Optimierung: Der neue SEO-König 2026

Im Jahr 2026 bemisst sich eine „schnelle“ Website nicht mehr nur daran, wie schnell das erste Bild erscheint. Heute gehört zur Geschwindigkeit auch die Reaktionsfähigkeit.

Wenn ein Nutzer auf Ihrer WordPress-Seite auf einen Button klickt, reagiert dieser sofort, oder gibt es ein spürbares Ruckeln? Diese Lücke, die Zeit zwischen der Aktion des Nutzers und der visuellen Antwort des Browsers, misst Interaction to Next Paint (INP). INP ist einer der drei Core Web Vitals, und laut Google Search fließen die Core Web Vitals in die Ranking-Systeme der Suche ein. Dieselbe Dokumentation ergänzt, dass es kein einzelnes Page-Experience-Signal gibt und Relevanz an erster Stelle steht. INP entscheidet also zwischen gleich nützlichen Seiten, es hebt keine Seite an besseren Inhalten vorbei. Der stärkere Grund für die Optimierung ist der Besucher: Ein träges Menü oder ein eingefrorener Button „In den Warenkorb“ ist bei jedem Seitenaufruf zu spüren.

Dieser Leitfaden ergänzt unseren Core-Web-Vitals-Leitfaden 2026. Er erklärt, wie INP berechnet wird, was jede Phase einer Interaktion auf einer typischen WordPress-Seite verlangsamt, wie Sie das verantwortliche Skript mit Long Animation Frames finden und welche WordPress-APIs dabei helfen.

#Was ist INP und seit wann ersetzt es FID

INP ist seit dem 12. März 2024 ein stabiler Core Web Vital und hat First Input Delay (FID) abgelöst. Der Ankündigungsbeitrag auf web.dev gab Entwicklern bis zum 9. September 2024 Zeit, Code umzustellen, der FID aus der CrUX- oder PageSpeed-Insights-API auslas. Danach war die Verfügbarkeit von FID nicht mehr garantiert. PageSpeed Insights bewertet in der Core-Web-Vitals-Prüfung inzwischen INP statt FID.

Der Unterschied zwischen beiden Metriken liegt im Umfang. FID maß nur die Eingabeverzögerung der ersten Interaktion auf einer Seite. INP beobachtet die gesamte Latenz (Eingabeverzögerung, Verarbeitung und Darstellung) jedes Klicks, jedes Tippens und jedes Tastendrucks während des gesamten Besuchs. Eine Seite, die gut lädt, aber bei der dritten Interaktion hängt, besteht daher nicht mehr.

#Wie wird INP berechnet

Die Definition von INP auf web.dev legt drei Bereiche fest, bewertet am 75. Perzentil der Seitenaufrufe und getrennt nach Mobilgeräten und Desktop:

Bei jedem Seitenaufruf erfasst der Browser die Latenz jeder beobachteten Interaktion. Als INP gilt die längste davon, mit einer Regel für sehr interaktionsreiche Seiten: Pro 50 Interaktionen wird jeweils die höchste ignoriert. Die meisten Seitenaufrufe haben weniger als 50 Interaktionen, in der Praxis wird also meist die schlechteste Interaktion zum INP dieses Besuchs. Wenn Sie INP selbst per JavaScript erfassen, empfiehlt web.dev, beim Verlassen der Seite das 98. Perzentil der Interaktionen zu nehmen, was dieselbe Regel annähert.

Gezählt werden nur Mausklicks, Tippen auf Touchscreens und Tastendrücke. Hovern, Scrollen und Zoomen werden nicht beobachtet, ein Klick oder Tastendruck innerhalb dieser Gesten kann es aber sein. Das hat eine praktische Folge: Eine Seite kann überhaupt keinen INP-Wert haben. Das passiert, wenn der Besucher nie klickt, tippt oder schreibt, wenn er nur scrollt oder wenn der Besuch von einem Bot stammt, etwa einem Such-Crawler, der nicht für Interaktionen geskriptet wurde. Ein Blogbeitrag, dessen Leser überwiegend nur scrollen, hat oft dünnere INP-Daten als eine Produktseite mit Variantenauswahl.

#Welche drei Phasen hat INP

Jede von INP gemessene Interaktion ist die Summe aus drei Teilen, wie im web.dev-Leitfaden zur INP-Optimierung beschrieben:

1. Eingabeverzögerung (Input Delay): vom Beginn der Interaktion bis zum Start des ersten Event-Handler-Callbacks. Sie wächst, wenn der Main Thread mit etwas anderem beschäftigt ist, etwa mit dem Parsen eines Skripts, einem auslösenden Timer oder einer noch laufenden vorherigen Interaktion.
2. Verarbeitungsdauer (Processing Duration): die Zeit, die alle Event-Handler-Callbacks dieser Interaktion zur Ausführung brauchen.
3. Darstellungsverzögerung (Presentation Delay): vom Ende der Callbacks bis der Browser den nächsten Frame zeichnet, einschließlich Neuberechnung der Styles, Layout und Paint.

Für die Bewertung „Gut“ muss jede Interaktion, vom Klick auf ein Navigationsmenü bis zum Tastendruck in einem Suchfeld, in 200 ms oder weniger sichtbar abgeschlossen sein. Wer eine langsame Interaktion behebt, legt oft die nächste frei. Behandeln Sie INP-Optimierung deshalb als wiederkehrende Schleife, nicht als einmalige Aufgabe.

#Wie reduziert man Input Delay in WordPress

Eingabeverzögerung entsteht meist, weil der Main Thread beschäftigt ist, während der Nutzer klicken will. Auf WordPress-Seiten sind die häufigsten Ursachen die Skriptauswertung beim Laden (Parsen, Kompilieren und Ausführen des JavaScripts von Plugins und Theme) sowie Drittanbieter-Skripte, die periodisch Arbeit erledigen, ohne Rücksicht auf Nutzereingaben.

#Wie gibt man den Main Thread mit scheduler.yield() frei

Der web.dev-Artikel zu langen Tasks definiert einen langen Task als jeden Task über 50 ms. Die Lösung besteht darin, lange JavaScript-Arbeit in kleinere Tasks aufzuteilen, damit der Browser dazwischen eine Interaktion verarbeiten kann. scheduler.yield() gibt ein Promise zurück, das in einem neuen Task aufgelöst wird, und die Fortsetzung wird priorisiert: Der Rest Ihrer Arbeit läuft vor anderen wartenden Tasks derselben Art weiter, sodass sich kein Drittanbieter-Skript zwischen Ihre Teilstücke drängen kann.

Die Browserunterstützung spielt hier eine Rolle. scheduler.yield() ist in Chrome 129, Edge 129 und Firefox 142 verfügbar, Safari unterstützt es nicht. web.dev empfiehlt einen Fallback auf setTimeout(), der ebenfalls den Main Thread freigibt, nur ohne priorisierte Fortsetzung:

function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

async function processLargeList(items) {
  for (const item of items) {
    expensiveOperation(item);
    await yieldToMain();
  }
}

Ältere Tutorials machen das Freigeben von navigator.scheduling.isInputPending() abhängig. web.dev empfiehlt diese API nicht mehr: Sie kann direkt nach einer Nutzerinteraktion false liefern, und Eingaben sind nicht der einzige Grund zum Freigeben, denn auch Animationen und andere Rendering-Updates brauchen den Main Thread. Geben Sie den Thread unabhängig von wartenden Eingaben frei.

#Wie entfernt man ungenutztes JavaScript in WordPress

Laden sollte nur das JavaScript, das für die aktuelle Ansicht nötig ist. Liest ein Nutzer einen Blogbeitrag, gibt es keinen Grund für eine Checkout-Bibliothek auf der Seite. Bedingtes Laden von Assets, nach Template oder nach Block, prüfen wir bei einem WordPress-INP-Audit als Erstes, denn Code, der nie geladen wird, kann auch keine Interaktion blockieren. Mehr dazu in unserem Leitfaden zur WordPress-Geschwindigkeitsoptimierung.

#Wie lädt man Skripte mit der Ladestrategie aus WordPress 6.3 per defer

WordPress 6.3 hat wp_register_script() und wp_enqueue_script() um eine Ladestrategie erweitert, dokumentiert in der Make-WordPress-Core-Notiz zu async und defer. Der fünfte Parameter akzeptiert jetzt ein Array mit zwei Schlüsseln, strategy (defer oder async) und in_footer:

wp_enqueue_script(
  'wppoland-filters',
  get_theme_file_uri( 'assets/filters.js' ),
  array(),
  '1.4.2',
  array(
    'strategy'  => 'defer',
    'in_footer' => true,
  )
);

Die Strategie ist ein Wunsch, keine Garantie. WordPress prüft den Abhängigkeitsbaum: Ein per defer geladenes Skript, von dem ein blockierendes Skript abhängt, wird ebenfalls blockierend, damit die Ausführungsreihenfolge erhalten bleibt. Auch ein Inline-Skript mit der Position after setzt sein Elternskript wieder auf blockierend, und diese Änderung kann sich durch den Baum fortpflanzen. Prüfen Sie deshalb nach der Umstellung eines Themes oder Plugins auf defer den Seitenquelltext, ob das Attribut tatsächlich gesetzt ist. Dieselbe Notiz empfiehlt, alte Hacks über den Filter script_loader_tag durch diese API zu ersetzen.

#Wie reduziert man die Verarbeitungszeit bei INP

Hier zeigt sich, wie effizient Ihr eigener Code ist. Die allgemeine Empfehlung von web.dev lautet, in Event-Callbacks so wenig Arbeit wie möglich zu erledigen.

#Wie hält man Event-Handler schlank

Vermeiden Sie komplexe Logik in Klick-Handlern. Aktualisieren Sie den Teil der Oberfläche, auf den der Nutzer wartet, geben Sie dann den Main Thread frei und erledigen Sie alles andere in einem späteren Task. Das Beispiel auf web.dev verwendet ein Textfeld: Das getippte Zeichen erscheint sofort, während Wortzählung, Rechtschreibprüfung und Speichern mit requestAnimationFrame() und einem darin verschachtelten setTimeout() verschoben werden, sodass sie erst nach dem Zeichnen des nächsten Frames laufen.

button.addEventListener('click', () => {
  const price = calculatePrice(product, variant);
  priceElement.textContent = formatPrice(price);

  requestAnimationFrame(() => {
    setTimeout(() => {
      sendAnalytics('price_calculated', price);
      saveCartDraft(product, price);
    }, 0);
  });
});

Die sichtbare Änderung passiert im Handler, Analytics und Speichern warten, bis der Frame mit dem neuen Preis gezeichnet ist.

#Wie vermeidet man Layout Thrashing

Layout Thrashing, auch erzwungenes synchrones Layout genannt, entsteht, wenn Code Styles ändert und im selben Task eine Layout-Eigenschaft wie offsetWidth ausliest. Der Browser muss das Layout dann sofort berechnen statt einmal am Ende des Frames, und in einer Schleife passiert das bei jedem Durchlauf. Lesen Sie zuerst alle Werte, dann schreiben Sie:

// Erzwingt bei jedem Durchlauf ein Layout: vermeiden
elements.forEach((el) => {
  const width = el.offsetWidth;
  el.style.width = width + 10 + 'px';
});

// Erst lesen, dann schreiben
const widths = elements.map((el) => el.offsetWidth);
elements.forEach((el, i) => {
  el.style.width = widths[i] + 10 + 'px';
});

#Wie lagert man Drittanbieter-Skripte aus dem Main Thread aus

Nicht essenzielle Drittanbieter-Skripte wie Chat-Widgets und Analytics-Tags lassen sich mit einer Bibliothek wie Partytown in einen Web Worker verschieben, sodass sie nicht mehr mit den Event-Handlern um den Main Thread konkurrieren. Das passt nicht für jedes Skript, weil manche Tags synchronen Zugriff auf das DOM brauchen. Die Abwägungen, einschließlich der Frage, welche Tags im Worker nicht funktionieren, behandeln wir in unserem Leitfaden zur Reduzierung der Auswirkungen von Drittanbieter-Skripten in WordPress.

#Wie geht man mit langen Listen um

Auf Seiten mit langen Listen, etwa Blogarchiven, WooCommerce-Kategorieseiten oder Datentabellen, bezahlt jede spätere Interaktion für ein großes DOM, wenn Hunderte Einträge sofort gerendert werden. Virtualisierung rendert nur die Einträge nahe dem sichtbaren Bereich und erzeugt und entfernt Elemente, während der Nutzer scrollt. Paginierung oder Buttons „Mehr laden“ erreichen dasselbe Ziel mit weniger JavaScript.

#Wie behebt man Presentation Delay

Auch wenn Ihr Code schnell fertig ist, kann der Browser Mühe haben, das Ergebnis zu zeichnen, wenn das DOM groß ist oder die Styles aufwendig neu zu berechnen sind.

#Wie wirkt sich die DOM-Größe auf INP aus

Laut web.dev wächst die Rendering-Arbeit mit der DOM-Größe, wenn auch nicht linear, und ein großes DOM verlangsamt sowohl das erste Rendern als auch das Rendern nach jeder Interaktion. Zwei Möglichkeiten: das DOM abflachen, was in WordPress meist weniger Wrapper-Elemente aus Theme oder Page Builder bedeutet, und Knoten erst dann hinzufügen, wenn eine Interaktion sie braucht, statt jeden Tab, jedes Modal und jedes Mega-Menü vorab zu rendern.

#Wie nutzt man content-visibility und contain

Mit content-visibility: auto kann der Browser Layout und Paint für ein Element überspringen, bis es sich dem sichtbaren Bereich nähert. Laut dem web.dev-Artikel zu content-visibility sank die anfängliche Rendering-Zeit der Reiseblog-Demo von 232 ms auf 30 ms, und die Eigenschaft ist seit dem 15. September 2025 Baseline Newly available (Chrome 85, Firefox 125, Safari 18). Kombinieren Sie sie mit contain-intrinsic-size, damit übersprungene Abschnitte eine Platzhalterhöhe behalten. Das Schlüsselwort auto sorgt dafür, dass sich der Browser die zuletzt gerenderte Größe merkt:

.comments-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 2000px;
}

.sidebar {
  contain: layout style paint;
}

Die Eigenschaft contain auf unabhängigen Abschnitten wie einer Sidebar oder einem Kommentarbereich teilt dem Browser mit, dass eine Änderung darin den Rest der Seite nicht beeinflusst. Das begrenzt, wie viel der Seite vor dem nächsten Paint neu berechnet werden muss.

#Warum clientseitig gerendertes HTML die Darstellungsverzögerung erhöht

Wird HTML vom Server gestreamt, parst der Browser es in Teilstücken und gibt den Thread dazwischen frei. Baut dagegen ein Skript große HTML-Mengen auf dem Client, gibt der Browser den Thread erst frei, wenn dieses HTML geparst und gerendert ist, was den nächsten Frame verzögern kann. In WordPress zeigt sich das bei AJAX-Filtern und Buttons „Mehr laden“, die einen großen HTML-String auf einmal einfügen. Kleinere Portionen mit einer Freigabe dazwischen halten den Frame nach dem Klick kurz.

#Was verursacht schlechten INP in WordPress

Das sind die Ursachen, auf die wir am häufigsten stoßen, wenn eine WordPress-Seite beim INP durchfällt. Keine davon ist WordPress-spezifisch, aber Plugins machen es leicht, sie unbemerkt zu installieren.

#Schwere Page Builder

Divi und Elementor erzeugen oft tief verschachteltes DOM mit mehreren Wrapper-Elementen um jedes Widget, was die Neuberechnung des Layouts nach einer Interaktion verlangsamt. Prüfen Sie die Tiefe im Elements-Panel der DevTools, bevor und nachdem Sie einen Abschnitt durch native Blöcke ersetzen.

#Chat-Widgets

Die meisten Live-Chat-Skripte sind große Verbraucher des Main Threads, die auf jeder Seite laden und ihre Arbeit beginnen. Ein Click-to-Load-Muster, bei dem ein schlanker Button das eigentliche Widget erst lädt, wenn der Nutzer um Hilfe bittet, nimmt diese Arbeit von Seiten, auf denen niemand chattet.

#Automatisch rotierende Slider

Übergänge, die alle paar Sekunden auslösen, können mit Klicks der Nutzer zusammenfallen. Steckt der Browser mitten in einem Slider-Übergang, wenn der Nutzer auf einen Menülink tippt, muss die Interaktion auf diese Arbeit warten, was als Eingabeverzögerung sichtbar wird.

#WooCommerce-Skripte außerhalb des Shops

Cart Fragments und andere Shop-Skripte landen mitunter auf Seiten ohne jede Shop-Funktion, etwa in Blogbeiträgen. Prüfen Sie, welche WooCommerce-Skripte jedes Template einbindet, und lesen Sie unseren Leitfaden zur WooCommerce-Performance für shopspezifische Lösungen.

#Eingebettete Google Maps

Eine eingebettete Google-Maps-Karte lädt eine beträchtliche Menge JavaScript und hält Event-Listener aktiv. Ein statisches Bild, das die interaktive Karte erst per Klick lädt, erspart diese Kosten allen Besuchern, die die Karte nie nutzen.

#Die besten Tools zur INP-Messung 2026

Um INP zu verbessern, brauchen Sie Daten von echten Nutzern und eine Möglichkeit, die langsame Interaktion im Labor nachzustellen.

#CrUX API und PageSpeed Insights

Die Dokumentation der CrUX API beschreibt die Daten als gleitenden 28-Tage-Durchschnitt, der täglich gegen 04:00 UTC aktualisiert wird und etwa zwei Tage hinter dem aktuellen Datum liegt. Jede Metrik enthält ein Histogramm und einen p75-Wert, und Sie können nach PHONE, DESKTOP oder TABLET filtern. Beitragen nur Chrome-Nutzer auf Desktop und Android, die zugestimmt haben. Chrome unter iOS und andere Chromium-Browser wie Edge sind also nicht in den Daten enthalten. Seiten mit wenig Traffic haben oft keinen eigenen Datensatz und fallen auf die Daten des Origins zurück. PageSpeed Insights und der Core-Web-Vitals-Bericht in der Search Console zeigen dieselben Felddaten.

#Wie findet man das langsame Skript mit Long Animation Frames (LoAF)

Die Long Animation Frames API ist seit Chrome 123 verfügbar. Sie meldet jeden Frame, dessen Rendering-Update sich um mehr als 50 ms verzögert, und gruppiert die Arbeit anders als die Long Tasks API nach Frames, was dem entspricht, wie INP erlebt wird. Long Tasks verschwindet nicht: Laut Chrome gibt es keine Pläne, die API abzukündigen, aber LoAF liefert eine weit bessere Zuordnung. Jeder Eintrag enthält duration, blockingDuration, renderStart, styleAndLayoutStart und ein Array scripts. Skripte, die länger als 5 ms laufen, erhalten eine Zuordnung mit sourceURL, sourceFunctionName, invokerType und forcedStyleAndLayoutDuration, was oft genügt, um das verantwortliche Plugin zu benennen.

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log('LoAF', entry.duration, entry.blockingDuration,
      entry.scripts.map((s) => ({
        sourceURL: s.sourceURL,
        sourceFunctionName: s.sourceFunctionName,
        duration: s.duration,
        forcedLayout: s.forcedStyleAndLayoutDuration,
      })));
  }
});
observer.observe({ type: 'long-animation-frame', buffered: true });

LoAF wird in Chrome und Edge unterstützt. Firefox und Safari stellen die API nicht bereit, Zuordnungsdaten aus dem Feld-Monitoring stammen also nur aus Chromium-Browsern.

#Felddaten mit dem Attribution-Build von web-vitals

Die Bibliothek web-vitals hat einen Attribution-Build, der Ihnen sagt, warum eine Interaktion langsam war. Der web.dev-Leitfaden zum Finden langsamer Interaktionen im Feld nennt die Felder: interactionTarget (ein CSS-Selektor für das Element), interactionType, inputDelay, processingDuration, presentationDelay und seit Version 4 longAnimationFrameEntries. Senden Sie sie mit sendBeacon an Ihren Analytics-Endpunkt:

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

onINP(({ value, rating, attribution }) => {
  navigator.sendBeacon('/analytics', JSON.stringify({
    value,
    rating,
    target: attribution.interactionTarget,
    inputDelay: attribution.inputDelay,
    processingDuration: attribution.processingDuration,
    presentationDelay: attribution.presentationDelay,
  }));
});

Die Aufschlüsselung nach Phasen zeigt, wo Sie suchen müssen: Eine große Eingabeverzögerung weist auf Arbeit vor dem Klick hin, eine lange Verarbeitungsdauer auf Ihre Handler und eine große Darstellungsverzögerung auf DOM-Größe und Rendering.

#Web-Vitals-Erweiterung und DevTools

Die Web-Vitals-Erweiterung und das Performance-Panel der Chrome DevTools zeigen den INP jeder Interaktion, während Sie sie ausführen. Klicken Sie jeden Button, jeden Link und jedes Formularfeld Ihrer wichtigsten Templates an und beobachten Sie die Werte. Labortests auf einem schnellen Laptop unterschätzen die Latenz auf Mobilgeräten, nutzen Sie also die CPU-Drosselung in den DevTools, wenn Sie eine aus dem Feld gemeldete langsame Interaktion nachstellen. Mobilspezifische Einschränkungen behandeln wir in unserem Leitfaden zu Mobile-First-Performance-Strategien.

#INP in WordPress verbessern Schritt für Schritt

#Schritt 1: Ausgangsaudit

Holen Sie die CrUX-Daten für Ihren Origin und Ihre Haupt-Templates (Startseite, Blogbeitrag, Produkt, Kategorie) und notieren Sie INP getrennt für Smartphones und Desktop. Beginnen Sie mit den Templates, die den schlechtesten p75-Wert und genug Traffic haben, damit es sich lohnt.

#Schritt 2: langsame Interaktionen finden

Binden Sie den Attribution-Build von web-vitals auf der Seite ein oder nutzen Sie den LoAF-Observer von oben, und sammeln Sie interactionTarget und die Phasenaufschlüsselung langsamer Interaktionen. So wird aus „die Seite fühlt sich langsam an“ eine Liste konkreter Elemente.

#Schritt 3: Skriptinventur

Listen Sie alle Skripte auf, die jedes Template lädt. Notieren Sie für jedes, ob es auf diesem Template gebraucht wird, ob es die Strategie defer nutzen kann, ob es erst bei Interaktion laden kann und ob es in einen Worker verschoben oder entfernt werden kann.

#Schritt 4: lange Tasks aufteilen

Teilen Sie bei den Skripten, denen LoAF langsame Frames zuordnet, lange Tasks mit scheduler.yield() und dem Fallback setTimeout() auf. Beginnen Sie mit der Arbeit, die während oder direkt nach einer Interaktion läuft.

#Schritt 5: DOM- und Rendering-Kosten senken

Flachen Sie die am tiefsten verschachtelten Abschnitte ab, setzen Sie content-visibility: auto für lange Bereiche unterhalb des sichtbaren Bereichs ein und erwägen Sie, Page-Builder-Abschnitte dort durch native Gutenberg-Blöcke zu ersetzen, wo das DOM am tiefsten ist.

#Schritt 6: kontinuierliches Monitoring

Lassen Sie das Feld-Monitoring nach den Korrekturen weiterlaufen. CrUX braucht 28 Tage, um eine Änderung vollständig abzubilden. Vergleichen Sie daher Ihre eigenen Felddaten Woche für Woche und richten Sie eine Warnung ein, wenn der p75-INP 200 ms überschreitet.

#INP-Optimierung von WPPoland

Bei WPPoland spezialisieren wir uns auf die Performance-Metrik, bei der der Mensch im Mittelpunkt steht.

1. JavaScript-Refactoring: Wir schreiben aufgeblähten Plugin-Code in schlanke Alternativen um, die die Funktion behalten, aber nicht das Gewicht.
2. LoAF-Diagnostik: Wir nutzen Feld-Telemetrie mit LoAF-Zuordnung, um das Skript und die Funktion zu finden, die Ihre Verzögerung verursachen.
3. Interaktivitäts-Design: Wir sorgen dafür, dass die sichtbare Reaktion auf einen Klick zuerst passiert und alles andere bis nach dem Paint wartet.

#Fazit

Bei den Core Web Vitals geht es darum, wie sich ein Nutzer bei der Interaktion mit Ihrer Marke fühlt. Interaction to Next Paint ist die Metrik des Vertrauens. Reagiert Ihre Seite sofort, haben Ihre Nutzer das Gefühl, die Kontrolle zu behalten. Hängt sie, wirkt sie kaputt, und auf Mobilgeräten gilt ein Menü, das nicht reagiert, oft als defekt. Keine veröffentlichte Studie verknüpft einen INP-Bereich mit einem festen Prozentsatz bei Absprungrate oder Conversion, messen Sie Ihre eigenen Werte also vorher und nachher.

Fühlt sich Ihre WordPress-Seite träge an? Kontaktieren Sie WPPoland, um Ihren INP zu diagnostizieren und die Interaktionen zu beheben, die ihn ausbremsen.