Wymiar Core/Dash: LOAF

Znajdź dokładne adresy URL skryptów, które blokują wątek główny i pogarszają INP, przypisując Long Animation Frames do ich źródła.

Wypróbuj za darmo

Trusted by market leaders · Client results

harvardvpnsaturnfotocasakpnaleteiaebaymonarchwhowhatwearworkivasnvloopearplugsnestlemarktplaatsnina carecompareadevintadpg mediaerasmusmchappyhorizonmy work featured on web.devperion

Wymiar: Long Animation Frames (lurl)

Wymiar LOAF uwidacznia adresy URL skryptów, które spowodowały wystąpienie Long Animation Frames podczas sesji Twoich użytkowników. Każda wartość to adres URL skryptu: paczka first-party, tag analityczny third-party, widżet czatu, menedżer zgód (consent manager) lub cokolwiek innego, co działało wystarczająco długo, aby zablokować renderowanie. To atrybucja na poziomie źródła, a nie tylko ślad stosu (stack trace), który musisz zrekonstruować w DevTools.

CoreDash gromadzi te dane za pomocą Long Animation Frames API (LoAF), które przeglądarka Chrome udostępnia jako zamiennik starszego API Long Tasks. Tam, gdzie Long Tasks informowało, że klatka trwała zbyt długo, LoAF wskazuje, które skrypty zostały uruchomione w tej klatce i jakie były ich adresy URL. Właśnie ta różnica sprawia, że wymiar ten jest niezwykle użyteczny na produkcji.

coredash loaf scripts

Dlaczego API Long Tasks to za mało

API Long Tasks (dostępne od 2017 roku) oflagowywało każde zadanie w wątku głównym przekraczające 50 ms, ale nie dawało prawie żadnych informacji o atrybucji. Widziałeś, że wystąpiło blokowanie; nie widziałeś jednak, co je spowodowało. Programiści spędzali godziny na korelowaniu znaczników czasu (timestamps) z kaskadami sieciowymi (network waterfalls), zgadując, który skrypt jest za to odpowiedzialny.

API LoAF całkowicie to zmienia. Raportuje obiekty PerformanceLongAnimationFrameEntry, z których każdy zawiera tablicę scripts. Każdy wpis w tej tablicy posiada właściwości invokerType, sourceURL oraz duration. CoreDash odczytuje sourceURL dla każdego skryptu uruchomionego podczas długiej klatki i zapisuje go jako wartość wymiaru LOAF. Wynikiem jest zrankingowana lista adresów URL skryptów, uporządkowana według częstotliwości ich występowania w długich klatkach Twoich 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, które się do tego przyczyniły, bezpośrednio obok obserwacji INP. Oznacza to, że możesz filtrować swoje dane INP według adresów URL LOAF i dokładnie zobaczyć, który skrypt odpowiada za najgorsze interakcje. Wymiar grupuje dane według adresu URL, dzięki czemu widzisz liczbę sesji, w których dany skrypt spowodował opóźnienie renderowania.

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/... (widżet czatu)
  • /static/js/app.bundle.js (kod Twojej własnej aplikacji)
  • https://connect.facebook.net/en_US/fbevents.js (Piksel Meta)

W danych CoreDash skrypty third-party odpowiadają za długie klatki animacji (Long Animation Frames) w około 60-70% witryn. Same tag managery przyczyniają się do powstawania długich klatek w blisko 45% monitorowanych usług. Za resztę odpowiadają głównie paczki first-party, najczęściej z powodu ponownego renderowania (re-renders) w React lub przez niezoptymalizowane procedury obsługi zdarzeń (event handlers).

Atrybucja INP za pomocą LoAF

