In che modo le lunghe attività JavaScript influenzano le prestazioni del sito – e cosa fare al riguardo

L’esecuzione di attività JavaScript è spesso la fonte dei più comuni problemi di prestazione dei siti web. Evitare le cosiddette attivtà lunghe e bloccare il thread JavaScript (JS) principale è una delle strategie più importanti per migliorare le prestazioni. In questo articolo, daremo un’occhiata a come le lunghe attività JavaScript possono influire sulle prestazioni del sito, nonché ai metodi che si possono adottare per gestirle.

Riepilogo

• Cos’è un’ attività JavaScript lunga?
• Perché le attività JavaScript lunghe sono dannosi per Core Web Vitals?
• Come trovare e misurare le lunghe attività JavaScript?
• Raccomandazioni generali per eliminare le attivià JavaScript lunghe
• Come abbiamo risolto il problema delle lunghe attività JavaScript con Prism

Cos’è un’ attività JavaScript lunga?

I browser eseguono le operazioni di visualizzazione della pagina in un singolo thread, quindi è fondamentale che il tempo di esecuzione delle attivià  in JS non superi i 50 ms. Se questo indicatore viene superato, il fenomeno è chiamato attivià lunga. Quando si verifica, l’utente nota un aumento del carico sul browser. In questo caso, i clic sugli elementi della pagina sono ritardati, lo scorrimento diventa a scatti, o la pagina non risponde affatto.

Inoltre, oltre al codice del sito (esecuzione di JS), la formazione di attività lunghe  può essere influenzata dalla velocità della rete e dalla potenza di elaborazione. Per esempio, se le attività lunghe bloccano il thread principale del browser a causa della bassa potenza di elaborazione, il browser non sarà in grado di elaborare i dati dell’utente abbastanza velocemente, portando a un ritardo nella risposta della pagina.

Vale la pena menzionare che le attività lunghe possono verificarsi quando si cambia lo stile di un elemento via JS, per esempio, quando un blocco cambia in altezza, forzando un ricalcolo delle coordinate sulla pagina: ricalcolare lo stile => reflow, repaint.

Perché le lunghe attività JavaScript sono un male per Core Web Vitals?

La metrica FID (First Input Delay o tempo di attesa prima della prima interazione con il contenuto) è la più colpita dalle attività lunghe. Il thread principale del browser non è uniformemente occupato per tutta la durata di una pagina, quindi FID può variare notevolmente, a seconda di quando esattamente l’utente interagisce per la prima volta con la pagina. Di conseguenza, alcuni utenti possono non sperimentare alcuna latenza, mentre altri affrontano immediatamente i sintomi di sovraccarico che abbiamo già discusso. Ecco perché è importante capire come cercare attività lunghe e ottimizzare il codice per migliorare il FID del tuo sito.

Il FID dipende direttamente dal comportamento reale degli utenti e, come già detto sopra, è unico per ognuno di loro. La chiave qui è il monitoraggio del comportamento, che può essere fatto con uno strumento di monitoraggio Core Web Vitals per eseguire l’ottimizzazione basata su dati reali.

Come trovare e misurare le attività JavaScript lunghe? 

I seguenti servizi ci aiuteranno in questo:

Chrome DevTools

Nel pannello Performance, registra la traccia di caricamento della pagina web.

Cerca le bandiere rosse nell’area del flusso. Le “attività” sono mostrate in grigio.

Passa il cursore sulla barra per vedere quanto tempo ha impiegato L’attività per essere eseguita e se è considerata “lunga”.

Per scoprire l’origine di un’ attività lunga, seleziona la barra grigia delle attività. Nel pannello a scorrimento in basso seleziona le opzioni Bottom-Up e Group by Activity. Potrai vedere quali azioni hanno contribuito maggiormente all’esecuzione dell’attività.

Webpagetest.org

Il blocco del thread principale per 50 ms è mostrato nel diagramma con i blocchi rossi. Questo evento blocca anche l’input dell’utente. Il colore verde significa che il thread non è bloccato.

API per le attività lunghe

Possiamo misurare le attività lunghe in qualsiasi applicazione dopo aver sottoscritto l’interfaccia PerformanceObserver con il seguente codice:

var observer = new PerformanceObserver(function(list) {

    var perfEntries = list.getEntries();

    for (var i = 0; i < perfEntries.length; i++) {

        // Process long task notifications:

        // report back for analytics and monitoring

        // …

    }

});

// register observer for long task notifications

observer.observe({entryTypes: [“longtask”]});

// Long script execution after this will result in queueing

// and receiving “longtask” entries in the observer.

Raccomandazioni generali per eliminare le lunghe attività JavaScript

• Eseguire il codice dei Web Workers in un thread separato, permettendo al thread principale di concentrarsi su altre attività importanti, come l’analisi dell’HTML, la preparazione del rendering, il rendering dei pixel, la risposta all’input dell’utente, ecc.
• Rompere il codice JavaScript contrassegnato come attività lunga in compiti più piccoli, utilizzando le funzioni “setTimeout/requestidlecallback/requestAnimationFrame”. Questo farà sì che il thread principale venga eseguito nel modo più efficiente possibile ed esegua tutte le operazioni senza ritardi.
• Facilitare il carico di rete quando si carica una pagina (fare meno richieste di rete possibili, caricarle il più tardi possibile, preferibilmente dopo l’evento FID).
• Ritardare il JavaScript inutilizzato usando async o defer.

Come abbiamo risolto il problema delle lunghe attività  JavaScript con Prism

Clickio Prism utilizza una tecnologia avanzata per creare una versione di un sito web a caricamento rapido e ottimizzata per i dispositivi mobili. Durante lo sviluppo di Prism, era importante garantire che le pagine venissero caricate rapidamente, senza alcun impatto negativo sull’esperienza dell’utente, quindi abbiamo intrapreso le seguenti azioni per eliminare le attività JavaScript lunghe:

• Diviso le attività lunghe in attività più piccole usando la funzione requestidlecallback/requestAnimationFrame.
• Ottenuto big data che non interagiscono con il DOM (usando i Web Workers). 
• Creato una coda di script per i widget di caricamento.
• Ridotto il carico della CPU dei processi durante il caricamento della pagina (riducendo il numero di richieste e il trasferimento di dati durante il rendering della pagina).
• Caricato alcuni tracker di terze parti con la libreria partytown.js.

Incorporando modifiche tecniche come queste, insieme ad altre caratteristiche come un CDN globale e il lazy loading intelligente, Prism può fare una differenza significativa per le prestazioni del sito e l’esperienza dell’utente. Infatti, in media gli editori che usano Prism vedono i visitatori passare il 45% di tempo in più sul loro sito e un aumento del 59% del loro RPM di sessione.

Per saperne di più su Prism e impostare una prova gratuita, clicca qui.