API Long Animation Frames

Barry Pollard

Noam Rosenthal

L'API Long Animation Frames (loAF, pronunciato Lo-Af) è un aggiornamento dell'API Long Tasks che consente di comprendere meglio gli aggiornamenti lenti dell'interfaccia utente (UI). Questo può essere utile per identificare i frame di animazione lenti che probabilmente influiranno sulla metrica Core Web Vital Interaction to Next Paint (INP), che misura la reattività, oppure per identificare altri blocchi dell'interfaccia utente che influiscono sulla smooty.

Stato dell'API

A seguito di una prova dell'origine da Chrome 116 a Chrome 122, l'API LoAF è stata spedita da Chrome 123.

Background: l'API Long Tasks

L'API Long Animation Frames è un'alternativa all'API Long Tasks, disponibile in Chrome da un po' di tempo (a partire dalla versione 58 di Chrome). Come suggerisce il nome, l'API Long Tasks consente di monitorare le attività lunghe, ovvero quelle che occupano il thread principale per almeno 50 millisecondi. È possibile monitorare le attività lunghe utilizzando l'interfaccia di PerformanceLongTaskTiming con un PeformanceObserver:

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

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

È probabile che le attività lunghe causino problemi di reattività. Se un utente prova a interagire con una pagina, ad esempio fa clic su un pulsante o apre un menu, ma il thread principale ha già a che fare con un'attività lunga, l'interazione dell'utente viene ritardata in attesa del completamento dell'attività.

Per migliorare la reattività, spesso è consigliato suddividere attività lunghe. Se ogni attività lunga è invece suddivisa in una serie di più attività più piccole, potrebbe consentire l'esecuzione di attività più importanti tra di loro per evitare ritardi significativi nella risposta alle interazioni.

Di conseguenza, quando si cerca di migliorare la reattività, il primo sforzo è spesso eseguire un'analisi delle prestazioni e osservare attività lunghe. ad esempio mediante uno strumento di controllo basato su lab come Lighthouse (che dispone di un controllo Evita attività lunghe nel thread principale) oppure esaminando le attività lunghe in Chrome DevTools.

I test basati su lab sono spesso un punto di partenza non ottimale per identificare i problemi di reattività, poiché questi strumenti potrebbero non includere le interazioni. Quando lo fanno, si tratta di un piccolo sottoinsieme di probabili interazioni. Idealmente, dovresti misurare le cause delle interazioni lente sul campo.

Difetti dell'API Long Tasks

La misurazione di attività lunghe sul campo con Performance Observer è solo parzialmente utile. In realtà, non fornisce così tante informazioni, a parte il fatto che si sia verificata un'attività lunga e il tempo che ci è voluto.

Gli strumenti di Real User Monitoring (RUM) spesso lo usano per tracciare il numero o la durata delle attività lunghe o per identificare le pagine su cui si verificano. Tuttavia, senza i dettagli sottostanti su cosa ha causato l'attività lunga, questa funzionalità è di uso limitato. L'API Long Tasks ha solo un modello di attribuzione di base, che nella migliore delle ipotesi indica solo il container in cui si è verificata l'attività lunga (il documento di primo livello o un <iframe>), ma non lo script o la funzione che lo ha definito, come mostrato da una voce tipica:

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

Anche l'API Long Tasks è una visualizzazione incompleta, poiché può escludere anche alcune attività importanti. Alcuni aggiornamenti, come il rendering, avvengono in attività separate che idealmente dovrebbero essere incluse insieme all'esecuzione precedente, grazie alla quale l'aggiornamento misura con precisione il "lavoro totale". per quell'interazione. Per ulteriori dettagli sui limiti dell'utilizzo delle attività, consulta "Dove le attività lunghe non sono sufficienti" del messaggio esplicativo.

