API für Frames für lange Animationen

Die Long Animation Frames API (LoAF – ausgesprochen Lo-Af) ist eine Aktualisierung der Long Tasks API, um langsame UI-Updates besser nachvollziehen zu können. Dies kann nützlich sein, um langsame Animationsframes zu ermitteln, die sich wahrscheinlich auf den Core Web Vital-Messwert Interaction to Next Paint (INP) auswirken, der die Reaktionszeit misst, oder um andere UI-Verzögerungen zu ermitteln, die sich auf die Flüssigkeit auswirken.

Status der API

Nach einem Ursprungstest von Chrome 116 zu Chrome 122 wurde die LoAF API aus Chrome 123 ausgeliefert.

Long Tasks API

Das Long Animation Frames API ist eine Alternative zum Long Tasks API, das seit Chrome 58 schon seit einiger Zeit in Chrome verfügbar ist. Wie der Name schon sagt, können Sie mit der Long Task API lange Aufgaben überwachen. Das sind Aufgaben, die den Hauptthread 50 Millisekunden oder länger in Anspruch nehmen. Lange Aufgaben können über die PerformanceLongTaskTiming-Schnittstelle mit einem PeformanceObserver überwacht werden:

const observer = new PerformanceObserver((list) => {
  console.log(list.getEntries());
});

observer.observe({ type: 'longtask', buffered: true });

Lange Aufgaben führen häufig zu Problemen mit der Reaktionszeit. Wenn ein Nutzer versucht, mit einer Seite zu interagieren, z. B. auf eine Schaltfläche zu klicken oder ein Menü zu öffnen, der Hauptthread aber bereits mit einer langen Aufgabe zu tun hat, verzögert sich die Interaktion des Nutzers, bis die Aufgabe abgeschlossen ist.

Um die Reaktionsfähigkeit zu verbessern, wird häufig empfohlen, lange Aufgaben aufzuteilen. Wenn jede lange Aufgabe stattdessen in eine Reihe von mehreren, kleineren Aufgaben aufgeteilt wird, können wichtigere Aufgaben dazwischen ausgeführt werden, um erhebliche Verzögerungen bei der Reaktion auf Interaktionen zu vermeiden.

Wenn Sie also die Reaktionszeit verbessern möchten, besteht der erste Versuch oft darin, eine Leistungsverfolgung auszuführen und sich lange Aufgaben anzusehen. Das könnte über ein Lab-basiertes Auditing-Tool wie Lighthouse (mit dem Audit Lange Hauptthread-Aufgaben vermeiden) oder das Prüfen langer Aufgaben in den Chrome-Entwicklertools sein.

Lab-basierte Tests sind oft eine schlechte Ausgangsbasis für die Identifizierung von Reaktionsproblemen, da diese Tools möglicherweise keine Interaktionen umfassen – sie sind nur eine kleine Teilmenge wahrscheinlicher Interaktionen. Idealerweise würden Sie die Ursachen für langsame Interaktionen vor Ort messen.

Schwachstellen der Long Tasks API

Lange Aufgaben vor Ort mit einem Performance Observer zu messen, ist nicht sehr hilfreich. In Wirklichkeit liefert sie aber nicht so viele Informationen, außer dass eine lange Aufgabe stattgefunden hat und wie lange sie gedauert hat.

RUM-Tools (Real User Monitoring) verwenden diese Funktion häufig, um die Anzahl oder Dauer langer Aufgaben zu verfolgen oder zu ermitteln, auf welchen Seiten sie ausgeführt werden. Aber ohne die zugrunde liegenden Details zur Ursache der langen Aufgabe ist dies nur von begrenzter Verwendung. Die Long Tasks API verfügt nur über ein grundlegendes Attributionsmodell, das Ihnen im besten Fall nur den Container mitteilt, in dem die lange Aufgabe ausgeführt wurde (in dem Dokument auf oberster Ebene oder ein <iframe>), aber nicht das Skript oder die Funktion, mit dem bzw. der sie aufgerufen wurde, wie ein typischer Eintrag zu sehen ist:

{
  "name": "unknown",
  "entryType": "longtask",
  "startTime": 31.799999997019768,
  "duration": 136,
  "attribution": [
    {
      "name": "unknown",
      "entryType": "taskattribution",
      "startTime": 0,
      "duration": 0,
      "containerType": "window",
      "containerSrc": "",
      "containerId": "",
      "containerName": ""
    }
  ]
}

