Reidratazione, o più semplicemente "idratazione", è un termine che ricorre spesso quando guardiamo alle SPA e al rendering lato server.
L'idratazione, in sostanza, non influisce sulla SEO, ma è un passaggio essenziale per servire le pagine renderizzate all'utente.
Esistono diversi tipi di idratazione che possono essere utilizzati.
Diversi stack e framework tecnologici potrebbero già supportare diversi tipi di idratazione.
Cos'è la reidratazione?
In parole povere, la reidratazione consente a un'applicazione Web o a una pagina di raggiungere il suo stato interattivo dopo il rendering sul lato server.
Questo potrebbe non essere importante per i motori di ricerca, ma è fondamentale per ottenere risultati corretti se il sito Web offre agli utenti componenti renderizzati e interattivi.
Questo processo viene utilizzato nelle applicazioni a pagina singola (SPA) insieme al rendering lato server, che consente un First Contentful Paint (FCP) più rapido e il contenuto lato client viene "idrato" per il Largest Contentful Paint (LCP).
Il processo, quindi, prevede l'acquisizione dello stato corrente della pagina o dell'app sul lato client serializzato dal renderer, l'avvio dei componenti JavaScript nell'interattività utilizzando JavaScript caricato o collegato nella risposta HTML.
Come termine generale, idratazione, in questo caso, significa che tutti i componenti della pagina web sono inizializzati.
Ciò può portare a risultati Core Web Vital migliori e richiede intrinsecamente meno sforzi da parte di Googlebot per il rendering della pagina web. Inoltre, i motori di ricerca possono indicizzare le pagine più velocemente, in quanto ciò non deve passare attraverso il WRS (Web Rendering Service) di Google.
Spiegazione della reidratazione progressiva
La reidratazione progressiva ottimizza il rendering e l'interattività dei singoli componenti e coinvolge sia il rendering lato server che il rendering lato client (CSR) man mano che le parti di una pagina vengono avviate nel tempo.
La reidratazione progressiva consente ai componenti JavaScript di essere essenzialmente caricati in modo pigro, in cui i nodi vengono idratati nel tempo anziché tutti i nodi vengono idratati contemporaneamente.
Ciò consente di inizializzare successivamente i componenti che potrebbero non essere essenziali, riducendo il tempo di caricamento totale.
Infatti, sia gli utenti che i robot e i crawler dei motori di ricerca possono iniziare a vedere e interagire con le pagine non appena viene eseguito il rendering dell'HTML, anche prima dell'esecuzione di JavaScript.
La reidratazione progressiva aiuta anche a evitare le comuni insidie SSR, ad esempio quando un albero DOM (Document Object Model) con rendering del server viene distrutto e ricostruito immediatamente.
Cos'è la reidratazione parziale?
Un'altra forma di reidratazione, la reidratazione parziale, consente l'idratazione selettiva dei componenti JavaScript o, più specificamente, delle "isole" senza dover idratare tutti i componenti.
La tecnica combina sia SSR che CSR.
In questo scenario, il server invia al client un documento HTML iniziale insieme al contenuto reso dal server. Una volta caricato, il JavaScript lato client avvia e manipola il DOM per aggiungere o aggiornare il contenuto esistente su "isole" specificate.
Ciò significa che JavaScript aggiorna in modo selettivo parti della pagina anziché l'intera pagina.
La reidratazione parziale è vista come una tecnica potente per l'ottimizzazione delle prestazioni delle SPA per il caricamento delle prestazioni e dell'efficienza.
Detto questo, ha i suoi problemi, in quanto può presentare sfide per la memorizzazione nella cache e la navigazione lato client.
Uno sguardo al rendering trisomorfo
Il rendering trisomorfo è meno comune nelle comunità di sviluppo e SEO tecnico.
Il processo prevede il rendering di SPA sui lati server e client, nonché su un service worker per eseguire il rendering dell'HTML per l'utilizzo delle navigazioni.
Il processo utilizza una combinazione di rendering in streaming lato server, che esegue il rendering delle navigazioni iniziali, e il service worker esegue il rendering dell'HTML per le navigazioni. Il rendering lato server in streaming assicura che il contenuto necessario venga inviato ai motori di ricerca.
Nel mondo dello sviluppo, significa che i componenti e i modelli memorizzati nella cache possono essere mantenuti aggiornati e che è possibile abilitare le navigazioni in stile SPA per il rendering di nuove viste nella stessa sessione.
Quando è meglio usare la reidratazione?
La reidratazione è una necessità per i siti Web che devono essere altamente interattivi, come le applicazioni a pagina singola, perché consente tempi di caricamento iniziale più rapidi e una migliore esperienza utente.
Scegliere un tipo specifico di idratazione richiede la conoscenza di come funziona il tuo stack tecnologico e cosa funziona meglio per il tuo sito web.
Esistono anche alternative all'idratazione, come la ripresabilità, che differisce in base a dove viene eseguito il codice e quando viene eseguito.
La ripresabilità può essere un'alternativa all'idratazione e può quasi eliminare la necessità di eseguire JavaScript all'avvio della pagina, ovvero app quasi "istantanee" rispetto a un processo di idratazione.
Quando il client invia una richiesta al server, il server prima ricostruisce l'applicazione e la serializza in HTML. L'HTML viene quindi restituito al client.
Il client quindi riprende l'applicazione dal punto in cui il server l'ha serializzata; quindi, quando un utente interagisce con un elemento della pagina, solo quel gestore di eventi viene richiesto ed eseguito su richiesta.
La ripristinabilità e i framework ripristinabili non sono nuovi. Google ha utilizzato un framework ripristinabile internamente denominato Wiz per i prodotti di ricerca e foto e eBay utilizza un framework chiamato Marko che ha aggiunto la ripristinabilità come funzionalità.
Altre risorse:
Immagine di presentazione: UnderhilStudio/Shutterstock
