SMXL 2021: un intervento dedicato alla Page Experience
Sul palco virtuale di SMXL Milan ho portato alcune innovazione tecnologiche volte a migliorare le performance dei siti web, e quindi i Core Web Vitals e la Page Experience. In particolare ho parlato di rendering delle pagine, di Early Hints, di Signed Exchanges (SXGs), di Priority Hints e di HTTP/3.
In occasione di SMXL Milan ho parlato di alcune interessanti evoluzioni tecnologiche volte a migliorare la Page Experience, anche in vista del recente annuncio di Google relativo all'estensione del Page Experience Update ai risultati desktop a partire da febbraio 2022!
Ricapitoliamo l'intervento in alcuni punti chiave.
Il Rendering
Il viaggio è iniziato dalla fase di rendering delle pagine web. Come si colloca tale fase dalla scoperta della pagina fino all'indicizzazione?
- La pagina viene "scoperta";
- viene inserita in coda, in attesa di crawl budget;
- viene scansionata, ottenendo l’HTML;
- viene indicizzata e messa in coda di rendering, in attesa di budget;
- infine, avviene il rendering, ottenendo l’HTML "renderizzato".
In pratica, il rendering permette di comprendere l’esperienza dell’utente, e la priorità dei contenuti, e grazie alla "second wave of indexing", consente di riconsiderare potenziali contenuti generati e/o modificati da javascript.
Durante una recentissima intervista a Martin Splitt, gli è stato chiesto se il rendering può aiutare a posizionarsi meglio. Giustamente ha risposto "in linea di massima, NO".
Tuttavia, se alcuni contenuti non vengono visualizzati dal motore di ricerca, il rendering impatta sulla corretta indicizzazione delle pagine. Inoltre, influisce sulle prestazioni delle pagine, e chiaramente nelle metriche dei Core Web Vitals (ad esempio su LCP).
Quello che vorrei come SEO, è che uscissimo dall’idea di mettere in atto azioni pensandole come attività ad impatto diretto sul ranking. Dobbiamo ragionare sulla qualità, con l’esperienza dell’utente al centro. Io credo che, se diamo le risposte che l’utente sta cercando ed un’esperienza straordinaria, unite ad un livello SEO adeguato, i risultati verranno da noi, e non il contrario.
Le tipologie di rendering
Esistono due principali categorie di rendering:
- SSR (Server-Side Rendering), in cui le pagine vengono renderizzate lato server;
- CSR (Client-Side Rendering), in cui il rendering della pagina avviene lato client, ovvero nel browser.
Il mondo SEO tende a demonizzare il CSR, e quindi l’ecosistema javascript, perché anche se oggi Chrome Headless renderizza le pagine per conto di Google, abbiamo imparato dal passato ad associare javascrip a problemi di interpretazione delle pagine da parte del motore di ricerca.
Inoltre, i sistemi CSR, implicano il fatto di dover fare i conti con quello che viene definito rendering budget (anche se ormai le prestazioni sono elevate e la latenza è bassissima).
Tuttavia è arrivato il momento di svincolarci da questi pensieri, perché oggi stanno nascendo delle grandi soluzioni tecnologiche.
Google, nella documentazione mostra questa infografica che analizza diverse tecniche di rendering anche ibride, offrendo i pro e i contro, e anche esempi per ognuna.
Esiste una soluzione migliore ed una peggiore per la SEO? Certo che sì, e la "regola" è sempre la stessa: quella che riesce a dare il maggior numero di pagine al crawler e al servizio di rendering usando il minor budget.
E tutto questo, nel giusto bilancio con la soluzione che offre la miglior esperienza all’utente. E per questo, i Core Web Vitals e la Page Experience sono la "cartina tornasole".
Rendering Tips
Nell'intervento ho condiviso alcuni "tips" relativi al rendering, che secondo me sono molto interessanti.
1) Sistemi SSR ad alte prestazioni
Oggi abbiamo a disposizione sistemi SSR ad altissime prestazioni, ad esempio Ghost, che io uso come CMS in questo sito web (che per me è un laboratorio di test).
La tecnologia usata lato server è NodeJs e grazie ad un’architettura molto prestante lato server, ad un sistema ci chaching molto performante, all’uso di CDN, il tutto in un perfetto mix, si riescono ad avere performance elevate con uno sforzo minimo.
Il backend, invece viene renderizzato sul client (CSR). E anche questa scelta, secondo me è azzeccatissima.
2) Rendering Dinamico
Ma se volessimo utilizzare un rendering lato client, e contemporaneamente essere sereni dal punto di vista SEO e dei motori di ricerca? Possiamo implementare quello che Google definisce rendering dinamico.
In questo caso l’utente nel suo browser visualizzerà la versione CSR, mentre il crawler riceverà la versione statica, generata lato server.
Può essere interpretato come cloaking? No, e Google lo specifica espressamente nella documentazione. A meno che non renderizziamo versioni di pagina completamente diverse.
Per dimostrare che tutto funziona perfettamente, ho presentato un esempio di un sito web in cui viene usata questa tecnica (si tratta di un e-commerce di abbigliamento). Il catalogo prodotti viene renderizzato completamente lato client: se disabilitassimo javascript dal browser il corpo delle pagine non verrebbe visualizzato.
Ma al crawler viene inviato l’HTML statico.
Come vediamo dai dati, non sembra avere grandi problemi di indicizzazione.. Anzi!
3) Framework Javascript
Oggi i front-end più prestanti tendono ad essere realizzati con dei framework javascript che utilizzano un’architettura definita JAMstack, quindi basata su Javascript, API e Markup.
Alcuni esempi (tra i più premiati nel 2021) sono Gatsby, Jekyll, Hugo, NuxtJS e NextJS.
Tali framework, consentono di poter gestire la modalità di rendering delle pagine, anche in maniera selettiva (pagina per pagina), in base alla frequenza di aggiornamento (ad esempio, se la pagina viene aggiornata raramente, è possibile renderizzare la versione statica lato server) e in base alle prestazioni del server, perché la renderizzazione lato server, ad esempio, necessita di risorse.
Una parentesi finale sulle architetture che stanno accelerando oggi..
Nello schema che segue vediamo a sinistra una struttura abbastanza nota, composta da una CDN, un web server ed la base di dati.
A destra, invece abbiamo una struttura moderna, verso la quale, probabilmente ci stiamo avviando.
Quali sono le caratteristiche? Un front-end sviluppato con le tecnologie che abbiamo visto fino a questo momento, che viene distribuito direttamente nell’EDGE (per approfondire, consiglio di documentarsi su servizi come Cloudflare Pages o Netlify); mentre il back-end è composto da un CMS Headless per i contenuti, e da microservizi per le funzionalità.
Un CMS Headless è un sistema che consente di fare ciò che un CMS dovrebbe fare.. ovvero gestisce i contenuti, che possono essere erogati in qualsiasi front-end via API. Tutti i CMS si stanno muovendo per offrire una versione Headless (es. WordPress, Shopify, Ghost, Contentful, Magento, Salesforce, ecc.).
Perché vi ho raccontato tutto questo? Perché ci tenevo a trasmettervi come si stia accelerando con la tecnologia, alla ricerca di una Page Experience straordinaria.
Ma questo non deve spaventarci come SEO. Non dobbiamo avere paura del cambiamento, perché la SEO sarà sempre più UX centrica!
E non è solo una questione di SEO.. Tutto andrà in quella direzione: i Core Web Vitals sono solo un assaggio!
Quello che dovremo fare sarà.. essere costanti nello studio e nella ricerca di miglioramento.
Early Hints
Nello schema che segue, nella parte alta vediamo la pipeline di caricamento di una pagina web e delle sue risorse.
Nella parte interiore, invece, si può comprendere ciò che accade sfruttando gli early hints. In pratica, prima che arrivi la risposta 200, durante il cosiddetto "think time", il server manda al client dei "suggerimenti", con uno status code 103. Tali suggerimenti, ovvero gli early hints, sono proprio le risorse da precaricare.
Il risultato lo vediamo nella pipeline in basso a sinistra: nel momento in cui arriva la risposta completa dal server, il client avrà già scaricato tutte le risorse necessarie per "disegnare" la pagina, e quindi potrà procedere immediatamente alla renderizzazione. Di conseguenza velocizziamo il rendering, il load time, e quindi miglioriamo i Core Web Vitals e la User Experience.
Un aspetto molto interessante, è l'approccio di Cloudflare a questa tecnologia. Il seguente post lo approfondisce in maniera dettagliata, comprendendo anche uno sguardo verso il futuro con gli Smart Early Hints.
Alessio Pomaro
Secondo Cloudflare, i risultati mostrano una riduzione del 30% del load time per i browser che visitano la pagina per la prima volta, quindi nel caso peggiore.
Chiaramente questo dipende dal livello di prestazioni di partenza, tuttavia si tratta di ottimizzazioni di un certo livello.
Signed Exchanges (SXGs)
Quello dei Signed Exchange è un concetto abbastanza complesso, ma lo vediamo insieme senza entrare troppo in tecnicismi.
Si tratta, fondamentalmente, di un metodo di distribuzione delle risorse che consente di certificarne l’origine indipendentemente da come vengono e consegnate. E questo permette di avere enormi vantaggi, ad esempio di usare delle copie certificate del sito web in cache di terze parti distribuite, sistemi di prefetch e funzionamenti offline.
Per spiegarlo con una metafora, immaginiamo un re (il server), che deve distribuire dei messaggi a tutto il regno (le pagine web), ma non potendo farlo di persona, perché il regno è troppo vasto, crea un timbro non replicabile (Signed Exchange) e usa dei fidati cavalieri per distribuire i messaggi timbrati (copie certificate su cache di terze parti).
Ma uscendo dal significato del sistema, quali sono gli aspetti interessanti?
Signed Exchange consente a Google di precaricare i contenuti dei risultati SERP, ottenendo quindi una velocità di apertura praticamente istantanea.
Nello schema seguente vediamo come funziona: nel momento in cui il crawler scansiona il sito web, se il sistema è dotato di SXG, Google sarà in grado di creare la cache e precaricare le risorse.
E chiaramente questo impatta nell’esperienza dell’utente, e nei Core Web Vitals.
Anche in questo caso Cloudflare offre un sistema (ancora in versione beta) per poter gestire i Signed Exchange nell'EDGE, il tutto attivabile dal pannello utente. Per approfondire ulteriormente questo aspetto e l'argomento in generale, consiglio il seguente post.
Alessio Pomaro
Priority Hints
I priority hints sono degli attributi che si potranno aggiungere ai tag HTML delle risorse per specificare il loro livello di priorità nel rendering della pagina.
Fantastico!! ..se si ha chiaro cosa significa progettare un rendering per ottenere le massime prestazioni.
Le risorse critiche, fondamentalmente, avranno importance high, mentre quelle non critiche, low.
Anche in questo caso, parliamo di miglioramento della Page Experience e dei Core Web Vitals.
Patrick Meenan, di Google Chrome, parla addirittura di riduzioni della metrica di LCP superiori al mezzo secondo. Chiaramente, anche in questo caso, dipende dalla situazione di partenza!
HTTP/3
Dopo diversi anni di sviluppo, ci siamo con la terza versione del protocollo HTTP.
Se osservai i caricamenti delle risorse su Chrome, vedrai che in realtà è già presente, e se hai un account Cloudflare lo puoi già abilitare.
Non avremo l’impatto di prestazioni visto nel passaggio da HTTP ad HTTP/2,
ma cambierà il modo di trasmettere i dati su Internet, permettendoci di avere prestazioni e sicurezza superiori.
Conclusioni
Come abbiamo visto..
siamo diretti verso UX straordinarie, ma siamo diretti anche verso la necessità di competenze tecniche sempre maggiori.
Concludo con un appello..
Anche se ci sono sempre più soluzioni "no-code", "one-click", dove per fare tutto basta installare plugin, continuiamo a studiare!
E questo lo dico da SEO, da appassionato di evoluzione tecnologica, ma soprattutto da utente.
Per approfondire
Alessio Pomaro
bashi
Alessio Pomaro