Die Long Tasks API ist ebenfalls unvollständig, da sie auch einige wichtige Aufgaben ausschließen kann. Einige Aktualisierungen, wie das Rendering, finden in separaten Aufgaben statt, die idealerweise zusammen mit der vorherigen Ausführung einbezogen werden sollten. Diese Aktualisierung hat dazu geführt, dass die „Gesamtarbeit“ für diese Interaktion genau gemessen wird. Weitere Informationen zu den Einschränkungen bei der Verwendung von Aufgaben finden Sie im Abschnitt Wann lange Aufgaben nicht erledigt werden der Erläuterung.

Das letzte Problem ist, dass bei der Messung langer Aufgaben nur einzelne Aufgaben erfasst werden, die länger als die 50-Millisekunden-Grenze dauern. Ein Animationsframe könnte aus mehreren Aufgaben bestehen, die unterhalb dieser 50-Millisekunden-Grenze liegen, aber dennoch gemeinsam das Rendering des Browsers blockieren.

Long Animation Frames API

Die Long Animation Frames API (LoAF) ist eine neue API, mit der einige der Schwachstellen der Long Tasks API behoben werden sollen. Sie soll Entwicklern mehr umsetzbare Informationen zur Behebung von Reaktionsproblemen und zur Verbesserung von INP ermöglichen.

Gute Reaktionszeiten bedeutet, dass eine Seite schnell auf Interaktionen reagiert, die mit ihr erfolgen. Dazu gehört, dass Sie alle von Nutzern benötigten Aktualisierungen zeitnah darstellen können und vermeiden, dass diese Aktualisierungen blockiert werden. Für INP empfiehlt es sich, innerhalb von 200 Millisekunden oder weniger zu antworten. Bei anderen Updates (z. B. Animationen) können diese jedoch zu lang sein.

Die Long Animation Frames API ist ein alternativer Ansatz zum Messen der Blockierarbeit. Anstatt die einzelnen Aufgaben zu messen, werden mit der Long Animation Frames API – wie der Name schon sagt – lange Animationsframes gemessen. Ein langer Animations-Frame liegt vor, wenn eine Rendering-Aktualisierung um mehr als 50 Millisekunden verzögert wird (entspricht dem Grenzwert für die Long Tasks API).

Lange Animationsframes können auf ähnliche Weise beobachtet werden wie lange Aufgaben mit einem PerformanceObserver, aber wenn stattdessen der Typ long-animation-frame betrachtet wird:

const observer = new PerformanceObserver((list) => {
  console.log(list.getEntries());
});

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

Vorherige lange Animationsframes können auch so über die Leistungszeitachse abgefragt werden:

const loafs = performance.getEntriesByType('long-animation-frame');

Es gibt jedoch ein maxBufferSize für Leistungseinträge, nach dem neuere Einträge gelöscht werden, sodass der Ansatz „PerformanceObserver“ der empfohlene Ansatz ist. Die Puffergröße für long-animation-frame ist auf 200 festgelegt, genau wie für long-tasks.

Vorteile von Frames anstelle von Aufgaben

Der Hauptvorteil, dies aus der Frame-Perspektive statt aus der Aufgabenperspektive zu betrachten, ist, dass eine lange Animation aus einer beliebigen Anzahl von Aufgaben bestehen kann, die insgesamt zu einem langen Animations-Frame führen. Dies ist der letzte Punkt, den wir zuvor erwähnt haben, wo die Summe aus vielen kleineren Aufgaben, die das Rendering blockieren, vor einem Animationsframe möglicherweise nicht von der Long Tasks API angezeigt werden kann.

Ein weiterer Vorteil dieser alternativen Ansicht bei langen Aufgaben besteht in der Möglichkeit, zeitliche Aufschlüsselungen des gesamten Frames bereitzustellen. Anstatt wie bei der Long Tasks API nur ein startTime und ein duration einzubinden, enthält LoAF eine viel detailliertere Aufschlüsselung der verschiedenen Teile der Framedauer, darunter:

• startTime: Startzeit des langen Animationsframes im Verhältnis zur Startzeit der Navigation.
• duration: die Dauer des langen Animations-Frames (ohne Präsentationszeit).
• renderStart: die Startzeit des Renderingzyklus, einschließlich requestAnimationFrame-Callbacks, Stil- und Layoutberechnung, Beobachtervergrößerung und Callback-Beobachter-Callbacks.
• styleAndLayoutStart: der Beginn des Zeitraums, der für Stil- und Layoutberechnungen aufgewendet wird.
• firstUIEventTimestamp: die Zeit des ersten UI-Ereignisses (Maus/Tastatur usw.), das im Verlauf dieses Frames verarbeitet werden soll.
• blockingDuration: die Dauer in Millisekunden, während der der Animationsframe blockiert wurde.

Mithilfe dieser Zeitstempel kann der Frame für die lange Animation in Timings unterteilt werden:

Dauer	Berechnung
Beginn	startTime
Ende	startTime + duration
Arbeitsdauer	renderStart ? renderStart - startTime : duration
Renderingdauer	renderStart ? (startTime + duration) - renderStart: 0
Rendering: Dauer des Vorlayouts	styleAndLayoutStart ? styleAndLayoutStart - renderStart : 0
Rendering: Stil und Layoutdauer	styleAndLayoutStart ? (startTime + duration) - styleAndLayoutStart : 0

Weitere Informationen zu diesen einzelnen Timings finden Sie in der Erläuterung. Dort finden Sie detaillierte Informationen dazu, welche Aktivität zu einem langen Animationsframe beigetragen hat.

Bessere Attribution

Der Eintragstyp long-animation-frame enthält bessere Attributionsdaten für jedes Skript, das zu einem langen Animationsframe beigetragen hat.

Ähnlich wie bei der Long Tasks API wird dies in einem Array von Zuordnungseinträgen bereitgestellt, die jeweils folgende Details enthalten:

• Für name und EntryType wird jeweils script zurückgegeben.
• Eine aussagekräftige invoker, die angibt, wie das Skript aufgerufen wurde, z. B. 'IMG#id.onload', 'Window.requestAnimationFrame' oder 'Response.json.then'.
• invokerType des Skripteinstiegspunkts:
  • user-callback: Ein bekannter Callback, der von einer Webplattform-API registriert wurde (z. B. setTimeout oder requestAnimationFrame).
  • event-listener: Ein Listener für ein Plattformereignis (z. B. click, load, keyup).
  • resolve-promise: Handler eines Plattform-Promise (z. B. fetch()). Im Fall von Promise-Werten werden alle Handler derselben Promise zu einem einzigen „Script“ vermischt..
  • reject-promise: Gemäß resolve-promise, aber für die Ablehnung.
  • classic-script: Skriptauswertung (z. B. <script> oder import())
  • module-script: wie classic-script, aber für Modulskripts.
• Separate Zeitdaten für das Script:
  • startTime: Zeitpunkt, zu dem die Eingabefunktion aufgerufen wurde.
  • duration: Der Zeitraum zwischen startTime und dem Zeitpunkt, zu dem die nachfolgende Mikroaufgabenwarteschlange die Verarbeitung abgeschlossen hat.
  • executionStart: Die Zeit nach der Kompilierung.
  • forcedStyleAndLayoutDuration: Die Gesamtzeit, die für die Verarbeitung des erzwungenen Layouts/Stils in dieser Funktion aufgewendet wurde (siehe Thrashing).
  • pauseDuration: Gesamtzeit, die für synchrone Vorgänge zum "Anhalten" aufgewendet wurde (Warnung, synchrone XHR).
• Details zur Skriptquelle:
  • sourceURL: Der Name der Skriptressource, falls verfügbar (oder leer, wenn er nicht gefunden wird).
  • sourceFunctionName: Name der Skriptfunktion, falls verfügbar (oder leer, wenn er nicht gefunden wird)
  • sourceCharPosition: Die Zeichenposition des Skripts, sofern verfügbar (oder -1, wenn sie nicht gefunden wird).
• windowAttribution: Der Container (das Dokument der obersten Ebene oder <iframe>), in dem der Frame mit langer Animation angezeigt wurde.
• window: ein Verweis auf das Fenster mit demselben Ursprung.

Sofern angegeben, können Entwickler anhand der Quelleinträge genau wissen, wie jedes Skript im langen Animationsframe aufgerufen wurde, bis hin zur Zeichenposition im aufrufenden Skript. Dadurch wird der genaue Speicherort in einer JavaScript-Ressource angegeben, der zu dem langen Animationsframe geführt hat.

Beispiel für einen long-animation-frame-Leistungseintrag