L'ultimo problema è che la misurazione delle attività lunghe genera report solo sulle singole attività che richiedono più di 50 millisecondi. Un frame di animazione può essere costituito da diverse attività di dimensioni inferiori a questo limite di 50 millisecondi, pur continuando a bloccare la capacità del browser di eseguire il rendering.

API Long Animation Frames

L'API Long Animation Frames (LoAF) è una nuova API che cerca di risolvere alcuni dei difetti dell'API Long Tasks per consentire agli sviluppatori di ottenere informazioni più strategiche per risolvere i problemi di reattività e migliorare INP.

Una buona reattività indica che una pagina risponde rapidamente alle interazioni che la riguardano. Ciò comporta la possibilità di visualizzare in modo tempestivo tutti gli aggiornamenti necessari per l'utente ed evitare di bloccarne l'esecuzione. Per INP, si consiglia di rispondere entro 200 millisecondi, ma per altri aggiornamenti (ad esempio le animazioni) anche che potrebbero essere troppo lunghi.

L'API Long Animation Frames è un approccio alternativo alla misurazione del lavoro di blocco. Anziché misurare le singole attività, l'API Long Animation Frames, come suggerisce il suo nome, misura i frame di animazione lunghi. Un frame dell'animazione lungo si verifica quando un aggiornamento del rendering viene ritardato oltre i 50 millisecondi (come la soglia dell'API Long Tasks).

È possibile osservare lunghi frame dell'animazione in modo simile alle attività lunghe con un PerformanceObserver, ma esaminando il tipo long-animation-frame:

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

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

È possibile eseguire query anche dalla sequenza temporale del rendimento sui precedenti fotogrammi dell'animazione lunghi:

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

Tuttavia, esiste un maxBufferSize per le voci relative alle prestazioni, dopo la quale vengono eliminate le voci più recenti, per cui l'approccio PerformanceObserver è l'approccio consigliato. La dimensione del buffer long-animation-frame è impostata su 200, come per long-tasks.

Vantaggi di esaminare i frame invece delle attività

Il vantaggio principale di questa analisi dal punto di vista di un frame piuttosto che di un'attività è che un'animazione lunga può essere costituita da un numero qualsiasi di attività che cumulativamente hanno generato un frame dell'animazione lungo. Questo affronta l'ultimo punto citato in precedenza, in cui la somma di molte attività più piccole che bloccano il rendering prima di un frame di animazione potrebbe non essere visualizzata dall'API Long Tasks.

Un ulteriore vantaggio di questa visione alternativa sulle attività lunghe è la possibilità di fornire suddivisioni temporali dell'intero frame. Anziché includere semplicemente un startTime e un duration, come l'API Long Tasks, LoAF include un'analisi molto più dettagliata delle varie parti della durata del frame, tra cui:

• startTime: l'ora di inizio del frame dell'animazione lungo rispetto all'ora di inizio della navigazione.
• duration: la durata del lungo frame dell'animazione (escluso il tempo di presentazione).
• renderStart: l'ora di inizio del ciclo di rendering, che include callback requestAnimationFrame, calcolo di stile e layout, callback di osservatore del ridimensionamento e di osservatore delle intersezioni.
• styleAndLayoutStart: l'inizio del periodo di tempo dedicato ai calcoli di stile e layout.
• firstUIEventTimestamp: l'ora del primo evento UI (mouse/tastiera e così via) da gestire nel corso di questo frame.
• blockingDuration: la durata in millisecondi durante la quale il frame dell'animazione è stato bloccato.

Questi timestamp consentono di suddividere il lungo frame dell'animazione in tempistiche:

Per ulteriori dettagli su queste singole tempistiche, fai riferimento al messaggio esplicativo, che fornisce dettagli granulari su quale attività contribuisce a un lungo frame dell'animazione.

Migliore attribuzione

Il tipo di voce long-animation-frame include dati di attribuzione migliori per ogni script che ha contribuito a un frame dell'animazione lungo.

Analogamente all'API Long Tasks, verrà fornita in un array di voci di attribuzione, ciascuna delle quali fornisce i seguenti dettagli:

• Sia name che EntryType restituiranno script.
• Un valore invoker significativo, che indica come è stato chiamato lo script (ad esempio, 'IMG#id.onload', 'Window.requestAnimationFrame' o 'Response.json.then').
• invokerType del punto di ingresso dello script:
  • user-callback: un callback noto registrato dall'API di una piattaforma web (ad esempio setTimeout, requestAnimationFrame).
  • event-listener: un listener di un evento della piattaforma (ad esempio click, load, keyup).
  • resolve-promise: gestore di una promessa relativa alla piattaforma (ad esempio fetch(). Tieni presente che, nel caso delle promesse, tutti i gestori delle stesse promesse vengono mescolati come un unico "script").
  • reject-promise: resolve-promise, ma per il rifiuto.
  • classic-script: valutazione dello script (ad esempio, <script> o import())
  • module-script: come classic-script, ma per gli script dei moduli.
• Separa i dati temporali per lo script:
  • startTime: ora in cui la funzione di immissione è stata richiamata.
  • duration: la durata tra il giorno startTime e il momento in cui la coda di microattività successiva ha terminato l'elaborazione.
  • executionStart: il tempo dopo la compilazione.
  • forcedStyleAndLayoutDuration: il tempo totale impiegato per elaborare il layout e lo stile forzati all'interno di questa funzione (vedi thrashing).
  • pauseDuration: tempo totale trascorso in "messa in pausa" operazioni sincrone (avviso, XHR sincrona).
• Dettagli origine script:
  • sourceURL: il nome della risorsa dello script, dove disponibile (o vuoto se non trovato).
  • sourceFunctionName: il nome della funzione dello script, dove disponibile (o vuoto se non trovato).
  • sourceCharPosition: la posizione del carattere dello script, se disponibile (o -1 se non trovata).
• windowAttribution: il contenitore (il documento di primo livello o <iframe>) in cui si è verificato il lungo frame dell'animazione.
• window: un riferimento alla finestra della stessa origine.

Ove fornite, le voci di origine consentono agli sviluppatori di sapere esattamente come è stato chiamato ogni script nel lungo frame dell'animazione, fino alla posizione del carattere nello script di chiamata. Ciò fornisce la posizione esatta in una risorsa JavaScript che ha generato il frame dell'animazione lungo.

Esempio di voce relativa al rendimento long-animation-frame

Un esempio completo di voce relativa al rendimento di long-animation-frame, contenente un singolo script, è:

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

Come si può vedere, ciò fornisce una quantità di dati senza precedenti per consentire ai siti web di comprendere la causa degli aggiornamenti in ritardo del rendering.

Utilizza l'API Long Animation Frames nel campo

Strumenti come Chrome DevTools e Lighthouse, sebbene utili per individuare e riprodurre i problemi, sono strumenti di laboratorio che potrebbero trascurare aspetti importanti dell'esperienza utente che possono essere forniti solo dai dati sul campo.

L'API Long Animation Frames è progettata per essere utilizzata sul campo per raccogliere importanti dati contestuali per le interazioni degli utenti che l'API Long Tasks non potrebbe. Questo può aiutarti a identificare e riprodurre i problemi di interattività che altrimenti non avresti individuato.

Rilevamento della funzionalità del supporto dell'API Long Animation Frames

Per verificare se l'API è supportata, puoi utilizzare il codice seguente:

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

Link all'interazione INP più lunga

Il caso d'uso più ovvio dell'API Long Animation Frames è quello di aiutare a diagnosticare e risolvere i problemi di Interaction to Next Paint (INP) ed è stato uno dei motivi principali per cui il team di Chrome ha sviluppato questa API. Un INP buono è il caso in cui tutte le interazioni ricevono una risposta in 200 millisecondi o meno dall'interazione fino al completamento del disegno e, poiché l'API Long Animation Frames misura tutti i frame che richiedono 50 ms o più, la maggior parte degli INP problematici dovrebbe includere i dati LoAF per aiutarti a diagnosticare queste interazioni.

