Rendering delle pagine: come avviene e perché serve ai motori di ricerca

Tempo di lettura : 6 minuti

La fase di scoperta e analisi delle pagine web non si concretizza solo con il processo di indicizzazione che già conosciamo, ma c’è un altro momento decisivo in cui i crawler entrano in contatto con ciò che pubblichiamo: è il rendering, l’operazione di interpretazione e resa grafica della pagina. Oggi ci dedichiamo proprio a questo argomento per comprendere come funziona e perché serve ai motori di ricerca.

Il processo di scoperta dei siti per i motori di ricerca

Generalmente, quando pensiamo al ranking delle pagine ci viene in mente subito l’indicizzazione, dice Dave Davies sulle pagine di SEL, e in particolare al momento in cui un motore di ricerca ha già:

• Scoperto una pagina tramite sitemap o crawling.
• Continuato a visitare la pagina per l’indicizzazione.
• Raccolto tutto il contenuto della pagina.
• Iniziato a classificare la pagina per le query.

Probabilmente, questa è la fase più importante del processo perché sono questi i fattori che influenzano le classifiche, ma non è la fase finale del processo di scoperta e, secondo Davies, il suo peso potrebbe diminuire nel tempo mentre la fase finale – ovvero il rendering – guadagna strada.

Che cos’è il rendering

Letteralmente, rendering deriva dal verbo inglese to render ed è traducibile con rappresentazione o resa grafica: il rendering è proprio la codificazione grafica delle informazioni presenti sulla pagina in linguaggio HTML, che vengono tradotte (rese) in modo da dare una forma comprensibile agli elementi grafici che compongono tutti i siti web, ciascuno con le sue caratteristiche.

A consentire questo processo sono gli appositi motori di rendering, i rendering engine, che raccolgono e digeriscono i pacchetti dati in arrivo dal server e trasformano le righe di codice del linguaggio HTML in elementi grafici e funzionali, come ad esempio blocchi di testo con link ipertestuali, immagini, video e altri elementi come file PDF.

Il lavoro dei motori di rendering

Sono essenzialmente tre le fasi in cui si compone il lavoro di un rendering engine:

• Decodifica degli input – le informazioni in ingresso.
• Elaborazione dei dati.
• Rappresentazione grafica delle informazioni.

Provando a semplificare, il motore di rendering web preleva il codice sorgente delle pagine web richieste dall’utente e ne scansiona tutti gli elementi HTML e CSS presenti; queste informazioni sono quindi decodificate per iniziare a costruire la pagina web da visualizzare.

In questo processo sono identificate le varie parti di cui si compone la pagina, come il blocco di testo e la sua formattazione, lo sfondo, il colore, il contenuto, i vari elementi multimediali e così via. Usando le informazioni riportate nel codice sorgente della risorsa e nel file CSS, il motore rielabora e mette in ordine gli elementi e successivamente, insieme alla GPU, trasforma il codice sorgente negli elementi effettivamente visualizzati nella scheda del browser, permettendo finalmente all’utente di accedere e consultare in modo corretto la risorsa desiderata.

Le differenze tra rendering e indexing

La differenza tra rendering e indexing si può rappresentare molto facilmente con un confronto tra due immagini, spiega Davies: in alto abbiamo le righe di codice HTML di una pagina del nostro blog, mentre in basso c’è la rappresentazione grafica della stessa pagina così come visualizzata nel browser.

In sostanza, si tratta dello stesso contenuto, dapprima mostrato per come appare durante l’indicizzazione (HTML) e poi per come viene reso nel rendering (Chrome).

Perché è importante il rendering

Si potrebbe pensare che il rendering sia importante solo per chi ha siti JavaScript, ma in realtà questo processo riguarda e interessa tutti i siti, come conferma il fatto che i motori di ricerca eseguissero il rendering delle pagine anche prima della recente impulso all’uso di JavaScript per i siti Web.

Essenzialmente, il motivo per cui questo processo conta è che il rendering fornisce la verità.

Attraverso il codice, un motore di ricerca può capire di cosa tratta una pagina e approssimativamente quello che contiene. Con il rendering, possono comprendere l’user experience e avere molte più informazioni su quali contenuti dovrebbero avere la priorità.

Durante la fase di resa grafica il motore di ricerca può dare risposta a tante domande rilevanti per comprendere correttamente una pagina e come dovrebbe essere classificata. Ad esempio, nell’articolo si citano questioni come:

• Il contenuto è nascosto dietro un clic?
• Un annuncio riempie la pagina?
• Il contenuto visualizzato nella parte inferiore del codice viene effettivamente visualizzato nella parte superiore o nella navigazione?
• Il caricamento di una pagina è lento?

Quando avviene il rendering

