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

1. Einführung

In diesem interaktiven Codelab erfahren Sie, wie Sie Interaction to Next Paint (INP) mit der web-vitals-Bibliothek messen.

Vorbereitung

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

Lerninhalte

• So fügen Sie die web-vitals-Bibliothek auf Ihrer Seite ein und verwenden ihre Attributionsdaten.
• Mithilfe der Attributionsdaten können Sie herausfinden, wo und wie Sie mit der Verbesserung des INP beginnen sollten.

Voraussetzungen

• Ein Computer, auf dem Code von GitHub geklont und npm-Befehle ausgeführt werden können.
• Einen Texteditor.
• Eine aktuelle Version von Chrome, damit alle Interaktionsmessungen funktionieren.

2. Einrichten

Code abrufen und ausführen

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

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 ausprobieren

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

Interagieren Sie mit der Seite, um herauszufinden, welche Interaktionen langsam sind.

3. Chrome-Entwicklertools kennenlernen

Öffnen Sie die Entwicklertools über das Menü Weitere Tools > Entwicklertools, indem Sie mit der rechten Maustaste auf die Seite klicken und Untersuchen auswählen oder indem Sie einen Tastenkürzel verwenden.

In diesem Codelab verwenden wir sowohl das Leistungsübersicht-Panel als auch die Konsole. Sie können jederzeit über die Tabs oben in den DevTools zwischen den beiden Ansichten wechseln.

• INP-Probleme treten am häufigsten auf Mobilgeräten auf. Wechseln Sie daher zur Emulation der mobilen Anzeige.
• Wenn Sie auf einem Computer 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 Bereich Leistung auf das Zahnradsymbol und wählen Sie CPU 4x slowdown aus.

Sie können auch beide Bereiche gleichzeitig geöffnet haben. Wechseln Sie zum Bereich Leistung und drücken Sie dann die Esc-Taste, um die Konsole zu öffnen.

4. Installation von „web-vitals“

web-vitals ist eine JavaScript-Bibliothek zum Messen der Web Vitals-Messwerte, die Ihre Nutzer sehen. Sie können die Bibliothek verwenden, um diese Werte zu erfassen und dann an einen Analyseendpunkt zu senden, um später zu analysieren, 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, den Build-Prozess und andere Faktoren verwalten. In der Dokumentation der Bibliothek finden Sie alle Optionen.

In diesem Codelab wird das Script direkt aus npm installiert und geladen, um einen bestimmten Build-Prozess zu vermeiden.

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

• Der „Standard“-Build sollte verwendet werden, wenn Sie die Messwerte der Core Web Vitals bei einem Seitenaufbau erfassen möchten.
• Die „Attribution“-Version fügt jedem Messwert zusätzliche Debugging-Informationen hinzu, um zu analysieren, warum ein Messwert den jeweiligen Wert hat.

Für die INP-Messung in diesem Codelab benötigen wir den Attributions-Build.

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

Fügen Sie der Seite web-vitals hinzu:

Fügen Sie die Attributionsversion des Skripts 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

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

INP wird während des gesamten Lebenszyklus einer Seite gemessen. Daher wird INP in web-vitals standardmäßig erst gemeldet, wenn der Nutzer die Seite verlässt oder schließt. Das ist das ideale Verhalten für das Senden von Beacons für Analysen, aber weniger ideal für die interaktive Fehlersuche.

web-vitals bietet die Option reportAllChanges für ausführlichere Berichte. Wenn diese Option aktiviert ist, wird nicht jede Interaktion gemeldet, sondern nur, wenn eine Interaktion langsamer ist als die vorherige.

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 es eine neue langsamste Interaktion gibt. Geben Sie z. B. etwas in das Suchfeld ein und löschen Sie die Eingabe dann wieder.

5. Was enthält eine Quellenangabe?

Beginnen wir mit der ersten Interaktion, die die meisten Nutzer mit der Seite haben werden: dem Dialogfeld zur Einwilligung in Cookies.

Auf vielen Seiten sind Scripts vorhanden, für die Cookies synchron ausgelöst werden müssen, wenn ein Nutzer Cookies akzeptiert. Dadurch wird der Klick zu einer langsamen Interaktion. Das passiert hier.

