Dimensione Core/Dash: LOAF

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 prima parte, un tag analytics di terze parti, un widget di chat, un gestore del consenso, o qualsiasi altra cosa sia stata eseguita abbastanza a lungo da bloccare il rendering. Questa è un'attribuzione a livello di origine, non solo una stack trace da ricostruire in DevTools.

CoreDash raccoglie questi dati utilizzando la Long Animation Frames API (LoAF), che Chrome fornisce come sostituzione della vecchia Long Tasks API. Mentre le Long Tasks ti dicevano che un frame aveva impiegato troppo tempo, la LoAF ti dice quali script sono stati eseguiti all'interno di quel frame e quali erano i loro URL. Questa è la differenza che rende questa dimensione utile in produzione.

Perché le Long Tasks non erano sufficienti

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

La API LoAF cambia tutto questo. Riporta oggetti PerformanceLongAnimationFrameEntry, ognuno dei quali contiene un array scripts. Ogni voce in quell'array ha un invokerType, un sourceURL e una duration. CoreDash legge il sourceURL per ogni script eseguito durante un long frame e lo memorizza come valore della dimensione LOAF. Il risultato è un elenco classificato di URL di script ordinati 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 tramite l'URL LOAF e vedere quale script è responsabile delle tue peggiori interazioni. La dimensione li raggruppa per URL, in modo che tu possa vedere il conteggio di quante sessioni hanno coinvolto quello script nel causare 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 prima parte dominano il resto, solitamente a causa di re-render di React o gestori di eventi non ottimizzati.

Attribuzione INP tramite LoAF

L'INP misura il tempo che intercorre dall'interazione dell'utente alla successiva pittura del frame. Se questo divario supera i 200ms, Google classifica l'esperienza come "needs improvement". I dati LoAF ti dicono quale script è stato eseguito durante quel divario. Un INP di 280ms in cui 210ms sono riconducibili a uno script per la gestione del consenso rappresenta un problema completamente diverso da un INP di 280ms in cui 190ms sono riconducibili al tuo gestore del checkout. La soluzione è diversa. Il team responsabile è diverso. L'urgenza è diversa.

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

Flusso di lavoro per il debug

1. Apri la dimensione LOAF in CoreDash: Ordina per frequenza (quante sessioni hanno visto questo URL in un long frame). La prima voce in alto è il tuo obiettivo con la priorità più alta.
2. Incrocia il filtro con l'INP: Applica il filtro LOAF alla visualizzazione della metrica INP. Controlla se l'INP p75 cambia quando isoli le sessioni in cui quello script è stato eseguito. Un aumento di oltre 30ms conferma che lo script sta contribuendo al peggioramento dell'INP in produzione.
3. Classifica come prima parte o terze parti: Se l'URL contiene il tuo dominio, significa che hai tu il controllo della 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 a dopo la prima interazione dell'utente utilizzando un facade o un'inizializzazione ritardata. Per il codice di prima parte, profila la funzione specifica in Chrome DevTools con il CPU throttling impostato su 4x. Distribuisci la modifica e osserva l'aggiornamento della dimensione LOAF entro 24-48 ore di traffico degli utenti reali.

Regole pratiche per l'ingegneria

• Qualsiasi singolo URL di script che appare in long frames in 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 click, si tratta di un problema di configurazione, non di una limitazione del browser.
• Una durata del long frame superiore a 200ms per un singolo script è un segnale inequivocabile. La API LoAF riporta la durata per singolo script all'interno del frame. Qualsiasi script che consumi 200ms o più di un frame è la causa primaria di qualsiasi INP che ne consegue.
• Gli script di prima parte nell'elenco 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 stesso bundle. Profila l'albero dei componenti, non solo la rete.

La dimensione LOAF ti dà qualcosa che nessun test sintetico può offrirti: la prova di quali script bloccano gli utenti reali in produzione, classificati in base alla frequenza nel mondo reale. Filtra per questa dimensione, incrocia i risultati con i tuoi dati INP e avrai un elenco prioritario di cosa sistemare esattamente e in quale ordine.