Core Web Vitals in WordPress: INP, LCP und CLS optimieren

#Core Web Vitals Grenzwerte für LCP, INP und CLS

#Gute und schlechte Werte für LCP, INP und CLS

#Warum ist INP schwerer zu beheben als LCP und CLS

LCP dreht sich primär um Servergeschwindigkeit und Bildoptimierung - gut verstandene Probleme mit klaren Lösungen. Ein schnellerer Server, optimierte Bilder im AVIF-Format und ein CDN bringen LCP zuverlässig unter 2,5 Sekunden. CLS geht um die Reservierung von Platz für dynamische Inhalte - eine reine CSS- und HTML-Disziplin. Explizite Breiten- und Höhenangaben bei Bildern und reservierter Platz für Werbeanzeigen lösen die meisten CLS-Probleme.

INP hingegen betrifft die Effizienz der JavaScript-Ausführung - ein grundlegend schwierigeres Problem, weil es ein Verständnis des Browser-Hauptthreads, der Task-Planung und der Event-Verarbeitung voraussetzt. Es gibt keine einzelne Konfigurationsänderung die INP behebt. Stattdessen erfordert es eine systematische Analyse jedes einzelnen Skripts, das auf der Seite läuft, und die Frage: Blockiert dieses Skript den Hauptthread in dem Moment, in dem ein Nutzer mit der Seite interagiert?

WordPress-Seiten sind besonders anfällig für schlechtes INP:

1. Plugin-Bloat - jedes Plugin kann JavaScript hinzufügen das den Hauptthread blockiert
2. Page Builder - Elementor, Divi, WPBakery fügen schwere Frontend-Frameworks hinzu
3. Drittanbieter-Skripte - Analytik, Werbung, Chat-Widgets, Social Embeds konkurrieren um Hauptthread-Zeit
4. jQuery-Abhängigkeit - viele WordPress-Themes und Plugins basieren auf jQuery (85KB+ blockierendes JavaScript)
5. Kein Code Splitting - traditionelle Themes laden allen JavaScript auf jeder Seite

#Wie INP funktioniert

#Welche drei Phasen hat eine Interaktion

Wenn ein Benutzer einen Button klickt, einen Link antippt oder eine Taste drückt, verarbeitet der Browser die Eingabe in drei Phasen:

1. Eingabeverzögerung (Input Delay) - Zeit zwischen der physischen Interaktion und dem Beginn der Event-Handler-Verarbeitung. Diese Verzögerung entsteht, wenn der Hauptthread bereits mit anderen Aufgaben beschäftigt ist.
2. Verarbeitungszeit (Processing Time) - Zeit zur Ausführung aller Event-Handler für diese Interaktion
3. Präsentationsverzögerung (Presentation Delay) - Zeit zum Rendern der visuellen Aktualisierung nachdem die Event-Handler abgeschlossen sind

Die Formel lautet:

INP = Eingabeverzögerung + Verarbeitungszeit + Präsentationsverzögerung

Die Metrik meldet die langsamste Interaktion des Besuchs. Auf Seiten mit vielen Interaktionen ist die Regel etwas milder: Laut web.dev wird pro 50 Interaktionen die jeweils höchste ignoriert. Die meisten Seiten erleben weniger als 50 Interaktionen pro Besuch, also zählt in der Praxis die schlechteste. Google bewertet die Seite anschließend am 75. Perzentil aller im Feld erfassten Besuche. Das bedeutet: eine einzige langsame Interaktion kann den gesamten INP-Wert ruinieren, selbst wenn alle anderen Interaktionen blitzschnell sind. Eine typische WordPress-Seite mit Formularen, Menüs, Filtern und Karussells bietet Dutzende mögliche Interaktionen, und eine schlechte reicht.

INP wurde am 12. März 2024 offiziell zur Core Web Vital und ersetzte FID, wie web.dev angekündigt hatte. FID wurde im selben Schritt eingestellt und aus dem Search-Console-Bericht entfernt.

#Was als Interaktion zählt

Nicht jede Benutzeraktion löst eine INP-Messung aus. Folgendes wird erfasst:

• Klicks auf Buttons, Links, Toggles, Menüs
• Taps auf Mobilgeräten (Touch-Events)
• Tastatureingaben in Eingabefeldern, Suchboxen, Formularen

Folgendes wird nicht als Interaktion gewertet:

• Scrollen - wird separat gemessen und fließt nicht in INP ein
• Hovern - reine Mausbewegungen über Elemente lösen kein INP aus

#INP auf WordPress-Seiten messen

#Google Search Console (Felddaten)