Il "Pantone INP" è il LoAF che include l'interazione INP, come mostrato nel seguente diagramma:

In alcuni casi è possibile che un evento INP interessi due LoAF, di solito se l'interazione avviene dopo che il frame ha avviato la parte di rendering del frame precedente, quindi il gestore di eventi è stato elaborato nel frame successivo:

In rare circostanze, è persino possibile che raggiunga più di due LoAF.

La registrazione dei dati dei LoAF associati all'interazione INP ti consente di avere molte più informazioni sull'interazione INP per facilitarne la diagnosi. Ciò è particolarmente utile per comprendere il ritardo dell'input, in quanto puoi vedere quali altri script erano in esecuzione in quel frame.

Può anche essere utile comprendere la durata dell'elaborazione e il ritardo della presentazione inspiegabili se i tuoi gestori di eventi non riproducono i valori osservati, poiché potrebbero essere in esecuzione altri script che potrebbero non essere inclusi nei tuoi test.

Non esiste un'API diretta per collegare una voce INP alla voce o alle voci LoAF correlate, sebbene sia possibile farlo nel codice confrontando l'ora di inizio e l'ora di fine di ciascuna (vedi lo script di esempio per WhyNp).

La libreria web-vitals include tutti i LoAF intersecati nella proprietà longAnimationFramesEntries dell'interfaccia di attribuzione INP della versione 4.

Dopo aver collegato le voci LoAF, puoi includere informazioni con l'attribuzione INP. L'oggetto scripts contiene alcune delle informazioni più importanti in quanto può mostrare cos'altro era in esecuzione in quei frame, quindi il beacon di quei dati al tuo servizio di analisi ti consentirà di capire meglio il motivo per cui le interazioni sono state lente.

Segnalare i LoAF per l'interazione INP è un buon modo per individuare i problemi di interattività più urgenti nella tua pagina. Ogni utente potrebbe interagire in modo diverso con la tua pagina e con un volume sufficiente di dati di attribuzione INP, verranno inclusi una serie di potenziali problemi nei dati di attribuzione INP. In questo modo puoi ordinare gli script in base al volume per vedere quali sono correlati a un INP lento.

Segnalare più dati di animazione lunghi a un endpoint di analisi

Uno svantaggio del solo esame delle LoAF INP è che potresti perderti altre potenziali aree di miglioramento che potrebbero causare futuri problemi INP. Questo può determinare la sensazione di andare all'inseguimento e risolvere un problema INP aspettandosi di vedere un enorme miglioramento, per poi scoprire che la successiva interazione più lenta è di poco migliore, quindi l'INP non migliora molto.

Quindi, anziché puntare i riflettori solo guardando il LoAF INP, è consigliabile prendere in considerazione tutte le LoAF dell'intera durata della pagina:

Tuttavia, ogni voce LoAF contiene una quantità considerevole di dati, quindi probabilmente non vorrai ritrasmetterli tutti. Ti consigliamo invece di limitare l'analisi ad alcuni LoAF o ad alcuni dati.

Ecco alcuni pattern suggeriti:

• Osservare frame di animazione lunghi con interazioni
• Osservare i frame dell'animazione più lunghi di una determinata soglia
• Osservare i peggiori frame lunghi dell'animazione
• Identificare pattern comuni nei frame dell'animazione lunghi

Quale di questi pattern funziona meglio per te, dipende dalla lunghezza del tuo percorso di ottimizzazione e dalla lunghezza dei fotogrammi dell'animazione più comuni. Per un sito che non è mai stato ottimizzato per la reattività prima d'ora, potresti voler limitare solo i LoAF con interazioni, impostare una soglia alta o considerare solo i LoAF più peggiori. Per risolvere i problemi comuni di reattività, puoi estenderla non limitandoti alle sole interazioni e abbassando le soglie oppure cercando modelli particolari.