INP mierzy czas od interakcji użytkownika do wyrenderowania następnej klatki przez przeglądarkę. Jeśli ta luka przekroczy 200 ms, Google klasyfikuje doświadczenie jako "wymagające poprawy" (needs improvement). Dane LoAF precyzują, który skrypt działał w czasie tej luki. INP wynoszące 280 ms, w którym 210 ms to czas wykonania skryptu zarządzania zgodami, to zupełnie inny problem niż INP na poziomie 280 ms, w którym 190 ms pochodzi z Twojego własnego modułu kasy (checkout handler). Rozwiązanie jest inne. Odpowiedzialny zespół jest inny. Poziom pilności problemu także jest inny.

Bez atrybucji LoAF, obie sytuacje wyglądają identycznie na Twoim histogramie INP. Dzięki niej możesz natychmiast skierować problem do właściwej osoby.

Przepływ pracy debugowania

  1. Otwórz wymiar LOAF w CoreDash: Posortuj według częstotliwości (w ilu sesjach dany adres URL wystąpił w długiej klatce). Pierwsza pozycja na liście to Twój priorytetowy cel.
  2. Przefiltruj krzyżowo dane INP: Zastosuj filtr LOAF do widoku metryki INP. Sprawdź, czy p75 dla INP ulega zmianie po wyizolowaniu sesji, w których działał analizowany skrypt. Wzrost o ponad 30 ms jest potwierdzeniem, że skrypt bezpośrednio przyczynia się do degradacji INP na produkcji.
  3. Sklasyfikuj jako first-party lub third-party: Własna domena w adresie URL oznacza, że to Ty kontrolujesz wdrożenie poprawki. Adres URL CDN innej firmy (third-party) oznacza, że musisz usunąć, opóźnić lub zastąpić skrypt dostawcy.
  4. Wdróż poprawkę i zweryfikuj: W przypadku skryptów third-party opóźnij ich ładowanie do czasu pierwszej interakcji użytkownika, wykorzystując wzorzec fasady (facade) lub opóźnioną inicjalizację. W przypadku kodu first-party sprofiluj konkretną funkcję w Chrome DevTools z włączonym dławieniem (throttling) procesora ustawionym na 4x. Wdróż zmianę i obserwuj aktualizację wymiaru LOAF w ciągu 24-48 godzin dla rzeczywistego ruchu użytkowników.

Inżynieryjna reguła kciuka

  • Każdy pojedynczy adres URL skryptu pojawiający się w długich klatkach w więcej niż 5% sesji jest bezwzględnie wart zbadania. Przy takiej częstotliwości problem dotyka już zauważalnej i istotnej części rzeczywistych użytkowników w skali miesiąca.
  • Skrypty third-party nigdy nie powinny być uruchamiane podczas procedur obsługi interakcji. Jeśli tag manager uruchamia się synchronicznie na zdarzenie kliknięcia, jest to błąd konfiguracji, a nie ograniczenie samej przeglądarki.
  • Czas trwania długiej klatki przekraczający 200 ms dla pojedyncnego skryptu to wyraźny sygnał ostrzegawczy. API LoAF raportuje czas trwania wykonania poszczególnych skryptów wewnątrz klatki. Każdy skrypt zużywający 200 ms lub więcej z danego okna renderowania jest wprost główną przyczyną następującego po nim wysokiego wyniku INP.
  • Skrypty first-party pojawiające się na liście LOAF często wskazują na narzut generowany przez framework. React, Vue i Angular mogą generować długie klatki podczas aktualizacji stanu (state updates). Adres URL w LoAF wskaże wprost na Twoją własną paczkę (bundle). Zawsze profiluj drzewo komponentów, a nie tylko ruch sieciowy.

Wymiar LOAF daje Ci do ręki argument, którego nie zapewni żaden test syntetyczny: namacalny dowód na to, które skrypty faktycznie blokują rzeczywistych użytkowników na środowisku produkcyjnym, uszeregowane według częstotliwości ich występowania. Odfiltruj wyniki według niego, zweryfikuj krzyżowo ze swoimi danymi INP, a otrzymasz bezbłędnie spriorytetyzowaną listę pokazującą, co dokładnie musisz naprawić i w jakiej kolejności.