Wenn Sie die Einwilligung zum Setzen von Cookies bereits abgelehnt haben, müssen Sie möglicherweise den lokalen Speicher der Demo leeren, damit sie wieder angezeigt wird. 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 Einwilligung in Cookies sollte dann wieder angezeigt werden.

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

Diese Informationen auf höchster Ebene sind sowohl in den Standard- als auch in den Attributions-Web-Vitals-Builds verfügbar:

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

Die Zeitspanne vom Klicken des Nutzers bis zum nächsten Rendern betrug 344 Millisekunden – ein INP, das verbessert werden muss. Das entries-Array 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 attribution-Property am interessantesten. Um die Attributionsdaten zu erstellen, ermittelt web-vitals, welche Long Animations Frame (LoAF) mit dem Klickereignis übereinstimmen. Der LoAF kann dann detaillierte Daten dazu 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 Property attribution, um weitere Informationen zu sehen. Die Daten sind viel umfassender.

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

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

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

Zuerst werden Informationen dazu angezeigt, womit interagiert wurde:

• interactionTargetElement: ein Live-Verweis auf das Element, mit dem interagiert wurde (sofern das Element nicht aus dem DOM entfernt wurde).
• interactionTarget: Eine Auswahl, mit der das Element auf der Seite gefunden wird.

Im Folgenden wird der Zeitablauf auf übergeordneter Ebene beschrieben:

• inputDelay: Die Zeit zwischen dem Beginn der Interaktion durch den Nutzer (z. B. Mausklick) und dem Start des Ereignis-Listeners für diese Interaktion. In diesem Fall betrug die Eingabeverzögerung nur etwa 27 Millisekunden, obwohl die CPU-Drosselung aktiviert war.
• processingDuration: Die Zeit, die benötigt wird, bis Event-Listener vollständig ausgeführt werden. 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 diesem Zeitraum zusammengefasst. In diesem Fall dauert die Verarbeitung 295,6 Millisekunden, was den Großteil der INP-Zeit ausmacht.
• presentationDelay: Die Zeitspanne zwischen dem Abschluss der Event-Listener und dem Zeitpunkt, zu dem der Browser den nächsten Frame gerendert hat. In diesem Fall 21, 4 Millisekunden.

Diese INP-Phasen können ein wichtiges Signal sein, um zu ermitteln, was optimiert werden muss. Weitere Informationen zu diesem Thema finden Sie im Leitfaden zur Optimierung von INP.

Wenn wir uns das genauer ansehen, enthält processedEventEntries fünf Ereignisse im Gegensatz zum einzelnen Ereignis im INP-Array entries 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 Attribution processedEventEntries umfasst alle Ereignisse, die während desselben Frames verarbeitet wurden. Beachten Sie, dass sie auch andere Ereignisse wie mouseover und mousedown enthält, 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 longAnimationFrameEntries-Array. Das kann ein einzelner Eintrag sein, aber es gibt Fälle, in denen sich eine Interaktion über mehrere Frames erstrecken kann. Hier sehen Sie den einfachsten Fall mit einem einzelnen langen Animationsframe.

longAnimationFrameEntries

So erweitern Sie den Eintrag „Standortangaben auf Google“:

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

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

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

Hier finden Sie eine Reihe nützlicher Werte, z. B. die Zeit, die für das Styling aufgewendet wurde. Im Artikel zur Long Animation Frames API werden diese Eigenschaften genauer beschrieben. Derzeit sind wir hauptsächlich an der Eigenschaft scripts interessiert, die Einträge mit Details zu den Skripts enthält, die für den Frame mit langer Laufzeit 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 meiste Zeit in einer einzelnen event-listener verbracht wurde, die 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 anhand dieser Attributionsdaten über diesen Fall ermitteln?

