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
• Empfehlung: Lesen Sie die INP-Dokumentation 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 Optimierung von INP beginnen sollten.

Voraussetzungen

• Ein Computer, auf dem Code von GitHub geklont und npm-Befehle ausgeführt werden 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 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. Abhängigkeiten installieren: npm ci.
4. Starten Sie den Webserver: npm run start.
5. Rufen Sie http://localhost:8080/ in Ihrem Browser 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 ein Gefühl dafür zu bekommen, welche Interaktionen langsam sind.

3. Erste Schritte mit den Chrome-Entwicklertools

Ö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 Leistungsbereich 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.

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 über npm installiert und direkt 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 Messung von INP in diesem Codelab benötigen wir die Attributionsversion.

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 Beaconing 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 werden immer dann aktualisiert, wenn es eine neue langsamste Interaktion gibt. Geben Sie beispielsweise etwas in das Suchfeld ein und löschen Sie die Eingabe dann wieder.

5. Was ist eine Quellenangabe?

Beginnen wir mit der ersten Interaktion, die die meisten Nutzer mit der Seite haben werden: dem Dialogfeld zur Einwilligung in die Verwendung von 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. Genau das passiert hier.

Klicken Sie auf Ja, um (Demo-)Cookies zu akzeptieren, und sehen Sie sich die INP-Daten an, die jetzt in der DevTools-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 Zeit 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 Property attribution am wichtigsten. Um die Attributionsdaten zu erstellen, ermittelt web-vitals, welche Long Animations Frame (LoAF) mit dem Click-Event übereinstimmt. 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: Ein Selektor zum Suchen des Elements auf der Seite.

Als Nächstes wird der Zeitablauf auf allgemeiner Ebene aufgeschlüsselt:

• 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 Event-Listener benötigen, um vollständig ausgeführt zu 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 dieser Zeit zusammengefasst. In diesem Fall dauert die Verarbeitung 295, 6 Millisekunden – der Großteil der INP-Zeit.
• presentationDelay: Die Zeit, die vergeht, bis die Event-Listener abgeschlossen sind und der Browser den nächsten Frame gerendert hat. 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 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 Click-Event. 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

Wenn Sie den LoAF-Eintrag maximieren:

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 Aufschlüsselung der 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 feststellen, 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 Element button#confirm (aus attribution.interactionTarget und der Property invoker in einem Skript-Attributionseintrag) ausgelöst.
• Die meiste Zeit wurde mit der Ausführung von Event-Listenern verbracht (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 sind genug Daten, 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 Cookie-Einwilligung nicht mehr die längste Interaktion ist.

Geben Sie Text in das Suchfeld ein. 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 unter 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 index.js-Quelldatei werden angegeben.

Es gibt jedoch eine neue Property: forcedStyleAndLayoutDuration. Das ist die Zeit, die für die Neugestaltung der Seite durch den Browser während dieses Skriptaufrufs benötigt wurde. 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.

Wiederkehrende Hö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 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 ein Tastendruck pro Frame verarbeitet wird.

7. Eingabeverzögerung

Der typische Grund für Eingabeverzögerungen – die Zeitspanne zwischen der Interaktion des Nutzers und dem Zeitpunkt, an dem ein Event-Listener mit der Verarbeitung der Interaktion beginnen kann – ist, dass der Hauptthread ausgelastet ist. Dafür kann es mehrere 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 das Schneckenlogo klicken, wird es animiert und es werden einige rechenintensive JavaScript-Vorgänge im Hauptthread ausgeführt.

• Klicken Sie auf das Schneckenlogo, 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 abprallt, 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 identifiziert werden kann.

Hier sehen Sie ein Beispiel für die Zuordnung, wenn der Fokus während des Schnecken-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 Fehlersuche in dieser Situation kann schwierig 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 darstellte. Stattdessen war es etwas anderes auf der Seite, das die Verarbeitung der Interaktion verzögerte. Aber wo sollten wir mit der Suche beginnen?

Hier kommen 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 nicht angezeigt wird

Die Präsentationsverzögerung misst die Zeitspanne zwischen dem Ende der Ausführung von Event-Listenern und dem Zeitpunkt, zu dem der Browser einen neuen Frame auf dem Bildschirm rendern 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 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 Verzögerung bei der Darstellung, die den Großteil der langsamen Interaktion ausmacht. Das bedeutet, dass alles, was den Hauptthread blockiert, nach Abschluss der Event-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 einer user-callback aus einer FrameRequestCallback verbracht wird. Dieses Mal wird die Präsentationsverzögerung durch einen requestAnimationFrame-Callback verursacht.

9. Fazit

Felddaten aggregieren

Es ist einfacher, wenn Sie sich einen einzelnen INP-Attributionseintrag aus einem einzelnen Seitenaufbau ansehen. 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 nützlich zu wissen, welches Seitenelement häufig für langsame Interaktionen verantwortlich ist. Wenn auf Ihrer Seite jedoch kompilierte CSS-Klassennamen verwendet werden, die sich von Build zu Build ändern, können sich web-vitals-Selektoren für dasselbe Element 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.

Ebenso können die scripts-Einträge dateibasierte Hashes in ihren sourceURL-Pfaden enthalten, 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 Grundlage von LoAF ist ein leistungsstarkes Tool zur Fehlerbehebung. Sie bietet detaillierte Daten dazu, was genau während einer INP passiert ist. In vielen Fällen kann er Sie auf die genaue Stelle in einem Script hinweisen, an der 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: Interaction to Next Paint optimieren
• Codelab zum INP