I benefici del dynamic rendering sulla SEO
Negli ultimi anni i framework JavaScript sono diventati sempre più popolari, in gran parte grazie alla flessibilità che offrono: nonostante i progressi, però, quando i crawler dei motori di ricerca visitano siti Web basati su script come AngularJS, React, Vue.js o jQuery è possibile che non “vedano” i contenuti come poi effettivamente fanno i browser, e questo può provocare problemi di indicizzazione o anche peggio. Ci sono però alcuni modi per far dialogare al meglio il sito e i bot, e la tecnica del rendering dinamico è una soluzione, per quanto temporanea, che sembra offrire le risposte adeguate per tradurre i contenuti e la struttura del sito nella lingua preferita dai crawler.
Che cos’è il dynamic rendering o rendering dinamico
Il rendering dinamico è un pre-rendering esclusivo per i robot dei motori di ricerca: mentre, infatti, ai visitatori normali del sito viene servito il normale contenuto renderizzato lato client, i crawler ricevono una versione HTML statica delle pagine, servite in rendering lato server.
Si tratta, quindi, di un sistema che permette una visualizzazione del sito differente in base alla tipologia di user agent che esegue la chiamata, distinguendo tra la normale versione lato client del sito per gli utenti (con tutte le funzionalità JavaScript) e quella progettata appositamente per Googlebot, Bingbot e altri bot, che possono quindi accedere, scansionare e indicizzare i contenuti senza eseguire JavaScript.
La storia del rendering dinamico
Il concetto di dynamic rendering è stato introdotto ufficialmente da Google nel 2018, anche se molti siti stavano già adottando tecniche simili tramite soluzioni autoprodotte o utilizzando software di terze parti: in occasione della conferenza Google I/O del 2018, appunto, John Mueller definì il rendering dinamico come “il principio dell’invio agli utenti di contenuto renderizzato lato client normale e dell’invio di contenuto renderizzato completamente lato server ai motori di ricerca”.
Successivamente anche Bing ha iniziato a suggerire questa pratica, a riprova di come effettivamente il rendering dinamico possa quindi rappresentare un’utile soluzione per un problema “storico” come il rendering e, in particolare, l’esecuzione di alcuni framework JavaScript.
Anche se motori di ricerca come Google e Bing possono elaborare JavaScript, infatti, devono affrontare limitazioni nel tentativo di farlo su larga scala; inoltre, il crawler HTML di Google non è sempre in grado di elaborare JavaScript, e quindi Googlebot può mettere una pagina così costruita in una coda, in attesa che le risorse di rendering diventino disponibili per eseguire il rendering completo della pagina – e ciò vale anche per Bingbot.
La raccomandazione di Google: usare dynamic rendering come soluzione temporanea
Dobbiamo però sottolineare un aspetto importante, messo in evidenza anche da un recente aggiornamento della documentazione ufficiale di Big G a questo aspetto tecnico: per Google, il rendering dinamico è una soluzione alternativa ai problemi di scansione e indicizzazione della Ricerca Google con JavaScript, e non quindi il metodo definitivo e consigliato, perché genera complessità aggiuntive e richiede più risorse.
In realtà, questa è la posizione che Google ha adottato sin dal principio, ma è stato necessario ribadirlo e marcarlo più nettamente dopo i costanti progressi nella tecnologia Web e di scansione (e il sempre crescente uso di JavaScript), per tentare di convincere sviluppatori, webmaster e SEO a implementare alternative al rendering dinamico, vale a dire rendering lato server, rendering statico o hydration. In questi casi, infatti, tutto il contenuto significativo viene visualizzato sul server del sito Web e sia gli utenti che i bot ricevono una pagina completamente caricata, senza la necessità di richiedere risorse aggiuntive.
Come funziona il rendering dinamico e a quali siti serve
Il rendering dinamico non serve a tutti i siti, quindi, ma rappresenta una possibile soluzione alternativa per chi ospita pagine con contenuti indicizzabili pubblici generati con JavaScript che cambiano rapidamente o utilizzano funzionalità JavaScript non supportate dai crawler importanti.
Il rendering Javascript è user-friendly, ma non bot-friendly, soprattutto quando i crawler si trovano di fronte a siti Web di grandi dimensioni, perché ci sono ancora limitazioni all’elaborazione di JavaScript su larga scala riducendo al minimo il numero di richieste HTTP.
L’implementazione di questa modalità ha quindi il vantaggio di superare questo aspetto, poiché permette ai bot dei motori di ricerca di accedere ai contenuti senza doverli renderizzare.
Le differenze con il rendering lato client
In un intervento a SMX Next, Nati Elimelech (tech SEO lead di Wix) ha fornito una panoramica di come funziona JavaScript per il rendering lato client, lato server e dinamico, mettendo in luce alcuni aspetti interessanti riportati da questo articolo su Search Engine Land.
Il primo passo è capire cosa succede con il rendering lato client: quando un utente fa clic su un link, il suo browser invia richieste al server su cui è ospitato il sito. Nel caso di framework JavaScript, quel server risponde con qualcosa di leggermente diverso, perché fornisce uno scheletro HTML, ovvero “solo l’HTML di base, ma con molto JavaScript, dicendo in pratica al browser di eseguire JavaScript per ottenere tutto l’HTML importante”. Il browser quindi produce l’HTML visualizzato – quello utilizzato per costruire la pagina nel modo in cui effettivamente l’utente finale lo visualizza.
Secondo Elimelech, questo processo ricorda il montaggio dei mobili Ikea, perché in pratica il server dice al browser: “Questi sono tutti i pezzi, queste sono le istruzioni, costruisci la pagina”, spostando così tutto il duro lavoro viene spostato sul browser anziché sul server.
Il rendering lato client può essere ottimo per gli utenti, ma ci sono casi in cui un client non esegue JavaScript e pertanto l’user agent non può ottenere l’intero contenuto della pagina: quando succede a Googlebot o un crawler dei motori di ricerca la situazione è ovviamente pericolosa per la SEO, perché può precludere la visibilità della pagina nelle SERP.
Le caratteristiche del rendering lato server
Per i client che non eseguono JavaScript, è possibile utilizzare il rendering lato server, che sposta sul server appunto l’esecuzione di tutto “tutto quel JavaScript”; tutte le risorse sono richieste sul lato server e il browser dell’utente e il bot del motore di ricerca non hanno bisogno di eseguire JavaScript per ottenere l’HTML completamente renderizzato. Pertanto, il rendering lato server può essere più veloce e meno dispendioso in termini di risorse per i browser.
Usando la stessa analogia dell’esempio precedente, Elimelech spiega che “il rendering lato server è come fornire agli ospiti una vera sedia su cui possono sedersi invece di pezzi da assemblare”, e quando eseguiamo il rendering lato server rendiamo sostanzialmente l’HTML visibile a tutti i tipi di bot e di client, che potranno vedere “l’importante HTML renderizzato finale” a prescindere dalle capacità di JavaScript.
Comprendere come funziona il rendering dinamico
In tal senso, il rendering dinamico rappresenta “il meglio dei due mondi” prima descritti, afferma Elimelech, perché consente il “passaggio tra contenuto renderizzato lato client e contenuto pre-renderizzato per user agent specifici”, come spiega anche questo diagramma.
In questo caso, il browser dell’utente esegue JavaScript per ottenere l’HTML visualizzato, ma beneficia comunque dei vantaggi del rendering lato client, che spesso include un aumento percepito della velocità. D’altra parte, quando il client è un bot, il rendering lato server viene utilizzato per servire l’HTML completamente renderizzato e “vede tutto ciò che deve essere visto”.
Così, i proprietari dei siti sono ancora in grado di offrire i propri contenuti indipendentemente dalle capacità JavaScript del client; essendoci due flussi, poi, possono anche ottimizzarli singolarmente per servire meglio gli utenti o i bot senza influire sull’altro.
A quali siti serve il rendering dinamico
Come detto, la guida di Google descrive quali tipologie di sito “devono utilizzare il rendering dinamico”, che è utile per i contenuti indicizzabili pubblici generati con JavaScript che cambiano rapidamente o per i contenuti che utilizzano le funzionalità JavaScript non supportate dai crawler che sono considerate importanti.
Oggi, i framework JavaScript consentono un rapido sviluppo e offrono una migliore esperienza utente, perché assicurano prestazioni migliori e funzionalità avanzate che i framework tradizionali, non JavaScript, non possono raggiungere; non sorprende quindi che siti Web molto grandi o interfacce utente complesse, con logiche e funzionalità complesse di solito, tendano a utilizzare framework JavaScript.
Più in generale, è consigliabile adottare il dynamic rendering se il sito ha grandi dimensioni e pubblica contenuti in rapida evoluzione che richiedono un’indicizzazione rapida, come un sito di e-commerce con inventario che cambia frequentemente; ovviamente, se il sito si basa sulle moderne funzionalità JavaScript per generare parte o tutto il contenuto e si cerca di assicurare la piena indicizzazione delle pagine, che gli utenti poi possano trovare nei motori di ricerca; se il sito si fonda sui social media e sulle applicazioni di chat che richiedono l’accesso al contenuto della pagina.
Se abbiamo ancora dubbi sulla possibilità di implementare il rendering dinamico – che, vale la pena sottolinearlo, è una soluzione alternativa per i crawler e non un obbligo – possiamo poi analizzare quali sono le condizioni della proprietà rispetto a due temi come il crawl budget e il render budget: se abbiamo problemi con tali fattori, e quindi se i bot dei motori di ricerca non trovano tutti i contenuti importanti, ricorrere al dynamic rendering potrebbe effettivamente essere una soluzione ottimale e più rapida rispetto all’implementazione del rendering lato server.
L’importanza del dynamic rendering per la SEO
Già da quanto scritto si comprende che il rendering dinamico è essenzialmente una soluzione SEO JavaScript per consentire ai motori di ricerca di elaborare correttamente pagine che altrimenti non riuscirebbero a eseguire.
I bot infatti si basano su elementi HTML statici e non su interfacce grafiche che sono scontate per gli esseri umani: con il rendering dinamico, le pagine lato client vengono tradotte, rese completamente accessibili e servite ai bot dei motori di ricerca nel loro formato HTML statico preferito, in modo gli stessi possano accedere, comprendere e indicizzare immediatamente i contenuti da trovare nelle ricerche.
Come spiega Google, il rendering dinamico richiede che il server web rilevi i crawler (ad esempio, con il controllo dello user agent); le richieste dei crawler vengono indirizzate a un renderer, le richieste degli utenti vengono gestite normalmente. Se necessario, il renderer dinamico pubblica una versione dei contenuti adatta al crawler, come ad esempio una versione HTML statica.
Storicamente, i siti Web basati su JavaScript hanno difficoltà a emergere nella Ricerca perché sono facili da usare ma non bot-friendly; ciò può dipendere anche dal crawl budget limitato del bot di ricerca di Google e dalla natura ad alta intensità di risorse del rendering di contenuti JS. Quando i crawler dei motori di ricerca incontrano pesanti contenuti JavaScript, infatti, spesso devono indicizzare in più ondate di scansione e questo processo frammentato si traduce in elementi mancanti, come metadati e tag canonici, che sono fondamentali per una corretta indicizzazione.
Il rendering dinamico non crea problemi di cloaking
L’implementazione di questa soluzione, inoltre, non determina alcun problema di comprensione a Google: per molto tempo, i SEO temevano che fornire sostanzialmente due pagine diverse a utenti e bot potesse ricadere nella definizione stessa di cloaking, nota tattica black hat esposta a penalizzazioni, ma la guida ufficiale del motore di ricerca di Mountain View ci rassicura su questo fronte,
“Generalmente Googlebot non considera il rendering dinamico come cloaking” neppure se genera contenuti simili, leggiamo nel documento; allo stesso modo, non viene valutata come cloaking la generazione di pagine di errore, che Googlebot considera come qualsiasi altra pagina di errore.
Diverso è il caso di utilizzo del rendering dinamico per mostrare contenuti completamente diversi a utenti e crawler, come ad esempio “se un sito web mostra una pagina sui gatti agli utenti e una pagina sui cani ai crawler”, perché questo può essere considerato cloaking.
Ma, al di là dell’ultimo esempio volutamente forzato, nelle altre circostanze si tratta di fornire a Google dati simili su una pagina nel modo in cui desidera, ovvero in un formato che può scansionare e indicizzare in modo rapido, semplice ed economico.
Come implementare il rendering dinamico
L’implementazione autonoma del rendering dinamico può essere difficile, dispendiosa in termini di tempo e di risorse, ma è comunque possibile, come spiega la guida di Google con le linee generali a cui attenersi.
Innanzitutto, è possibile adottare questa soluzione per tutte le pagine o per pagine singole, ma ogni configurazione è specifica e varia in base all’implementazione.
Per garantire un approccio pratico, Google ha attivato un codelab che consente l’implementazione del rendering dinamico con Rendertron, una soluzione open source basata su Chromium headless.
- Installa e configura un renderer dinamico per trasformare i contenuti in codice HTML statico, più facile da utilizzare per i crawler. Alcuni renderer dinamici comuni sono Puppeteer, Rendertrone io.
- Scegli gli user agent che vuoi che ricevano il codice HTML statico e fai riferimento ai dettagli di configurazione specifici su come aggiornare o aggiungere user agent. Ecco un esempio di elenco di user agent comuni nel middleware Rendertron:
export const botUserAgents = [
‘googlebot’,
‘bingbot’,
‘linkedinbot’,
‘mediapartners-google’,
];
- Se il pre-rendering rallenta il server o vedi un numero elevato di richieste di pre-rendering, valuta l’implementazione di una cache per i contenuti di pre-rendering o verifica che le richieste provengano da crawler legittimi.
- Determina se gli user agent richiedono contenuti per dispositivi mobili o desktop. Utilizza la pubblicazione dinamica per fornire la versione desktop o per dispositivi mobili appropriata. Questo è un esempio di come una configurazione può determinare se uno user agent richiede contenuti desktop o per dispositivi mobili:
isPrerenderedUA = userAgent.matches(botUserAgents)
isMobileUA = userAgent.matches([‘mobile’, ‘android’])
if (!isPrerenderedUA) {
} else {
servePreRendered(isMobileUA)
}
In questo esempio, utilizza if (!isPrerenderedUA) {…} per pubblicare contenuti visualizzati lato client. Utilizza else { servePreRendered(isMobileUA)} per pubblicare la versione per dispositivi mobili, se necessario.
- Configura il tuo server per fornire l’HTML statico ai crawler selezionati. Ci sono molti modi per farlo, in base alle tecnologie a tua disposizione; ecco alcuni esempi:
- Richieste proxy provenienti dai crawler al renderer dinamico.
- Esegui il pre-rendering come parte della procedura di implementazione e fai in modo che il server fornisca l’HTML statico ai crawler.
- Integra il rendering dinamico nel tuo codice server personalizzato.
- Fornisci contenuti statici da un servizio di pre-rendering ai crawler.
- Utilizza un middleware per il tuo server (ad esempio, il middleware rendertron).
I principali problemi col rendering dinamico
Il rendering dinamico può essere una strada percorribile per i siti web con JavaScript pesante (in genere difficile da scansionare) e per le attività che dipendono quindi da JavaScript, ma come detto ha alcuni limiti e problematiche.
Il primo aspetto critico riguarda la complessità di gestione del sistema, che richiede competenze tecniche e attenzione nell’implementare la versione “alternativa” delle pagine da servire ai bot – senza peraltro alcun vantaggio sulla user experience, visto che gli utenti non percepiscono nulla di questo “lavoro”.
Spesso quindi questa modalità di rendering rischia di non essere sostenibile dal punto di vista economico né dal punto di vista dell’impegno richiesto al team di sviluppo, senza considerare i potenziali problemi pratici in cui si può incappare nel processo.
Ci sono tre strumenti di Google che possono aiutarci a verificare che l’implementazione del rendering dinamico funzioni correttamente, ovvero il Test di ottimizzazione mobile, lo Strumento Controllo URL e il Test dei Risultati multimediali avanzati, che ci permettono di analizzare rispettivamente se il sito funziona per gli utenti sui dispositivi mobili, se i contenuti desktop siano visibili anche sulla pagina visualizzata da Googlebot e se che i dati strutturati vengano visualizzati in modo appropriato.
Quando invece questi strumenti segnalano la presenza di errori o verifichiamo che le pagine non compaiono nei risultati della Ricerca Google, è il momento di analizzare le cause del problema, che secondo Google ricadono in genere in 4 casistiche:
- I contenuti sono incompleti o sembrano diversi
Questo errore deriva da una configurazione sbagliata del renderer o dalla incompatibilità tra l’applicazione web e la soluzione di rendering, ma a volte anche i timeout possono causare un errore di rendering dei contenuti.
- Tempi di risposta elevati
Questo caso dipende dall’utilizzo di un browser headless per il rendering di pagine on demand, che spesso causa tempi di risposta elevati e, quindi, potrebbero spingere i crawler ad annullare la richiesta e a non indicizzare i contenuti. Gli elevati tempi di risposta possono anche portare i crawler a ridurre la frequenza di scansione durante la scansione e l’indicizzazione dei contenuti. Per risolvere il problema, possiamo configurare e attivare una cache per l’HTML sottoposto a pre-rendering o creare una versione HTML statica dei contenuti nell’ambito del processo di compilazione, e poi verificare che i crawler possano accedere rapidamente ai contenuti e che le richieste non vadano in timeout.
- Il rendering dei componenti web non avviene come previsto
Questo avviene se Shadow DOM è isolato dal resto della pagina: le soluzioni di rendering (come Rendertron) non sono in grado di vedere i contenuti all’interno dello shadow DOM isolato. La soluzione è caricare i polyfill webcomponents.js relativi agli elementi personalizzati e a shadow DOM, verificando poi che i contenuti appaiano nel codice HTML visualizzato della soluzione di rendering.
- Dati strutturati mancanti
Una mancanza dello user agent dei dati strutturati o di tag di script JSON-LD nell’output può causare errori nei dati strutturati; per risolvere il problema, dobbiamo controllare che i tag di script JSON-LD siano inclusi nell’HTML con rendering dinamico dei contenuti.
