Interfejs API Long Animation Frames

Barry Pollard

Noam Rosenthal

Interfejs Long Animation Frames API (Lo-Af nazywany w języku LoAF) to aktualizacja interfejsu Long Animation API, która ma zapewnić lepsze zrozumienie powolnych aktualizacji interfejsu użytkownika. Może to być przydatne do identyfikowania spowolnionych klatek animacji, które mogą mieć wpływ na podstawowy wskaźnik internetowy interakcji z następnym wyrenderowaniem (INP), który mierzy czas reagowania, lub do identyfikowania innych zacięć interfejsu, które wpływają na płynność.

Stan interfejsu API

Po testowaniu origin z Chrome 116 do Chrome 122 interfejs LoAF API został wysłany z Chrome 123.

Informacje ogólne: interfejs Long Tasks API

Interfejs Long Animation Frames API jest alternatywą dla interfejsu API Long Tasks API, który jest dostępny w Chrome już od pewnego czasu (od wersji Chrome 58). Jak sama nazwa wskazuje, interfejs Long Task API umożliwia monitorowanie długich zadań, czyli zadań, które zajmują w wątku głównym przez co najmniej 50 milisekund. Długie zadania można monitorować za pomocą interfejsu PerformanceLongTaskTiming i PeformanceObserver:

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

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

Długie zadania mogą powodować problemy z czasem reakcji. Jeśli użytkownik próbuje wejść w interakcję ze stroną – na przykład kliknąć przycisk lub otworzyć menu, ale wątek główny zajmuje się już długim zadaniem, jest opóźniona w oczekiwaniu na ukończenie tego zadania.

Aby poprawić czas reagowania, często zaleca się podzielenie długich zadań. Jeśli każde długie zadanie zostanie podzielone na kilka mniejszych zadań, może to umożliwić wykonywanie ważniejszych zadań między nimi, co pozwoli uniknąć znacznych opóźnień w reagowaniu na interakcje.

Kiedy próbujesz poprawić responsywność, pierwszym krokiem jest często wykonanie zrzutu danych i przyjrzenie się długim zadaniom. Można to zrobić za pomocą narzędzia kontrolnego opartego na laboratorium, takiego jak Lighthouse (z aplikacją Unikaj długich zadań w wątku głównym) lub przeglądanie długich zadań w Narzędziach deweloperskich w Chrome.

Testy oparte na laboratoriach często nie są dobrym punktem wyjścia do identyfikowania problemów z responsywnością, ponieważ narzędzia te mogą nie uwzględniać interakcji, a gdy już się pojawią, stanowią niewielki odsetek prawdopodobnych interakcji. Najlepiej byłoby mierzyć przyczyny powolnych interakcji w terenie.

Wady interfejsu Long Tasks API

Pomiar długich zadań w terenie za pomocą obserwatora wydajności jest tylko nieco przydatne. W rzeczywistości raport nie zawiera zbyt wielu informacji poza tym, że masz długie zadanie i ile czasu zajęło.

Narzędzia do monitorowania użytkowników rzeczywistego (RUM) często wykorzystują tę technologię do ustalania trendów liczby i czasu trwania długich zadań lub identyfikowania stron, na których mają one miejsce. Jednak bez informacji o tym, co spowodowało długie zadanie, takie rozwiązanie jest wykorzystywane w ograniczonym zakresie. Interfejs Long Tasks API ma tylko podstawowy model atrybucji, który najlepiej wskazuje kontener, w którym wystąpiło długie zadanie (dokument najwyższego poziomu lub <iframe>), ale nie skrypt lub funkcję, która je wywołała (jak widać w typowym wpisie):

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

Interfejs Long Tasks API również jest niekompletny, ponieważ może również wykluczać niektóre ważne zadania. Niektóre aktualizacje – np. renderowanie – występują w ramach osobnych zadań, które powinny być uwzględnione razem z poprzednim wykonaniem, które spowodowało, że aktualizacja precyzyjnie mierzy „całkowitą pracę”. za tę interakcję. Więcej informacji o ograniczeniach polegania na zadaniach znajdziesz w sekcji „Kiedy długie zadania są niewidoczne?” wyjaśnienia.