Stando alle informazioni in nostro possesso – e sempre in linea di massima – il rendering si verifica dopo l’indicizzazione e può addirittura richiedere alcuni giorni o settimane, con una sequenza temporale variabile. Ciò significa essenzialmente che i motori di ricerca comprenderanno il contenuto e il contesto di una pagina prima di ottenere una piena comprensione di come ciò deve essere reso prioritario.

Questo ovviamente non significa che i motori di ricerca siano completamente ignoranti fino al rendering, perché ci sono alcune regole e impressioni solide che hanno acquisito nel corso degli anni che consentono loro di fare rapidamente ipotesi su:

• Quali elementi sono presenti.
• Dove sono posizionati.
• Quanto sono importanti per l’utente.

Ma è solo dopo la resa grafica delle pagine che i motori sapranno che i loro presupposti sono corretti e potranno comprendere a pieno una pagina e la sua forma.

I problemi con il rendering

In sintesi, i motori di ricerca inviano un crawler al sito, che rappresenterà la pagina come farebbe un browser.

Se in Bing “sembrano essere un po’ più bravi nel rendering, il che è interessante”, in casa Google Googlebot ha un componente Web Rendering Service (WRS), aggiornato a maggio del 2019, in occasione dell’aggiornamento evergreen del crawler, che ora usa la versione più recente di Chrome anche per il rendering.

Fino ad allora, il WRS utilizzava la versione 41 di Chrome, che era eccezionale per la compatibilità ma “era un incubo per i siti che si basavano su funzionalità moderne, come quelle del moderno JavaScript”, scrive Davies.

In sostanza, ciò significa che “quando la tua pagina è renderizzata da Googlebot è resa più o meno come la vedresti nel tuo browser”. Tuttavia, è sbagliato pensare che sia sufficiente verificare su un browser se la pagina funziona correttamente, perché il senso del rendering è altro.

Se abbiamo un “sito basic con HTML prevedibile e contenuti dinamici quasi nulli, non c’è davvero nulla di cui preoccuparti” e probabilmente non c’erano preoccupazioni neppure con la vecchia configurazione del WRS.

Ma per i siti “con contenuti dinamici offerti tramite JavaScript, c’è un grande avvertimento ed è radicato in un gap”: fino a quando la pagina non viene visualizzata, il motore non sa cosa ci sia sopra. A differenza di un sito con un semplice output HTML – in cui il motore potrebbe perdere un po’ del contesto ma comprende il contenuto – con un sito basato su qualcosa come JavaScript che si basa sul rendering “il motore non saprà quale contenuto è nella pagina fino a quando il WRS non ha completato il suo lavoro”.

E quindi, le “settimane” di lavoro necessarie per raggiungere questo risultato sono piuttosto d’impatto, ed è anche per questo motivo che i motori stanno lavorando per ridurre la latenza. Fino a quel momento, però, gli sviluppatori JavaScript dovranno fare affidamento sul pre-rendering (creazione di una versione statica di ogni pagina per i motori), che non è affatto la soluzione ideale.

Come funziona il Web Rendering Service

Il ciclo di vita del rendering segue questo percorso:

• Una pagina viene scoperta tramite sitemap, crawler, ecc.
• La pagina viene aggiunta all’elenco delle pagine del sito da sottoporre a scansione quando è disponibile il crawl budget.
• Il contenuto della pagina viene sottoposto a scansione e indicizzato.
• La pagina viene aggiunta all’elenco delle pagine da renderizzare su un sito quando è disponibile il rendering budget.
• La pagina è renderizzata.

L’elemento critico e non detto del processo è la coda di rendering: “Googlebot potrebbe arrivare a una pagina settimane prima del rendering e fino ad allora alcuni contenuti (siti JavaScript) o contesto (tutti i siti) potrebbero mancare”, spiega l’articolo. E quando una pagina raggiunge la cima della rendering queue, il motore invierà ciò che viene definito headless browser, browser senza testa, ovvero un browser senza un’interfaccia utente grafica.

In qualche modo, comunque, il motore di ricerca riesce a capire cosa dove e come appare su una pagina, anche se non ha occhi per vederlo: quando il processo si completa in modo positivo, “la versione renderizzata apparirà uguale a Googlebot e nei browser grafici”, mentre “in caso contrario è probabile che la pagina si basi su una funzione non supportata come una richiesta di autorizzazione dell’utente”.

Le conclusioni: il rendering è ancora problematico

Secondo Davies, al momento “possiamo contare sulle capacità di indicizzazione dei motori, ma il lato rendering ha ancora molta strada da fare” per colmare il divario tra ciò che i motori di ricerca vedono e ciò che fa il browser di un utente.

In base all’esperienza dell’autore, c’è la possibilità che nel breve-medio periodo si riduca “drasticamente la latenza tra indicizzazione e rendering, specialmente sui siti che si basano su questo processo”, e ciò potrebbe portare all’apertura di un mondo per i siti che necessitano di resa grafica per essere compresi.