Die wichtigste Datenquelle. Navigiere zu Core Web Vitals und wähle Mobil oder Desktop. Die Search Console zeigt echte Nutzerdaten über 28 Tage aggregiert. Seiten werden nach URL-Muster gruppiert und als Gut, Verbesserungsbedarf oder Schlecht eingestuft. Da es sich um Felddaten handelt, spiegeln sie das tatsächliche Nutzererlebnis wider - keine simulierte Laborumgebung. Fang immer hier an: Felddaten enthalten langsame Geräte, schwache Verbindungen und Interaktionen, die kein Labortest nachstellt. Meldet die Search Console schlechtes INP, sieht Google dieses Problem, und es kann sich auf die Rankings auswirken.

Besonders wertvoll ist der Detailbericht: Klicke auf eine URL-Gruppe mit dem Status „Schlecht”, um die betroffenen Seiten zu sehen. Oft konzentrieren sich INP-Probleme auf wenige Seitentypen - beispielsweise Produktseiten mit vielen interaktiven Elementen oder Checkout-Seiten mit umfangreicher Formularvalidierung. Diese Konzentration ermöglicht es, die Optimierung gezielt anzusetzen statt die gesamte Seite umzubauen.

#PageSpeed Insights (Labor- und Felddaten)

Gib eine beliebige URL ein und erhalte beides:

• Felddaten - echte Nutzermessungen aus dem Chrome UX Report (CrUX). Diese Daten nutzt Google für seine Bewertung
• Labordaten - simulierte Messungen durch Lighthouse in einer kontrollierten Umgebung

Für INP sind Felddaten entscheidend wichtiger, weil Labortests möglicherweise nicht dieselben Interaktionen auslösen, die echte Nutzer durchführen. Labordaten zeigen nur die TBT (Total Blocking Time) als Annäherung. Eine Seite kann im Labor sauber aussehen und im Feld trotzdem schlechtes INP haben, weil echte Nutzer komplexe Menüs, Suchfilter und Formulare bedienen, die Lighthouse nie anfasst.

#Chrome DevTools (Debugging)

So gehst du vor:

1. DevTools öffnen, in das Performance-Panel wechseln und die Aufnahme starten
2. Mit der Seite interagieren: Buttons klicken, Menüs öffnen, Formulare ausfüllen
3. Aufnahme stoppen und das Ergebnis analysieren

Achte auf:

• Long Tasks (mit einem roten Dreieck in der Ecke markiert) - jede Aufgabe über 50ms blockiert den Hauptthread. Klicke auf eine Long Task um den Call Stack zu sehen und das verantwortliche Skript zu identifizieren
• Event-Handler - wie lange jeder Klick oder Tap zur Verarbeitung benötigt. Die Interactions-Spur zeigt jede gemessene Interaktion mit ihrer Gesamtdauer
• Layout Thrashing - erzwungene synchrone Layouts während Interaktionen, erkennbar an violetten Balken mit dem Label „Forced reflow”. Dies tritt auf wenn JavaScript DOM-Eigenschaften wie offsetHeight liest und anschließend Styles ändert

Ein praktischer Tipp: Aktiviere im Performance-Panel unter CPU Throttling eine 4-fache Drosselung. Das simuliert ein deutlich langsameres Gerät und macht INP-Probleme sichtbar, die auf leistungsstarken Entwickler-Laptops verborgen bleiben.

#INP in WordPress verbessern

#1. Nicht-kritisches JavaScript verschieben

Die wirkungsvollste einzelne Maßnahme. Die meisten WordPress-Plugins laden JavaScript im <head>, was den Hauptthread blockiert noch bevor die Seite gerendert wird:

<!-- Vorher: blockierend -->
<script src="plugin-slider.js"></script>

<!-- Nachher: verzögert -->
<script src="plugin-slider.js" defer></script>

Das Attribut defer weist den Browser an, die Datei parallel herunterzuladen, sie aber erst auszuführen, wenn das HTML vollständig geparst ist. Das entlastet den Hauptthread beim ersten Laden und senkt die Eingabeverzögerung früher Interaktionen.

Plugins die am meisten von defer profitieren:

• Analytik (GA4, GTM) - per defer laden oder via requestIdleCallback nachladen
• Chat-Widgets (Intercom, Tawk.to) - erst nach Benutzer-Scroll oder nach 5 Sekunden laden
• Social Embeds (Facebook, Twitter) - erst laden wenn sichtbar (Intersection Observer)
• Slider und Karussells - Initialisierung verzögern bis das Element sichtbar ist

#2. Ungenutztes Plugin-JavaScript entfernen