Ostatni problem polega na tym, że pomiar długich zadań uwzględnia w raportach tylko poszczególne zadania, których czas trwania przekracza 50 milisekund. Ramka animacji może składać się z kilku zadań krótszych niż ten limit 50 milisekund, ale łącznie blokujemy w przeglądarce możliwość renderowania.

Interfejs API Long Animation Frames

Long Animation Frames API (LoAF) to nowy interfejs API mający rozwiązać niektóre z niedociągnięć interfejsu Long Tasks API, aby deweloperzy mogli uzyskiwać bardziej przydatne statystyki, które pomagają rozwiązywać problemy z responsywnością i ulepszać wskaźnik INP.

Dobra responsywność oznacza, że strona szybko reaguje na podejmowane z nią interakcje. Polega to na umieszczaniu potrzebnych aktualizacji w odpowiednim czasie oraz zapobieganiu ich blokowaniu. W przypadku INP zaleca się odpowiadanie w ciągu maksymalnie 200 milisekund, ale w przypadku innych aktualizacji (np. animacji), nawet takich, które są za długie.

Interfejs Long Animation Frames API to alternatywne podejście do pomiaru prac blokujących. Zamiast mierzyć poszczególne zadania, interfejs Long Animation Frames API (jak sama nazwa wskazuje) mierzy długie klatki animacji. Długa klatka animacji pojawia się, gdy aktualizacja renderowania jest opóźniona o ponad 50 milisekund (tak samo jak w przypadku interfejsu Long Tasks API).

Długie klatki animacji można obserwować w podobny sposób jak w przypadku długich zadań z metodą PerformanceObserver, ale z uwzględnieniem typu long-animation-frame:

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

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

Poprzednie długie klatki animacji można też pobrać na osi czasu skuteczności w ten sposób:

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

Występuje jednak pole maxBufferSize dla wpisów dotyczących wydajności, po których nowsze wpisy są usuwane, dlatego zalecaną metodą jest PerformanceObserver. Rozmiar bufora long-animation-frame jest ustawiony na 200, tak jak w przypadku long-tasks.

Zalety oglądania ramek zamiast zadań

Główną zaletą spojrzenia na ten model z perspektywy klatki, a nie z perspektywy zadań, jest to, że długa animacja może się składać z dowolnej liczby działań, które łącznie spowodowały wyświetlenie długiej klatki animacji. To dotyczy ostatniego wspomnianego wcześniej punktu, w którym suma wielu mniejszych zadań blokujących renderowanie przed klatką animacji może nie być wyświetlana przez interfejs Long Tasks API.

Inną zaletą takiego alternatywnego widoku w przypadku długich zadań jest możliwość przedstawienia podziału czasowego całej klatki. Zamiast tylko uwzględniać startTime i duration, jak w przypadku interfejsu Long Tasks API, LoAF zawiera znacznie bardziej szczegółowe zestawienie różnych elementów czasu trwania klatki, w tym:

• startTime: czas rozpoczęcia długiej klatki animacji w stosunku do czasu rozpoczęcia nawigacji.
• duration: czas trwania długiej klatki animacji (bez czasu prezentacji).
• renderStart: czas rozpoczęcia cyklu renderowania, który obejmuje wywołania zwrotne requestAnimationFrame, obliczanie stylu i układu, obserwatora zmiany rozmiaru i wywołania zwrotne obserwatora interakcji.
• styleAndLayoutStart: początek okresu poświęconego obliczaniu stylu i układu.
• firstUIEventTimestamp: czas pierwszego zdarzenia interfejsu (myszki/klawiatury itd.), które ma być obsługiwane podczas wyświetlania tej klatki.
• blockingDuration: czas (w milisekundach), przez jaki klatka animacji była blokowana.

Te sygnatury czasowe umożliwiają podzielenie długiej klatki animacji na czasy:

Więcej informacji o poszczególnych czasach wyświetlania znajdziesz w wyjaśnieniach, które szczegółowo wyjaśniają, które działanie przyczynia się do wyświetlenia długiej klatki w animacji.

Lepsza atrybucja

Typ wpisu long-animation-frame zawiera lepsze dane o atrybucji każdego skryptu, który przyczynił się do długiej klatki animacji.

Podobnie jak w przypadku interfejsu Long Tasks API, wartość ta będzie dostępna w tablicy wpisów atrybucji, których szczegóły:

• Zarówno name, jak i EntryType zwracają wartość script.
• znaczący element invoker wskazujący sposób wywołania skryptu (np. 'IMG#id.onload', 'Window.requestAnimationFrame' lub 'Response.json.then').
• Element invokerType punktu wejścia skryptu:
  • user-callback: znane wywołanie zwrotne zarejestrowane przez interfejs API platformy internetowej (np. setTimeout, requestAnimationFrame).
  • event-listener: detektor zdarzenia na platformie (np. click, load, keyup).
  • resolve-promise: moduł obsługi obietnicy platformy (np. fetch(). Pamiętaj, że w przypadku obietnic wszystkie moduły obsługi tych samych obietnic są wymieszane w jednym „skrypcie”)..
  • reject-promise: zgodnie z zasadą resolve-promise, ale za odrzucenie.
  • classic-script: ocena skryptu (np. <script> lub import())
  • module-script: taka sama jak classic-script, ale w przypadku skryptów modułu.
• Osobne dane o czasie dla tego skryptu:
  • startTime: czas wywołania funkcji wpisu.
  • duration: czas od startTime do zakończenia przetwarzania kolejnej kolejki mikrozadań.
  • executionStart: czas po kompilacji.
  • forcedStyleAndLayoutDuration: łączny czas przetwarzania wymuszonego układu i stylu w tej funkcji (patrz: thrashing).
  • pauseDuration: łączny czas w trybie „wstrzymywania” operacji synchronicznych (alerty, synchroniczne XHR).
• Szczegóły źródła skryptu:
  • sourceURL: nazwa zasobu skryptu, jeśli jest dostępna (lub pusta, jeśli nie znaleziono).
  • sourceFunctionName: nazwa funkcji skryptu, jeśli jest dostępna (lub pusta, jeśli nie zostanie znaleziona).
  • sourceCharPosition: pozycja znaku w skrypcie, jeśli jest dostępna (lub -1, jeśli nie znaleziono).
• windowAttribution: kontener (dokument najwyższego poziomu lub <iframe>), w którym wystąpiła długa klatka animacji.
• window: odwołanie do okna z tej samej domeny.

Jeśli zostały podane, wpisy źródłowe pozwalają programistom dokładnie dowiedzieć się, jak został wywołany każdy skrypt w długiej ramce animacji – aż do pozycji znaku w skrypcie wywołującym. Wskazuje dokładną lokalizację zasobu JavaScript, w wyniku której została wyświetlona długa klatka animacji.

Przykład pozycji dotyczącej skuteczności (long-animation-frame)

Przykładowy wpis wydajności long-animation-frame, który zawiera pojedynczy skrypt, to:

{
  "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
}

Jak widać, w ten sposób strony uzyskują bezprecedensową ilość danych, które mogą pomóc w zrozumieniu przyczyn powolnego aktualizowania renderowania.

Użyj w polu interfejsu API Long Animation Frames

Narzędzia takie jak Chrome Dev Tools i Lighthouse, choć przydatne przy wykrywaniu i odtwarzaniu problemów, to narzędzia laboratoryjne, które mogą nie uwzględniać ważnych aspektów wygody użytkowników, które zapewniają tylko dane z terenu.

Interfejs Long Animation Frames API został zaprojektowany do zbierania ważnych danych kontekstowych dotyczących interakcji użytkowników, których interfejs Long Task API nie mógł. Może to pomóc w wykryciu i odtworzeniu problemów związanych z interakcją, które w innym wypadku mogłyby nie zostać wykryte.

Obsługa interfejsu API Long Animation Frames przez interfejs API

Aby sprawdzić, czy interfejs API jest obsługiwany, możesz użyć tego kodu:

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

Link do najdłuższej interakcji INP

Najbardziej oczywistym przypadkiem użycia interfejsu API Long Animation Frames jest ułatwienie diagnozowania i rozwiązywania problemów z interakcją z następnym wyrenderowaniem (INP). To właśnie jeden z głównych powodów stworzenia tego interfejsu API przez zespół Chrome. Dobra wartość INP to czas odpowiedzi na wszystkie interakcje w ciągu 200 milisekund od momentu wyrenderowania klatki. Ponieważ interfejs Long Animation Frames API mierzy wszystkie klatki, których długość trwa co najmniej 50 ms, większość problematycznych wartości INP powinna uwzględniać dane LoAF, aby ułatwić diagnozowanie tych interakcji.

