Messung der Interaktion mit der nächsten Farbe (INP)

1. Einführung

Dies ist ein interaktives Codelab, in dem Sie erfahren, wie Sie Interaction to Next Paint (INP) mit der web-vitals-Bibliothek messen.

Vorbereitung

• Kenntnisse der HTML- und JavaScript-Entwicklung
• Empfohlen: Lesen Sie die Dokumentation zum INP-Messwert auf web.dev.

Lerninhalte

• Wie Sie die web-vitals-Bibliothek zu Ihrer Seite hinzufügen und ihre Attributionsdaten verwenden
• Wie Sie die Attributionsdaten verwenden, um zu diagnostizieren, wo und wie Sie mit der Verbesserung des INP beginnen können

Voraussetzungen

• Ein Computer, auf dem Sie Code von GitHub klonen und npm-Befehle ausführen können
• Ein Texteditor
• Eine aktuelle Version von Chrome, damit alle Interaktionsmessungen funktionieren

2. Einrichten

Code abrufen und ausführen

Der Code befindet sich im dem web-vitals-codelabs Repository.

1. Klonen Sie das Repository in Ihrem Terminal: git clone https://github.com/GoogleChromeLabs/web-vitals-codelabs.git.
2. Wechseln Sie in das geklonte Verzeichnis: cd web-vitals-codelabs/measuring-inp.
3. Installieren Sie die Abhängigkeiten: npm ci.
4. Starten Sie den Webserver: npm run start.
5. Rufen Sie in Ihrem Browser http://localhost:8080/ auf.

Seite testen

In diesem Codelab wird die Website Gastropodicon (eine beliebte Referenzseite zur Anatomie von Schnecken) verwendet, um potenzielle Probleme mit dem INP zu untersuchen.

Interagieren Sie mit der Seite, um ein Gefühl dafür zu bekommen, welche Interaktionen langsam sind.

3. Chrome-Entwicklertools

Öffnen Sie die Entwicklertools über das Menü Weitere Tools > Entwicklertools. Klicken Sie dazu mit der rechten Maustaste auf die Seite und wählen Sie Untersuchen aus oder verwenden Sie eine Tastenkombination.

In diesem Codelab verwenden wir sowohl den Tab Leistung als auch die Konsole. Sie können jederzeit über die Tabs oben in den Entwicklertools zwischen den beiden Tabs wechseln.

• INP-Probleme treten am häufigsten auf Mobilgeräten auf. Wechseln Sie daher zur Emulation der mobilen Anzeige.
• Wenn Sie auf einem Desktop oder Laptop testen, ist die Leistung wahrscheinlich deutlich besser als auf einem echten Mobilgerät. Wenn Sie sich die Leistung realistischer ansehen möchten, klicken Sie oben rechts im Tab Leistung auf das Zahnrad und wählen Sie dann CPU 4x slowdown (CPU-Verlangsamung um das Vierfache) aus.

Wenn es Ihnen passt, können Sie auch beide Tabs gleichzeitig öffnen. Wechseln Sie zum Tab Leistung und drücken Sie dann die Esc-Taste , um die Konsole zu öffnen.

4. `web-vitals` installieren

web-vitals ist eine JavaScript-Bibliothek zum Messen der Web Vitals-Messwerte, die Ihre Nutzer erleben. Sie können die Bibliothek verwenden, um diese Werte zu erfassen und sie dann an einen Analytics-Endpunkt zu senden, um sie später zu analysieren. In unserem Fall möchten wir herausfinden, wann und wo langsame Interaktionen auftreten.

Es gibt verschiedene Möglichkeiten, die Bibliothek einer Seite hinzuzufügen. Wie Sie die Bibliothek auf Ihrer eigenen Website installieren, hängt davon ab, wie Sie Abhängigkeiten und den Build-Prozess verwalten und von anderen Faktoren. In der Dokumentation der Bibliothek finden Sie alle Optionen.

In diesem Codelab wird die Bibliothek über npm installiert und das Skript direkt geladen, um nicht auf einen bestimmten Build-Prozess einzugehen.

Es gibt zwei Versionen von web-vitals, die Sie verwenden können:

• Die Standardversion sollte verwendet werden, wenn Sie die Messwerte der Core Web Vitals beim Laden einer Seite erfassen möchten.
• Die Version mit Attribution fügt jedem Messwert zusätzliche Debug-Informationen hinzu, um zu diagnostizieren, warum ein Messwert den jeweiligen Wert hat.

Für die Messung des INP in diesem Codelab benötigen wir die Version mit Attribution.

Fügen Sie web-vitals den devDependencies des Projekts hinzu, indem Sie npm install -D web-vitals ausführen.

web-vitals der Seite hinzufügen:

Fügen Sie die Version des Skripts mit Attribution unten in index.html ein und protokollieren Sie die Ergebnisse in der Konsole:

<script type="module">
  import {onINP} from './node_modules/web-vitals/dist/web-vitals.attribution.js';

  onINP(console.log);
</script>

Jetzt ausprobieren

Interagieren Sie noch einmal mit der Seite, während die Konsole geöffnet ist. Wenn Sie auf der Seite klicken, wird nichts protokolliert.

Der INP wird während des gesamten Lebenszyklus einer Seite gemessen. Standardmäßig meldet web-vitals den INP erst, wenn der Nutzer die Seite verlässt oder schließt. Das ist das ideale Verhalten für das Beaconing für etwas wie Analytics, aber weniger ideal für das interaktive Debugging.

web-vitals bietet die Option reportAllChanges für eine ausführlichere Berichterstellung. Wenn diese Option aktiviert ist, wird nicht jede Interaktion gemeldet, aber jedes Mal, wenn eine Interaktion langsamer ist als eine vorherige, wird sie gemeldet.

Fügen Sie die Option dem Skript hinzu und interagieren Sie noch einmal mit der Seite:

<script type="module">
  import {onINP} from './node_modules/web-vitals/dist/web-vitals.attribution.js';

  onINP(console.log, {reportAllChanges: true});
</script>

Aktualisieren Sie die Seite. Interaktionen sollten jetzt in der Konsole gemeldet werden und sich immer dann aktualisieren, wenn eine neue langsamste Interaktion auftritt. Geben Sie beispielsweise etwas in das Suchfeld ein und löschen Sie die Eingabe dann.

5. Was ist eine Attribution?

Beginnen wir mit der ersten Interaktion, die die meisten Nutzer mit der Seite haben, dem Dialogfeld zur Cookie-Einwilligung.

Viele Seiten haben Skripts, die Cookies synchron auslösen müssen, wenn Cookies von einem Nutzer akzeptiert werden. Dadurch wird der Klick zu einer langsamen Interaktion. Das passiert hier.

Wenn Sie die Cookie-Einwilligung bereits abgelehnt haben, müssen Sie möglicherweise den lokalen Speicher der Demo löschen, um sie noch einmal zu sehen. Klicken Sie in der Adressleiste des Browsers neben der URL auf das Infosymbol, wählen Sie Cookies und Websitedaten und dann Websitedaten auf dem Gerät verwalten aus. Klicken Sie dann neben "localhost" auf das Papierkorbsymbol, um die Daten zu löschen. Aktualisieren Sie die Seite. Das Dialogfeld zur Cookie-Einwilligung sollte wieder angezeigt werden.

Klicken Sie auf Ja , um die (Demo-)Cookies zu akzeptieren, und sehen Sie sich die INP-Daten an, die jetzt in der Entwicklertools-Konsole protokolliert wurden.

Diese Informationen auf oberster Ebene sind sowohl in der Standardversion als auch in der Version mit Attribution von `web-vitals` verfügbar:

{
  name: 'INP',
  value: 344,
  rating: 'needs-improvement',
  entries: [...],
  id: 'v4-1715732159298-8028729544485',
  navigationType: 'reload',
  attribution: {...},
}

Die Zeit vom Klick des Nutzers bis zum nächsten Paint betrug 344 Millisekunden. Das ist ein "needs improvement" INP, der verbessert werden muss. Das Array entries enthält alle PerformanceEntry-Werte, die mit dieser Interaktion verknüpft sind. In diesem Fall ist das nur ein Klickereignis.