Viele Plugins laden ihre Skripte auf jeder Seite, egal ob sie dort gebraucht werden. Prüfe welche Plugins tatsächlich Frontend-JavaScript benötigen:

# Die im Frontend eingereihten Skripte auflisten
wp eval 'do_action("wp_enqueue_scripts"); global $wp_scripts; foreach ($wp_scripts->queue as $s) echo $s . "\n";'

wp eval läuft außerhalb eines Seitenaufrufs, deshalb muss der Hook wp_enqueue_scripts von Hand ausgelöst werden, sonst bleibt die Warteschlange leer. Skripte, die ein Plugin nur für ein bestimmtes Template oder eine bestimmte Abfrage einreiht, erscheinen so nicht. Für die Sicht pro Seite listet das Plugin Query Monitor die eingereihten Skripte der gerade geöffneten Seite. Markiere in dieser Liste, was die Seite nicht braucht.

Häufige Übeltäter:

• Contact Form 7 lädt CSS und JavaScript auf jeder Seite, obwohl Formulare meist nur auf einer oder zwei Seiten existieren. Lösung: nur dort bedingt laden, wo ein Formular steht
• WooCommerce Cart Fragments - der AJAX-Aufruf läuft auf jeder Seite, auch außerhalb des Shops. Lösung: auf Nicht-Shop-Seiten deaktivieren
• Gutenberg-Block-Styles - WordPress lädt CSS und JavaScript für alle registrierten Blöcke, auch für ungenutzte. Lösung: Styles ungenutzter Blöcke entfernen

Bedingtes Laden lässt sich in der functions.php des Themes umsetzen oder mit einem Asset-Manager-Plugin wie Asset CleanUp oder Perfmatters.

#3. Lange Aufgaben aufbrechen

Jede JavaScript-Aufgabe über 50ms blockiert den Hauptthread. Solange sie läuft, kann der Browser nicht auf Eingaben reagieren, was direkt die Eingabeverzögerung von INP erhöht.

scheduler.yield() ist die moderne API. Sie ist noch nicht in allen Browsern verfügbar (der web.dev-Leitfaden zu langen Aufgaben nennt Chrome und Edge 129 sowie Firefox 142, Safari fehlt noch). Deshalb mit einem setTimeout-Fallback kombinieren und nach Zeitbudget abgeben:

// Kontrolle an den Browser abgeben, mit Fallback ohne scheduler.yield()
function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise(resolve => setTimeout(resolve, 0));
}

// Eine lange Schleife aufbrechen und etwa alle 50 ms abgeben
async function processItems(items, deadline = 50) {
  let lastYield = performance.now();
  for (const item of items) {
    processItem(item);
    if (performance.now() - lastYield > deadline) {
      await yieldToMain();
      lastYield = performance.now();
    }
  }
}

Ältere Anleitungen, auch eine frühere Fassung dieses Beitrags, knüpften das Abgeben an navigator.scheduling.isInputPending(). web.dev empfiehlt diese API nicht mehr: Sie kann false liefern, obwohl der Nutzer interagiert hat, und Eingaben sind nicht der einzige Grund zum Abgeben, weil auch Animationen und andere Oberflächen-Updates den Hauptthread brauchen. Abgeben nach Zeitbudget, ob Eingaben anstehen oder nicht, hält die Seite reaktionsfähig.

Durch das Aufbrechen langer Aufgaben bleibt der Hauptthread für Benutzerinteraktionen verfügbar. Der Browser kann eingehende Klicks und Tastatureingaben zwischen den Arbeitsabschnitten verarbeiten, was die Eingabeverzögerung drastisch reduziert.

#4. Passive Event Listeners verwenden

Scroll- und Touch-Event-Listener blockieren den Browser beim flüssigen Scrollen:

// Vorher: blockierend
element.addEventListener('touchstart', handler);

// Nachher: passiv (signalisiert dem Browser dass Scrollen nicht verhindert wird)
element.addEventListener('touchstart', handler, { passive: true });

// Auch für Scroll-Listener anwenden
window.addEventListener('scroll', onScroll, { passive: true });

Dieses Muster gilt auch für wheel- und touchmove-Events. Durch die Markierung als passiv kann der Browser sofort mit dem Scrollen beginnen, ohne auf die Rückgabe des Event-Handlers zu warten.

#5. DOM-Größe optimieren

