Dimensione Core/Dash: LOAF

Trova gli esatti URL degli script che bloccano il tuo main thread e degradano l'INP attribuendo i Long Animation Frames alla loro origine.

Prova gratuita

Trusted by market leaders · Client results

aleteiaharvardmy work featured on web.devsnvperionwhowhatwearadevintamarktplaatsnestledpg mediavpnloopearplugsnina careerasmusmcfotocasakpncompareebaymonarchhappyhorizonworkivasaturn

Dimensione: Long Animation Frames (lurl)

La dimensione LOAF fa emergere gli URL degli script che hanno causato Long Animation Frames durante le sessioni dei tuoi utenti. Ogni valore è l'URL di uno script: un bundle di prime parti, un tag di analytics di terze parti, un widget di chat, un consent manager, o qualsiasi altra cosa che sia stata in esecuzione abbastanza a lungo da bloccare il rendering. Questa è un'attribuzione a livello di origine, non solo una stack trace da ricostruire nei DevTools.

CoreDash raccoglie questi dati utilizzando la Long Animation Frames API (LoAF), che Chrome distribuisce in sostituzione della vecchia Long Tasks API. Se Long Tasks ti diceva che un frame richiedeva troppo tempo, LoAF ti dice quali script sono stati eseguiti all'interno di quel frame e quali erano i loro URL. Questa è la distinzione che rende questa dimensione utile in produzione.

coredash loaf scripts

Perché i Long Tasks non erano abbastanza

La Long Tasks API (disponibile dal 2017) segnalava qualsiasi task del main thread superiore a 50 ms, ma non forniva quasi alcuna attribuzione. Potevi vedere che si verificava un blocco; non potevi vedere cosa lo causava. Gli sviluppatori passavano ore a correlare i timestamp dei task con i waterfall di rete, tirando a indovinare quale script fosse il responsabile.

La LoAF API cambia le cose. Segnala oggetti PerformanceLongAnimationFrameEntry, ciascuno contenente un array scripts. Ogni voce in quell'array ha un invokerType, un sourceURL e una duration. CoreDash legge il sourceURL di ogni script eseguito durante un long frame e lo salva come valore della dimensione LOAF. Il risultato è un elenco classificato di URL di script ordinato in base alla frequenza con cui appaiono nei long frames dei tuoi utenti.

Come CoreDash utilizza i dati LoAF

Ogni volta che l'interazione di un utente innesca un long animation frame, CoreDash registra gli URL degli script che vi hanno contribuito insieme all'osservazione dell'INP. Questo significa che puoi filtrare i tuoi dati INP per URL LOAF e vedere quale script è responsabile delle tue interazioni peggiori. La dimensione si raggruppa per URL, così puoi vedere un conteggio di quante sessioni hanno coinvolto quello script causando un long frame.

Voci tipiche che vedrai nella dimensione LOAF:

  • https://www.googletagmanager.com/gtm.js (contenitore Google Tag Manager)
  • https://cdn.cookielaw.org/consent/... (OneTrust o piattaforma di consenso simile)
  • https://js.intercomcdn.com/... (widget di chat)
  • /static/js/app.bundle.js (il codice della tua applicazione)
  • https://connect.facebook.net/en_US/fbevents.js (Meta Pixel)

Nei dati di CoreDash, gli script di terze parti sono responsabili dei long animation frames in circa il 60-70% dei siti. I tag manager da soli contribuiscono ai long frames su circa il 45% delle proprietà monitorate. I bundle di prime parti dominano la parte restante, di solito a causa di re-render di React o di gestori di eventi non ottimizzati.

Attribuzione dell'INP tramite LoAF

L'INP misura il tempo che intercorre dall'interazione dell'utente al successivo paint del frame. Se questo intervallo supera i 200 ms, Google classifica la user experience come "needs improvement". I dati LoAF ti dicono quale script è stato eseguito durante quell'intervallo. Un INP di 280 ms in cui 210 ms sono riconducibili a uno script di un consent manager è un problema completamente diverso rispetto a un INP di 280 ms in cui 190 ms sono riconducibili al tuo gestore del checkout. La correzione è diversa. Il team responsabile è diverso. L'urgenza è diversa.

Senza l'attribuzione LoAF, entrambi sembrano identici nel tuo istogramma dell'INP. Con essa, puoi indirizzare immediatamente il problema alla persona giusta.

Flusso di lavoro per il Debugging

  1. Apri la dimensione LOAF in CoreDash: Ordina per frequenza (quante sessioni hanno visto questo URL in un long frame). La voce in cima è il tuo obiettivo con la priorità più alta.
  2. Filtra incrociando con l'INP: Applica il filtro LOAF alla visualizzazione della tua metrica INP. Controlla se il p75 dell'INP cambia quando isoli le sessioni in cui è stato eseguito quello script. Un aumento di oltre 30 ms conferma che lo script sta contribuendo al degrado dell'INP in produzione.
  3. Classifica come di prime parti o di terze parti: Il tuo dominio nell'URL significa che controlli la correzione. L'URL di una CDN di terze parti significa che devi rimuovere, ritardare o sostituire lo script del fornitore.
  4. Applica la correzione e verifica: Per gli script di terze parti, posticipa il caricamento fino a dopo la prima interazione dell'utente utilizzando una facade o un'inizializzazione ritardata. Per il codice di prime parti, profila la funzione specifica nei Chrome DevTools con il CPU throttling impostato a 4x. Distribuisci la modifica e osserva l'aggiornamento della dimensione LOAF entro 24-48 ore di traffico reale degli utenti.

Regole pratiche di ingegneria

  • Qualsiasi singolo URL di script che appare nei long frames per più del 5% delle sessioni merita di essere investigato. A quel ritmo, sta influenzando una porzione misurabile di utenti reali nel corso del mese.
  • Gli script di terze parti non dovrebbero essere eseguiti durante i gestori di interazione. Se un tag manager si attiva in modo sincrono su un evento di clic, si tratta di un problema di configurazione, non di una limitazione del browser.
  • Una durata del long frame superiore a 200 ms per un singolo script è un segnale chiaro. La LoAF API riporta la durata per-script all'interno del frame. Qualsiasi script che consuma 200 ms o più di un frame è la causa primaria di qualsiasi INP che ne consegue.
  • Gli script di prime parti nella lista LOAF spesso indicano un sovraccarico del framework. React, Vue e Angular possono tutti produrre long frames durante gli aggiornamenti di stato. L'URL LoAF sarà il tuo bundle. Profila l'albero dei componenti, non solo la rete.

La dimensione LOAF ti dà qualcosa che nessun test sintetico può dare: la prova di quali script bloccano gli utenti reali in produzione, classificati per frequenza nel mondo reale. Filtra in base ad essa, incrocia i dati con il tuo INP e avrai una lista con le priorità di cosa correggere esattamente e in quale ordine.