Um herauszufinden, was in dieser Zeit passiert, ist die Eigenschaft attribution jedoch am wichtigsten. Um die Attributionsdaten zu erstellen, web-vitals ermittelt, welcher Long Animations Frame (LoAF) sich mit dem Klickereignis überschneidet. Der LoAF kann dann detaillierte Daten darüber liefern, wie die Zeit während dieses Frames verbracht wurde, von den ausgeführten Skripts bis hin zur Zeit, die in einem requestAnimationFrame-Callback, Stil und Layout verbracht wurde.

Maximieren Sie die Eigenschaft attribution, um weitere Informationen zu sehen. Die Daten sind viel umfangreicher.

attribution: {
  interactionTargetElement: Element,
  interactionTarget: '#confirm',
  interactionType: 'pointer',

  inputDelay: 27,
  processingDuration: 295.6,
  presentationDelay: 21.4,

  processedEventEntries: [...],
  longAnimationFrameEntries: [...],
}

Zuerst gibt es Informationen dazu, womit interagiert wurde:

• interactionTargetElement: Ein Live-Verweis auf das Element, mit dem interagiert wurde (wenn das Element nicht aus dem DOM entfernt wurde).
• interactionTarget: Ein Selektor zum Suchen des Elements auf der Seite.

Als Nächstes wird die Zeit auf hoher Ebene aufgeschlüsselt:

• inputDelay: Die Zeit zwischen dem Beginn der Interaktion durch den Nutzer (z. B. ein Mausklick) und dem Beginn der Ausführung des Ereignis-Listeners für diese Interaktion. In diesem Fall betrug die Eingabeverzögerung nur etwa 27 Millisekunden, selbst bei aktivierter CPU-Drosselung.
• processingDuration: Die Zeit, die benötigt wird, bis die Ereignis-Listener vollständig ausgeführt wurden. Häufig haben Seiten mehrere Listener für ein einzelnes Ereignis (z. B. pointerdown, pointerup und click). Wenn sie alle im selben Animationsframe ausgeführt werden, werden sie in dieser Zeit zusammengefasst. In diesem Fall beträgt die Verarbeitungsdauer 295, 6 Millisekunden – der Großteil der INP-Zeit.
• presentationDelay: Die Zeit vom Abschluss der Ereignis-Listener bis zum Abschluss des Malens des nächsten Frames durch den Browser. In diesem Fall 21, 4 Millisekunden.

Diese INP-Phasen können ein wichtiges Signal für die Diagnose sein, was optimiert werden muss. Weitere Informationen finden Sie im Leitfaden INP optimieren.

Wenn wir etwas genauer hinsehen, enthält processedEventEntries fünf Ereignisse im Gegensatz zu dem einzelnen Ereignis im entries-Array des INP auf oberster Ebene. Was genau ist der Unterschied?

processedEventEntries: [
  {
    name: 'mouseover',
    entryType: 'event',
    startTime: 1801.6,
    duration: 344,
    processingStart: 1825.3,
    processingEnd: 1825.3,
    cancelable: true
  },
  {
    name: 'mousedown',
    entryType: 'event',
    startTime: 1801.6,
    duration: 344,
    processingStart: 1825.3,
    processingEnd: 1825.3,
    cancelable: true
  },
  {name: 'mousedown', ...},
  {name: 'mouseup', ...},
  {name: 'click', ...},
],

Der Eintrag auf oberster Ebene ist das INP-Ereignis, in diesem Fall ein Klick. Die processedEventEntries der Attribution sind alle Ereignisse, die im selben Frame verarbeitet wurden. Dazu gehören auch andere Ereignisse wie mouseover und mousedown, nicht nur das Klickereignis. Informationen zu diesen anderen Ereignissen können wichtig sein, wenn sie ebenfalls langsam waren, da sie alle zu einer langsamen Reaktionszeit beigetragen haben.

Schließlich gibt es noch das Array longAnimationFrameEntries. Das kann ein einzelner Eintrag sein, aber es gibt Fälle, in denen sich eine Interaktion über mehrere Frames erstrecken kann. Hier haben wir den einfachsten Fall mit einem einzelnen Long Animation Frame.