Große DOM-Bäume verlangsamen jede Interaktion, weil der Browser bei jedem Event Styles und Layout für mehr Elemente neu berechnen muss. Laut dem web.dev-Artikel zu DOM-Größe und Interaktivität stuft Lighthouse ein DOM ab 1.400 Knoten als übermäßig ein und warnt ab 800. WordPress-Seiten mit Page Buildern liegen oft deutlich darüber, und gutes INP wird dann sehr schwer.

• Unnötige Wrapper-Divs entfernen - Page Builder wie Elementor erzeugen mehrere Wrapper pro Abschnitt und Spalte. web.dev nennt die Verringerung der DOM-Tiefe als wichtigsten Hebel
• Inhalte unterhalb des Folds per Lazy Loading nachladen - Tabs, Akkordeons und ausklappbare Bereiche sollten ihren Inhalt erst bei Bedarf in den DOM einfügen
• Virtual Scrolling für lange Listen verwenden - besonders relevant für WooCommerce-Shops mit hunderten Produkten auf einer Kategorieseite
• Page-Builder-Layouts vereinfachen - jedes zusätzliche Element im DOM erhöht die Rechenzeit für Style-Neuberechnungen bei jeder Interaktion

#6. jQuery wo möglich eliminieren

jQuery fügt rund 85KB minifiziertes JavaScript hinzu und blockiert den Hauptthread während der Initialisierung. Moderne Alternativen sind schlanker und schneller:

// jQuery: document.ready
$(function() { /* ... */ });

// Modern: DOMContentLoaded
document.addEventListener('DOMContentLoaded', () => { /* ... */ });

// jQuery: Selektor
$('.my-class');

// Modern: querySelectorAll
document.querySelectorAll('.my-class');

// jQuery: Event-Binding
$('.btn').on('click', handler);

// Modern: addEventListener
document.querySelector('.btn').addEventListener('click', handler);

// jQuery: Klasse hinzufügen
$('.element').addClass('active');

// Modern: classList
document.querySelector('.element').classList.add('active');

// jQuery: AJAX
$.ajax({ url: '/api/data', success: callback });

// Modern: fetch
fetch('/api/data').then(res => res.json()).then(callback);

Bei vielen WordPress-Themes lässt sich jQuery nicht vollständig entfernen, weil abhängige Plugins es erfordern. In diesen Fällen sollte jQuery zumindest in den Footer verschoben und mit defer geladen werden.

#Web Workers, content-visibility und requestIdleCallback für INP

#Web Workers für schwere Berechnungen

CPU-intensive Operationen vom Hauptthread auslagern. Der Web Worker läuft in einem separaten Thread und blockiert keine Benutzerinteraktionen:

// main.js - Verarbeitung an Worker delegieren
const worker = new Worker('heavy-task.js');
worker.postMessage(data);
worker.onmessage = (e) => updateUI(e.data);

// heavy-task.js - läuft in einem eigenen Thread
self.onmessage = (event) => {
  const result = heavyComputation(event.data);
  self.postMessage(result);
};

Während die Berechnung läuft, kann der Nutzer ohne Verzögerung weiter mit der Seite interagieren.

Typische Anwendungsfälle für Web Workers auf WordPress-Seiten: Bildverarbeitung auf Client-Seite, komplexe Filterlogik bei WooCommerce-Produktlisten und Sortierung großer Datensätze.

#Content Visibility für Off-Screen-Inhalte

Dem Browser mitteilen, dass das Rendering für noch nicht sichtbare Inhalte übersprungen werden kann:

/* Rendering für Abschnitte unterhalb des Folds überspringen */
.below-fold-section {
  content-visibility: auto;
  contain-intrinsic-size: 0 500px;
}

Diese CSS-Eigenschaft reduziert die Arbeit, die der Browser bei Interaktionen leisten muss, weil nicht sichtbare Bereiche erst gerendert werden wenn sie in den Viewport scrollen. Bei langen Seiten mit vielen Abschnitten kann das die Präsentationsverzögerung erheblich senken.

#requestIdleCallback für nicht-dringende Arbeit

Nicht-essentielle Arbeit in Leerlaufphasen des Browsers verschieben:

// Analytik während der Leerlaufzeit laden
requestIdleCallback(() => {
  loadGoogleAnalytics();
}, { timeout: 3000 }); // Fallback: spätestens nach 3 Sekunden laden

// Die nächste Seite in der Leerlaufzeit vorab laden
requestIdleCallback(() => {
  const link = document.createElement('link');
  link.rel = 'prefetch';
  link.href = '/next-page/';
  document.head.appendChild(link);
});

Die Option timeout stellt sicher, dass die Aufgabe innerhalb einer Höchstfrist läuft, auch wenn der Browser nie ganz untätig wird. Sie wägt Reaktionsfähigkeit (keine blockierten Interaktionen) gegen Funktion (Analytik wird trotzdem geladen) ab.

