Il problema dell’idratazione completa

L'hydration è il processo con cui React prende l'HTML renderizzato dal server e vi associa i listener degli eventi JavaScript. Il server invia l'HTML iniziale, rapidamente; poi il browser scarica il bundle JavaScript e React esegue l'"hydration" dell'HTML statico per renderlo interattivo. Fino al completamento dell'hydration, la pagina sembra interattiva, ma non lo è.

Una single-page application tradizionale invia al browser l'intero bundle JavaScript. React deve scaricarlo, analizzarlo, eseguirlo e poi associare i listener degli eventi a ogni componente dell'albero. Nelle applicazioni di grandi dimensioni, questo processo può richiedere diversi secondi sui dispositivi mobili di fascia media.

Il Time To Interactive misura quanto tempo deve trascorrere prima che l'utente possa interagire con la pagina. L'hydration blocca direttamente il TTI: la pagina può sembrare pronta, perché l'HTML renderizzato dal server è visibile, ma pulsanti e form non rispondono finché React non ha terminato di associare i listener degli eventi. Un valore TTI elevato indica un'esperienza utente scadente.

Si consideri una pagina di marketing: l'80% dei contenuti è costituito da testo, immagini e intestazioni statici che non cambiano mai. Solo il 20% comprende widget interattivi, come un form per la newsletter o un lettore video. L'hydration di una SPA tradizionale viene comunque eseguita sul 100% della pagina, elaborando inutilmente i componenti statici.

La profilazione delle prestazioni in Chrome DevTools rivela il costo dell'hydration. Nel grafico a cascata del thread principale è possibile individuare l'attività "React hydration" come un lungo blocco di esecuzione JavaScript successivo al primo rendering. Più è lungo questo blocco, più a lungo il thread principale è occupato e meno reattiva risulta la pagina.

Più è grande l'albero dei componenti React, maggiore è il lavoro richiesto dall'hydration. React deve visitare ogni componente, confrontare l'HTML renderizzato dal server con quello che il componente produrrebbe e associare i listener degli eventi. Una pagina complessa con centinaia di componenti può avere un sovraccarico di hydration misurabile anche sui dispositivi più veloci.

React 18 ha introdotto l'hydration concorrente, che consente a React di suddividere l'hydration in blocchi più piccoli e di cedere il controllo al browser tra un blocco e l'altro. In questo modo si evita che il browser sembri completamente bloccato durante l'hydration di alberi di grandi dimensioni. Tuttavia, l'hydration concorrente riduce l'impatto, ma non elimina il costo fondamentale.

L'hydration selettiva, tramite Suspense, consente a React di eseguire l'hydration dei componenti in ordine di priorità: le interazioni dell'utente attivano immediatamente l'hydration del componente interessato. Questo migliora la reattività, ma opera comunque all'interno di un unico albero React: alla fine tutti i componenti dell'albero vengono sottoposti a hydration.

L'intuizione fondamentale alla base di Islands Architecture è che gran parte di una pagina tipica non ha affatto bisogno di JavaScript. Barre di navigazione, sezioni hero, collegamenti nel footer, testo degli articoli di blog e descrizioni dei prodotti sono esclusivamente presentazionali. Imporre l'hydration anche a questi elementi è, per definizione, uno spreco.

Gli studi condotti dai team che si occupano delle prestazioni web mostrano che il tempo di analisi ed esecuzione di JavaScript è il costo principale sui dispositivi mobili. Un bundle JavaScript da 300 kB richiede da 2 a 3 secondi per essere analizzato su un telefono Android mediano. Ridurre la quantità di JavaScript inviata al browser porta vantaggi prestazionali molto superiori rispetto a qualsiasi ottimizzazione interna di React.

Ogni kilobyte di JavaScript aggiunto a un'applicazione React comporta ulteriore lavoro di hydration. Anche se un componente è puramente decorativo, se fa parte dell'albero React partecipa all'hydration. Questa "tassa dell'hydration" cresce con le dimensioni dell'applicazione e rende progressivamente più difficile mantenere buoni valori TTI man mano che le applicazioni aumentano di dimensioni.

Qual è il rapporto tra l'hydration di React e il Time To Interactive (TTI)?

L'hydration tradizionale di React elabora l'intero albero dei componenti, compresi i contenuti statici che non hanno bisogno di JavaScript. Questo blocca il Time To Interactive e presenta una scalabilità scarsa all'aumentare delle dimensioni dell'applicazione. I miglioramenti all'hydration concorrente e selettiva introdotti in React 18 ne riducono l'impatto, ma non eliminano il costo fondamentale. L'intuizione principale è che gran parte dei contenuti della pagina non ha semplicemente bisogno di JavaScript, rendendo l'hydration completa uno spreco.