Render budget di Google: cos’è e come migliorarlo
Ogni volta che pensiamo alla ricerca su Google immaginiamo un processo automatico e fluido: Googlebot scansiona le nostre pagine, ne analizza il contenuto e i risultati sono pronti per apparire nei motori di ricerca. Tuttavia, dietro questo meccanismo c’è una complessità notevole, legata soprattutto alla gestione delle risorse computazionali: in estrema sintesi, più un sito utilizza tecnologie avanzate come JavaScript, CSS dinamici o contenuti caricati lato client, più Google deve investire risorse per riuscire a renderizzare correttamente ciò che l’utente e Googlebot stesso vedranno. Questo è il contesto in cui si inserisce il concetto di render budget, vale a dire il tempo di rendering che Google destina alle pagine web: questo concetto ha un valore fondamentale e influisce sulla “searchability” e comprendere che cos’è e come ottimizzare il render budget diventa cruciale per chiunque voglia massimizzare l’indicizzazione corretta delle proprie pagine.
Che cos’è il render budget
Il render budget è una espressione che si riferisce al limite di risorse che Google allocca per eseguire il rendering delle pagine web, soprattutto quelle che fanno ampio uso di JavaScript.
Per specificare, possiamo dire che il render budget è la quantità di risorse impiegata per eseguire il rendering di una pagina, ovvero per fare in modo che Googlebot possa interpretare i contenuti che non sono immediatamente disponibili in HTML statico. Il processo di rendering è particolarmente rilevante quando interagiamo con JavaScript, poiché richiede un livello di elaborazione aggiuntivo, e oggi molti siti moderni si affidano a framework JavaScript per arricchire l’esperienza utente.
Mentre la scansione di una pagina HTML avviene relativamente in fretta, infatti, quando le risorse di una pagina dipendono da JavaScript o CSS dinamici il processo diventa più complesso e richiede che il motore di ricerca non solo visiti la pagina, ma la “esegua” per comprendere completamente il contenuto disponibile.
Questo passaggio aggiuntivo è fondamentale per l’indicizzazione perché Google, per “vedere” tutto ciò che è presente su una pagina, deve renderizzarla nel modo corretto. Se i contenuti non vengono resi disponibili in forma HTML o non vengono eseguiti correttamente attraverso una renderizzazione pulita, Google potrebbe non trovare o non comprendere le informazioni, penalizzando di fatto la capacità del sito di apparire nei risultati di ricerca.
Già da questo intuiamo che la gestione del render budget assume un’importanza critica: Google non ha risorse illimitate e non può permettersi di renderizzare in modo approfondito tutte le pagine alla stessa velocità o intensità. Il motore di ricerca esegue quindi una serie di scelte su quali pagine possano ricevere più risorse in termini di rendering e quanto tempo dedicare a ciascuna. Pagine altamente performanti, ottimizzate per il rendering già lato server o che presentano una minimizzazione di codice JavaScript, riceveranno una quota maggiore del budget di risorse rispetto alle pagine che soffrono di pesanti tempi di esecuzione o di tecnologie mal ottimizzate.
L’importanza del render budget è legata alla capacità della pagina di essere indicizzata nel modo corretto. Inoltre, una scarsa gestione dell’esperienza di rendering non solo impatta il processo di indicizzazione ma spreca anche risorse, generando pagine che possono essere considerate incomplete o addirittura non pertinenti a livello SEO.
Render budget e indicizzazione: perché è importante
Il render budget è un concetto molto rilevante nell’attuale panorama della SEO tecnica eppure, al di fuori degli ambienti più specializzati, non è ancora ben compreso. Cerchiamo di fare chiarezza spiegando non solo cosa sia, ma soprattutto perché è diventato essenziale saperlo gestire per garantire un buon posizionamento nei risultati di ricerca.
Per iniziare, dobbiamo comprendere cosa succede “dietro le quinte” quando Googlebot scansiona e indicizza le pagine del nostro sito. Prima di tutto, Googlebot accede al codice HTML di una pagina web — durante questa fase, si limita a esaminare tutto ciò che è già presente nel sorgente, come testo, link, immagini, e altre risorse statiche. Tuttavia, la struttura di molti moderni siti web non si basa più solo su pagine HTML statiche: sempre più sviluppatori adottano JavaScript per creare pagine web dinamiche e interattive, offrendo agli utenti contenuti personalizzati in tempo reale. Questo introduce una nuova complessità nell’indicizzazione.
Mentre una pagina HTML statica può essere immediatamente letta da Googlebot, una pagina dinamica, ricca di JavaScript e CSS avanzato, richiede un passaggio aggiuntivo, ovvero il rendering. Googlebot non vede immediatamente i contenuti generati da JavaScript ma per avervi accesso deve “renderizzarli” eseguendo il codice JavaScript associato alla pagina. Ed è in questo esatto punto che entra in gioco il render budget.
Il nodo del rendering: perché è complesso e cruciale per la SEO
Il rendering è particolarmente importante nel contesto SEO perché influisce direttamente sulla comprensione del contenuto della pagina da parte di Google. Se, ad esempio, il contenuto principale di una pagina è generato in dinamica da uno script JavaScript, Google non sarà in grado di indicizzare correttamente quella pagina se il codice non viene eseguito completamente. In altre parole, quando il rendering non funziona alla perfezione, il rischio è che Googlebot “veda” solo una parte dei contenuti, ignorando quelli che vengono caricati successivamente tramite script.
Con l’espressione rendering facciamo riferimento a un’operazione molto specifica, ovvero l’elaborazione di una pagina web per permettere che il suo contenuto sia correttamente visualizzato sia dagli utenti che da Googlebot. A livello tecnico, Googlebot non si limita a fare un semplice “copia e incolla” del codice HTML di una pagina: deve eseguire script, caricare i file di JavaScript e processare immagini, CSS e altre risorse per ottenere l’aspetto finale e interpretare il contenuto visibile. Per le pagine che fanno un uso intensivo di JavaScript, questo processo di rendering diventa essenziale perché non tutto il contenuto è immediatamente presente nel file HTML inviato dal server.
Nel corso degli anni, Google ha fatto enormi progressi nel rendering di JavaScript, evolvendo il proprio motore di rendering basato su Chrome. Tuttavia, il tempo e le risorse necessari per eseguire questo processo sono ancora limitati. Pagine che impiegano troppo tempo per essere renderizzate o che dipendono da JavaScript non ottimizzato possono subire ritardi nell’indicizzazione o, nel peggiore dei casi, non essere affatto indicizzate. Questo è uno dei motivi per cui le Single-Page Application (SPA) hanno spesso difficoltà ad ottenere una buona visibilità nella SERP se non implementate correttamente.
Non dobbiamo dimenticare che il contenuto non renderizzato è considerato praticamente assente dagli occhi dei motori di ricerca, e ciò può avere un impatto devastante sulle performance SEO di un sito. Un esempio classico è l’uso massiccio di JavaScript per la navigazione interna o la generazione di link: se Google non riesce a seguire questi link perché non vengono renderizzati in tempo, una parte importante del sito potrebbe rimanere inaccessibile ai motori di ricerca, con conseguente perdita di visibilità e traffico organico.
Come funziona il render budget: un’analogia pratica
Abbiamo definito il crawl budget come il limite di risorse e tempo che Google dedica a ogni sito per decidere se e cosa sottoporre a scansione: usando lo stesso approccio, il render budget è quindi come il tempo, o meglio le risorse computazionali, che Google investe ulteriormente per renderizzare completamente le pagine dinamiche.
Esattamente come il crawl budget, il render budget non è illimitato. Ogni sito web, in modo direttamente proporzionale alla sua importanza e alla popolarità, riceve una certa “quota” di risorse che Googlebot può applicare per attività di rendering. Questo vuol dire che più grande e rilevante è il sito, più alta sarà la sua priorità e quindi il tempo o le risorse dedicate alla renderizzazione del suo contenuto dinamico.
Immaginiamo Googlebot come un visitatore che entra in una libreria. Il crawling è l’atto di percorrere rapidamente i corridoi, osservando e annotando i titoli dei libri sugli scaffali — in questo modo, la persona riesce velocemente a farsi un’idea dei volumi potenzialmente interessanti. Questo è un processo di esplorazione superficiale, che permette di avere un’idea generale dei contenuti disponibili, ma proprio come i titoli dei libri non raccontano l’intero contenuto, lo stesso accade con il crawling: Googlebot vede solo le informazioni immediatamente presenti nel codice HTML.
Il rendering , invece, è l’operazione successiva in cui il visitatore sceglie di aprire i libri e dedica tempo a sfogliarne le pagine per leggere e ottenere i dettagli completi. Alcuni volumi possono avere tutte le informazioni già immediatamente disponibili (come le pagine HTML statiche di un sito), mentre altri avranno contenuti nascosti più in profondità o complessi, richiedendo quindi uno sforzo maggiore e operazioni aggiuntive, come a Googlebot con l’esecuzione di JavaScript.
In questo contesto, il render budget rappresenta le risorse computazionali che Google dedica per consentire al suo “visitatore” di non fermarsi solo ai titoli, ma di aprire e leggere in modo approfondito anche le pagine dinamiche di un sito. Maggiore è la complessità dei contenuti, più risorse Googlebot dovrà utilizzare per processare e indicizzare completamente tutto ciò che è presente.
Quali sono le implicazioni concrete del render budget
Il render budget diventa rilevante quando il contenuto di una pagina web non è immediatamente disponibile nel sorgente HTML, ma invece viene generato e visualizzato dinamicamente solo dopo che il codice JavaScript associato è stato eseguito. Moltitudini di risorse web moderne funzionano in questo modo, in particolare tramite l’uso di framework come React o Angular che trasformano il modo in cui i contenuti vengono generati e distribuiti agli utenti.
Pensiamo alle già citate Single-Page Application, che sono pagine web o applicazioni che caricano solo un documento singolo e successivamente aggiornano dinamicamente il contenuto man mano che l’utente interagisce con la pagina. In queste situazioni, quando un utente accede per la prima volta al sito, riceve solo una breve porzione di HTML “scheletrico”, con altre parti della pagina (come testi, immagini o pulsanti) che vengono aggiunte dinamicamente attraverso JavaScript. Senza eseguire correttamente quel codice, Googlebot vedrebbe solo una pagina vuota o parzialmente completa, perdendo molte informazioni fondamentali.
Questo meccanismo pone una serie di sfide. Non tutte le pagine di un sito complesso riceveranno una renderizzazione completa in tempo reale. Google, infatti, deve gestire milioni di pagine che fanno uso del rendering dinamico e, per quanto grande sia la sua infrastruttura, non può renderizzare tutto sempre e per tutti. Di conseguenza, le pagine meno importanti o che richiedono molte risorse computazionali per essere renderizzate potrebbero subire ritardi nell’indicizzazione, o addirittura non venire renderizzate affatto.
Uno dei problemi più comuni associati a una scarsa ottimizzazione del render budget è proprio questo: contenuti non resi o parzialmente resi. Se i contenuti centrali di una pagina dipendono da JavaScript e Google non riesce a renderizzarli entro un determinato periodo, quei contenuti non verranno indicizzati o valorizzati come dovrebbero. Questo, a sua volta, può danneggiare la SEO del sito, limitando gravemente la sua capacità di apparire in modo visibile nei risultati di ricerca.
Render budget: un fattore decisivo per i contenuti JavaScript
Uno studio di Onely ha dimostrato come Google impieghi fino a 9 volte più tempo per rendere correttamente le pagine costruite con JavaScript rispetto a pagine HTML statiche. La complessità che deriva dall’elaborazione di file JavaScript pesanti, combinata con risorse CSS avanzate e richieste asincrone, può incrementare significativamente i tempi di rendering e consumare risorse computazionali che potrebbero essere altrimenti allocate altrove.
In pratica, più complesse sono le risorse JavaScript che una pagina richiede per essere completamente interattiva e visibile, più risorse computazionali Google deve assegnare per renderizzarla.
L’origine del concetto di render budget
Il concetto di render budget non è stato introdotto formalmente da Google in forma ufficiale, ma ha iniziato a prendere piede nel panorama SEO attorno al 2019, sulla scia della crescente dipendenza dei siti web da tecnologie avanzate, come JavaScript, che ha fatto emergere problematiche legate all’indicizzazione corretta di contenuti dinamici.
In particolare, è stato Kazushi Nagayama, già Webmaster Trends Analyst di Google, a impiegare per la prima volta questo termine nel suo articolo “Render Budget, or: How I Stopped Worrying and Learned to Render Server-Side”, pubblicato appunto nell’agosto 2019.
Nagayama notava che, nonostante i progressi del motore di ricerca nella gestione di JavaScript, l’aumento dell’uso di Single-Page Application (SPA) e framework moderni come React o Angular metteva Google sotto pressione in termini di risorse computazionali necessarie per eseguire il rendering di intere pagine. In quest’ottica, evidenziava come la capacità di Google di vedere effettivamente i contenuti di una pagina (specialmente nei grandi progetti web che producono migliaia di URL) fosse limitata da una questione legata alle risorse disponibili. Per rendere sostenibile tale elaborazione, Google doveva stabilire priorità e bilanciare le proprie risorse, e fu così che prese piede l’idea di un budget dedicato alla renderizzazione.
L’apertura al rendering di JavaScript
L’articolo di Nagayama partiva proprio da una sua esperienza diretta, ricordando che quando ancora lavorava per la compagnia di Mountain View, nel 2014, fu incaricato di dare notizia sul blog ufficiale del fatto che Google Search avrebbe iniziato a renderizzare le pagine web che usavano JavaScript. Questo significava che tante pagine che non erano precedentemente indicizzabili iniziarono a comparire nei risultati di ricerca, migliorando enormemente la searchability complessiva del web.
All’epoca, il team iniziò con il rendering di una piccola parte dell’Indice, gradualmente incrementata, e alla fine si riuscì a deprecare il vecchio schema di scansione AJAX. Anche se il lavoro compiuto dal grande team di ingegneri di Google ha consentito di fare passi da gigante rispetto alla renderizzazione delle pagine web che eseguono JavaScript (risultato di cui lo sviluppatore giapponese si dice “personalmente molto orgoglioso”), ci sono ancora alcuni chiarimenti da fare, e il primo è piuttosto importante e drastico: al 2019 – e per certi versi ancora oggi – Google non indicizza ancora tutte le pagine in JavaScript con rendering lato client.
Ne consegue, quindi, che nessuno può usare JavaScript per creare siti web che si affidano interamente al rendering lato client e attendersi che Google indicizzi tutte le loro pagine. E, quindi, bisogna sapere che il rendering completo lato client nelle single-page application può ancora ostacolare la ricercabilità di un sito, specialmente per i siti di grandi dimensioni.
Come funziona il render budget di Google
Grazie al post di Nagayama si iniziò quindi a far strada la metafora di un “budget” parallelo al crawl budget, alimentata da studi ed esperimenti che mostravano quanto tempo in più fosse necessario a Google per rendere correttamente una pagina JavaScript rispetto a una in HTML semplice.
Si rese quindi evidente che, esattamente come per il crawl budget, la capacità di un sito di essere correttamente indicizzato si riduceva quando le sue risorse dinamiche non erano ottimizzate per essere renderizzate in modo efficiente. Questo ha infine portato gli specialisti SEO a mettere al centro delle proprie strategie il concetto di render budget come una risorsa limitata che può avere un impatto tangibile sulla visibilità organica dei siti.
Nagayama aveva per la prima volta fornito informazioni aggiuntive rispetto al lavoro di Martin Splitt, Webmaster Trends Analyst di Google, che in varie circostanze aveva comunque invitato a usare JavaScript responsabilmente e a ottimizzare gli aspetti onpage, con particolare riferimento alle performance del sito per offrire più rapidamente contenuti agli utenti e, al tempo stesso, semplificare le scansioni di Googlebot.
In concreto, il punto di partenza è stato uno schema realizzato proprio da Martin Splitt per spiegare come sono impostati i processi di rendering di Google, progettati per essere un passo precedente rispetto alla indicizzazione vera e propria, come si nota anche nell’immagine.
È questo il punto focale: solo se Google valuterà che una pagina merita di essere renderizzata la aggiunge alla Render Queue per attendere che il Renderer la elabori e restituisca l’HTML renderizzato. Quindi, viene implicitamente suggerito che Google ha bisogno di giudicare l’importanza del contenuto della pagina prima di vedere di fatto qual è il contenuto: anche se non ha ancora renderizzato la pagina, deve provare a ipotizzare quale valore aggiunto porti all’Indice la renderizzazione di quel contenuto.
Ed è qui che, secondo Nagayama, c’è una stretta somiglianza strutturale tra il problema di rendering con la gestione del crawling: anche nella fase di scansione Google deve fare un’ipotesi strutturata sull’importanza della pagina che ha scoperto sul web prima di completare effettivamente la scansione.
I problemi di Google per gestire crawling e rendering
Nel crawling, il collo di bottiglia più grande è di solito la risorsa del server sul lato dei siti web sottoposti a scansione: Google ha bisogno di fare buone previsioni su quanto carico l’hosting può tollerare, e decidere quanto velocemente eseguire la scansione del sito, trovando un buon equilibrio tra le esigenze dell’utente e la frequenza di aggiornamento. Si tratta di un sistema molto sofisticato che i grandi team di ingegneri di crawl hanno costruito, anche se riceve poca attenzione da parte di terzi.
D’altra parte, il collo di bottiglia più grande nel rendering è rappresentato dalle risorse del server da parte di Google. Naturalmente, ci sono nuove risorse come JavaScript e file JSON di cui Google ha bisogno per eseguire la scansione, che si aggiungeranno al “crawl budget”. Tuttavia, mentre alcune delle risorse possono essere messe in cache per ridurre al minimo il crawl, le pagine che hanno bisogno di rendering generalmente devono essere restituite ogni volta da zero. E anche Google non può usare liberamente le proprie risorse informatiche per avere un indice con pagine completamente aggiornate e completamente renderizzate dall’intero Web.
Come Google sceglie quali pagine renderizzare: popolarità e quantità delle pagine
Google deve quindi decidere quali pagine renderizzare, quando e quanto. E proprio come il crawl budget, utilizza dei segnali per calcolare le priorità: in questo caso, i più importanti sono la popolarità del sito e il numero di URL che necessitano di rendering.
Se un sito è popolare e ha bisogno di molto rendering, allora ottiene più risorse; se non c’è bisogno di rendering, non vengono allocate risorse. Se c’è un sito web che ha bisogno di molto rendering ma non è molto popolare, Google assegnerà parte delle risorse per eseguire la resa di alcune delle pagine ritenute importanti all’interno del sito web.
Nagayama fornisce anche un esempio pratico, applicando questo ragionamento a uno scenario in cui “hai creato una nuova single-page application che esegue il rendering completo sul lato client”. Restituisci il modello HTML e invii il contenuto separatamente in file JSON, prosegue: quanto budget di rendering sarà stato assegnato da Google?
Nagayama spiega che ci sono molti casi in cui il sito non ha URL scansionabili (bisogna dare URL permanenti agli stati che si desideri sottoporre a scansione!), ma anche se le operazioni sono state eseguite bene, è abbastanza difficile per Google capire quanto sia importante un nuovo sito per gli utenti. Molto probabilmente, Google darà lentamente il budget per testare le acque mentre cerca di raccogliere segnali sul sito. Di conseguenza, non tutti gli URL saranno indicizzati al primo passaggio, e potrebbe volerci molto tempo prima che siano completamente indicizzati.
I segnali di priorità per stimare il render budget
Non tutte le pagine hanno lo stesso peso o la stessa rilevanza agli occhi di Google, pertanto il motore di ricerca deve prendere decisioni ponderate su dove allocare risorse di rendering aggiuntive per processare pagine complesse o di grandi dimensioni. Possiamo quindi ipotizzare che, nel determinare quando e come allocare risorse di rendering per un dato sito, Google si basi su una serie di segnali di priorità che aiutano a ottimizzare la distribuzione del render budget: tra i principali ci sono la popolarità del sito, le performance delle sue risorse e la quantità di JavaScript in esecuzione.
Un primo criterio che guida la priorizzazione del render budget riguarda come detto la popolarità del sito. Siti grandi e importanti, con un flusso di traffico significativo o con una forte presenza nel panorama online tendono a ricevere più attenzione e risorse da parte di Google. La logica è semplice: un sito più popolare è più probabile che abbia contenuti rilevanti per gli utenti e, di conseguenza, merita un impiego maggiore di risorse per garantire che tutto il contenuto sia correttamente indicizzato. Un sito meno noto, d’altra parte, potrebbe ricevere meno risorse, con conseguenti rallentamenti nei tempi di rendering o una selezione più attenta su quali sezioni del sito meritino di essere elaborate per prime.
Altri fattori che influenzano la decisione di Google includono la qualità delle performance del sito e delle sue risorse. Un sito ottimizzato, che carica velocemente e minimizza le richieste HTTP e i file JavaScript pesanti, richiederà meno risorse per essere processato, il che può indurre Google a dedicare più render budget per esamina diretta di tutte le sue pagine. Al contrario, un sito con carichi eccessivi di JavaScript, tempi di caricamento lenti o contenuti complessi da eseguire potrebbe vedere assegnato un budget più limitato. Questo non significa che siti meno ottimizzati non vengano resi e indicizzati, ma l’intero processo sarà più lento e meno efficiente.
Google inoltre adotta una strategia basata sull’importanza di gerarchia e freschezza del contenuto. Quando una nuova pagina viene pubblicata, il crawl budget e il render budget si sovrappongono: Googlebot visiterà la pagina, identificherà se richiede o meno rendering e deciderà se dedicare tempo e risorse immediate per eseguirlo. Tuttavia, se la pagina non viene considerata una priorità (ad esempio, se contiene pochi segnali di traffico o non mostra nuovi aggiornamenti di contenuto rilevante), la renderizzazione potrebbe avvenire più tardi o essere parziale. Pagine aggiornate di frequente o con segnali di freschezza evidenti riceveranno invece un trattamento di maggiore attenzione, quindi un più ampio investimento di render budget.
I consigli per gestire il render budget di un sito
Nagayama presenta anche un caso di riflessione, ovvero “il mio sito è stato nell’indice per molto tempo e Google sa quanto sia popolare: questo significa che va bene fare un revamping completo del sito per renderizzarlo lato client?”. Secondo lo sviluppatore, no: se hai restituito HTML che non ha bisogno di molto rendering, e poi improvvisamente cambiato tutti i tuoi URL per renderizzare il lato client, Google ha bisogno di eseguire nuovamente la scansione e renderizzare tutti gli URL. Sia il crawl budget che il render budget hanno un impatto negativo sul sito in questa configurazione, e di conseguenza potrebbero volerci mesi, anche più di un anno, per portare tutti i tuoi URL all’indice dopo il rinnovo del sito.
In conclusione, questo articolo ci offre una serie di indicazioni molto utili per la miglior gestione della velocità di resa del sito per Google. Secondo Nagayama, il rendering lato client nei siti web su larga scala non è ancora realistico se si desidera che gli URL siano indicizzati in modo efficiente.
Per lui, l’impostazione ideale è di restituire il semplice HTML che non necessita di alcuna esecuzione JavaScript. Il rendering è un passo in più che Google supporta, ma ciò significa costringere Google a fare sforzi extra per comprendere i contenuti: un dispendio in termini di tempo e risorse, che può rallentare il processo di indicizzazione. Al contrario, se si implementa il rendering dinamico, restituendo a Googlebot i contenuti server-rendering e continuando a servire agli utenti il rendering lato client, sarà più facile per Google elaborare il sito, ma questo significa anche impegnare i propri server a fare il lavoro per Google.
La considerazione finale è quindi che il semplice e statico HTML continua a essere la soluzione più veloce e precisa per chi desidera che il sito sia indicizzato velocemente e su larga scala. Il rendering lato client può ostacolare le prestazioni del sito web nelle SERP, specialmente per siti di notizie che devono essere indicizzati velocemente o per piattaforme web su larga scala che producono centinaia di migliaia di nuovi URL ogni giorno.
Google ha lavorato duramente per riconoscere le pagine che utilizzano JavaScript, e questo sforzo lo rende anni avanti rispetto ad altri motori di ricerca nella comprensione del web di oggi, e funziona bene fino a siti web di medie dimensioni.
È garantito che si evolverà ancora di più, ma bisogna riconoscere che il sistema attuale non è perfetto, proprio come qualsiasi altro sistema ingegnerizzato. Dove Google fallisce, i webmaster devono intervenire per fornire aiuto dall’altra parte: se il vostro servizio produce centinaia di migliaia di URL ogni giorno, dice Nagayama, allora probabilmente dovete prestare attenzione a questi dettagli e procedere con cautela.
Questo impegno di tutti i partecipanti dell’ecosistema web può aiutare a creare un mondo in cui le informazioni sono fornite rapidamente agli utenti che ne hanno bisogno: “Continuiamo a costruire un web migliore, per un mondo migliore”, scrive in chiusura Kazushi Nagayama.
Eliminare gli sprechi: come ottimizzare il render budget per migliorare l’indicizzazione
Vista la delicatezza del tema, che interessa un aspetto molto specifico della SEO tecnica, è utile andare a guardare in maniera un po’ più analitica quali sono le best practice da adottare per minimizzare l’uso eccessivo delle risorse, e quindi per gestire al meglio il render budget e assicurare che Google indicizzi correttamente tutte le pagine di un sito.
Uno dei passi più efficaci è ridurre la quantità e la complessità dei codici JavaScript e CSS, ovviamente, in modo da facilitare il compito di Googlebot di visualizzare e comprendere i contenuti chiave della pagina senza impegnarsi in processi computazionali troppo pesanti.
Una soluzione particolarmente utile, specialmente per i siti dinamici, è il prerendering, una tecnica che consente di generare una versione statica della pagina, pronta per essere servita a Googlebot, semplificando e accelerando notevolmente il processo di rendering. In questo modo, il motore di ricerca ottiene fin da subito una versione completa della pagina, mentre il JavaScript viene eseguito solo dal lato utente.
Anche tecniche come il caching delle risorse dinamiche rivestono un ruolo importante: le risorse come i file JavaScript ripetitivi e alcune parti del CSS possono essere memorizzate localmente per evitare che Google le debba scaricare e processare ripetutamente, alleggerendo così il carico di rendering.
Come misurare e migliorare il render budget: il concetto di render ratio
Per comprendere se Google sta utilizzando in maniera efficace il render budget sul nostro sito, dobbiamo partire da una semplice domanda: il motore di ricerca riesce a rendere correttamente i contenuti più importanti? Il concetto di render ratio, di cui parla anche questo approfondimento di Prerender, ci aiuta a dare una risposta precisa a questo interrogativo.
Render ratio è una metrica che ci permette di capire quanta parte del nostro sito viene effettivamente renderizzata da Google rispetto a quella che viene semplicemente scansionata in HTML. Sebbene non esista uno strumento diretto fornito da Google che ci dia una misurazione esplicita di questo rapporto, è comunque possibile dedurre la render ratio confrontando il numero di pagine indicizzate che contengono contenuti resi solo dopo l’elaborazione di JavaScript con quelle indicizzate basandosi su contenuti presenti immediatamente nel codice HTML.
Per misurare la render ratio, possiamo:
- Identificare una “HTML phrase”, ovvero una frase che appare in tutte le pagine direttamente nel codice HTML statico.
- Identificare una “rendered phrase”, cioè una frase che appare soltanto una volta eseguito il rendering di JavaScript.
Successivamente, usando un comando di ricerca avanzato come site:tuodominio.com “HTML phrase” possiamo verificare quante pagine sono state indicizzate con il contenuto HTML immediatamente disponibile. Lo stesso processo viene ripetuto per la rendered phrase (site:tuodominio.com “rendered phrase”), permettendoci di confrontare il numero di pagine HTML indicizzate con quelle renderizzate. Dividendo il numero di risultati renderizzati per il numero di pagine HTML indicizzate, possiamo calcolare la nostra render ratio, ossia il rapporto tra il contenuto renderizzato e quello puramente scansionato.
Una render ratio bassa significa che Google non riesce a processare correttamente i contenuti caricati via JavaScript, il che può danneggiare la visibilità del sito nei risultati di ricerca. Se Google non rende il contenuto, questo non verrà considerato rilevante per l’indicizzazione, indipendentemente dal fatto che gli utenti possano vederlo correttamente sul browser. La conseguenza è che pagine importanti che affidano contenuti centralmente a JavaScript potrebbero rimanere fuori dai radar di Google.
Le parole di Google su render budget e rendering
Sebbene Google non usi tecnicamente il termine “render budget” nei suoi documenti ufficiali, spesso alcune delle principali voci pubbliche della compagnia, come Martin Splitt e John Mueller, hanno affrontato la questione del rendering di JavaScript e degli impatti che questa tecnologia può avere sull’efficacia dell’indicizzazione di un sito.
In particolare, Google ha chiarito che il rendering di pagine complesse, soprattutto quelle che utilizzano JavaScript per generare contenuti, richiede risorse computazionali significative, che vengono distribuite gradualmente, secondo priorità che Google assegna sulla base della popolarità del sito, della qualità dei contenuti e dell’efficienza del codice.
In vari interventi, Martin Splitt ha spiegato che, pur non esistendo una vera e propria “traccia” del costo monetario del rendering, Googlebot effettua comunque una gestione attenta delle risorse necessarie. JavaScript, che è diventato un elemento fondante su molti siti web, rallenta l’indicizzazione: non si tratta di un problema legato solo alla complessità del codice, quanto piuttosto al tempo extra necessario perché Google capisca che cosa contiene esattamente una pagina che fa largo uso di risorse dinamiche. La linea di fondo è che se una pagina non viene renderizzata correttamente, non verrà indicizzata e, di conseguenza, non apparirà nei risultati di ricerca.
John Mueller ha sottolineato più volte l’importanza di non sovraccaricare Googlebot con JavaScript non necessario, consigliando le tecniche del Server-Side Rendering (SSR) o del prerendering come soluzioni per alleggerire la quantità di calcoli che Google deve fare per rendere visibili i contenuti. Mueller ha anche spiegato che gestire correttamente la renderizzazione non è solo una questione di evitare errori tecnici: una cattiva implementazione può causare anche numerosi problemi in termini di disseminazione di crawl budget su pagine che in realtà forniscono contenuti incompleti o duplicati.
Nonostante Google lavori costantemente per migliorare la propria capacità di rendere contenuti dinamici, il rendering rimane una sfida significativa. Per siti di piccole e medie dimensioni, Google è attualmente in grado di gestire JavaScript in modo efficiente, ma per i siti di grandi dimensioni, l’utilizzo di risorse di caching e di rendering statico continua a essere altamente raccomandato.
Problematiche del rendering di JavaScript: tempi e risorse
JavaScript ha portato incredibili opportunità di interattività e personalizzazione per il web moderno, ma ha anche introdotto sfide significative per il processo di indicizzazione sui motori di ricerca, primi fra tutti i tempi di rendering più lunghi e l’uso intensivo di risorse computazionali. Quando Googlebot visita una pagina, il processo di crawling è relativamente veloce, a meno che il contenuto non sia contenuto in script JavaScript. In questo caso, Googlebot deve “eseguire” JavaScript, caricando e processando tutte le risorse correlate con la pagina, il che richiede un’allocazione aggiuntiva di risorse note come render budget.
Uno degli aspetti problematici del rendering di JavaScript è il tempo extra calcolato tra la fase di crawling e quella di rendering. Come già accennato, alcuni studi hanno dimostrato che Google impiega fino a nove volte più tempo per rendere le pagine basate su JavaScript rispetto a quelle costruite su semplice HTML: questo ritardo è dovuto al fatto che Google mette le pagine in una sorta di rendering queue, una coda nella quale le pagine attendono di essere processate, a seconda delle risorse disponibili sul lato di Googlebot. Più complesso e pesante è JavaScript da eseguire, più il tempo necessario per completare il rendering aumenta — e tutto questo può ritardare o rallentare l’indicizzazione di intere sezioni del sito.
A ciò si aggiunge un ulteriore problema: ogni risorsa JavaScript che Google deve caricare (file .js, framework, script asincroni) incide sui limiti del render budget di un sito. Più sono i file da elaborare e più pesante risulterà la pagina in termini di richieste HTTP, maggiori saranno le risorse necessarie per eseguire il rendering. Questo può portare Google a non riuscire a rendere correttamente parti cruciali della pagina, come testi o link interni, influenzando negativamente l’indicizzazione e, inevitabilmente, il traffico organico. Quando i contenuti o i link sono inseriti tramite JavaScript e non vengono eseguiti correttamente, Googlebot potrebbe non riuscire a scoprirli o interpretarli, lasciando ampi spazi del sito non scansionati o non indicizzati.
La capacità di minimizzare i tempi di rendering e ottimizzare il consumo delle risorse viene quindi a giocare un ruolo cruciale nella SEO. Implementare tecnologie come il Server-Side Rendering (SSR) o il dynamic rendering può ridurre drasticamente il tempo necessario per il completamento del rendering, permettendo a Google di accedere al contenuto più velocemente, senza dover attendere il completamento di pesanti elaborazioni client-side. Anche ricorrere ad accorgimenti come il caching di script ripetitivi e il lazy loading delle risorse meno critiche può migliorare l’efficienza del processo di indicizzazione. Tali pratiche aiutano anche a evitare sprechi di crawl budget, altro elemento intaccato quando Googlebot non riesce a scansionare o rendere efficientemente una pagina.
