La missione dell'Economic Times per correggere l'INP

La riduzione di TBT di 30 volte e la migrazione a Next.js ha aiutato The Ecomonic Times a ridurre l'INP di quasi quattro volte, generando una diminuzione del 50% della frequenza di rimbalzo e un aumento del 43% delle visualizzazioni di pagina.

Daya Ram Yadav
Daya Ram Yadav
Saurabh Rajpal
Saurabh Rajpal

Interazione con Next Paint (INP) è una metrica che valuta la reattività di un sito web all'input degli utenti. Una buona reattività indica che una pagina risponde rapidamente alle interazioni degli utenti. Più basso è l'INP di una pagina, migliore è la capacità di rispondere alle interazioni degli utenti.

I valori INP buoni sono pari o inferiori a 200 millisecondi, quelli bassi sono superiori a 500 millisecondi e qualsiasi intervallo intermedio deve essere migliorato.

L'inizio indistinto

Quando Google ha inizialmente introdotto l'INP come metrica sperimentale con il potenziale di evolvere in una delle metriche di Core Web Vitals, il team di Economic Times ha deciso di risolvere questo problema prima che passasse a una delle metriche sperimentali, poiché offrire un'esperienza utente di prim'ordine è fondamentale per i nostri valori aziendali fondamentali.

L'INP è stato una delle metriche più difficili da risolvere finora. All'inizio, non era chiaro come misurare efficacemente l'INP. Ciò che ha reso più difficile è stata la mancanza di assistenza dalla community, inclusa la maggior parte dei fornitori di Real User Monitoring (RUM) che non lo supporta ancora. Tuttavia, avevamo strumenti RUM di Google come il Report sull'esperienza utente di Chrome (CrUX), la libreria JavaScript web-vitals e altri strumenti che lo supportavano, che ci hanno dato un'idea del nostro punto di vista durante la valutazione del percorso da intraprendere. Quando abbiamo iniziato,il nostro INP era vicino ai 1000 millisecondi al livello di origine.

Una cosa che è emersa durante la correzione dell'INP sul campo è che una delle metriche del lab da scegliere come target potrebbe essere il tempo di blocco totale (TBT). TBT era già ben documentato e supportato dalla community. Nonostante avesse già raggiunto le soglie previste per Core Web Vitals, tuttavia, non abbiamo avuto un buon rendimento sul fronte TBT, dato che erano trascorsi più di 3 secondi quando abbiamo iniziato.

Che cos'è TBT e quali misure abbiamo adottato per migliorarla?

TBT è una metrica di laboratorio che misura la reattività di una pagina web all'input dell'utente durante il caricamento della pagina. Qualsiasi attività che richieda più di 50 millisecondi per essere eseguita è considerata lunga, mentre il tempo dopo la soglia di 50 millisecondi è noto come tempo di blocco.

Il valore TBT viene calcolato sommando il tempo di blocco di tutte le attività lunghe durante il caricamento della pagina. Ad esempio, se ci sono due attività lunghe durante il caricamento, il tempo di blocco viene determinato come segue:

  • L'attività A richiede 80 millisecondi (30 millisecondi in più di 50 millisecondi).
  • L'attività B richiede 100 millisecondi (50 millisecondi in più di 50 millisecondi).

Il TBT della pagina sarà: 80 millisecondi (30 + 50). Più basso è il TBT, meglio è; inoltre, TBT correla bene con INP.

Ecco un rapido confronto di laboratorio della nostra prima e dopo l'esecuzione delle azioni per migliorarla:

Un'immagine composita di attività lunghe durante l'avvio, come mostrato nel riquadro delle prestazioni di Chrome DevTools, e un report delle metriche della pagina. Il thread principale viene bloccato durante il caricamento della pagina per 3260 millisecondi.
. Il thread principale durante l'avvio prima di ottimizzare TBT. Il valore TBT è di 3260 millisecondi.
. Un'immagine composita di attività lunghe durante l'avvio, come mostrato nel riquadro delle prestazioni di Chrome DevTools, e un report delle metriche della pagina. Il thread principale viene bloccato durante il caricamento della pagina per 120 millisecondi.
Il thread principale durante l'avvio dopo l'ottimizzazione di TBT. Il valore TBT è di 120 millisecondi.

Riduci al minimo il lavoro del thread principale

Il thread principale del browser gestisce tutto, dall'analisi del codice HTML alla creazione del DOM, all'analisi del codice CSS e all'applicazione di stili, nonché alla valutazione e all'esecuzione di JavaScript. Il thread principale gestisce anche le interazioni degli utenti, ovvero clic, tocchi e pressioni di tasti. Se il thread principale è impegnato con altre attività, potrebbe non rispondere in modo efficiente agli input dell'utente e portare a un'esperienza utente insoddisfacente.

Questa è stata l'attività più difficile per noi, poiché disponiamo di nostri algoritmi per rilevare l'identità degli utenti e pubblicare annunci in base allo stato dell'abbonamento e script di terze parti per i test A/B, le analisi e altro ancora.

All'inizio abbiamo fatto piccoli passi, come ridurre la priorità al caricamento di asset aziendali meno importanti. In secondo luogo, abbiamo utilizzato requestIdleCallback per le attività non critiche, il che può contribuire a ridurre le TBT.

if ('requestIdleCallback' in window) {
  this.requestIdleCallbackId = requestIdleCallback(fetchMarketsData.bind(this), {timeout: 3000});
} else {
  fetchMarketsData(); // Fallback in case requestIdleCallback is not supported
}

Si consiglia di specificare un timeout quando si utilizza requestIdleCallback, in quanto fa in modo che, se il tempo specificato è trascorso e il callback non è già stato chiamato, il callback esegue il callback immediatamente dopo il timeout.

