Wir verwenden Cookies, um deine Erfahrung zu verbessern, den Datenverkehr zu analysieren und Inhalte zu personalisieren. Du kannst alle Cookies akzeptieren oder auswählen, welche Kategorien zugelassen werden. Mehr erfahren
INP-Optimierung für Produktdetailseiten (PDP) im Jahr 2026 | Ordiko
Leitfaden
INP-Optimierung für Produktdetailseiten (PDP) im Jahr 2026
Ein fokussierter Leitfaden zur Behebung von Interaction to Next Paint (INP) auf E-Commerce-PDPs im Jahr 2026, der den Variantenwechsel, die Galerie, den Warenkorb und die React Server Components-Muster behandelt, die INP konstant unter 200 ms bringen.
PT1H30M
TL;DR. INP auf PDP wird verbessert, indem weniger JavaScript geladen und Interaktionen optimistisch gestaltet werden. Verwenden Sie React Server Components für statische Teile. Nutzen Sie useOptimistic für den Variantenwechsel und das Hinzufügen zum Warenkorb. Verwenden Sie startTransition für nicht dringende Updates. Debouncen Sie die Suche mit AbortController. Heben Sie Regex hervor und vermeiden Sie Spread in Ereignishandlern. Ziel: < 200ms p75, erreichbar < 100ms.
Was INP misst
Interaction to Next Paint (INP) misst die längste Zeit von Interaktion bis zum Malen auf einer Seite während des Besuchs des Nutzers. Eine "Interaktion" ist ein Klick, Tipp oder Tastendruck, der JavaScript auslöst.
INP wird als der schlechteste Fall (ohne seltene Ausreißer) berechnet, nicht als Durchschnitt. Ein langsamer Filterklick kann Ihre INP-Bewertung ruinieren, selbst wenn 99 andere Interaktionen schnell waren.
INP-Wert
Urteil
≤ 200ms
Gut
200ms – 500ms
Verbesserungsbedarf
> 500ms
Schlecht
Häufige Fragen
Warum ist INP so viel schwieriger als LCP?
LCP ist hauptsächlich ein Problem der CDN- und Bildoptimierung mit gut verstandenen Lösungen. INP ist die JavaScript-Ausführungszeit bei Benutzerinteraktionen; jeder Klick kann einen anderen Engpass haben. Die Behebung von INP erfordert Disziplin auf Komponentenebene für jedes interaktive Element auf der Seite.
Behebt React Server Components INP automatisch?
Im Großen und Ganzen ja. RSC reduziert das JS-Bundle, das an den Browser gesendet wird, was die Arbeit im Hauptthread verringert und INP verbessert. Aber interaktive Teile der Seite benötigen weiterhin Client-JS — RSC allein behebt nicht eine schlecht geschriebene Client-Komponente, die Regex in onClick erstellt.
Was ist der größte INP-Killer auf PDPs?
Schweres clientseitiges Rendering von Empfehlungs-Widgets ('Häufig zusammen gekauft', 'Das könnte Ihnen auch gefallen'), die 50–200 KB JS versenden und aggressiv bei der ersten Interaktion hydratisieren. Verschieben Sie diese zu Server-Komponenten oder laden Sie sie hinter IntersectionObserver lazy.
Wie schnell kann ein gut optimierter PDP bei INP werden?
Im realen Einsatz ist ein p75 INP unter 100 ms erreichbar. Ordiko PDPs haben standardmäßig 80–160 ms p75 INP ohne manuelle Optimierung. Individuelle Themen, die den Mustern in diesem Leitfaden folgen, können konstant unter 100 ms kommen.
Weiterführende Artikel
Schritt 1: Profilieren, nicht raten
Verwenden Sie den Performance-Tab in Chrome DevTools, um eine PDP-Interaktionssitzung aufzuzeichnen. Achten Sie auf:
Lange Aufgaben (gelbe Balken > 50ms) während der Interaktionen.
Zwangsneuladen (lila Balken).
Hohe attribution für INP-Einträge.
Oder verwenden Sie die Long Animation Frames (LoAF) API in Ihrem RUM:
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.duration > 200) {
console.log('Langer Frame:', entry);
}
}
});
observer.observe({ type: 'long-animation-frame', buffered: true });
Schritt 2: Nicht-kritisches JS aufschieben
Die größten INP-Gewinne auf den meisten PDPs kommen von der Entfernung oder dem Aufschieben von Skripten, die Sie nicht sofort laden mussten:
Skripttyp
Empfohlene Strategie
Analytik (GA4, Plausible)
afterInteractive
Marketing-Pixel
afterInteractive oder lazyOnload
Chat-Widget
lazyOnload + IntersectionObserver
A/B-Test SDK
Inline-blockierend (selten) oder beforeInteractive
// PDPPage (Server Component)
import { ProductGallery } from './product-gallery'; // Server
import { ProductInfo } from './product-info'; // Server
import { AddToCartButton } from './add-to-cart-button'; // Client (interaktiv)
import { VariantSelector } from './variant-selector'; // Client (interaktiv)
import { RelatedProducts } from './related-products'; // Server
import { ReviewSummary } from './review-summary'; // Server
export default async function PDP({ params }) {
const product = await getProduct(params.slug);
return (
<article>
<ProductGallery images={product.images} />
<ProductInfo product={product} />
<VariantSelector variants={product.variants} />
<AddToCartButton productId={product.id} />
<ReviewSummary reviews={product.reviews} />
<RelatedProducts productId={product.id} />
</article>
);
}
Nur AddToCartButton und VariantSelector sind Client Components. Alles andere bleibt auf dem Server. Die Bundle-Größe sinkt um 60–80 % im Vergleich zu einer vollständig-clientseitigen PDP.
Schritt 4: Optimistischer Variantenwechsel
Der naive Varianten-Klickfluss:
Nutzer klickt auf Variante.
POST an /api/variant/select mit neuer Varianten-ID.
function handleClick(text) {
if (/[<>]/.test(text)) { ... } // regex wird bei jedem Klick erstellt
setItems(prev => [...prev, ...newItems]); // spread im Akkumulator
}
Gut:
const TAG_REGEX = /[<>]/; // in den Modulbereich verschoben
function handleClick(text) {
if (TAG_REGEX.test(text)) { ... }
setItems(prev => prev.concat(newItems));
}
Schritt 8: Lazy-Load unterhalb der Sichtbarkeit
Empfehlungen, Bewertungen, verwandte Produkte: Platzieren Sie sie unterhalb der Sichtbarkeit und laden Sie sie lazy mit dynamic + ssr: false für rein clientseitige Widgets oder laden Sie sie bei der Intersektion:
Für servergerenderte Abschnitte, wickeln Sie sie in <Suspense> mit aktiviertem PPR, damit sie nach dem statischen Shell gestreamt werden.
Erfolg messen
Nach der Bereitstellung von Fixes zeigen INP-Verbesserungen:
Chrome DevTools unter Performance → Web Vitals Overlay (synthetisch, sofort).
Ihr eigenes RUM mit der web-vitals-Bibliothek (echter Nutzer, nahezu in Echtzeit).
Search Console → Core Web Vitals (echter Nutzer, p75 über 28 Tage, 2–4 Wochen Verzögerung).
Eine typische PDP, die mit 350ms p75 INP begonnen hat und dieser Anleitung folgt, erreicht innerhalb von 2–4 Wochen nach der Bereitstellung 80–120ms p75 INP.
Wie Ordiko standardmäßig INP-gute PDPs bereitstellt
Statische Teile der PDP sind RSC (kein clientseitiges JS geladen).
Der Variantenwähler verwendet useOptimistic + Server Actions.
Die Galerie verwendet startTransition + Bildvorladen beim Hover.
Die Suche wird mit 200ms und AbortController debounct.
Der Warenkorb-Drawer zeigt die zuletzt bekannte Anzahl optimistisch an.
Standard p75 INP: 80–160ms.
FAQ
Warum ist INP so viel schwieriger als LCP? LCP ist hauptsächlich ein Problem der CDN- und Bildoptimierung mit gut verstandenen Lösungen. INP ist die JavaScript-Ausführungszeit bei Benutzerinteraktionen; jeder Klick kann einen anderen Engpass haben. Die Behebung von INP erfordert Disziplin auf Komponentenebene für jedes interaktive Element auf der Seite.
Behebt React Server Components INP automatisch? Im Großen und Ganzen ja. RSC reduziert das JS-Bundle, das an den Browser gesendet wird, was die Arbeit im Hauptthread verringert und INP verbessert. Aber interaktive Teile der Seite benötigen weiterhin clientseitiges JS — RSC allein behebt keine schlecht geschriebenen Client-Komponenten, die Regex in onClick erstellen.
Was ist der größte INP-Killer auf PDPs? Schweres clientseitiges Rendering von Empfehlungs-Widgets ('Häufig zusammen gekauft', 'Das könnte Ihnen auch gefallen'), die 50–200KB JS liefern und aggressiv bei der ersten Interaktion hydratisieren. Verschieben Sie diese in Server Components oder laden Sie sie lazy hinter IntersectionObserver.
Wie schnell kann eine gut optimierte PDP bei INP werden? Echte p75 INP unter 100ms sind erreichbar. Ordiko PDPs haben standardmäßig 80–160ms p75 INP ohne manuelle Optimierung. Benutzerdefinierte Themen, die den Mustern in dieser Anleitung folgen, können konstant unter 100ms kommen.