Ein vollständiges Beispiel für einen long-animation-frame-Leistungseintrag mit einem einzelnen Skript lautet:

{
  "blockingDuration": 0,
  "duration": 60,
  "entryType": "long-animation-frame",
  "firstUIEventTimestamp": 11801.099999999627,
  "name": "long-animation-frame",
  "renderStart": 11858.800000000745,
  "scripts": [
    {
      "duration": 45,
      "entryType": "script",
      "executionStart": 11803.199999999255,
      "forcedStyleAndLayoutDuration": 0,
      "invoker": "DOMWindow.onclick",
      "invokerType": "event-listener",
      "name": "script",
      "pauseDuration": 0,
      "sourceURL": "https://web.dev/js/index-ffde4443.js",
      "sourceFunctionName": "myClickHandler",
      "sourceCharPosition": 17796,
      "startTime": 11803.199999999255,
      "window": [Window object],
      "windowAttribution": "self"
    }
  ],
  "startTime": 11802.400000000373,
  "styleAndLayoutStart": 11858.800000000745
}

Wie Sie sehen, bedeutet dies eine noch nie dagewesene Datenmenge, mit der Websites die Ursache verzögerter Rendering-Aktualisierungen ermitteln können.

Long Animation Frames API aktivieren

Die Long Animation Frames API ist ab Chrome 123 standardmäßig aktiviert.

Verwendung der Long Animation Frames API im Außendienst

Tools wie Lighthouse sind nützlich, um Probleme zu erkennen und zu reproduzieren, sind aber Labortools, denen möglicherweise wichtige Aspekte der User Experience fehlen, die nur Felddaten bieten können. Die Long Animation Frames API kann vor Ort verwendet werden, um wichtige Kontextdaten für Nutzerinteraktionen zu sammeln, die die Long Tasks API nicht erfassen konnte. So können Sie Interaktivitätsprobleme erkennen und reproduzieren, die Ihnen sonst vielleicht nicht aufgefallen wären.

Einige vorgeschlagene Strategien sind im Folgenden aufgeführt. Das Chrome-Team würde jedoch gerne Feedback zu dieser API hören und wissen, wie Entwickler und RUM-Anbieter die Informationen, die die API bereitstellt, nutzen würden.

Erkennung der Unterstützung der Long Animation Frames API

Mit dem folgenden Code können Sie testen, ob die API unterstützt wird:

if (PerformanceObserver.supportedEntryTypes.includes('long-animation-frame')) {
  // Monitor LoAFs
}

In diesem Fall kann die folgende Alternative verwendet werden, obwohl lange Animationsframes noch nicht standardmäßig unterstützt werden und sich in diesem Übergangsstatus befinden:

if ('PerformanceLongAnimationFrameTiming' in window) {
  // Monitor LoAFs
}

Lange Animationsdaten an einen Analyseendpunkt zurückmelden

Wie gezeigt, enthält der LoAF-Leistungseintrag wertvolle Informationen. Eine Strategie wäre es, alle LoAFs zu überwachen und diejenigen, die über einem bestimmten Schwellenwert liegen, zur späteren Analyse an einen Analyseendpunkt zurückzusenden:

const REPORTING_THRESHOLD_MS = 150;

const observer = new PerformanceObserver(list => {
  for (const entry of list.getEntries()) {
    if (entry.duration > REPORTING_THRESHOLD_MS) {
      // Example here logs to console, but could also report back to analytics
      console.log(entry);
    }
  }
});
observer.observe({ type: 'long-animation-frame', buffered: true });

Da die Einträge langer Animationsframes recht groß sein können, sollten Entwickler entscheiden, welche Daten des Eintrags an Analytics gesendet werden sollen. Zum Beispiel die Zusammenfassungszeiten des Eintrags und vielleicht die Skriptnamen oder ein anderer Mindestsatz anderer kontextbezogener Daten, die als notwendig erachtet werden können.

Schlechteste lange Animationsframes beobachten

Möglicherweise möchten Websites Daten über die längsten Animationsframes (oder Frames) sammeln, um die Datenmenge zu reduzieren, die für das Beaconing erforderlich ist. Unabhängig von der Anzahl der langen Animationsframes einer Seite werden also nur die Daten für die schlechtesten, fünf oder die unbedingt notwendigen langen Animationsframes zurückgegeben.

MAX_LOAFS_TO_CONSIDER = 10;
let longestBlockingLoAFs = [];