Riduci al minimo i tempi di valutazione degli script

Inoltre, abbiamo caricato librerie di terze parti tramite caricamento lento utilizzando Componenti caricabili. Abbiamo anche rimosso JavaScript e CSS inutilizzati profilando la pagina con lo strumento di copertura in Chrome DevTools. Ci ha aiutato a identificare le aree in cui era necessario l'agitazione degli alberi per distribuire meno codice durante il caricamento della pagina e, di conseguenza, ridurre le dimensioni iniziali del bundle dell'applicazione.

Uno screenshot dello strumento Copertura in Chrome DevTools. Qui, lo strumento mostra le parti inutilizzate dei file JavaScript e CSS durante il caricamento della pagina.

Riduci le dimensioni del DOM

Per Lighthouse, le dimensioni DOM di grandi dimensioni aumentano l'utilizzo della memoria, causano ricalcoli di stile più lunghi e generano costosi ricalcoli del layout.

Uno screenshot dell'audit delle dimensioni del DOM in Lighthouse. Il numero di elementi DOM riportato è pari a 2706 elementi.

Abbiamo ridotto il numero di nodi DOM in due modi:

  • In primo luogo, abbiamo reso le voci di menu su richiesta dell'utente (al clic). Ha ridotto le dimensioni del DOM di circa 1200 nodi.
  • Secondo, abbiamo caricato widget meno importanti tramite caricamento lento.

Grazie a tutti questi sforzi, abbiamo ridotto in modo significativo il valore TBT e il nostro INP è stato ridotto di conseguenza di quasi il 50%:

Uno screenshot del controllo INP in CrUX. L'INP della pagina è di 539 millisecondi, ossia supera il valore "scarso" soglia.

A questo punto, avevamo quasi esaurito le facili vittorie per ridurre ulteriormente TBT (e INP per proxy), ma sapevamo di avere molto margine di miglioramento. Per questo motivo abbiamo deciso di eseguire l'upgrade del nostro boilerplate personalizzato di UI alla versione più recente di React insieme a Next.js per utilizzare meglio gli hook ed evitare il rendering non necessario dei componenti.

A causa di aggiornamenti più frequenti e di un traffico relativamente minore rispetto alle altre parti del sito web, abbiamo iniziato a eseguire la migrazione delle nostre pagine degli argomenti a Next.js. Abbiamo anche utilizzato PartyTown per trasferire ai worker sul web altre attività molto complesse relative al thread principale, insieme a tecniche come requestIdleCallBack per rimandare le attività non critiche.

In che modo il miglioramento dell'INP ha aiutato The Economic Times?

Attuali TBT e INP sull'origine

Al momento della pubblicazione di questo post, il valore TBT per la nostra origine era di 120 millisecondi, in calo rispetto ai 3260 millisecondi quando abbiamo iniziato i nostri sforzi di ottimizzazione. Analogamente, l'INP per la nostra origine era di 257 millisecondi dopo i nostri sforzi di ottimizzazione, in calo da oltre 1000 millisecondi.

Uno screenshot del controllo INP in CrUX. L'INP della pagina è di 257 millisecondi, rientrando nelle "necessità di miglioramento" soglie.

Tendenza INP CrUX

Il traffico ricevuto sulle pagine degli argomenti rappresenta una porzione notevolmente minore del traffico complessivo. Pertanto, era un luogo ideale per la sperimentazione. I risultati di CrUX, insieme ai risultati aziendali, sono stati molto incoraggianti e ci hanno portato a espandere i nostri sforzi sull'intero sito web per ottenere ulteriori vantaggi.

Uno screenshot delle distribuzioni INP visualizzate in CrUX in un periodo di quattro mesi, a partire da luglio 2022 e fino a ottobre 2022. Valori all'interno del criterio "scarso" e "richiede miglioramenti" le soglie sono leggermente diminuite, mentre i valori all'interno dei valori "buoni" soglia è stata aumentata.

Analisi TBT di Akamai mPulse

Utilizziamo mPulse di Akamai come soluzione RUM, che misura i TBT sul campo. Abbiamo osservato una diminuzione costante del valore da registrare, che corrisponde chiaramente ai risultati dei nostri sforzi per ridurre l'INP. Come si può vedere nello screenshot seguente, i valori TBT alla fine sono scesi da circa 5 secondi a circa 200 millisecondi sul campo.

Uno screenshot di un grafico in Akamai mPulse, che mostra un calo del valore di TBT nel corso di circa un mese.

Risultati aziendali

Nel complesso, i nostri sforzi per ridurre TBT di 30 volte, insieme alla migrazione a Next.js, ci hanno aiutato a ridurre l'INP di quasi 4 volte, il che alla fine ha portato a una diminuzione del 50% della frequenza di rimbalzo e un aumento del 43% delle visualizzazioni di pagina sulle pagine degli argomenti.

Uno screenshot di Google Analytics che mette a confronto le visualizzazioni di pagina e la frequenza di rimbalzo. Grazie alle ottimizzazioni apportate a INP sul sito web The Economic Times, è stata registrata una diminuzione del 50% della frequenza di rimbalzo e un aumento del 43% delle visualizzazioni di pagina.

Conclusione

Per riassumere, INP ha notevolmente contribuito a determinare i problemi di prestazioni del runtime in parti del sito web di Economic Times. Ha dimostrato di essere una delle metriche più efficaci per avere un impatto positivo sui risultati aziendali. A causa dei numeri molto incoraggianti che abbiamo osservato come risultato di questo impegno, siamo motivati a estendere i nostri sforzi di ottimizzazione ad altre aree del nostro sito web e a trarre ulteriori vantaggi.