• Die Interaktion wurde durch einen Klick auf das button#confirm-Element ausgelöst (aus attribution.interactionTarget und der invoker-Property in einem Eintrag für die Script-Attribution).
• Die meiste Zeit wurde mit der Ausführung von Event-Listenern verbracht (von attribution.processingDuration im Vergleich zum Gesamtmesswert value).
• Der Code für den langsamen Event-Listener beginnt mit einem Klick-Listener, der in third-party/cmp.js (aus scripts.sourceURL) definiert ist.

Das reicht aus, um zu wissen, wo wir optimieren müssen.

6. Mehrere Event-Listener

Aktualisieren Sie die Seite, damit die Entwicklertools-Konsole leer ist und die Interaktion zur Einwilligung in die Verwendung von Cookies nicht mehr die längste Interaktion ist.

Beginnen Sie mit der Eingabe in das Suchfeld. Was zeigen die Attributionsdaten? Was denkst du, was los ist?

Attributionsdaten

Zuerst ein allgemeiner Überblick über 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: [...],
  }
}

Es handelt sich um einen schlechten INP-Wert (mit aktivierter CPU-Drosselung) aufgrund einer Tastatureingabe im input#search-terms-Element. Der Großteil der Zeit (1.061 Millisekunden von insgesamt 1.072 Millisekunden INP) wurde für die Verarbeitung aufgewendet.

Die Einträge für scripts sind jedoch interessanter.

Seitenflattern

Der erste Eintrag des scripts-Arrays liefert uns wertvollen Kontext:

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 (handleSearch) und die Zeichenposition in der Quelldatei index.js werden angegeben.

Es gibt jedoch eine neue Property: forcedStyleAndLayoutDuration. Das ist die Zeit, die der Browser während dieses Skriptaufrufs für das erneute Layout der Seite benötigt hat. Mit anderen Worten: 78% der Zeit, die für die Ausführung dieses Event-Listeners aufgewendet wurde (388 Millisekunden von 497), wurden tatsächlich für Layout-Thrashing verwendet.

Das sollte höchste Priorität haben.

Wiederholte Zuhörer

Die nächsten beiden Skripteinträge sind einzeln betrachtet nicht besonders bemerkenswert:

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. Wir haben jedoch weiterhin eine Quelldatei und eine Zeichenposition, sodass wir den Code finden können.

Das Seltsame daran ist, dass beide aus derselben Quelldatei und Zeichenposition stammen.

Der Browser hat mehrere Tastendrücke in einem einzigen Animationsframe verarbeitet, sodass dieser Event-Listener zweimal ausgeführt wurde, bevor etwas gerendert werden konnte.

Dieser Effekt kann sich auch verstärken: Je länger die Event-Listener zum Ausführen benötigen, desto mehr zusätzliche Eingabeereignisse können eingehen, wodurch die langsame Interaktion noch länger dauert.

Da es sich um eine Such-/Autocompletion-Interaktion handelt, wäre es eine gute Strategie, die Eingabe zu entprellen, sodass maximal eine Tasteneingabe pro Frame verarbeitet wird.

7. Eingabeverzögerung

Der typische Grund für Eingabeverzögerungen (die Zeitspanne zwischen der Interaktion des Nutzers und dem Zeitpunkt, zu dem ein Ereignis-Listener mit der Verarbeitung der Interaktion beginnen kann) ist, dass der Hauptthread ausgelastet ist. Dafür kann es verschiedene Gründe geben:

• Die Seite wird geladen und der Hauptthread ist mit der anfänglichen Arbeit beschäftigt, das DOM einzurichten, die Seite zu gestalten und zu formatieren sowie Skripts auszuwerten und auszuführen.
• Die Seite ist in der Regel stark ausgelastet, z. B. durch Berechnungen, skriptbasierte Animationen oder Anzeigen.
• Die Verarbeitung früherer Interaktionen dauert so lange, dass zukünftige Interaktionen verzögert werden, wie im letzten Beispiel zu sehen ist.

Die Demoseite hat eine geheime Funktion: Wenn Sie oben auf der Seite auf das Schneckenlogo klicken, wird es animiert und es werden einige rechenintensive JavaScript-Aufgaben 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 Ende des Bounces mit der Seite zu interagieren, und sehen Sie, wie hoch der INP ist, den Sie auslösen können.