Osservare i frame di animazione lunghi con le interazioni

Per ottenere informazioni oltre al semplice frame di animazione INP, puoi esaminare tutti i LoAF con interazioni (che possono essere rilevate dalla presenza di un valore firstUIEventTimestamp).

Questo può anche essere un metodo più semplice per monitorare le LoAF INP piuttosto che cercare di correlare i due, il che può essere più complesso. Nella maggior parte dei casi viene incluso il valore INP LoAF di una determinata visita e, nei rari casi in cui non lo è, vengono comunque mostrate interazioni lunghe che è importante risolvere, in quanto potrebbero essere l'interazione INP per altri utenti.

Il seguente codice registra tutte le voci LoAF superiori a 150 millisecondi in cui si è verificata un'interazione durante il frame. Qui si sceglie il 150 perché è leggermente inferiore al valore "Buono" di 200 millisecondi Soglia INP. Puoi scegliere un valore superiore o inferiore a seconda delle tue esigenze.

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

Osserva i frame dell'animazione più lunghi di una determinata soglia

Un'altra strategia prevede il monitoraggio di tutti i LoAF e il beacon di quelli superiori a una certa soglia per tornare a un endpoint di analisi per analisi successive:

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

Poiché le voci dei frame dell'animazione lunghe possono essere piuttosto grandi, gli sviluppatori dovrebbero decidere quali dati della voce inviare ad Analytics. Ad esempio, i tempi di riepilogo della voce e forse i nomi degli script o qualche altro insieme minimo di altri dati contestuali che potrebbero essere considerati necessari.

Osserva i peggiori fotogrammi lunghi dell'animazione

Anziché avere una soglia impostata, i siti potrebbero voler raccogliere dati sui frame di animazione più lunghi per ridurre il volume dei dati da beaconing. Quindi, indipendentemente dal numero di frame di animazione lunghi su cui è possibile sperimentare una pagina, vengono visualizzati solo i dati relativi al peggiore, ai cinque o al numero di frame di animazione lunghi assolutamente necessari.

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

Anche queste strategie possono essere combinate: basta osservare i 10 LoAF peggiori con interazioni più lunghe di 150 millisecondi.

Al momento opportuno (idealmente in occasione dell'evento visibilitychange), torna ad Analytics. Per i test locali, puoi utilizzare console.table periodicamente:

console.table(longestBlockingLoAFs);

Identificare i pattern comuni nei frame di animazione lunghi

Una strategia alternativa consiste nell'esaminare gli script comuni che appaiono più spesso nelle voci di frame dell'animazione lunghe. I dati potrebbero essere riportati a livello di script e posizione del carattere per identificare i trasgressori recidivi.

Questo approccio potrebbe funzionare particolarmente bene per le piattaforme personalizzabili, dove su vari siti è possibile identificare temi o plug-in che causano problemi di prestazioni.

Il tempo di esecuzione degli script più comuni (o origini di terze parti) nei frame di animazione lunghi potrebbe essere riepilogato e riportato per identificare i fattori comuni che contribuiscono ai frame di animazione lunghi su un sito o in una raccolta di siti. Ad esempio, per esaminare gli 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});

Un esempio di questo output è:

Utilizza l'API Long Animation Frames negli strumenti

L'API consente inoltre agli sviluppatori strumenti aggiuntivi per il debug locale. Anche se alcuni strumenti come Lighthouse e Chrome DevTools sono stati in grado di raccogliere gran parte di questi dati utilizzando dettagli di tracciamento di livello inferiore, questa API di livello superiore potrebbe consentire ad altri strumenti di accedere a questi dati.

Mostra i dati dei frame di animazione lunghi in DevTools

Puoi far emergere frame di animazione lunghi in DevTools utilizzando l'API performance.measure(), che vengono poi visualizzati nella traccia dei tempi utente di DevTools nelle analisi delle prestazioni per mostrare dove concentrare i tuoi sforzi per migliorare le prestazioni:

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

