Perché il rendering dinamico non è una soluzione a lungo termine
Pubblicato: 2022-08-29Nel caso te lo fossi perso, Google ha recentemente specificato che:
- Il rendering dinamico è una soluzione alternativa e non una soluzione a lungo termine per i problemi di JavaScript e
- Google consiglia invece di utilizzare il rendering lato server, il rendering statico o l'idratazione.
Sebbene la documentazione ufficiale di Google faccia luce su come dovremmo trattare il rendering dinamico ora, la domanda che infastidisce molti rimane: perché esattamente dovremmo considerare il rendering dinamico una soluzione temporanea?
Se questa domanda ti spinge a cercare la risposta come me, scaviamo!
Perché questo aggiornamento è importante?
Per capire perché consideriamo vitale questo aggiornamento, torniamo indietro per vedere come Google ha trattato in precedenza il rendering (dinamico).
La cronologia della storia del rendering dinamico
Tutto è iniziato nel 2009, quando Google si è reso conto che quasi il 70% di tutti i siti Web di cui Google conosceva già utilizzava JavaScript. Ma il problema era che a quel tempo non erano affatto in grado di eseguire il rendering di JavaScript.
Per garantire la scansione e l'indicizzazione di JavaScript, Google ha suggerito di offrire ai bot una versione HTML statica di un sito Web quando offre agli utenti un sito Web basato su JavaScript con funzionalità complete. È stato l'inizio del rendering dinamico di oggi come soluzione alternativa nei casi in cui Google non poteva gestire un sito Web con rendering lato client.
Nel 2014, Google ha ammesso ufficialmente di aver iniziato a eseguire il rendering di siti Web basati su JavaScript , per aggiornare nel 2015 che sono generalmente in grado di eseguire il rendering di JavaScript . Tuttavia, molti siti Web hanno ancora difficoltà a eseguire correttamente il rendering e l'indicizzazione del proprio contenuto JavaScript.
Ecco perché Bartosz Goralewicz, CEO di Onely, ha iniziato a fare ricerche sull'argomento e a sperimentare per scoprire se Google può eseguire correttamente la scansione e l'indicizzazione dei framework JavaScript .
Mentre, da parte di Google, nel 2018 sono emerse informazioni più precise sul rendering dinamico. Durante la conferenza I/O di Google , i googler hanno ammesso di utilizzare due ondate di indicizzazione. Ha sottolineato che, in generale, il rendering di siti Web basati su JavaScript è differito finché Google non ha le risorse per elaborare quel contenuto. Inoltre, poco dopo la conferenza, Google ha pubblicato la sua documentazione ufficiale (ora aggiornata), consigliando il rendering dinamico per ottenere un'indicizzazione più rapida del contenuto JavaScipt.
Poi, nel 2019, Bartosz Goralewicz ha elaborato il rendering dinamico durante la sua presentazione a SMX WEST . Voleva spiegare perché questa soluzione non è un proiettile d'argento per tutti i problemi di rendering.
E sebbene noi di Onely sapessimo già che il rendering dinamico non è la soluzione migliore, Google lo consigliava comunque come soluzione alternativa all'elaborazione di JavaScript da parte dei crawler in modo che i webmaster continuassero a utilizzarlo. Ma sfortunatamente, spesso non si sono resi conto di quanto sia costoso ospitare.
Che cos'è il rendering dinamico?
Il rendering dinamico (noto anche come prerendering) consiste nel fornire agli utenti una versione JavaScript completa del tuo sito Web e una versione HTML statica ai crawler per presentare i tuoi contenuti JavaScript. Funziona rilevando e distinguendo diversi agenti utente e fornendo versioni di siti Web adeguate a utenti e bot.
Tuttavia, ciò non significa necessariamente che gli utenti debbano ricevere contenuti renderizzati interamente lato client; semplicemente non vengono serviti gli stessi file statici dei bot. In termini generali, l'intera esperienza JavaScript viene offerta agli utenti e i file HTML ‒ ai robot.
Google integra tale definizione specificando:
Lo chiamiamo dinamico perché il tuo sito rileva dinamicamente se nella richiesta c'è un crawler dei motori di ricerca, come Googlebot, e solo allora invia il contenuto renderizzato lato server direttamente al client. Puoi includere qui anche altri servizi Web che non possono gestire il rendering. Ad esempio, magari servizi di social media, servizi di chat, qualsiasi cosa cerchi di estrarre informazioni strutturate dalle tue pagine. E per tutti gli altri richiedenti, quindi i tuoi utenti normali, serviresti il tuo normale codice ibrido o renderizzato lato client.fonte: John Müller
Poiché la fase di rendering, in generale, è costosa da elaborare da parte dei crawler, il rendering dinamico offre a Googlebot una versione HTML statica, leggera e facilmente comprensibile per rendere i tuoi contenuti pronti per un'eventuale indicizzazione più velocemente.
Ecco perché Google suggerisce che il rendering dinamico può essere un compromesso principalmente per i siti Web:
- cambiano frequentemente i loro contenuti, come i siti web di pubblicazione di notizie ‒ devono indicizzare i loro nuovi contenuti il prima possibile in modo da non poter rinviare l'esecuzione del rendering JavaScript,
- utilizzando moderne funzionalità JavaScript che non sono supportate dai crawler e
- basandosi sulla condivisione dei propri contenuti attraverso i social media o le applicazioni di chat.
In che modo il rendering dinamico differisce da altri modi popolari di servire JavaScript?
Il rendering è un passaggio cruciale della pipeline di indicizzazione: il modo in cui viene visualizzato il tuo sito Web influisce sul modo in cui i motori di ricerca vedono i tuoi contenuti. E per soddisfare le esigenze sia dei bot che degli utenti, è necessario conoscere due diversi approcci: rendering lato server e lato client.
Comprenderli è fondamentale poiché questi concetti ricorrono anche in diversi modi di servire JavaScript che puoi scegliere, come il rendering dinamico.
Rendering lato client
Il rendering lato client si basa sull'elaborazione del contenuto direttamente nel browser utilizzando JavaScript. Inizialmente, browser e crawler ottengono l'HTML iniziale (che di solito rappresenta pagine vuote con poco o nessun contenuto). Quindi, JavaScript viene scaricato in modo asincrono ed eseguito dal server che mostra il tuo contenuto dinamico agli utenti.
Tuttavia, adottando questo approccio, rischi che i tuoi contenuti non vengano visualizzati da Google poiché potrebbe avere difficoltà a elaborare la versione basata su JavaScript di un sito Web in modo indipendente a causa delle sue risorse limitate. Tieni presente che il rendering lato client da solo non è un problema e Google può gestirlo, ma a meno che non sia ben ottimizzato, è molto costoso per Google eseguire la scansione, il rendering e l'indicizzazione.
Rendering lato server
Con il rendering lato server, i bot e gli utenti ricevono la versione HTML del tuo sito Web completamente renderizzata sul server immediatamente, al momento della richiesta. Il fatto che il rendering dell'HTML sia gestito sul server rende l'intero processo più veloce per i browser e generalmente più facile per i motori di ricerca raccogliere il contenuto.
Inoltre, sebbene il rendering lato server sia una soluzione consigliata, Google sottolinea che la sua scelta non influenza le tue classifiche ‒ differisce dal rendering dinamico solo in termini di configurazione e manutenzione:
Non ci sono bonus di ranking SEO per implementarlo in un modo o nell'altro: sono solo modi diversi di rendere il contenuto indicizzabile (come il rendering lato client). Le differenze tra il rendering dinamico e il rendering lato server dal mio POV sono più in termini di configurazione e manutenzione pratica dell'infrastruttura (può anche influire sulla velocità, a seconda di come sono state configurate le cose).fonte: John Müller
Come funziona il rendering dinamico?
Il rendering dinamico può utilizzare un renderer esterno per facilitare la modifica dell'HTML e del JavaScript iniziali nell'HTML statico che i crawler possono elaborare.
Google consiglia di utilizzare i seguenti renderer dinamici:
- Prerender.io (software di terze parti),
- Burattinaio (software open source) o
- Rendertron (software open source).
Dopo aver configurato una delle soluzioni consigliate, ricordarsi di:
- Scegli gli agenti utente che desideri fornire alla versione HTML statica del tuo sito Web, ad esempio "googlebot" o "twitterbot".
- Configura una cache per consentire al tuo sito Web di essere servito il più rapidamente possibile ed evitare timeout.
- Assicurati che la versione prerenderizzata del tuo sito web serva la versione orientata al dispositivo. In altre parole, i crawler dei motori di ricerca mobili dovrebbero vedere la versione mobile del tuo sito quando altri crawler, quello desktop.
- Assicurati che il tuo server possa servire l'HTML statico agli agenti utente scelti.
Per quanto riguarda l'implementazione del rendering dinamico, Google fornisce la sua documentazione ufficiale sull'implementazione e la verifica della configurazione del rendering dinamico.
Perché e come iniziare a navigare tra i problemi di rendering dinamico?
Google non può indicizzare completamente un sito Web basato su JavaScript finché non viene completamente visualizzato. Quindi, se il rendering dinamico fallisce, i tuoi contenuti non verranno inclusi nelle SERP.
E prendi come esempio i popolari siti di eCommerce con sede negli Stati Uniti: l' 80% utilizza JavaScript per generare contenuti principali e collegamenti a prodotti simili . Rappresenta una grave minaccia per l'indicizzabilità delle parti critiche di quei domini. Ora, pensa a come si traduce in una diminuzione delle loro entrate.
Ecco perché il passaggio cruciale dell'implementazione del rendering dinamico è navigare e verificare i potenziali problemi.
Usa il test di ottimizzazione mobile
Lo strumento ti consente di garantire la compatibilità mobile del tuo sito Web e di vedere il codice sorgente visualizzato del sito Web testato, insieme a uno screenshot di come Googlebot esegue il rendering della tua pagina sui dispositivi mobili.
Potresti notare alcune parti dei tuoi contenuti mancanti nel codice sorgente ‒ questo è un segnale per te che Googlebot non è stato in grado di eseguire il rendering di tali risorse e questo potrebbe essere il risultato di un rendering dinamico implementato in modo improprio.
All'interno dello strumento, puoi immergerti nella sezione Dettagli per sapere quando e da quale crawler è stata scansionata la pagina o persino controllare la risposta HTTP. Se stai controllando il tuo dominio, il Mobile-Friendly Test può trasferirti in ulteriori analisi in Google Search Console.
Se riscontri problemi con il Mobile-Friendly Test, leggi l'articolo sul nostro blog per scoprire come ottimizzare il tuo sito web per i dispositivi mobili.
Usa Google Search Console
Uno dei rapporti che devi controllare per assicurarti di aver implementato correttamente il rendering dinamico è il rapporto Copertura dell'indice (indicizzazione della pagina). Ti aiuta a risolvere i tuoi problemi di indicizzazione e ti informa su quali delle tue pagine non sono indicizzate e perché.
Un esempio di stato che può suggerire problemi di rendering sul tuo sito web è la Pagina indicizzata senza stato del contenuto: Googlebot non ha potuto vedere il contenuto perché non è stato in grado di eseguire il rendering della pagina.
Un'altra funzione utile all'interno di Google Search Console è lo strumento Controllo URL . Simile al test di ottimizzazione mobile, lo strumento Controllo URL ti consente di controllare lo stato di una pagina testata e di vederne la versione renderizzata.
Usa ZipTie.dev
Poiché i problemi di indicizzazione possono derivare da problemi di rendering, vale la pena analizzare come viene indicizzato il tuo sito web. Dovresti esaminare sia il numero di pagine indicizzate sia se sezioni specifiche di tali pagine vengono indicizzate.
Per verificare se un particolare frammento della tua pagina è indicizzato, puoi utilizzare il comando site: insieme a un frammento di testo tra virgolette. Ma quando hai un sito web di grandi dimensioni con milioni di URL da analizzare, non sarai in grado di controllarli tutti manualmente.
ZipTie.dev analizza l'indicizzazione insieme ad altri punti dati come il conteggio delle parole, i titoli, le intestazioni, le meta descrizioni e altro ancora. Questo ti aiuterà a identificare le potenziali cause dei tuoi problemi di indicizzazione (e quindi di rendering).
Usa il test dei risultati multimediali
Se utilizzi dati strutturati sul tuo sito web e ti preoccupi dei risultati multimediali, utilizza il test dei risultati multimediali per verificare se il markup è implementato correttamente.
Il test mostra anche la versione renderizzata del tuo sito web e delinea come Googlebot interpreta il tuo markup specificando eventuali errori, i loro tipi e dove appaiono nel codice.
Tuttavia, il solo spuntare le caselle nell'elenco "Come risolvere i problemi di rendering dinamico" di solito potrebbe non essere sufficiente. Più grande e complesso è il sito Web, più difficile può essere specificare cosa è andato storto a prima vista.
Ad esempio, i risultati di errore del test di ottimizzazione mobile potrebbero suggerire la presenza di alcuni problemi di rendering. Ma, allo stesso tempo, il server potrebbe aver appena riscontrato un problema tecnico temporaneo e non ha risposto efficacemente con altre risorse, come i file CSS. Di conseguenza, influenza il modo in cui viene visualizzato il sito Web, ma potrebbe essere solo una situazione occasionale.
La risoluzione dei problemi del rendering (dinamico) richiederà sempre una conoscenza SEO tecnica generale e un'analisi approfondita.
Perché il rendering dinamico non è una soluzione a lungo termine?
Il rendering dinamico utilizza quantità significative di risorse del server
Il rendering dinamico può rallentare notevolmente il tuo server. Una grande quantità di richieste di prerendering può far fallire il renderer, quindi, di conseguenza, Googlebot:
- Ricevi una pagina vuota ‒ Googlebot vede solo l'HTML iniziale, ma poiché non c'è alcun riferimento JavaScript nel codice, il resto di un sito web è invisibile ad esso. Il sito Web non può essere indicizzato perché Googlebot non vede il contenuto.
- Ricevi una versione renderizzata lato client di un sito Web ‒ Google può tecnicamente gestire JavaScript in molti casi, ma l'obiettivo principale dell'implementazione del rendering dinamico era quello di fornirgli contenuto statico. In alcuni casi, il costo del download del contenuto JavaScript e dell'aggiornamento della versione HTML iniziale di un sito Web con esso potrebbe essere troppo elevato per Googlebot.
Pertanto, prima di decidere sul rendering dinamico, è essenziale prendere una decisione deliberata se il tuo sito web ne ha bisogno.
L'implementazione e la manutenzione del rendering dinamico possono utilizzare una quantità significativa di risorse del server. E se vedi che Googlebot è in grado di indicizzare correttamente le tue pagine, allora se non stai apportando modifiche critiche ad alta frequenza al tuo sito, forse non è necessario implementare nulla di speciale. […]fonte: John Müller
Il rendering dinamico crea due strutture del sito separate anziché una
Usando il rendering dinamico, mantieni due versioni del tuo sito web. Significa che devi verificare separatamente che il tuo sito web sia ben ottimizzato per gli utenti e per i bot.
Un sito Web reso dinamico richiede team di sviluppo e SEO eccellenti. E anche se hai tali team a tua disposizione come proprietario di un sito Web, pensa a come potrebbero trascorrere meglio il loro tempo quando non si concentrano invece sulla verifica del rendering dinamico.
Il rendering dinamico peggiora l'esperienza dell'utente
Il rendering dinamico implica che agli utenti venga offerta una versione con rendering lato client e ciò può influire negativamente sulle prestazioni della pagina per gli utenti poiché richiede che i loro browser gestiscano il processo di rendering dalla loro parte. E questa può essere una vera lotta, soprattutto per gli utenti con telefoni più vecchi che avranno difficoltà a elaborare grandi quantità di JavaScript. Sebbene il rendering lato client non sia del tutto malvagio, consigliamo di seguire il percorso lato server quando possibile.
Il rendering dinamico aggiunge un ulteriore livello di complessità durante l'ottimizzazione di un sito web
Con il rendering dinamico, è più difficile individuare e riconoscere i problemi da esso generati.
A causa di problemi sul server o di componenti mancanti, il rendering dinamico spesso non riesce. Di conseguenza, Googlebot riceve una pagina vuota. Sfortunatamente, non ne hai idea quando guardi il sito web come utente (con JavaScript completo), non come un bot. Per risolvere il problema, cambia lo user agent in Googlebot nel tuo browser .
La diagnosi di tali problemi e la scoperta dell'agente utente che genera un particolare problema richiede una notevole esperienza SEO. E devi essere consapevole che nessuna risposta ai tuoi problemi di rendering può riflettersi sull'indicizzazione del tuo sito web.
Quali sono le migliori alternative al rendering dinamico?
Se ben implementate, tutte le soluzioni menzionate di seguito possono essere ugualmente vantaggiose per il tuo sito web dal punto di vista SEO.
Tuttavia, l'effetto dell'implementazione dipende principalmente dalla tecnologia che stai utilizzando e dal tuo team di sviluppo. Per quanto riguarda le risorse di sviluppo, il costo di implementazione di ciascuna soluzione può variare, ma dovrebbe essere valutato individualmente a seconda della situazione.
Rendering lato server
È una delle soluzioni più popolari che puoi utilizzare al posto del rendering dinamico.
Dal punto di vista SEO, il vantaggio più significativo dell'utilizzo del rendering lato server si basa sul mantenimento di una sola versione del tuo sito web. A differenza del rendering dinamico, non è necessario verificare se le versioni per gli utenti e Googlebot sono identiche: tutti i programmi utente ricevono lo stesso contenuto.
Inoltre, a differenza del rendering dinamico, il rendering lato server non fa in modo che gli utenti elaborino i file JavaScript dalla loro parte per generare elementi chiave della pagina. Rende più veloce il caricamento di una pagina; alcune metriche delle prestazioni web influiscono sulle tue classifiche e sull'esperienza utente.
Ma attenzione: con il rendering lato server, gli utenti possono sperimentare metriche Time to First Byte leggermente peggiori se il server deve generare HTML statico ad hoc o se il server che memorizza nella cache le risposte non è sufficientemente efficiente.
E giusto per chiarire: anche se il rendering lato server è implementato correttamente, i SEO devono comunque verificare tutti gli elementi del sito web. Ma tutto sommato, è più facile da mantenere con una sola versione di un sito web.
Resa statica
Il rendering statico (noto anche come generazione statica) si basa sul fornire ai bot e agli utenti la versione HTML statica generata in fase di compilazione . Significa che il codice del tuo sito Web è pronto per essere elaborato dai crawler e dagli utenti che aspettano solo di essere scaricati sul server.
Analogamente al rendering lato server, devi verificare solo una versione del tuo sito Web per tutti i programmi utente durante l'utilizzo di questa soluzione.
Inoltre, a differenza del rendering dinamico, il rendering statico migliora le prestazioni della pagina in quanto serve più rapidamente la versione prerenderizzata del tuo sito Web: i file statici possono essere memorizzati nella cache sui dispositivi degli utenti e riutilizzati.
Reidratazione
La reidratazione serve anche solo una versione di un sito Web a bot e utenti come le due soluzioni precedenti. Tuttavia, funziona in due fasi.
Nella prima fase, i crawler e gli utenti ricevono una pagina con rendering lato server che contiene elementi critici. Ad esempio, nel caso di un sito eCommerce, questi possono essere il nome del prodotto, la descrizione o le valutazioni del prodotto. Nella seconda fase, JavaScript scarica tutte le risorse non critiche che sono essenziali dal punto di vista SEO, ma gli utenti possono riceverle con un ritardo. Questi sono, ad esempio, widget di chat o sezioni di commenti.
Durante l'audit di un sito Web utilizzando la reidratazione, è necessario verificare se tutti gli elementi aggiunti da JavaScript sono quelli non critici.
Il rendering dinamico può mai funzionare a lungo termine?
Può, ma raramente lo fa. Soprattutto se hai un sito Web di grandi dimensioni e non sei esperto di SEO tecnologico, non adottare questo approccio da solo.
E ricorda che anche se non sei preoccupato per la SEO tecnica, il rendering dinamico sarà comunque costoso da mantenere.
Ecco due esempi di quando i nostri clienti hanno utilizzato il rendering dinamico per:
Servire collegamenti renderizzati lato client per gli utenti nel piè di pagina
In tal caso, grazie al rendering dinamico, Googlebot potrebbe trovare i link nel codice sorgente, ma allo stesso tempo, i link del footer sono stati generati per gli utenti e aggiunti al DOM (che rappresenta lo stato della tua pagina dopo il rendering) una volta iniziato a scorrere la pagina. Il cliente ha deciso di implementare il rendering dinamico per ottimizzarne le prestazioni: non tutti gli elementi devono essere archiviati immediatamente nel DOM se gli utenti non scorrono fino alla fine della pagina.
Fornire agli utenti l'elenco visualizzato lato client di risultati di ricerca interni
Il client ha deciso di fornire la versione renderizzata lato server ai bot (una versione più leggera delle inserzioni) e le versioni renderizzate lato client agli utenti (quando l'elenco dei prodotti è generato ad hoc e può essere personalizzato).
Avvolgendo
Mentre il rendering dinamico dovrebbe essere considerato solo come una soluzione temporanea, in alcuni casi lo considererai come una cintura di salvataggio per il tuo sito web.
Se devi implementare il rendering dinamico, ricorda di seguire questi quattro passaggi:
- Pianifica gli aggiornamenti e le implementazioni. Assicurati che i tuoi team di sviluppo e SEO dispongano di risorse sufficienti per gestire l'implementazione e la manutenzione di un sito Web prerenderizzato.
- Assicurati che la configurazione sia efficiente e priva di bug. Sviluppa un modo per verificare che la configurazione funzioni correttamente e che nella versione fornita ai bot non manchino elementi chiave della pagina.
- Ricorda che devi essere in grado di confrontare le versioni HTML e JavaScript del tuo sito Web e rilevare le discrepanze.
- Ricorda che, nella maggior parte dei casi, il rendering dinamico dovrebbe essere solo una soluzione alternativa. Cerca opportunità per passare ad altre soluzioni consigliate, considerando le tue risorse di sviluppo e le capacità tecnologiche.