„INP LoAF” to LoAF zawierający interakcję INP, jak pokazano na tym diagramie:

W niektórych przypadkach zdarzenie INP może obejmować 2 LOAF

W rzadkich przypadkach może nawet obejmować więcej niż 2 LoAF.

Zarejestrowanie danych LoAF powiązanych z interakcją INP pozwala uzyskać znacznie więcej informacji na temat interakcji INP, które pomogą w diagnozowaniu tej interakcji. Jest to szczególnie przydatne, jeśli chcesz poznać opóźnienie danych wejściowych, ponieważ możesz zobaczyć, jakie inne skrypty były uruchomione w danej klatce.

Pomocne może być też zrozumienie niewyjaśnionego czasu przetwarzania i opóźnienia prezentacji, jeśli moduły obsługi zdarzeń nie odtwarzają wartości widocznych dla tych modułów, ponieważ dla użytkowników mogą być uruchomione inne skrypty, które mogą nie być uwzględnione w Twoich testach.

Nie ma bezpośredniego interfejsu API umożliwiającego powiązanie wpisu INP z powiązanymi wpisami lub wpisami LoAF, ale można to zrobić w kodzie, porównując czasy rozpoczęcia i zakończenia każdego z nich (zobacz przykładowy skrypt WhyNp).

Biblioteka web-vitals zawiera wszystkie przecinające się LoAF w właściwości longAnimationFramesEntries interfejsu atrybucji INP (wersja 4).

Po połączeniu wpisów lub wpisów LoAF możesz dodawać informacje za pomocą atrybucji INP. Obiekt scripts zawiera jedne z najcenniejszych informacji, ponieważ pokazuje, co jeszcze było wykonywane w tych ramkach. Dzięki sygnalizowaniu z powrotem do usługi analitycznej sygnalizuje, co robisz, aby lepiej zrozumieć, dlaczego interakcje były powolne.

Raportowanie LoAF dla interakcji INP to dobry sposób na znalezienie najpilniejszych problemów z interaktywnością na stronie. Każdy użytkownik może wchodzić w różne interakcje z Twoją stroną. Przy odpowiedniej ilości danych atrybucji INP w danych atrybucji INP uwzględnią się liczne potencjalne problemy. Pozwala to posortować skrypty według głośności i zobaczyć, które z nich są skorelowane z wolnym z INP.

Przesyłaj więcej długich animacji do punktu końcowego analizy

Wadą, którą należy wziąć pod uwagę tylko w przypadku LoAF, jest to, że możesz przegapić inne potencjalne ulepszenia, które mogą powodować problemy z INP w przyszłości. Może to powodować wrażenie, że goni Cię za ogonem, gdy naprawiasz problem z INP, oczekując znacznej poprawy. Jednak znalezienie kolejnej najwolniejszej interakcji jest o niewiele korzystniejsze, więc wskaźnik INP raczej się nie poprawi.

Zamiast skupiać się wyłącznie na śledzeniu LoAF w INP, możesz rozważyć wszystkie takie działania przez cały okres istnienia strony:

Pamiętaj jednak, że każdy wpis LoAF zawiera spore dane, więc prawdopodobnie nie przypadnie to do gustu. Zamiast tego lepiej ograniczyć analizę do niektórych LoAF lub niektórych danych.

Niektóre sugerowane wzorce to:

• Obserwowanie długich klatek animacji z interakcjami
• Obserwowanie klatek animacji o długości przekraczającej określony próg
• Obserwowanie najdłuższych klatek animacji
• Rozpoznawanie typowych wzorców w długich klatkach animacji

To, który z tych wzorców sprawdzi się w Twoim przypadku, zależy od tego, jak daleko jesteś na drodze do optymalizacji i jak często występują długie klatki animacji. W przypadku witryny, która nigdy nie była zoptymalizowana pod kątem responsywności, może być wiele LoAF. Warto ograniczyć się tylko do LoAF z interakcjami, ustawić wysoki próg lub uwzględniać tylko najmniejsze z nich. Podczas rozwiązywania typowych problemów z reagowaniem możesz rozszerzyć ten zakres, nie ograniczając się tylko do interakcji, i obniżając progi. Możesz też poszukać określonych wzorców.

