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

1. Einführung

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

Vorbereitung

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

Lerninhalte

• So fügen Sie Ihrer Seite die web-vitals-Bibliothek hinzu und verwenden die zugehörigen Attributionsdaten.
• Anhand der Attributionsdaten können Sie feststellen, wo und wie Sie die Anzeigenleistung verbessern können.

Voraussetzungen

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

2. Einrichten

Code abrufen und ausführen

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

1. Klonen Sie das Repository in Ihrem Terminal: git clone https://github.com/GoogleChromeLabs/web-vitals-codelabs.git.
2. Rufen Sie das geklonte Verzeichnis auf: 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 das Gastropodicon (eine beliebte Referenzwebsite 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. 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 eine Tastenkombination verwenden.

In diesem Codelab verwenden wir sowohl den Bereich Leistung als auch die Console. Sie können jederzeit über die Tabs oben in den DevTools zwischen diesen wechseln.

• INP-Probleme treten am häufigsten auf Mobilgeräten auf. Stellen Sie daher auf die Displayemulation für Mobilgeräte um.
• Wenn Sie auf einem Computer oder Laptop testen, ist die Leistung wahrscheinlich deutlich besser als auf einem echten Mobilgerät. Wenn Sie sich ein realistischeres Bild der Leistung machen möchten, klicken Sie oben rechts im Bereich Leistung auf das Zahnrad und wählen Sie CPU-Verlangsamung um das Vierfache aus.

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

4. Web-Vitals installieren

web-vitals ist eine JavaScript-Bibliothek zum Erfassen der Web Vitals-Messwerte, die Ihre Nutzer sehen. Mit der Bibliothek können Sie diese Werte erfassen und dann zu einem Analyse-Endpunkt senden, um sie später zu analysieren. In unserem Fall geht es darum, herauszufinden, wann und wo es zu langsamen Interaktionen kommt.

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 verwalten, wie der Build-Prozess abläuft und von anderen Faktoren. In den Dokumenten der Bibliothek finden Sie alle Optionen.

In diesem Codelab wird das Script direkt über npm installiert und geladen, um einen bestimmten Buildprozess zu vermeiden.

Es gibt zwei Versionen von web-vitals:

• Verwenden Sie den Build „standard“, wenn Sie die Messwerte der Core Web Vitals beim Seitenaufbau erfassen möchten.
• Bei der Attribution werden jedem Messwert zusätzliche Informationen zur Fehlerbehebung hinzugefügt, um zu ermitteln, warum ein Messwert den jeweiligen Wert hat.

Für die Messung von indirekten Conversions in diesem Codelab benötigen wir die Attributionsaufschlüsselung.

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

Fügen Sie der Seite web-vitals hinzu:

Fügen Sie die Attributionsversion des Scripts unten in index.html ein und loggen 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 herumklicken, wird nichts protokolliert.

Der INP wird während des gesamten Lebenszyklus einer Seite gemessen. Daher wird in web-vitals standardmäßig kein INP erfasst, bis der Nutzer die Seite verlässt oder schließt. Das ist das ideale Verhalten für Beacons für Analysen, aber weniger ideal für die interaktive Fehlerbehebung.

web-vitals bietet die Option reportAllChanges für ausführlichere Berichte. Wenn diese Option aktiviert ist, werden nicht alle Interaktionen erfasst, sondern nur Interaktionen, die langsamer als die vorangegangenen sind.

Fügen Sie die Option dem Script hinzu und versuchen Sie noch einmal, mit der Seite zu interagieren:

<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 an die Konsole gesendet werden und bei jeder neuen langsamsten Interaktion aktualisiert werden. Geben Sie beispielsweise etwas in das Suchfeld ein und löschen Sie die Eingabe.

5. Was enthält eine Attribution?

Beginnen wir mit der allerersten Interaktion der meisten Nutzer mit der Seite, dem Dialogfeld zur Einwilligung in die Verwendung von Cookies.

Viele Seiten haben Scripts, die Cookies erfordern, die synchron ausgelöst werden, wenn Cookies von einem Nutzer akzeptiert werden. Dadurch wird der Klick zu einer langsamen Interaktion. Das passiert hier.

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

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 oberster Ebene sind sowohl in der Standard- als auch in der Attributionsversion von Web Vitals verfügbar:

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

Die Zeitspanne zwischen dem Klicken des Nutzers und dem nächsten Paint-Vorgang betrug 344 Millisekunden. Das ist ein INP vom Typ „Verbesserungsbedarf“. 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, sind wir jedoch am meisten an der Property attribution interessiert. Um die Attributionsdaten zu erstellen, ermittelt web-vitals, welcher Long Animations Frame (LoAF) mit dem Klickereignis übereinstimmt. Der LoAF kann dann detaillierte Daten dazu liefern, wie die Zeit in diesem Frame verbracht wurde, von den ausgeführten Scripts 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 umfangreicher.

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

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

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

Zuerst sehen Sie Informationen dazu, mit was interagiert wurde:

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

Als Nächstes wird der Zeitplan grob aufgeschlüsselt:

• inputDelay: Die Zeitspanne zwischen dem Start 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, selbst bei aktivierter CPU-Drosselung.
• processingDuration: die Zeit, die Ereignis-Listener benötigen, um vollständig ausgeführt zu werden. Oft 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 zu dieser Zeit zusammengeführt. In diesem Fall dauert die Verarbeitung 295,6 Millisekunden, was den Großteil der INP-Zeit ausmacht.
• presentationDelay: Die Zeitspanne zwischen dem Abschluss der Ereignis-Listener und dem Ende des Zeichnens 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 zu diesem Thema finden Sie im Leitfaden zur Optimierung von INP.

Bei genauerer Betrachtung enthält processedEventEntries fünf Ereignisse, im Gegensatz zum einzelnen Ereignis im INP-entries-Array der obersten 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 oberste Eintrag ist das INP-Ereignis, in diesem Fall ein Klick. Die Attribution processedEventEntries umfasst alle Ereignisse, die im selben Frame verarbeitet wurden. Beachten Sie, dass nicht nur das Klickereignis, sondern auch andere Ereignisse wie mouseover und mousedown enthalten sind. Informationen zu diesen anderen Ereignissen können entscheidend sein, wenn sie ebenfalls langsam waren, da sie alle zu einer langsamen Reaktion beigetragen haben.

Schließlich gibt es noch das Array longAnimationFrameEntries. Dies kann ein einzelner Eintrag sein, es gibt aber auch Fälle, in denen sich eine Interaktion über mehrere Frames erstreckt. Hier sehen wir den einfachsten Fall mit einem einzigen langen Animationsframe.

longAnimationFrameEntries

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 aufgeschlüsselte Zeit, die für das Design aufgewendet wurde. Im Artikel zur Long Animation Frames API werden diese Properties ausführlicher beschrieben. Derzeit sind wir vor allem an der Property scripts interessiert, die Einträge mit Details zu den Scripts enthält, die für den lang laufenden Frame 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 erkennen, dass die Zeit hauptsächlich in einer einzelnen event-listener verbracht wurde, die auf BUTTON#confirm.onclick aufgerufen wurde. Wir sehen sogar die URL der Scriptquelle und die Zeichenposition, an der die Funktion definiert wurde.

Fazit

Was lässt sich anhand dieser Attributionsdaten über diesen Fall sagen?

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

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

6. Mehrere Ereignis-Listener

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

Geben Sie einen Suchbegriff in das Suchfeld ein. Was zeigen die Attributionsdaten? Was könnte der Grund sein?

Attributionsdaten

Zuerst ein grober Überblick über ein Beispiel für den Test 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 ist ein niedriger INP-Wert (bei aktivierter CPU-Drosselung) bei einer Tastaturinteraktion mit dem 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 scripts-Einträge sind jedoch interessanter.

Layout-Überlastung

Der erste Eintrag des scripts-Arrays liefert uns 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 Verarbeitungszeit entfällt auf diese Scriptausführung, die ein input-Listener ist (INPUT#search-terms.oninput ist der Aufrufer). Der Funktionsname (handleSearch) und die Zeichenposition in der index.js-Quelldatei sind angegeben.

Es gibt jedoch eine neue Property: forcedStyleAndLayoutDuration. Dies ist die Zeit, die während dieser Scriptausführung verstrichen ist, in der der Browser gezwungen war, die Seite neu zu layouten. Mit anderen Worten: 78% der Zeit, die für die Ausführung dieses Ereignislisteners aufgewendet wurde (388 Millisekunden von 497), wurden für Layout-Auslastungen aufgewendet.

Das sollte mit höchster Priorität behoben werden.

Wiederholte Hörer

Die nächsten beiden Scripteinträ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 nacheinander ausgeführt werden. Die Listener sind anonyme Funktionen (darum wird in der sourceFunctionName-Eigenschaft nichts gemeldet). Wir haben jedoch eine Quelldatei und eine Zeichenposition, sodass wir den Code finden können.

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

Der Browser verarbeitete mehrere Tastenanschläge in einem einzigen Animationsframe, was dazu führte, dass dieser Ereignis-Listener zweimal ausgeführt wurde, bevor etwas gerendert werden konnte.

Dieser Effekt kann sich auch verstärken, je länger die Ereignis-Listener dauern, desto mehr zusätzliche Eingabeereignisse können auftreten, was die langsame Interaktion noch weiter verlängert.

Da es sich um eine Such-/Autocomplete-Interaktion handelt, wäre es eine gute Strategie, die Eingabe zu entprellen, damit pro Frame höchstens eine Tastenaktivierung verarbeitet wird.

7. Eingabeverzögerung

Der typische Grund für Eingabeverzögerungen (die Zeitspanne zwischen der Nutzerinteraktion und dem Beginn der Verarbeitung der Interaktion durch einen Ereignis-Listener) ist, dass der Hauptthread ausgelastet ist. Dafür kann es mehrere Gründe geben:

• Die Seite wird geladen und der Hauptthread ist mit der Ersteinrichtung des DOM, dem Layout und dem Stil der Seite sowie der Auswertung und Ausführung von Scripts beschäftigt.
• Die Seite ist im Allgemeinen ausgelastet, z. B. durch Berechnungen, scriptbasierte Animationen oder Anzeigen.
• Die Verarbeitung früherer Interaktionen dauert so lange, dass zukünftige Interaktionen verzögert werden, wie im letzten Beispiel gezeigt.

Die Demoseite hat eine geheime Funktion: Wenn Sie oben auf der Seite auf das Schneckenlogo klicken, wird es animiert und es werden einige intensive JavaScript-Arbeiten 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 Ende des Trampolins befindet. Versuchen Sie, so nah wie möglich am Ende des Bounces mit der Seite zu interagieren, und sehen Sie, wie hoch der INP sein kann.

Selbst wenn Sie beispielsweise keine anderen Ereignis-Listener auslösen, z. B. durch Klicken und Fokussieren des Suchfelds genau in dem Moment, in dem die Schnecke hüpft, führt die Arbeit im Haupt-Thread dazu, dass die Seite für einen spürbaren Zeitraum nicht reagiert.

Auf vielen Seiten ist die Auslastung des Hauptthreads nicht so gut, aber dies ist ein gutes Beispiel dafür, wie sich dies in den INP-Attributionsdaten erkennen lässt.

Hier ein Beispiel für eine Attribution, bei der das Suchfeld nur bei einem langsamen Absprung fokussiert wird:

{
  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 ging auf die Eingabeverzögerung zurück, die 702,3 Millisekunden von insgesamt 728 Millisekunden in Anspruch nahm.

Diese Situation kann die Fehlerbehebung erschweren. Wir wissen zwar, mit was 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 woher sollten wir wissen, wo wir suchen müssen?

LoAF-Scripteinträge sind die Lösung:

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
}]

Auch wenn 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 zusammengeführt werden.

So sehen wir, wie die Funktion, die die Interaktionsverarbeitung verzögert hat, ausgelöst wurde (durch einen animationiteration-Listener), welche Funktion genau dafür verantwortlich war und wo sie sich in unseren Quelldateien befindet.

8. Präsentationsverzögerung: Ein Update wird nicht angezeigt

Die Präsentationsverzögerung gibt an, wie lange es dauert, bis der Browser nach dem Ausführen der Ereignis-Listener einen neuen Frame auf dem Bildschirm anzeigen kann, der für den Nutzer sichtbares Feedback liefert.

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

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 das, was den Hauptthread blockiert, nach Abschluss der Ereignisereignisse 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. Diesmal wird die Verzögerung durch einen requestAnimationFrame-Callback verursacht.

Da requestAnimationFrame häufig zum Auslösen von JavaScript in jedem Frame für Animationen verwendet wird, kann man sich leicht vorstellen, dass damit ein Callback für den nächsten Frame ausgelöst wird. Tatsächlich wird aber ein Callback bevor der aktuelle Frame vom Browser gerendert wird, angefordert. Das bedeutet, dass ein langsamer requestAnimationFrame-Callback, der durch eine Interaktion ausgelöst wird, diese Interaktion verlangsamt und mit höherer Wahrscheinlichkeit zu einer schlechten INP führt.

9. Fazit

Felddaten aggregieren

Beachten Sie, dass dies alles einfacher ist, wenn Sie sich einen einzelnen INP-Attributionseintrag aus einem einzelnen Seitenladevorgang ansehen. Wie können diese Daten zusammengefasst werden, um INP anhand von Felddaten zu debuggen? Die Menge an hilfreichen Details macht das jedoch schwieriger.

Es ist beispielsweise sehr nützlich zu wissen, welches Seitenelement häufig zu langsamen Interaktionen führt. Wenn Ihre Seite jedoch kompilierte CSS-Klassennamen enthält, 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 Ihre spezifische Anwendung überlegen, um zu bestimmen, was am nützlichsten ist und wie die Daten aggregiert werden können. Bevor Sie die Attributionsdaten per Beacon zurückgeben, können Sie beispielsweise die web-vitals-Auswahl mit einer eigenen Kennung ersetzen, die auf der Komponente basiert, in der sich das Ziel befindet, oder auf den ARIA-Rollen, die das Ziel erfüllt.

Ähnlich können die scripts-Einträge dateibasierte Hash-Werte in ihren sourceURL-Pfaden enthalten, die eine Kombination erschweren. Sie können die Hash-Werte jedoch anhand Ihres bekannten Build-Prozesses entfernen, bevor Sie die Daten zurückgeben.

Leider gibt es bei so komplexen Daten keine einfache Lösung. Aber selbst die Verwendung eines Teils der Daten ist für den Fehlerbehebungsprozess wertvoller als gar keine Attributionsdaten.

Attribution überall

Die LoAF-basierte INP-Attribution 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 den genauen Ort in einem Script verweisen, an dem Sie mit der Optimierung beginnen sollten.

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

Auch wenn Sie keinen Zugriff zum Bearbeiten einer Seite haben, können Sie den Prozess aus diesem Codelab nachstellen. Führen Sie dazu einfach das folgende Snippet in der DevTools-Konsole aus, um zu sehen, was Sie finden:

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: Langsame Interaktionen im Feld finden
• web.dev: Interaction to Next Paint optimieren
• INP-Codelab