Cos’è il rendering JavaScript e come funziona
Il rendering JavaScript è il processo con cui un browser, o un motore di ricerca, legge HTML, CSS e JavaScript e li trasforma nella pagina visibile e interattiva che l’utente vede. In questo articolo lo guardo dal lato della SEO tecnica, cioè da cosa vede Googlebot quando una pagina si costruisce via script invece che già pronta nell’HTML di partenza.
Rendering JavaScript in sintesi
- Cos’è: la trasformazione del codice sorgente in una pagina visibile, fatta dal browser o da un motore di ricerca.
- Modelli: CSR, SSR, SSG e ISR distribuiscono diversamente il lavoro tra server e client.
- Chi lo esegue: nel browser dell’utente oppure, per il traffico organico, Googlebot in una fase separata dal crawling.
- Effetto sulla SEO: un rendering lento o incompleto ritarda l’indicizzazione e peggiora LCP e INP.
- Come si verifica: con gli strumenti per sviluppatori del browser e con i test di Google pensati per il rendering.
I modelli di rendering: CSR, SSR, SSG e ISR
Il rendering cambia nome a seconda di dove avviene l’elaborazione del codice, e questo decide che cosa riceve per primo chi apre la pagina. Nel CSR il lavoro passa quasi tutto al browser: il server invia un file HTML quasi vuoto e un pacchetto di JavaScript che, una volta eseguito, costruisce il contenuto. Nel SSR il server genera l’HTML completo prima di inviarlo, e chi riceve la pagina trova già tutto pronto. Nel SSG l’HTML viene prodotto una volta sola in fase di build e distribuito da una rete di distribuzione dei contenuti. L’ISR è una via di mezzo: rigenera le pagine statiche a intervalli o su richiesta, senza dover ricostruire l’intero sito.
| Modello | Dove avviene | Cosa riceve il browser | Effetto principale sulla SEO |
|---|---|---|---|
| CSR | Nel browser | HTML quasi vuoto + bundle JS | Richiede una fase di rendering aggiuntiva da parte del bot |
| SSR | Sul server, a ogni richiesta | HTML completo | Contenuto leggibile subito, nessuna attesa |
| SSG | In fase di build | File HTML statici pronti | Velocità massima, nessun carico server a runtime |
| ISR | Sul server, a intervalli | HTML statico aggiornato | Unisce la velocità dello statico con contenuti aggiornabili |
Non è un modello che vale sempre meglio degli altri: un catalogo che cambia ogni minuto si comporta male in SSG, una landing page istituzionale si comporta male in CSR puro. Nel mio lavoro guardo prima che tipo di contenuto cambia e con quale frequenza, poi scelgo il modello.
Cosa succede nel browser quando una pagina usa il rendering lato client
Quattro passaggi separano la richiesta dell’utente dalla pagina completa, in un sito costruito con React, Vue o Angular.
- Il browser chiede la pagina al server, come farebbe per qualsiasi URL.
- Il server risponde con un file HTML quasi vuoto, un contenitore, più i link ai file JavaScript necessari.
- Il browser scarica quel JavaScript, lo compila e lo esegue.
- Lo script costruisce gli elementi della pagina dentro il DOM, e solo a questo punto il contenuto diventa visibile.
Finché il terzo passaggio non è finito, chi guarda quella pagina (persona o bot) vede un contenitore vuoto. Per questo un sito in CSR puro ha quasi sempre un primo impatto più lento di un sito in SSR: il lavoro che prima faceva il server ora lo fa la CPU di chi riceve la pagina.
Come Google esegue il rendering di una pagina JavaScript
Googlebot ripete una versione del percorso del browser, ma in più fasi distinte. Prima scopre l’URL tramite link o sitemap, poi lo scarica (crawling) e legge HTML e CSS per capire struttura e stile. Se la pagina usa JavaScript per generare o modificare il contenuto, Googlebot esegue quel codice in una fase di rendering separata, costruisce il DOM risultante e solo allora indicizza ciò che ha trovato. Il ranking arriva dopo, sulla base di quel contenuto indicizzato.
Tra il crawling e l’esecuzione del JavaScript può passare del tempo: è la cosiddetta coda di rendering, e un sito con molte pagine da eseguire rischia ritardi nell’indicizzazione dei contenuti generati da script. Chi gestisce siti di grandi dimensioni, dove questo ritardo pesa di più sul budget di scansione, trova un approfondimento specifico nella pagina sull’ottimizzazione del crawl budget.
Molti scraper e i crawler dell’intelligenza artificiale generativa leggono solo il markup HTML iniziale e non eseguono JavaScript, quindi vedono il contenitore vuoto di un CSR puro.
Impatto del rendering JavaScript su SEO e Core Web Vitals
Il rendering lato client sposta lavoro dal server alla CPU di chi visita la pagina, e questo si vede sulle metriche di performance. Il LCP misura quando appare l’elemento principale della pagina, l’INP misura quanto la pagina resta reattiva agli input: un bundle JavaScript pesante da scaricare ed eseguire ritarda entrambi, perché il thread principale del browser resta occupato più a lungo. Anche il TTFB e il FCP peggiorano quando il server deve generare l’HTML dinamicamente a ogni richiesta, rispetto a un file statico già pronto.
Un sito con traffico molto variabile può adottare un rendering misto: pagine statiche o server-rendered per i contenuti che cambiano poco, e rendering lato client solo per le aree davvero interattive. Un grande servizio di streaming internazionale usa il server-side rendering per le pagine di destinazione relativamente stabili e riserva il client-side rendering alle schermate con più interazione.
Per interventi mirati su queste metriche, nel sito tratto il tema a parte nella pagina sull’ottimizzazione dei Core Web Vitals.
Idratazione, reidratazione e prerendering: i termini da conoscere
Idratazione, reidratazione e prerendering indicano tre cose diverse.
- Idratazione
- L’esecuzione di script lato client che aggiunge interattività a un HTML già generato sul server, assumendo che il DOM non cambi.
- Reidratazione
- L’aggiornamento continuo del DOM con lo stato più recente, anche dopo l’idratazione iniziale.
- Prerendering
- L’esecuzione di un’applicazione lato client in fase di build, per catturarne lo stato iniziale come HTML statico.
La differenza pratica si verifica così: una pagina con rendering statico resta interattiva anche con JavaScript disattivato nel browser, una pagina prerenderizzata ha bisogno di quello script per diventare davvero utilizzabile, anche se arriva già con un primo contenuto visibile.
Quale modello di rendering scegliere per la SEO
La scelta dipende da che cosa deve fare la pagina, non da quale framework è più discusso in quel momento.
| Se la priorità è… | Il modello da preferire è |
|---|---|
| Contenuto che cambia raramente (pagine informative, articoli) | SSG, per la velocità e per non dipendere dall’esecuzione di JS |
| Contenuto che cambia spesso ma non a ogni secondo (cataloghi, listini) | ISR, per aggiornare senza ricostruire tutto il sito |
| Contenuto generato su misura per ogni richiesta (ricerche interne, dati personalizzati) | SSR, per avere subito HTML completo e leggibile |
| Applicazione altamente interattiva, non indicizzabile o non centrale per il traffico organico | CSR, accettando il costo sul primo impatto |
Sconsiglio il CSR puro su qualunque pagina pensata per portare traffico da ricerca: funziona per le aree riservate o per le applicazioni dietro login, dove Google non deve leggere nulla.
Come verificare se Google vede il rendering della tua pagina
Si verifica confrontando quello che il browser mostra con quello che un motore di ricerca riesce a costruire dallo stesso codice.
- Apri la pagina negli strumenti per sviluppatori del browser e disattiva JavaScript: se i contenuti principali spariscono, quella pagina dipende dal rendering lato client.
- Controlla, nella sezione dedicata alla copertura dell’indice, se l’URL risulta scansionato e indicizzato correttamente: trovi la guida ai problemi di copertura risolti per interpretare gli stati che compaiono.
- Usa lo strumento di ispezione URL per vedere l’HTML renderizzato da Google, non solo quello di partenza, e confrontalo con il contenuto reale della pagina.
- Verifica che link interni, meta tag e testo essenziale compaiano anche in quella versione renderizzata: un contenuto assente lì rischia di restare fuori dal funzionamento dell’indicizzazione.
Se durante questo controllo compaiono elementi dinamici caricati via AJAX, verifica separatamente anche quelli: un motore di ricerca può eseguire JavaScript ma non è detto che aspetti ogni chiamata asincrona prima di fermare il rendering.
Errori frequenti che bloccano il rendering
La maggior parte dei problemi di rendering che trovo analizzando un sito si ripete sempre sugli stessi punti.
- File JavaScript o CSS bloccati da robots.txt: il motore di ricerca non può eseguirli e vede una versione incompleta della pagina.
- Contenuto generato solo dopo un’interazione dell’utente (clic, scroll), che il rendering automatico non simula.
- Tag canonical o direttive noindex diverse tra l’HTML di partenza e la versione renderizzata, che confondono quale versione va indicizzata.
- Versione mobile che non mostra lo stesso contenuto renderizzato di quella desktop, un problema serio con l’indicizzazione mobile-first.
- Tempi di esecuzione del JavaScript troppo lunghi, che rallentano l’intero processo di rendering e di conseguenza l’indicizzazione.
Molti di questi errori emergono anche in un controllo più ampio della SEO tecnica: li ho raccolti in modo più completo nella pagina sugli errori di SEO tecnica più comuni.
Domande frequenti sul rendering JavaScript
Cos’è il rendering JavaScript?
È il processo con cui un browser o un motore di ricerca trasforma HTML, CSS e JavaScript nella pagina visibile e interattiva. Avviene dopo il download del codice e costruisce il DOM, cioè la struttura su cui si basa tutto ciò che l’utente vede e può usare.
Che differenza c’è tra CSR e SSR?
Nel CSR il browser riceve un HTML quasi vuoto e costruisce il contenuto eseguendo JavaScript, nel SSR il server invia già l’HTML completo. La differenza principale è il tempo che passa prima che il contenuto diventi leggibile, per una persona o per un bot.
Google riesce a leggere il JavaScript?
Sì, Googlebot esegue JavaScript in una fase di rendering separata dal crawling, ma non tutti i bot si comportano allo stesso modo: molti scraper e crawler di intelligenza artificiale leggono solo il markup HTML iniziale e ignorano gli script.
Perché il rendering JavaScript rallenta i Core Web Vitals?
Perché sposta il lavoro di costruzione della pagina sulla CPU di chi la visita: più JavaScript da scaricare ed eseguire significa un thread principale più occupato, con effetti diretti su LCP e INP rispetto a una pagina che arriva già renderizzata.
Come faccio a sapere se Google vede il rendering della mia pagina?
Si verifica con lo strumento di ispezione URL, che mostra l’HTML renderizzato da Google, confrontandolo con il contenuto visibile nel browser e con lo stato di copertura della pagina nell’indice.
Cosa sono idratazione e prerendering?
L’idratazione aggiunge interattività a un HTML già generato sul server, il prerendering cattura lo stato iniziale di un’app client-side come HTML statico in fase di build. La prima presuppone un DOM stabile, il secondo serve a mostrare subito qualcosa prima che il JavaScript finisca di caricarsi.
Quale modello di rendering conviene per la SEO?
Conviene SSR o SSG per i contenuti pensati per portare traffico organico, perché arrivano già leggibili senza attendere l’esecuzione di script. Il CSR puro resta adatto alle aree non indicizzabili, come applicazioni dietro login.