Obserwuj długie klatki animacji z interakcjami

Aby uzyskać statystyki wykraczające poza ramkę długiej animacji INP, możesz przyjrzeć się wszystkim LoAFom z interakcjami (co można wykryć na podstawie wartości firstUIEventTimestamp).

Może to być też prostsza metoda monitorowania LoAF INP niż próba skorelowania dwóch, co może być bardziej złożone. W większości przypadków będzie to INP LoAF w przypadku danej wizyty, a w rzadkich przypadkach, gdy nie wystąpi długie interakcje, które należy rozwiązać, mogą to być interakcje INP w przypadku innych użytkowników.

Ten kod rejestruje wszystkie wpisy LoAF dłuższe niż 150 milisekund, w których wystąpiła interakcja w ramach klatki. Wybrano tu 150, ponieważ wartość ta jest nieco mniejsza niż „dobra” wartość 200 milisekund Próg INP. W zależności od potrzeb możesz wybrać większą lub mniejszą wartość.

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 });

Obserwuj klatki animacji o długości przekraczającej określony próg

Inną strategią jest monitorowanie wszystkich LoAF i przekazywanie tych, które przekraczają określony próg, z powrotem do punktu końcowego Analytics w celu późniejszej analizy:

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 });

Liczba wpisów w postaci długich klatek animacji może być dość duża, dlatego deweloperzy powinni zdecydować, jakie dane z nich wysłać do Analytics. Mogą to być na przykład podsumowania wpisów, nazwy skryptów lub inny minimalny zestaw innych danych kontekstowych, które mogą zostać uznane za konieczne.

Obserwowanie najgorszych długich klatek animacji

W celu zmniejszenia ilości danych wymagających sygnalizowania po stronie serwera zamiast ustawiania wartości progowej witryny może zdecydować się na zbieranie danych z najdłuższej klatki animacji (lub klatek). Bez względu na to, ile długich klatek animacji pojawia się na stronie, przesyłamy z powrotem tylko dane dotyczące najgorszej jakości, pięciu lub innej niezbędnej liczby długich klatek.

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 });

Te strategie można też łączyć – uwzględnia tylko 10 najgorszych LoAF, których interakcje są dłuższe niż 150 milisekund.

W odpowiednim momencie (najlepiej w visibilitychange zdarzeniu) z powrotem do statystyk. Do testów lokalnych możesz okresowo używać console.table:

console.table(longestBlockingLoAFs);

Rozpoznaj typowe wzorce w długich klatkach animacji

Alternatywną strategią jest przyjrzenie się typowym skryptom, które pojawiają się najczęściej w wpisach z długimi klatkami animacji. Dane mogą być zgłaszane na poziomie skryptu i pozycji postaci w celu identyfikacji osób wielokrotnie naruszających zasady.

Może się to sprawdzić szczególnie w przypadku konfigurowalnych platform, na których można zidentyfikować motywy lub wtyczki powodujące problemy z wydajnością w wielu witrynach.

Czas wykonywania typowych skryptów (lub źródeł zewnętrznych) w długich klatkach animacji może zostać zsumowany i raportowany w celu identyfikacji typowych czynników wpływających na długie klatki animacji w witrynie lub zbiorze witryn. Aby na przykład wyświetlić adresy URL:

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});

Oto przykładowe dane wyjściowe:

Używanie interfejsu API Long Animation Frames w narzędziach

Udostępnia on też dodatkowe narzędzia dla programistów do lokalnego debugowania. Niektóre narzędzia, takie jak Lighthouse i Narzędzia deweloperskie w Chrome, były w stanie zebrać większość tych danych przy użyciu szczegółów śledzenia niższego poziomu, ale ten wyższego poziomu API mógłby zapewnić dostęp do tych danych innym narzędziom.

Wyświetlanie danych o długich klatkach animacji w Narzędziach deweloperskich

Długie klatki animacji możesz wyświetlać w Narzędziach deweloperskich za pomocą interfejsu API performance.measure(). Są one wyświetlane na ścieżce czasu działań użytkownika w Narzędziach deweloperskich w statystykach wydajności, aby wskazać, na czym należy się skupić, aby poprawić wydajność:

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 });