const observer = new PerformanceObserver(list => {
  longestBlockingLoAFs = longestBlockingLoAFs.concat(list.getEntries()).sort(
    (a, b) => b.blockingDuration - a.blockingDuration
  ).slice(0, MAX_LOAFS_TO_CONSIDER);
});
observer.observe({ type: 'long-animation-frame', buffered: true });

Melde dich zum entsprechenden Zeitpunkt (idealerweise beim visibilitychange-Ereignis) an Analytics zurück. Für lokale Tests können Sie regelmäßig console.table verwenden:

console.table(longestBlockingLoAFs);

Mit der längsten INP-Interaktion verknüpfen

Als Erweiterung der Beobachtung der schlechtesten LoAF-Frames, die dem INP-Eintrag entsprechen, könnten die LOAF-Frames, die dem INP-Eintrag entsprechen, als Attributionsdaten verwendet werden, um weitere Details zur Verbesserung von INP zu liefern.

Derzeit gibt es keine direkte API, um einen INP-Eintrag mit dem zugehörigen LoAF-Eintrag oder den zugehörigen LoAF-Einträgen zu verknüpfen. Dies ist jedoch im Code durch einen Vergleich der Start- und Endzeiten möglich (siehe dieses Beispielskript).

Berichte über lange Animationsframes mit Interaktionen erstellen

Ein alternativer Ansatz, der weniger Code erfordert, wäre, immer die größten (oder die Top-X-größten) LoAF-Einträge zu senden, bei denen während des Frames eine Interaktion aufgetreten ist (die durch das Vorhandensein eines firstUIEventTimestamp-Werts erkannt werden kann). In den meisten Fällen umfasst dies die INP-Interaktion für einen bestimmten Besuch. In seltenen Fällen werden auch lange Interaktionen angezeigt, die behoben werden müssen, da sie für andere Nutzer möglicherweise die INP-Interaktion sind.

Mit dem folgenden Code werden alle LoAF-Einträge mit einer Dauer von mehr als 150 Millisekunden protokolliert, bei denen während des Frames eine Interaktion aufgetreten ist. Hier wurde der Wert von 150 ausgewählt, weil er etwas unter dem INP-Grenzwert von 200 Millisekunden liegt. Sie können je nach Ihren Anforderungen einen höheren oder niedrigeren Wert auswählen.

const REPORTING_THRESHOLD_MS = 150;

const observer = new PerformanceObserver(list => {
    for (const entry of list.getEntries()) {
      if (entry.duration > REPORTING_THRESHOLD_MS &&
        entry.firstUIEventTimestamp > 0
      ) {
        // Example here logs to console, but could also report back to analytics
        console.log(entry);
      }
    }
});
observer.observe({ type: 'long-animation-frame', buffered: true });

Häufige Muster in langen Animationsframes identifizieren

Eine alternative Strategie wäre die Betrachtung gängiger Skripts, die am häufigsten in Einträgen für lange Animationsframes erscheinen. Daten können auf Skript- und/oder Zeichenpositionsebene gemeldet werden, um Wiederholungstäter zu identifizieren.

Das funktioniert besonders gut für anpassbare Plattformen, auf denen Designs oder Plug-ins, die Leistungsprobleme verursachen, auf mehreren Websites leichter identifiziert werden können.

Die Ausführungszeit von gängigen Skripts – oder von Drittanbietern – in langen Animations-Frames kann summiert und gemeldet werden, um zu ermitteln, was häufig zu langen Animationsframes auf einer Website oder auf mehreren Websites beiträgt. Beispiele für URLs:

const observer = new PerformanceObserver(list => {
  const allScripts = list.getEntries().flatMap(entry => entry.scripts);
  const scriptSource = [...new Set(allScripts.map(script => script.sourceURL))];
  const scriptsBySource= scriptSource.map(sourceURL => ([sourceURL,
      allScripts.filter(script => script.sourceURL === sourceURL)
  ]));
  const processedScripts = scriptsBySource.map(([sourceURL, scripts]) => ({
    sourceURL,
    count: scripts.length,
    totalDuration: scripts.reduce((subtotal, script) => subtotal + script.duration, 0)
  }));
  processedScripts.sort((a, b) => b.totalDuration - a.totalDuration);
  // Example here logs to console, but could also report back to analytics
  console.table(processedScripts);
});

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