longAnimationFrameEntries

Maximieren des LoAF-Eintrags:

longAnimationFrameEntries: [{
  name: 'long-animation-frame',
  startTime: 1823,
  duration: 319,

  renderStart: 2139.5,
  styleAndLayoutStart: 2139.7,
  firstUIEventTimestamp: 1801.6,
  blockingDuration: 268,

  scripts: [{...}]
}],

Hier gibt es eine Reihe nützlicher Werte, z. B. die Aufschlüsselung der Zeit, die für das Styling aufgewendet wurde. Im Artikel Long Animation Frames API finden Sie weitere Informationen zu diesen Eigenschaften. Im Moment interessiert uns vor allem die Eigenschaft scripts, die Einträge mit Details zu den Skripts enthält, die für den Frame mit langer Ausführungszeit verantwortlich sind:

scripts: [{
  name: 'script',
  invoker: 'BUTTON#confirm.onclick',
  invokerType: 'event-listener',

  startTime: 1828.6,
  executionStart: 1828.6,
  duration: 294,

  sourceURL: 'http://localhost:8080/third-party/cmp.js',
  sourceFunctionName: '',
  sourceCharPosition: 1144
}]

In diesem Fall können wir sehen, dass die Zeit hauptsächlich in einem einzelnen event-listener verbracht wurde, der für BUTTON#confirm.onclick aufgerufen wurde. Wir können sogar die Quell-URL des Skripts und die Zeichenposition sehen, an der die Funktion definiert wurde.

Fazit

Was lässt sich aus diesen Attributionsdaten über diesen Fall ableiten?

• Die Interaktion wurde durch einen Klick auf das Element button#confirm ausgelöst (aus attribution.interactionTarget und der Eigenschaft invoker in einem Skript-Attributionseintrag).
• Die Zeit wurde hauptsächlich für die Ausführung von Ereignis-Listenern aufgewendet (aus attribution.processingDuration im Vergleich zum gesamten Messwert value).
• Der langsame Ereignis-Listener-Code beginnt mit einem Klick-Listener, der in third-party/cmp.js definiert ist (aus scripts.sourceURL).

Das sind genug Daten, um zu wissen, wo wir optimieren müssen.

6. Mehrere Ereignis-Listener

Aktualisieren Sie die Seite, damit die Entwicklertools-Konsole leer ist und die Cookie-Einwilligung nicht mehr die längste Interaktion ist.

Geben Sie etwas in das Suchfeld ein. Was zeigen die Attributionsdaten? Was denken Sie, was passiert?

Attributionsdaten

Zuerst ein Überblick über ein Beispiel für das Testen der Demo:

{
  name: 'INP',
  value: 1072,
  rating: 'poor',
  attribution: {
    interactionTargetElement: Element,
    interactionTarget: '#search-terms',
    interactionType: 'keyboard',

    inputDelay: 3.3,
    processingDuration: 1060.6,
    presentationDelay: 8.1,

    processedEventEntries: [...],
    longAnimationFrameEntries: [...],
  }
}

Das ist ein schlechter INP-Wert (mit aktivierter CPU-Drosselung) aus einer Tastaturinteraktion mit dem Element input#search-terms. Der Großteil der Zeit – 1061 Millisekunden von insgesamt 1072 Millisekunden INP – wurde für die Verarbeitungsdauer aufgewendet.

Die scripts-Einträge sind jedoch interessanter.

Layout-Thrashing

Der erste Eintrag des scripts-Arrays liefert uns einige wertvolle Informationen:

scripts: [{
  name: 'script',
  invoker: 'BUTTON#confirm.onclick',
  invokerType: 'event-listener',

  startTime: 4875.6,
  executionStart: 4875.6,
  duration: 497,
  forcedStyleAndLayoutDuration: 388,

  sourceURL: 'http://localhost:8080/js/index.js',
  sourceFunctionName: 'handleSearch',
  sourceCharPosition: 940
},
...]

