Render budget, come ottimizzare la gestione del rendering per Google
Mettici alla prova
Non esiste solo il crawl budget, il budget per la scansione che Google dedica a ogni sito per decidere se e cosa sottoporre a indicizzazione: il post di Kazushi Nagayama – già Webmaster Trends Analyst di Google – rivela che per il motore di ricerca anche il tempo di rendering ha un valore fondamentale e influisce sulla searchability.
Google, la scansione e il rendering
Negli ultimi tempi abbiamo toccato spesso questi topic di SEO tecnica, seguendo anche le ultime evoluzioni del motore di ricerca e soprattutto di Googlebot, il crawler di Google, che è stato reso evergreen a partire dallo scorso maggio, pur con alcune limitazioni. È il caso, ad esempio, della scansione in due tempi dei siti con JavaScript, che con la sua complessità resta una tecnologia poco digerita da questi sistemi.
L’apertura al rendering di JavaScript
L’articolo di Nagayama parte proprio da una sua esperienza diretta, ricordando che cinque anni fa (quando ancora lavorava per la compagnia di Mountain View) 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.
Resta ancora molto lavoro da fare
L’ex Googler spiega che il team iniziò con il rendering di una piccola parte dell’Indice, gradualmente incrementata, e che alla fine si riuscì a deprecare il vecchio schema di scansione AJAX. A distanza di 5 anni, molte persone danno ormai per scontato che Google riesca a renderizzare le pagine web che eseguono JavaScript, ma la realtà è ben diversa.
Anche se il lavoro compiuto dal grande team di ingegneri di Google ha consentito di fare passi da gigante rispetto a questo fattore (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.
Google non indicizza ancora tutte le pagine in JavaScript con rendering lato client
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.
Sono informazioni aggiuntive rispetto a quanto dichiarato di recente da Martin Splitt, Webmaster Trends Analyst di Google, che in varie circostanze ha 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.
Il Render Budget di Google
Ora Kazushi Nagayama ci permette di scoprire qualcosa in più anche in termini pratici, perché (per la prima volta da quando ha lasciato il lavoro con Big G) parla di che cos’è il “render budget” e offre indicazioni ai proprietari di servizi web su larga scala per aiutare Google a indicizzare le loro pagine.
Il punto di partenza è uno schema realizzato proprio da Martin Splitt per spiegare come sono impostati i processi di rendering di Google, che sono progettati per essere un passo precedente rispetto alla indicizzazione vera e propria, come si nota anche nell’immagine.
Google valuta in precedenza se una pagina merita il rendering
È 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.
Una gestione simile a quella del crawling
Secondo Nagayama, c’è dunque una stretta somiglianza strutturale tra questo 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.
Le similitudini tra render budget e crawl budget
Che cosa significa questo per i webmaster? Che esiste un Render Budget proprio come esiste il Crawl Budget, che forse è più noto (e che si può “scoprire” anche con i tool di SEOZoom). Già nel 2017, un altro Googler che spesso citiamo – Gary Illyes del team di WTA – chiarì il significato del crawl budget, sintetizzando che Google decide la priorità di scansione delle pagine in base alla popolarità del sito, alla freschezza dei contenuti e alle risorse del server.
I problemi del crawling per Google
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’host 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.
Le difficoltà nel rendering per Google
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.
Popolarità e quantità delle pagine: come Google sceglie quali pagine renderizzare
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.
Le spiegazioni di Nagayama sul render budget di Google
L’ex Googler continua con 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.
Come 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.
Le configurazioni migliori per l’indicizzazione
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.
L’Html resta la soluzione più veloce per l’indicizzazione su Gogole
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.
Serve anche uno sforzo dei webmaster
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.