A lungo termine, probabilmente verrà incorporato in DevTools stesso, ma nel frattempo lo snippet di codice precedente ne consente la visualizzazione.

Utilizza i dati dei frame di animazione lunghi in altri strumenti per sviluppatori

L'estensione Web Vitals ha mostrato il valore nel logging delle informazioni di debug di riepilogo per diagnosticare i problemi di prestazioni.

Ora vengono mostrati anche dati di frame di animazione lunghi per ogni callback INP e ogni interazione:

Utilizza i dati dei frame di animazione lunghi negli strumenti di test automatici

Analogamente, gli strumenti di test automatizzati nelle pipeline CI/CD possono mostrare dettagli su potenziali problemi di prestazioni misurando fotogrammi di animazione lunghi durante l'esecuzione di varie suite di test.

Domande frequenti

Alcune delle domande frequenti su questa API includono:

Perché non si limita a estendere o iterare l'API Long Tasks?

Si tratta di uno sguardo alternativo alla registrazione di una misurazione simile, ma sostanzialmente diversa, dei potenziali problemi di reattività. È importante assicurarsi che i siti che si basano sull'API Long Tasks esistente continuino a funzionare per evitare di interferire con i casi d'uso esistenti.

Anche se l'API Long Tasks può trarre vantaggio da alcune delle funzionalità di LoAF (ad esempio un modello di attribuzione migliore), riteniamo che concentrarsi sui frame anziché sulle attività offra molti vantaggi che rendono questa API sostanzialmente diversa rispetto all'API Long Tasks esistente.

Perché non ci sono voci di script?

Ciò potrebbe indicare che il frame dell'animazione lungo non era dovuto a JavaScript, ma a un rendering di grandi dimensioni.

Questo può accadere anche quando il frame dell'animazione lungo è dovuto a JavaScript, ma non è possibile fornire l'attribuzione dello script per vari motivi di privacy, come indicato in precedenza (principalmente JavaScript non di proprietà della pagina).

Perché sono presenti voci di script ma non informazioni o informazioni di origine limitate?

Questo può accadere per una serie di motivi, ad esempio non esiste una buona fonte a cui indirizzare.

Anche le informazioni relative agli script no-cors cross-origin saranno limitate, ma questo problema può essere risolto recuperando questi script tramite CORS aggiungendo crossOrigin = "anonymous" alla chiamata <script>.

Ad esempio, lo script predefinito di Google Tag Manager da aggiungere alla pagina:

<!-- 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 -->

Può essere migliorato per aggiungere j.crossOrigin = "anonymous" per consentire di fornire dettagli di attribuzione completi per GTM

Questa operazione sostituirà l'API Long Tasks?

Riteniamo che l'API Long Animation Frames sia un'API migliore e più completa per la misurazione di attività lunghe, ma al momento non prevediamo di ritirare l'API Long Tasks.

Feedback richiesto

È possibile fornire feedback nell'elenco dei problemi di GitHub oppure è possibile segnalare eventuali bug nell'implementazione dell'API di Chrome nello strumento di monitoraggio dei problemi di Chrome.

Conclusione

L'API Long Animation Frames è una nuova ed entusiasmante API che offre molti potenziali vantaggi rispetto alla precedente API Long Tasks.

Si sta rivelando uno strumento fondamentale per affrontare i problemi di reattività misurati da INP. L'INP è una metrica difficile da ottimizzare e questa API è uno dei modi in cui il team di Chrome sta cercando di semplificare l'identificazione e la risoluzione dei problemi per gli sviluppatori.

L'ambito dell'API Long Animation Frames va oltre il semplice INP e può aiutare a identificare altre cause di aggiornamenti lenti che possono influire sulla fluidità generale dell'esperienza utente di un sito web.

Ringraziamenti

Immagine in miniatura di Henry Be su Unsplash.