Der Großteil der Verarbeitungsdauer fällt auf die Ausführung dieses Skripts, das ein input Listener ist (der Aufrufer ist INPUT#search-terms.oninput). Der Funktionsname ist angegeben (handleSearch) sowie die Zeichenposition in der index.js Quelldatei.

Es gibt jedoch eine neue Eigenschaft: forcedStyleAndLayoutDuration. Das war die Zeit, die bei diesem Skriptaufruf aufgewendet wurde, bei dem der Browser gezwungen war, das Layout der Seite neu zu berechnen. Mit anderen Worten: 78% der Zeit – 388 von 497 Millisekunden – die für die Ausführung dieses Ereignis-Listeners aufgewendet wurden, wurden tatsächlich für Layout-Thrashing verwendet.

Das sollte oberste Priorität haben.

Wiederholte Listener

Einzeln betrachtet ist an den nächsten beiden Skripteinträgen nichts Besonderes:

scripts: [...,
{
  name: 'script',
  invoker: '#document.onkeyup',
  invokerType: 'event-listener',

  startTime: 5375.3,
  executionStart: 5375.3,
  duration: 124,

  sourceURL: 'http://localhost:8080/js/index.js',
  sourceFunctionName: '',
  sourceCharPosition: 1526,
},
{
  name: 'script',
  invoker: '#document.onkeyup',
  invokerType: 'event-listener',

  startTime: 5673.9,
  executionStart: 5673.9,
  duration: 95,

  sourceURL: 'http://localhost:8080/js/index.js',
  sourceFunctionName: '',
  sourceCharPosition: 1526
}]

Beide Einträge sind keyup-Listener, die direkt nacheinander ausgeführt werden. Die Listener sind anonyme Funktionen (daher wird in der Eigenschaft sourceFunctionName nichts gemeldet), aber wir haben trotzdem eine Quelldatei und eine Zeichenposition, sodass wir den Code finden können.

Seltsam ist, dass beide aus derselben Quelldatei und an derselben Zeichenposition stammen.

Der Browser hat mehrere Tastendrücke in einem einzigen Animationsframe verarbeitet, was dazu geführt hat, dass dieser Ereignis-Listener zweimal ausgeführt wurde, bevor etwas gemalt werden konnte.

Dieser Effekt kann sich auch verstärken. Je länger die Ausführung der Ereignis-Listener dauert, desto mehr zusätzliche Eingabeereignisse können eintreffen, wodurch sich die langsame Interaktion noch weiter verlängert.

Da es sich um eine Such-/Autovervollständigungsinteraktion handelt, wäre die Entprellung der Eingabe eine gute Strategie, damit pro Frame höchstens ein Tastendruck verarbeitet wird.

7. Eingabeverzögerung

Der typische Grund für Eingabeverzögerungen – die Zeit von der Interaktion des Nutzers bis zum Beginn der Verarbeitung der Interaktion durch einen Ereignis-Listener – ist, dass der Hauptthread beschäftigt ist. Das kann mehrere Ursachen haben:

• Die Seite wird geladen und der Hauptthread ist mit der anfänglichen Arbeit beschäftigt, das DOM einzurichten, das Layout der Seite zu erstellen, die Seite zu gestalten sowie Skripts auszuwerten und auszuführen.
• Die Seite ist allgemein beschäftigt, z. B. mit Berechnungen, skriptbasierten Animationen oder Anzeigen.
• Die Verarbeitung früherer Interaktionen dauert so lange, dass sie zukünftige Interaktionen verzögern. Das haben wir im letzten Beispiel gesehen.

Die Demoseite hat eine geheime Funktion: Wenn Sie oben auf der Seite auf das Schneckensymbol klicken, wird eine Animation gestartet und es wird viel JavaScript-Arbeit im Hauptthread ausgeführt.

• Klicken Sie auf das Schneckensymbol, um die Animation zu starten.
• Die JavaScript-Aufgaben werden ausgelöst, wenn sich die Schnecke am unteren Ende des Sprungs befindet. Versuchen Sie, so nah wie möglich am unteren Ende des Sprungs mit der Seite zu interagieren, und sehen Sie, wie hoch der INP ist, den Sie auslösen können.

Selbst wenn Sie keine anderen Ereignis-Listener auslösen – z. B. durch Klicken und Fokussieren des Suchfelds direkt beim Sprung der Schnecke – führt die Arbeit im Hauptthread dazu, dass die Seite für eine spürbare Zeit nicht reagiert.

Auf vielen Seiten ist die Arbeit im Hauptthread nicht so gut organisiert, aber das ist eine gute Demonstration, um zu sehen, wie sie in den INP-Attributionsdaten identifiziert werden kann.

Hier ist ein Beispiel für eine Attribution, bei der nur das Suchfeld während des Sprungs der Schnecke fokussiert wurde:

{
  name: 'INP',
  value: 728,
  rating: 'poor',

  attribution: {
    interactionTargetElement: Element,
    interactionTarget: '#search-terms',
    interactionType: 'pointer',

    inputDelay: 702.3,
    processingDuration: 4.9,
    presentationDelay: 20.8,

    longAnimationFrameEntries: [{
      name: 'long-animation-frame',
      startTime: 2064.8,
      duration: 790,

      renderStart: 2065,
      styleAndLayoutStart: 2854.2,
      firstUIEventTimestamp: 0,
      blockingDuration: 740,

      scripts: [{...}]
    }]
  }
}

Wie erwartet wurden die Ereignis-Listener schnell ausgeführt.Die Verarbeitungsdauer betrug 4, 9 Millisekunden.Der Großteil der schlechten Interaktion wurde durch die Eingabeverzögerung verursacht, die 702, 3 von insgesamt 728 Millisekunden betrug.

Diese Situation kann schwer zu debuggen sein. Wir wissen zwar, womit der Nutzer interagiert hat und wie, aber wir wissen auch, dass dieser Teil der Interaktion schnell abgeschlossen wurde und kein Problem war. Stattdessen hat etwas anderes auf der Seite die Verarbeitung der Interaktion verzögert. Aber wo sollen wir mit der Suche beginnen?

Hier kommen die LoAF-Skripteinträge ins Spiel:

scripts: [{
  name: 'script',
  invoker: 'SPAN.onanimationiteration',
  invokerType: 'event-listener',

  startTime: 2065,
  executionStart: 2065,
  duration: 788,

  sourceURL: 'http://localhost:8080/js/index.js',
  sourceFunctionName: 'cryptodaphneCoinHandler',
  sourceCharPosition: 1831
}]

Obwohl diese Funktion nichts mit der Interaktion zu tun hatte, hat sie den Animationsframe verlangsamt und ist daher in den LoAF-Daten enthalten, die mit dem Interaktionsereignis verknüpft sind.

Daraus können wir sehen, wie die Funktion, die die Verarbeitung der Interaktion verzögert hat, ausgelöst wurde (durch einen animationiteration-Listener), welche Funktion genau dafür verantwortlich war und wo sie sich in unseren Quelldateien befand.

8. Präsentationsverzögerung: Wenn ein Update einfach nicht gemalt wird

Die Präsentationsverzögerung misst die Zeit vom Abschluss der Ereignis-Listener bis zum Zeitpunkt, an dem der Browser einen neuen Frame auf dem Bildschirm malen kann, um dem Nutzer sichtbares Feedback zu geben.

Aktualisieren Sie die Seite, um den INP-Wert noch einmal zurückzusetzen, und öffnen Sie dann das Menü. Beim Öffnen gibt es eine deutliche Verzögerung.

Konkrete Beispiele

{
  name: 'INP',
  value: 376,
  rating: 'needs-improvement',
  delta: 352,

  attribution: {
    interactionTarget: '#sidenav-button>svg',
    interactionType: 'pointer',

    inputDelay: 12.8,
    processingDuration: 14.7,
    presentationDelay: 348.5,

    longAnimationFrameEntries: [{
      name: 'long-animation-frame',
      startTime: 651,
      duration: 365,

      renderStart: 673.2,
      styleAndLayoutStart: 1004.3,
      firstUIEventTimestamp: 138.6,
      blockingDuration: 315,

      scripts: [{...}]
    }]
  }
}

Dieses Mal macht die Präsentationsverzögerung den Großteil der langsamen Interaktion aus. Das bedeutet, dass alles, was den Hauptthread blockiert, nach Abschluss der Ereignis-Listener auftritt.

scripts: [{
  entryType: 'script',
  invoker: 'FrameRequestCallback',
  invokerType: 'user-callback',

  startTime: 673.8,
  executionStart: 673.8,
  duration: 330,

  sourceURL: 'http://localhost:8080/js/side-nav.js',
  sourceFunctionName: '',
  sourceCharPosition: 1193,
}]

Wenn wir uns den einzelnen Eintrag im scripts-Array ansehen, sehen wir, dass die Zeit in einem user-callback von einem FrameRequestCallback verbracht wird. Dieses Mal wird die Präsentationsverzögerung durch einen requestAnimationFrame-Callback verursacht.

Da requestAnimationFrame häufig verwendet wird, um JavaScript für Animationen in jedem Frame auszulösen, wird es leicht als Auslösen eines Callbacks für den nächsten Frame angesehen. Tatsächlich wird jedoch ein Callback vor dem Malen des aktuellen Frames durch den Browser angefordert. Das bedeutet, dass ein langsamer requestAnimationFrame-Callback, der durch eine Interaktion ausgelöst wird, diese Interaktion verlangsamt und die Wahrscheinlichkeit eines schlechten INP erhöht.

9. Fazit

Felddaten aggregieren

Es ist wichtig zu wissen, dass das alles einfacher ist, wenn Sie sich einen einzelnen INP-Attributionseintrag aus einem einzelnen Seitenaufruf ansehen. Wie können diese Daten aggregiert werden, um den INP anhand von Felddaten zu debuggen? Die Menge an hilfreichen Details macht das tatsächlich schwieriger.

Es ist beispielsweise äußerst nützlich zu wissen, welches Seitenelement eine häufige Quelle für langsame Interaktionen ist. Wenn Ihre Seite jedoch kompilierte CSS-Klassennamen hat, die sich von Build zu Build ändern, können sich die web-vitals-Selektoren für dasselbe Element zwischen den Builds unterscheiden.

Stattdessen müssen Sie an Ihre spezielle Anwendung denken, um zu ermitteln, was am nützlichsten ist und wie die Daten aggregiert werden können. Bevor Sie Attributionsdaten zurücksenden, können Sie beispielsweise den web-vitals-Selektor durch eine eigene Kennung ersetzen, die auf der Komponente basiert, in der sich das Ziel befindet, oder auf den ARIA-Rollen, die das Ziel erfüllt.

Ähnlich verhält es sich mit den scripts-Einträgen. Sie können dateibasierte Hashes in ihren sourceURL-Pfaden haben, die die Kombination erschweren. Sie können die Hashes jedoch basierend auf Ihrem bekannten Build-Prozess entfernen, bevor Sie die Daten zurücksenden.

Leider gibt es bei so komplexen Daten keinen einfachen Weg. Aber selbst die Verwendung einer Teilmenge ist für den Debugging-Prozess wertvoller als gar keine Attributionsdaten.

Attribution überall!

Die LoAF-basierte INP-Attribution ist eine leistungsstarke Debugging-Hilfe. Sie bietet detaillierte Daten darüber, was genau während eines INP passiert ist. In vielen Fällen können Sie damit die genaue Stelle in einem Skript finden, an der Sie mit der Optimierung beginnen sollten.

Sie können jetzt INP-Attributionsdaten auf jeder Website verwenden.

Auch wenn Sie keinen Zugriff auf die Bearbeitung einer Seite haben, können Sie den Prozess aus diesem Codelab nachvollziehen, indem Sie das folgende Snippet in der Entwicklertools-Konsole ausführen, um zu sehen, was Sie finden können:

const script = document.createElement('script');
script.src = 'https://unpkg.com/web-vitals@4/dist/web-vitals.attribution.iife.js';
script.onload = function () {
  webVitals.onINP(console.log, {reportAllChanges: true});
};
document.head.appendChild(script);

Weitere Informationen

• web.dev: Interaction to Next Paint
• web.dev: Find slow interactions in the field
• web.dev: Optimize Interaction to Next Paint
• Understanding INP codelab