Selbst wenn Sie keine anderen Event-Listener auslösen, z. B. durch Klicken und Fokussieren des Suchfelds genau dann, wenn die Schnecke hüpft, führt die Arbeit im Hauptthread dazu, dass die Seite für eine spürbare Zeit nicht reagiert.

Auf vielen Seiten ist die Hauptthread-Arbeit nicht so gut organisiert. Dieses Beispiel zeigt jedoch, wie sie in den INP-Attributionsdaten erkennbar sein kann.

Hier sehen Sie ein Beispiel für die Zuordnung, wenn der Fokus während des Snail Bounce nur auf dem Suchfeld liegt:

{
  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 vorhergesagt, wurden Event-Listener schnell ausgeführt – die Verarbeitungsdauer betrug 4,9 Millisekunden. Der Großteil der schlechten Interaktion war auf die Eingabeverzögerung zurückzuführen, die 702,3 Millisekunden von insgesamt 728 Millisekunden in Anspruch nahm.

Die Fehlerbehebung in dieser Situation kann schwierig sein. Wir wissen zwar, womit und wie der Nutzer interagiert hat, aber auch, dass dieser Teil der Interaktion schnell abgeschlossen wurde und kein Problem darstellte. Stattdessen war es etwas anderes auf der Seite, das die Verarbeitung der Interaktion verzögert hat. Aber wo sollten 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 erkennen, 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. Verzögerung bei der Darstellung: Wenn ein Update einfach nicht angezeigt wird

Die Präsentationsverzögerung gibt an, wie viel Zeit vergeht, bis der Browser einen neuen Frame auf dem Bildschirm rendern kann, nachdem die Event-Listener ausgeführt wurden.

Aktualisieren Sie die Seite, um den INP-Wert zurückzusetzen, und öffnen Sie dann das Dreistrich-Menü. Beim Öffnen gibt es einen deutlichen Ruck.

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: [{...}]
    }]
  }
}

Diesmal ist es die Präsentationsverzögerung, die den Großteil der langsamen Interaktion ausmacht. Das bedeutet, dass alles, was den Hauptthread blockiert, nach Abschluss der Event-Listener erfolgt.

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 aus einem FrameRequestCallback verbracht wird. Diesmal wird die Präsentationsverzögerung durch einen requestAnimationFrame-Callback verursacht.

Da requestAnimationFrame häufig zum Auslösen von JavaScript für Animationen in jedem Frame verwendet wird, wird es leicht als Auslösen eines Callbacks für den nächsten Frame angesehen. Tatsächlich wird jedoch ein Callback vor dem Rendern 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 einfacher, sich das alles anzusehen, wenn man sich einen einzelnen INP-Attributionseintrag aus einem einzelnen Seitenaufbau ansieht. Wie können diese Daten aggregiert werden, um INP anhand von Felddaten zu debuggen? Die Menge an hilfreichen Details macht es tatsächlich schwieriger.

Es ist beispielsweise sehr hilfreich zu wissen, welches Seitenelement häufig für langsame Interaktionen verantwortlich ist. Wenn Ihre Seite jedoch kompilierte CSS-Klassennamen hat, die sich von Build zu Build ändern, können sich web-vitals-Selektoren desselben Elements in verschiedenen Builds unterscheiden.

Stattdessen müssen Sie sich überlegen, was für Ihre spezielle Anwendung am nützlichsten ist und wie die Daten aggregiert werden können. Bevor Sie beispielsweise Attributionsdaten zurücksenden, können Sie den Selektor web-vitals 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.

Auch die scripts-Einträge können dateibasierte Hashes in ihren sourceURL-Pfaden haben, die das Kombinieren 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.

Überall Quellenangaben

Die INP-Attribution auf LoAF-Basis ist ein leistungsstarkes Debugging-Tool. Es bietet detaillierte Daten dazu, was genau während einer INP passiert ist. In vielen Fällen kann er Ihnen genau den Ort in einem Skript zeigen, an dem Sie mit der Optimierung beginnen sollten.

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

Auch wenn Sie keinen Zugriff zum Bearbeiten 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
• Codelab zum INP