Wymiar: Long Animation Frames (lurl)
Wymiar LOAF ujawnia adresy URL skryptów, które spowodowały długie klatki animacji (Long Animation Frames) podczas sesji użytkowników. Każda wartość to adres URL skryptu: pakiet własny, tag analityczny strony trzeciej, widget czatu, menedżer zgód lub cokolwiek innego, co działało wystarczająco długo, aby zablokować renderowanie. Jest to atrybucja na poziomie źródła, a nie tylko ślad stosu (stack trace), który trzeba rekonstruować w DevTools.
CoreDash gromadzi te dane za pomocą [url=https:\/\/developer.chrome.com\/docs\/web-platform\/long-animation-frames]Long Animation Frames API (LoAF)[\/url], które Chrome udostępnia jako zamiennik starszego Long Tasks API. Tam, gdzie Long Tasks informowało tylko, że klatka trwała zbyt długo, LoAF mówi, które skrypty zostały uruchomione w tej klatce i jakie były ich adresy URL. To właśnie to rozróżnienie sprawia, że ten wymiar jest użyteczny w środowisku produkcyjnym.
Dlaczego Long Tasks nie wystarczało
Long Tasks API (dostępne od 2017 r.) flagowało każde zadanie głównego wątku przekraczające 50 ms, ale nie zapewniało prawie żadnej atrybucji. Można było zauważyć, że nastąpiło blokowanie, ale nie było wiadomo, co je spowodowało. Programiści spędzali godziny na korelowaniu znaczników czasu zadań z kaskadami sieciowymi, zgadując, który skrypt był odpowiedzialny.
LoAF API zmienia to. Raportuje ono obiekty PerformanceLongAnimationFrameEntry, z których każdy zawiera tablicę scripts. Każdy wpis w tej tablicy posiada invokerType, sourceURL oraz duration. CoreDash odczytuje sourceURL dla każdego skryptu, który został uruchomiony podczas długiej klatki, i przechowuje go jako wartość wymiaru LOAF. Wynikiem jest ranking adresów URL skryptów uporządkowany według częstotliwości ich występowania w długich klatkach użytkowników.
Jak CoreDash wykorzystuje dane LoAF
Za każdym razem, gdy interakcja użytkownika wyzwala długą klatkę animacji, CoreDash rejestruje adresy URL skryptów przyczyniających się do tego obok obserwacji INP. Oznacza to, że możesz filtrować dane INP według adresu URL LOAF i zobaczyć, który skrypt jest odpowiedzialny za najgorsze interakcje. Wymiar grupuje dane według adresu URL, więc widzisz liczbę sesji, w których dany skrypt spowodował długą klatkę.
Typowe wpisy, które zobaczysz w wymiarze LOAF:
https:\/\/www.googletagmanager.com\/gtm.js (kontener Google Tag Manager)
https:\/\/cdn.cookielaw.org\/consent\/... (OneTrust lub podobna platforma zarządzania zgodami)
https:\/\/js.intercomcdn.com\/... (widget czatu)
\/static\/js\/app.bundle.js (Twój własny kod aplikacji)
https:\/\/connect.facebook.net\/en_US\/fbevents.js (Meta Pixel)W danych CoreDash skrypty stron trzecich odpowiadają za długie klatki animacji w około 60-70% witryn. Same menedżery tagów przyczyniają się do długich klatek w około 45% monitorowanych zasobów. Pakiety własne dominują w pozostałej części, zazwyczaj z powodu ponownego renderowania w React (re-renders) lub nieoptymalnych procedur obsługi zdarzeń.
Atrybucja INP poprzez LoAF
INP mierzy czas od interakcji użytkownika do namalowania następnej klatki. Jeśli ta luka przekracza 200 ms, Google klasyfikuje doświadczenie jako "wymagające poprawy". Dane LoAF mówią Ci, który skrypt działał w tym czasie. INP o wartości 280 ms, z czego 210 ms przypada na skrypt menedżera zgód, to zupełnie inny problem niż INP o wartości 280 ms, gdzie 190 ms przypada na Twoją własną procedurę obsługi procesu płatności. Inny jest sposób naprawy, inny zespół odpowiedzialny i inna pilność.
Bez atrybucji LoAF oba przypadki wyglądają identycznie na histogramie INP. Dzięki niej możesz natychmiast skierować sprawę do właściwej osoby.
Proces depuracji
- Otwórz wymiar LOAF w CoreDash: Posortuj według częstotliwości (ile sesji odnotowało ten adres URL w długiej klatce). Pierwszy wpis to Twój cel o najwyższym priorytecie.
- Filtruj krzyżowo z INP: Zastosuj filtr LOAF do widoku metryki INP. Sprawdź, czy p75 metryki INP zmienia się po odizolowaniu sesji, w których działał ten skrypt. Wzrost o ponad 30 ms potwierdza, że skrypt przyczynia się do pogorszenia INP w środowisku produkcyjnym.
- Sklasyfikuj jako kod własny lub zewnętrzny: Twoja własna domena w adresie URL oznacza, że kontrolujesz naprawę. Adres URL CDN strony trzeciej oznacza, że musisz usunąć, opóźnić lub zastąpić skrypt dostawcy.
- Zastosuj poprawkę i zweryfikuj: W przypadku skryptów stron trzecich odłóż ładowanie do czasu po pierwszej interakcji użytkownika, korzystając z fasady lub opóźnionej inicjalizacji. W przypadku kodu własnego przeprowadź profilowanie konkretnej funkcji w Chrome DevTools z ustawionym ograniczeniem procesora (CPU throttling) na 4x. Wdróż zmianę i obserwuj aktualizację wymiaru LOAF w ciągu 24-48 godzin ruchu rzeczywistych użytkowników.
Zasady inżynieryjne
- Każdy pojedynczy adres URL skryptu pojawiający się w długich klatkach w ponad 5% sesji jest wart zbadania. Przy takim wskaźniku wpływa on na mierzalną część rzeczywistych użytkowników w skali miesiąca.
- Skrypty stron trzecich nie powinny działać podczas obsługi interakcji. Jeśli menedżer tagów uruchamia się synchronicznie przy zdarzeniu kliknięcia, jest to problem z konfiguracją, a nie ograniczenie przeglądarki.
- Czas trwania długiej klatki powyżej 200 ms dla pojedynczego skryptu to wyraźny sygnał. LoAF API raportuje czas trwania poszczególnych skryptów wewnątrz klatki. Każdy skrypt pochłaniający 200 ms lub więcej klatki jest główną przyczyną opóźnienia INP, które po nim następuje.
- Skrypty własne na liście LOAF często wskazują na narzut frameworka. React, Vue i Angular mogą generować długie klatki podczas aktualizacji stanu. Adresem URL LOAF będzie Twój własny pakiet. Profiluj drzewo komponentów, a nie tylko sieć.
Wymiar LOAF daje Ci coś, czego nie zapewni żaden test syntetyczny: dowód na to, które skrypty blokują rzeczywistych użytkowników na produkcji, uszeregowany według częstotliwości występowania w świecie rzeczywistym. Filtruj według niego, konfrontuj z danymi INP, a otrzymasz priorytetową listę tego, co dokładnie naprawić i w jakiej kolejności.
[include]sidebarcoredash.html[\/include]