INP Presentation Delay: DOM-Größe, Layout-Arbeit und Rendering-Optimierung

Interaction to Next Paint (INP) Probleme verursacht durch Presentation Delay

Diese Seite ist Teil unserer Serie über Interaction to Next Paint (INP). INP misst die Gesamtzeit von einer Benutzerinteraktion bis zur nächsten visuellen Aktualisierung. Der Presentation Delay ist die dritte und letzte Phase des INP, nach dem Input Delay und der Processing Time. Wenn Sie neu beim Thema INP sind, lesen Sie zuerst unseren Leitfaden zur Identifizierung und Behebung von INP-Problemen.

Kurz gesagt: Der Interaction to Next Paint (INP) misst, wie lange es dauert, bis ein Benutzer nach einer Interaktion mit einer Seite eine visuelle Änderung sieht. Dieser INP kann in drei Komponenten unterteilt werden: „Input Delay“, „Processing Time“ und „Presentation Delay“.

Der Presentation Delay ist der Hauptfaktor für den Gesamt-INP und macht im Durchschnitt etwa 42 % der gesamten INP-Zeit aus. Die Optimierung Ihrer Rendering-Pipeline und die Vereinfachung Ihrer HTML-Struktur ist der größte Hebel zur Verbesserung des INP.

Presentation Delay: Haben Sie jemals auf eine Schaltfläche geklickt und sich gefragt, warum es einen Sekundenbruchteil zu lange gedauert hat, bis das Ergebnis zu sehen war? Das ist Interaction to Next Paint (INP) in Aktion. Der Presentation Delay ist der letzte Schritt im Interaktionsprozess und setzt ein, nachdem Ihr Klick verarbeitet wurde, aber bevor Sie visuelle Änderungen sehen.

Den Presentation Delay verstehen

Die Präsentation ist die letzte Phase einer Interaktion. Der Presentation Delay stellt die Zeit dar, die der Browser benötigt, um visuelle Aktualisierungen zu rendern, die auf die Interaktion folgen. Der Presentation Delay beginnt, wenn die Event-Handler für die Interaktion fertig ausgeführt sind, und endet, wenn der nächste Frame (der die visuellen Änderungen enthält) gezeichnet (painted) wird. Der Presentation Delay kann durch verschiedene Faktoren beeinflusst werden, darunter die Komplexität des Layouts, die Größe des DOM und der Umfang der erforderlichen Rendering-Arbeit.

Der Interaction to Next Paint (INP) kann in drei Teilschritte unterteilt werden: „Input Delay“, „Processing Time“ und „Presentation Delay“.

Presentation Delay und der INP

Der Presentation Delay ist die letzte Phase des INP. Im Durchschnitt macht der Presentation Delay etwa 42 % der gesamten INP-Zeit aus und ist damit der größte Einzelfaktor für langsame Interaktionen.

Bei CoreDash erfassen wir jede Stunde Millionen von Core Web Vitals Datenpunkten. Basierend auf diesen Daten macht der Presentation Delay 42 % des Interaction to Next Paint aus. Das ist mehr als die Processing Time (40 %) und deutlich mehr als der Input Delay (18 %). Obwohl er den größten Anteil ausmacht, ist der Presentation Delay oft die am schwierigsten zu optimierende Phase, da er die Rendering-Pipeline des Browsers und nicht Ihren Anwendungscode betrifft.

Beispiel für Presentation Delay: Stellen Sie sich vor, Sie suchen auf Ihrem Telefon auf einer E-Commerce-Website nach einem neuen Paar Schuhen. Sie tippen auf ein Produktbild, um weitere Details zu sehen. Ihr Telefon ist jedoch schon etwas älter und hat Mühe, mitzuhalten. Sie tippen auf das Bild (Interaktion). Das Telefon benötigt einige Zeit, um die Anfrage zu verarbeiten und die Anzeige zu aktualisieren (Processing Time). Die Website muss die neue Seite mit dem größeren Bild und den Details rendern. Schließlich dauert es eine spürbare Zeit, bis die neuen Produktdetails und das Bild auf Ihrem Bildschirm erscheinen (Presentation Delay). Diese Verzögerung beim INP kann für Benutzer frustrierend sein, weshalb es wichtig ist, sie zu beheben.

Was verursacht einen hohen Presentation Delay?

Der Presentation Delay umfasst die gesamte Arbeit, die der Browser erledigt, nachdem Ihre Event-Handler beendet sind und bevor die Pixel auf dem Bildschirm erscheinen. Dies umfasst Style-Rekalkulation, Layout-Berechnung, Paint und Compositing. Mehrere Faktoren tragen zu einem hohen Presentation Delay bei:

Große DOM-Größe

Ein großer oder tief verschachtelter DOM ist eine der häufigsten Ursachen für einen hohen Presentation Delay. Jedes Mal, wenn der Browser nach einer Interaktion den visuellen Zustand der Seite aktualisieren muss, muss er Stile neu berechnen, das Layout berechnen und die betroffenen Elemente neu zeichnen. Die Kosten für jeden dieser Schritte skalieren mit der Anzahl der betroffenen DOM-Knoten.

Google empfiehlt, Ihren DOM unter 1.400 Elementen zu halten, mit einer maximalen Tiefe von 32 Ebenen und nicht mehr als 60 Kindelementen pro Elternknoten (siehe den Lighthouse DOM-Größen-Audit). Wenn Ihr DOM diese Schwellenwerte überschreitet, verbringt der Browser nach jeder Interaktion viel mehr Zeit mit der Style-Rekalkulation und der Layout-Berechnung.

Stellen Sie sich dieses Szenario vor: Ein Benutzer klickt auf eine Schaltfläche, die eine CSS-Klasse an einem Container-Element umschaltet. Wenn dieser Container 5.000 untergeordnete Knoten hat, muss der Browser potenziell für alle Stile neu berechnen, selbst wenn sich visuell nur wenige Elemente tatsächlich ändern. Diese Style-Rekalkulation erfolgt synchron vor dem nächsten Paint und erhöht direkt den Presentation Delay.

Für spezifische Techniken zur Reduzierung Ihres DOM lesen Sie unseren Leitfaden zur Behebung einer übermäßigen DOM-Größe.

Übermäßige Layout-Arbeit

Das Layout (auch „Reflow“ genannt) ist der Prozess, bei dem der Browser die Position und Abmessungen jedes sichtbaren Elements auf der Seite berechnet. Nach einer Interaktion, die den DOM modifiziert oder CSS-Eigenschaften ändert, die die Geometrie beeinflussen (width, height, margin, padding, top, left), muss der Browser ein Layout durchführen, bevor er den aktualisierten Frame zeichnen kann.

Zwei Muster sind für den Presentation Delay besonders schädlich:

Erzwungenes synchrones Layout (Forced synchronous layout) tritt auf, wenn JavaScript eine Layout-Eigenschaft liest (wie offsetHeight oder getBoundingClientRect()), nachdem eine DOM-Änderung vorgenommen wurde, die das Layout ungültig macht. Der Browser ist gezwungen, das Layout synchron innerhalb Ihres Event-Handlers durchzuführen, um einen genauen Wert zurückzugeben. Diese Layout-Arbeit wird dann Teil der Processing Time, aber jedes nachfolgende Layout, das durch weitere DOM-Änderungen ausgelöst wird, wird Teil des Presentation Delay.

Layout Thrashing ist das wiederholte Muster, in einer Schleife in den DOM zu schreiben und dann Layout-Eigenschaften zu lesen. Jeder Lesevorgang zwingt den Browser dazu, das Layout neu zu berechnen, und jeder Schreibvorgang macht das Layout erneut ungültig. Dies kann Dutzende oder sogar Hunderte von unnötigen Layout-Berechnungen pro Interaktion verursachen. Hier ist ein Beispiel für Layout Thrashing und wie man es behebt:

\/\/ SCHLECHT: Layout Thrashing innerhalb einer Schleife
function resizeItems() {
  const items = document.querySelectorAll('.item');
  items.forEach(item => {
    \/\/ Lesen (erzwingt Layout)
    const parentWidth = item.parentElement.offsetWidth;
    \/\/ Schreiben (macht Layout ungültig)
    item.style.width = parentWidth + 'px';
  });
}

\/\/ GUT: Batch-Lesevorgänge, dann Batch-Schreibvorgänge
function resizeItems() {
  const items = document.querySelectorAll('.item');
  \/\/ Zuerst alle Werte lesen
  const widths = Array.from(items).map(
    item => item.parentElement.offsetWidth
  );
  \/\/ Dann alle Werte schreiben
  items.forEach((item, i) => {
    item.style.width = widths[i] + 'px';
  });
}

Client-seitiges Rendering in Single Page Applications

Das client-seitige Rendering von HTML kann den Presentation Delay erheblich beeinflussen, insbesondere in Single Page Applications (SPAs). Wenn eine Benutzerinteraktion eine Routenänderung oder eine große UI-Aktualisierung auslöst, muss das SPA-Framework:

1. Den Virtual-DOM-Diffing-Algorithmus ausführen, um festzustellen, was sich geändert hat
2. Die resultierenden DOM-Mutationen auf den realen DOM anwenden
3. Die Style-Rekalkulation und das Layout für alle betroffenen Elemente auslösen
4. Den aktualisierten Frame zeichnen