W dłuższej perspektywie zostanie on prawdopodobnie włączony do samych Narzędzi deweloperskich, ale poprzedni fragment kodu umożliwia jego wyświetlanie.

Używanie danych długich klatek animacji w innych narzędziach dla programistów

Rozszerzenie Web Vitals pokazuje wartość w podsumowanych informacjach debugowania, aby diagnozować problemy z wydajnością.

Teraz wyświetla też dane dotyczące długich klatek animacji w przypadku każdego wywołania zwrotnego INP i każdej interakcji:

Używaj danych o długich klatkach animacji w narzędziach do automatycznego testowania

Podobnie zautomatyzowane narzędzia do testowania w potokach CI/CD mogą wyświetlać szczegóły dotyczące potencjalnych problemów z wydajnością, mierząc długie klatki animacji podczas uruchamiania różnych zestawów testowych.

Najczęstsze pytania

Oto niektóre z najczęstszych pytań o ten interfejs API:

Może warto rozszerzyć lub iterować interfejs Long Tasks API?

Jest to inny sposób raportowania podobnego – ale ostatecznie innego – pomiaru potencjalnych problemów z reagowaniem. Ważne jest, aby zapewnić, że witryny korzystające z istniejącego interfejsu Long Tasks API będą nadal działać. Pozwoli to uniknąć zakłóceń w istniejących przypadkach użycia.

Chociaż interfejs Long Tasks API może mieć zalety w przypadku niektórych funkcji LoAF (takich jak lepszy model atrybucji), uważamy, że skupienie się na ramkach, a nie na zadaniach daje wiele korzyści, które sprawiają, że jest to zupełnie inny interfejs API niż obecny interfejs Long Tasks.

Dlaczego nie mam wpisów skryptu?

Może to oznaczać, że długa klatka animacji nie pochodzi z kodu JavaScipt, lecz z dużej ilości danych związanych z renderowaniem.

Zdarza się to również wtedy, gdy długa klatka animacji powstała z powodu JavaScriptu, ale nie można podać atrybucji skryptu z różnych powodów związanych z ochroną prywatności, jak wspomniano wcześniej (głównie kodu JavaScript nie należy do strony).

Dlaczego mam wpisy skryptu, ale nie mam informacji o źródle lub nie mam ich wcale?

Może się tak zdarzyć z różnych powodów, np. gdy nie jest to dobre źródło, które można wskazać.

Informacje o skryptach również będą ograniczone w przypadku skryptów no-cors cross-origin, ale można rozwiązać ten problem, pobierając te skrypty za pomocą funkcji CORS przez dodanie crossOrigin = "anonymous" do wywołania <script>.

Na przykład domyślny skrypt Menedżera tagów Google, który ma zostać dodany do strony:

<!-- Google Tag Manager -->
<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-XXXXXXX');</script>
<!-- End Google Tag Manager -->

Można rozszerzyć o j.crossOrigin = "anonymous", aby umożliwić podawanie pełnych szczegółów atrybucji dla Menedżera tagów Google

Czy to zastąpi interfejs Long Tasks API?

Chociaż uważamy, że interfejs Long Animation Frames API jest lepszy i pełniejszy do pomiaru długich zadań, obecnie nie planujemy wycofać tego interfejsu.

Prośba o opinię

Opinie można przesyłać na liście problemów w GitHub. Błędy w implementacji interfejsu API w Chrome można zgłaszać za pomocą narzędzia do zgłaszania problemów w Chrome.

Podsumowanie

Interfejs Long Animation Frames API to nowy, ciekawy interfejs, który ma wiele potencjalnych zalet.

Okazuje się, że jest to kluczowe narzędzie do rozwiązywania problemów z responsywnością, zgodnie z pomiarami INP. Wskaźnik INP jest trudny do optymalizacji, a ten interfejs API to jeden ze sposobów, w jakie zespół Chrome stara się ułatwić deweloperom identyfikowanie i rozwiązywanie problemów.

Zakres interfejsu Long Animation Frames API wykracza jednak poza INP i może pomóc w wykrywaniu innych przyczyn powolnych aktualizacji, które mogą wpływać na sprawne działanie witryny.

Podziękowania

Miniatura: Henry Be na kanale Unsplash.