Geeignet für Aufgaben wie Analytik-Initialisierung, A/B-Testing-Skripte, Prefetching von Ressourcen und das Vorladen von Schriftarten. Diese Aufgaben sind wichtig, aber nicht zeitkritisch für die aktuelle Benutzerinteraktion.

#Verbessert Headless WordPress den INP-Wert

Für Seiten, bei denen INP kritisch ist und die Optimierung des klassischen WordPress nicht reicht, ist eine Headless-Architektur die radikalere Option.

#INP auf Astro-Websites

Astro sendet standardmäßig null JavaScript an den Browser. Auf Seiten ohne interaktive Inseln ist INP kein Thema, weil nichts den Hauptthread blockiert. Der Browser erhält HTML und CSS, native Interaktionen reagieren sofort.

Selbst bei Inseln wird nur das JavaScript für die spezifischen interaktiven Komponenten geladen - der Rest bleibt statisches HTML. Ein Warenkorb-Button lädt sein eigenes Skript, Header, Text, Bilder und Footer bleiben statisch.

#INP mit Next.js und React Server Components

Next.js mit React Server Components rendert die UI auf dem Server und sendet nur das notwendige Client-JavaScript. Kombiniert mit automatischem Code Splitting lädt jede Seite nur das JavaScript das sie tatsächlich braucht, nicht das gesamte Anwendungs-Bundle.

Im App Router von Next.js sind Komponenten standardmäßig Server Components. Nur Komponenten, die ausdrücklich mit 'use client' markiert sind, schicken JavaScript an den Browser. Diese Umkehr des klassischen Modells führt zu deutlich kleineren JavaScript-Bundles.

#Typischer INP-Wert nach Website-Architektur

Das Muster ist eindeutig: Je weniger JavaScript den Browser erreicht, desto besser der INP. Für Seiten, bei denen jede Millisekunde Reaktionszeit zählt - etwa E-Commerce oder Lead-Generierung - ist diese Investition direkt in besseren Rankings und höheren Conversion-Raten spürbar.

#INP Checkliste für WordPress

• Search Console Core Web Vitals auf aktuelle INP-Werte prüfen
• Seiten mit dem schlechtesten INP über PageSpeed Insights identifizieren
• Alle nicht-kritischen JavaScript-Dateien mit defer oder async versehen
• Plugin-Skripte bedingt nur auf Seiten laden die sie benötigen
• jQuery-abhängigen Code wo möglich ersetzen oder entfernen
• { passive: true } zu Scroll- und Touch-Event-Listenern hinzufügen
• Lange Aufgaben mit scheduler.yield() oder setTimeout aufbrechen
• Inhalte unterhalb des Folds und Drittanbieter-Embeds lazy-loaden
• DOM-Größe unter die Lighthouse-Schwelle von 1.400 Elementen senken
• Migration zu Astro oder Next.js für die größte Verbesserung in Betracht ziehen
• Feld-INP in der Search Console über 28 Tage nach Änderungen überwachen

#Fazit

INP ist die Core Web Vital, die schnell fühlende Seiten von trägen trennt. Während LCP die Ladezeit misst und CLS die visuelle Stabilität bewertet, zeigt INP wie sich die Seite anfühlt wenn man mit ihr interagiert. Eine Seite, die schnell lädt, aber eine halbe Sekunde für die Antwort auf einen Klick braucht, wirkt trotzdem langsam. Für WordPress-Seiten erfordert der Weg zu gutem INP diszipliniertes JavaScript-Management - oder einen fundamentalen Architekturwechsel zu Headless.

Die drei Phasen jeder Interaktion - Eingabeverzögerung, Verarbeitungszeit und Präsentationsverzögerung - bieten jeweils eigene Optimierungshebel. Skripte verschieben senkt die Eingabeverzögerung. Event-Handler optimieren und lange Aufgaben aufbrechen reduziert die Verarbeitungszeit. DOM-Größe verringern und content-visibility nutzen verkürzt die Präsentationsverzögerung.

Die Investition zählt sich direkt in besseren Suchmaschinenrankings, höherem Nutzerengagement und steigenden Conversion-Raten aus. Jede Millisekunde INP-Verbesserung macht die Seite spürbar responsiver, und Google belohnt das mit besserer Sichtbarkeit.

Hilfe bei der Optimierung Ihrer Core Web Vitals? Entdecken Sie unsere WordPress Speed-Optimierung oder kontaktieren Sie uns für eine kostenlose Performance-Analyse.