In React-Anwendungen ist der Virtual-DOM-Reconciliation-Prozess Teil der Processing Time, aber die resultierenden DOM-Mutationen und deren Rendering-Kosten fallen in den Presentation Delay. Je mehr DOM-Knoten Ihr Komponentenbaum erzeugt, desto teurer sind die Reconciliation und die anschließende Rendering-Arbeit.

Um dies in React- und Next.js-Anwendungen zu mildern:

• Verwenden Sie React.memo(), um unnötige Re-Renders von Kindkomponenten zu verhindern, die dieselben Props erhalten.
• Verwenden Sie useDeferredValue() für Werte, die teure Re-Renders auslösen, damit React dringendere Aktualisierungen priorisieren kann.
• Halten Sie Komponentenbäume flach. Tief verschachtelte Komponentenhierarchien erzeugen einen tief verschachtelten DOM, was die Kosten sowohl für die Reconciliation als auch für das Browser-Rendering erhöht.
• Verwenden Sie Virtualisierungs-Bibliotheken (wie react-window oder @tanstack/react-virtual) für lange Listen, damit der DOM nur die sichtbaren Elemente enthält.

Reduzierung des Presentation Delay

DOM-Größe minimieren

Der größte Gewinn für den Presentation Delay ist ein kleiner DOM:

• Entfernen Sie ungenutzte HTML-Elemente, insbesondere tief verschachtelte Wrapper-Divs.
• Verwenden Sie Listen-Virtualisierung für lange Listen (nur sichtbare Elemente plus einen kleinen Puffer rendern).
• Flachen Sie tief verschachtelte Strukturen nach Möglichkeit ab.
• Verwenden Sie CSS Grid und Flexbox anstelle von verschachtelten Divs für das Layout.

\/\/ Lange Listen virtualisieren, um die DOM-Größe zu reduzieren
\/\/ Vorher: 10.000 Elemente im DOM

<ul>
  {allItems.map(item => 
     <li key="{item.id}">{item.name}<\/li>)
   }
<\/ul>

\/\/ Nachher: Nur sichtbare Elemente im DOM (unter Verwendung von react-window)
import { FixedSizeList } from 'react-window';

<FixedSizeList height={600} 
               itemCount={allItems.length} 
               itemSize={50} width="100%">  
  {({ index, style }) => (
    <div style={style}>{allItems[index].name}<\/div>
  )}
<\/FixedSizeList>

Verwenden Sie content-visibility zum Lazy-Render von Inhalten außerhalb des Bildschirms

Die CSS-Eigenschaft content-visibility weist den Browser an, das Rendering von Inhalten außerhalb des sichtbaren Bereichs zu überspringen, bis der Benutzer in deren Nähe scrollt. Dies reduziert den Umfang der Rendering-Arbeit während Interaktionen, indem der Bereich der Style-Rekalkulation und des Layouts auf den sichtbaren Teil der Seite beschränkt wird.