Und ein Beispiel für diese Ausgabe ist:

(index)	sourceURL	count	totalDuration
0	'https://example.consent.com/consent.js'	1	840
1	'https://example.com/js/analytics.js'	7	628
2	'https://example.chatapp.com/web-chat.js'	1	5

Long Animation Frames API in Tools verwenden

Die API kann auch zusätzliche Entwicklertools für die lokale Fehlerbehebung ermöglichen. Einige Tools wie Lighthouse und die Chrome-Entwicklertools konnten einen Großteil dieser Daten mithilfe von untergeordneten Tracing-Details erfassen. Mit dieser API auf höherer Ebene könnten auch andere Tools auf diese Daten zugreifen.

Daten aus langen Animationsframes in den Entwicklertools anzeigen

In den Entwicklertools können Sie mit der performance.measure() API lange Animationsframes einblenden. Diese werden dann im Nutzer-Timing-Track der Entwicklertools in Leistungs-Traces angezeigt, um zu zeigen, worauf Sie sich konzentrieren sollten, um die Leistung zu verbessern:

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    performance.measure('LoAF', {
      start: entry.startTime,
      end: entry.startTime + entry.duration,
    });
  }
});

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

Wenn sich diese API langfristig als nützlich erweist, wird sie wahrscheinlich in die Entwicklertools selbst integriert. Das vorherige Code-Snippet ermöglicht es jedoch, sie dort in der Zwischenzeit aufzudecken.

Verwendung von Daten aus langen Animationsframes in anderen Entwicklertools

Mit der Web Vitals-Erweiterung lassen sich zusammenfassende Informationen zur Fehlerbehebung protokollieren, um Leistungsprobleme zu diagnostizieren. Jetzt wird die API eingeführt. Mit diesen Tools können Sie nun leichter Daten abrufen und Entwickelnden darüber informieren, worauf sie sich konzentrieren müssen. Wir planen außerdem, diese Funktion in Version 4 der Web Vitals-JavaScript-Bibliothek hinzuzufügen.

Daten langer Animationsframes in automatisierten Testtools verwenden

Ähnlich automatisierte Testtools, z. B. in CI/CD-Pipelines, könnten Details zu potenziellen Leistungsproblemen aufdecken, indem lange Animationsframes gemessen werden, während verschiedene Testsuiten ausgeführt werden.

Häufig gestellte Fragen

Hier einige der häufig gestellten Fragen zu dieser API:

Warum wird nicht einfach die Long Tasks API erweitert oder iteriert?

Dies ist eine alternative Möglichkeit, ein ähnliches – aber letztendlich unterschiedliches – Maß für potenzielle Probleme mit der Reaktionszeit zu melden. Websites, die auf die bestehende Long Tasks API zurückgreifen, müssen auch weiterhin funktionieren, damit bestehende Anwendungsfälle nicht unterbrochen werden.

Während die Long Tasks API von einigen Funktionen von LoAF profitieren kann (z. B. ein besseres Attributionsmodell), sind wir der Meinung, dass sich der Fokus auf Frames statt auf Aufgaben viele Vorteile bietet, die diese API grundlegend von der bestehenden Long Tasks API unterscheiden.

Wird dadurch die Long Tasks API ersetzt?

Wir sind der Meinung, dass das Long Animation Frames API ein besseres, umfassenderes API für die Messung langer Aufgaben ist. Derzeit ist es jedoch nicht geplant, das Long Tasks API einzustellen.

Feedback erwünscht

Sie können Feedback über die Liste der GitHub-Probleme geben oder Fehler bei der Implementierung der API in Chrome über den Issue Tracker von Chrome melden.

Fazit

Das Long Animation Frames API ist eine spannende neue API mit vielen potenziellen Vorteilen gegenüber der vorherigen Long Tasks API.

Gemäß INP-Messung erweist sich dies als ein wichtiges Werkzeug bei der Lösung von Problemen mit der Reaktionszeit. INP ist ein schwierig zu optimierender Messwert und diese API ist eine Möglichkeit für das Chrome-Team, Probleme für Entwickler leichter zu erkennen und zu beheben.

Der Umfang der Long Animation Frames API geht jedoch über INP hinaus und kann dabei helfen, andere Ursachen für langsame Updates zu erkennen, die sich auf die Gesamtflüssigkeit einer Website auswirken können.

Danksagungen

Miniaturansicht von Henry Be auf Unsplash.