\/* content-visibility auf Bereiche unterhalb des sichtbaren Bereichs anwenden *\/.below-fold-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}

\/* Auf einzelne Elemente in langen Listen anwenden *\/.list-item {
  content-visibility: auto;
  contain-intrinsic-size: auto 80px;
}

Die Eigenschaft contain-intrinsic-size liefert eine geschätzte Höhe, damit der Browser die Größe der Bildlaufleiste korrekt berechnen kann, ohne den Inhalt zu rendern. Dies verhindert Layout-Verschiebungen (layout shifts), wenn der Benutzer scrollt und der Inhalt sichtbar wird.

Weitere CSS-Optimierungsstrategien zur Reduzierung der Rendering-Kosten finden Sie in unserem Leitfaden zum Entfernen von ungenutztem CSS.

Minimieren Sie die durch Interaktionen ausgelöste Layout-Arbeit

Bevorzugen Sie beim Entwerfen von Interaktionen CSS-Eigenschaften, die kein Layout auslösen. Eigenschaften wie transform und opacity können vom GPU-Compositor verarbeitet werden, ohne Layout oder Paint auszulösen. Verwenden Sie anstelle der Animation von top, left, width oder height lieber transform: translate() und transform: scale(). Die vollständige Liste der CSS-Eigenschaften, die ein Layout auslösen, finden Sie im web.dev Rendering Performance Guide.

Verwenden Sie die CSS-Eigenschaft will-change, um dem Browser mitzuteilen, dass ein Element animiert wird. Dies ermöglicht es dem Browser, eine separate Compositor-Ebene für das Element zu erstellen und dessen Rendering vom Rest der Seite zu isolieren:

\/* Elemente auf eine eigene Compositor-Ebene befördern *\/.animated-element {
  will-change: transform, opacity;
}

\/* Sichtbarkeit mit opacity statt display umschalten *\/.modal {
  opacity: 0;
  pointer-events: none;
  transform: translateY(10px);
  transition: opacity 0.2s, transform 0.2s;
}

.modal.active {
  opacity: 1;
  pointer-events: auto;
  transform: translateY(0);
}

Identifizierung langer Presentation Delays

Um lange Presentation Delays zu identifizieren, können Sie den Performance-Profiler von Chrome verwenden. Öffnen Sie die DevTools (Strg+Umschalt+I), navigieren Sie zum Tab Performance, drücken Sie auf Aufzeichnen und interagieren Sie mit der Seite.

Sie können dann die Timeline einer Interaktion analysieren und die verschiedenen Phasen visualisieren, einschließlich des Presentation Delay. Durch die Untersuchung der Rendering-Aktualisierungen, die nach Abschluss der Event-Handler auftreten, können Sie alle Engpässe lokalisieren, die zu einem langen Presentation Delay beitragen. Suchen Sie in der Timeline nach großen Einträgen wie „Recalculate Style“, „Layout“ und „Paint“. Diese stellen die Arbeit dar, die der Browser während der Phase des Presentation Delay leistet.

Identifizierung des Presentation Delay mit RUM Daten

Messung des Presentation Delay mit Long Animation Frames (LoAF)

Die Long Animation Frames (LoAF) API zeigt genau, was Rendering-Verzögerungen während Benutzerinteraktionen verursacht. Die API liefert Ihnen Timing-Daten, um die Verarbeitungszeit vom Presentation Delay zu trennen und genau zu bestimmen, welche Scripte das Rendering verlangsamen.

Die wichtigsten LoAF-Eigenschaften zum Verständnis des Presentation Delay sind:

• renderStart: Wann der Browser mit der Rendering-Phase (Style-Rekalkulation, Layout, Paint) begonnen hat
• styleAndLayoutStart: Wann die Style- und Layout-Berechnung begann
• duration: Gesamtdauer des Long Animation Frames
• blockingDuration: Wie viel des Frames durch Scripte blockiert wurde

LoAF ist derzeit Chromium-exklusiv (Chrome 123+). Verwenden Sie für andere Browser die Traces im Chrome DevTools Performance-Panel, um die Rendering-Arbeit zu analysieren.

Die Differenz zwischen dem Ende der Script-Ausführung und dem Ende des Frames stellt die reinen Rendering-Kosten dar, also den Presentation Delay. So können Sie diese Daten beobachten und protokollieren:

\/\/ Presentation Delay mit der LoAF API messen
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 50) {
      const scriptEnd = Math.max(
        ...entry.scripts.map(s => s.startTime + s.duration)
      );
      const presentationDelay = (
        entry.startTime + entry.duration
      ) - Math.max(scriptEnd, entry.renderStart);

      console.log('Aufschlüsselung des Presentation Delay:', {
        totalDuration: entry.duration,
        renderStart: entry.renderStart,
        styleAndLayoutStart: entry.styleAndLayoutStart,
        estimatedPresentationDelay: presentationDelay,
        scriptCount: entry.scripts.length
      });
    }
  }
});

observer.observe({
  type: 'long-animation-frame',
  buffered: true
});

RUM-Tools wie CoreDash integrieren LoAF-Daten und zeigen Ihnen mit vollständiger Script-Attribution, welche Scripte und DOM-Änderungen Rendering-Verzögerungen verursachen.

Erkunden Sie die anderen INP-Phasen

Um Ihren INP unter Kontrolle zu bringen, sollten Sie auch die anderen beiden Phasen angehen:

• Input Delay: Minimieren Sie die Wartezeit, bevor Event-Handler mit der Ausführung beginnen. Der Input Delay ist in der Regel die kleinste Phase, steigt aber während des Seitenstarts an, wenn der main thread beschäftigt ist.
• Processing Time: Optimieren Sie den Event-Handler-Code, der während der Interaktion ausgeführt wird. Auf den meisten Seiten zahlt sich hier der Großteil Ihres Optimierungsaufwands aus.

Für einen vollständigen Diagnose-Workflow lesen Sie unseren Leitfaden INP-Probleme finden und beheben. Weitere Strategien zur Rendering-Optimierung finden Sie in unseren Leitfäden zur Behebung einer übermäßigen DOM-Größe und zum Entfernen von ungenutztem CSS. Kehren Sie für den vollständigen Überblick zur INP-Hub-Seite zurück.