Segnali web essenziali: un nuovo fattore di ranking per Google?

Chiunque si occupi di SEO, al giorno d’oggi, dovrebbe sapere qualcosa sui segnali web essenziali, che da qualche tempo sono stati inseriti anche all’interno della Search Console dei nostri siti web. Con questa terminologia sembra che siano stati racchiusi ed unificati i segnali di prestazioni che conosciamo già da tempo, e che riguardano molte delle metriche user-centric che sono utilizzate anche dal controverso e discusso PageSpeed Insights.

La domanda di fondo sembra essere: “quanto tempo investirai nel far risparmiare tempo ai tuoi utenti“?

Metriche user-centric: che cosa sono?

Le metriche user-centric sono intese da Google in modo incentrato sulle esigenze degli utenti; gli utenti vogliono non soltanto siti veloci, ma anche che abbiano dei transitori di caricamento accettabili, che non mostrino roba strana a schermo, che non abbiano errori o notifiche che potrebbero infastidirli. Ma non solo: badano anche, ad esempio, alla stability grafica della nostra pagina, ovvero al fatto che contenuti importanti non finiscano per scivolare via dall’occhio dell’utente, ad esempio perchè il JS stava ancora caricando o perchè il browser non aveva finito di valutare per intero i file CSS del sito.

Metriche user-centric: come si intepretano?

Queste metriche sono, di per sè, abbastanza difficili da capire, e sono anche (a quanto pare) difficili da misurare in modo assoluto: un po’ come le ricerche SEO local (che sono quasi sempre un’esperienza soggettiva e relativa a dove ti trovi e a quali ricerche hai fatto in passato), anche queste benedette/maledette metriche misurano la stessa cosa da angolature diverse e molto soggettive o approssimate.

C’è anche da aggiungere una cosa, secondo me, sullo user-centrismo di Mountain View: Google ha probabilmente un’idea dell’utente medio molto più evoluta (con rispetto parlando, s’intende) di quanto non sia in realtà. Per cui – mi permetto di notare – molti di questi discorsi rischiano di diventare fini a se stessi. Un sito, del resto, deve essere sempre ottimizzato con la testa (e con il cuore, se proprio vogliamo essere romantici) sulla base di esigenze contingenti, effettive, misurabili dal proprietario del sito e dai suoi clienti.

Quello che voglio evidenziare è che sono molti siti che vengono “trattati male” dalle metriche di Google che sono, invece, funzionali alla prova dei fatti. E allora, forse, prima di lanciarsi in avventure pointless in cui sono richieste competenze, forze e budget esagerati, sarebbe meglio fermarsi a riflettere un po’ sulla propria effettiva realtà.

Come funziona il caricamento di una pagina web

Per valutare le prestazioni di caricamento di una pagina si usavano, in passato, metriche che erano relative ai semplici tempi di caricamento: il modo più semplice per misurarlo è quello di fare la differenza tra il momento in cui apriamo la finestra di un sito e quello in cui la pagina ha finito di caricare.

Ma questa misurazione rischierebbe di essere poco significativa: quando carichiamo una pagina web di un sito, infatti, ci sono tantissime cose che avvengono dietro le quinte, ed è impossibile prescindere da esse. Ad esempio:

1. vengono fatte varie chiamate HTTPS a file JS, CSS;
2. vengono caricate immagini
3. viene renderizzato il CSS (questo processo è iterativo e può richiedere molto tempo anche se i file da scaricare sono pochi, soprattutto nel caso in cui usiamo la direttiva !important che obbliga al ricalcolo)
4. viene parserizzato ed eseguito il JS (anche qui, il processo di valutazione è lungo e complesso, più di quanto non possa sembrare a prima vista)

Motivo per cui Google aveva introdotto metriche più elaborate, che quasi sembravano supercazzole (Prima visualizzazione con contenuti, Ritardo prima interazione, Variazione layout cumulativa) la cui comprensione è già ostica di suo, per non parlare del sapere quali manopole girare, di preciso, per correggere il tiro.

In realtà, ad esempio, il tempo di prima visualizzazione è tutto sommato intuitivo: dice quando, in media, l’utente inizia a vedere qualcosa nel sito. Il ritardo prima interazione, poi, misura il tempo necessario perchè l’utente possa, ad esempio, cliccare sul menu e quel menù si apra effettivamente (piccola sottigliezza: non conta quando finisce di caricare JS, conta quando l’utente può “mettere mano” alla parte interattiva del sito). La variazione layout cumulativa, infine, fa riferimento a quel concetto di stability di cui accennavo all’inizio: se la pagina sta caricando, gli elementi devono rimanere fissi, se iniziano a spostarsi o slittano senza un perchè, per l’utente è un problema (e per Google pure).

E soprattutto (tanto per cambiare) anche queste metriche sono relative: potrebbero scoraggiarci senza motivo oppure, al contrario, esaltarci – senza che questo produca un vero e proprio vantaggio SEO (quelli li otterrete con una consulenza personalizzata, in genere).

Se apriamo lo strumento per sviluppatori di Chrome, del resto, notiamo come il tempo di caricamento sia suddiviso in varie barrette orizzontali, ognuna delle quali indica un evento (DOM, rendering grafico, ecc.) che noi non vediamo ma in background esiste, e finisce per influenzare i tempi di caricamento delle pagina. Scomporre queste componenti ed ottimizzarle è il compito dei developer ottimizzatori più esperti, e (come accennavo prima) secondo me raramente viene fatto sul serio: non c’è tempo, non si vuole stravolgere l’assetto del sito, ci sono altre priorità, non c’è abbastanza budget e via dicendo.

Quello che segue, per rimanere sul concreto, è il tempo di caricamento reale di una semplice pagina di backend di WordPress. Non del sito della NASA, eh 😉

Che cos’è LCP (Largest Contentful Paint)

In concomitanza con la nuova versione di PageSpeed Insights è uscito fuori un nuovo, ulteriore, metodo di misurazione delle prestazioni, che si lega parecchio alla cosiddetta LCP o Largest Contentful Paint: il tempo necessario per effettuare il rendering del contenuto più grosso (in termini di dimensioni) visibile all’interno della finestra del browser. Se ad esempio la prima cosa che vediamo nel sito è un bel bannerone non ottimizzato di 2 MB, è chiaro che influirà molto sulle prestazioni dal punto di vista di Google. Secondo Google, LCP deve essere tenuto idealmente e al di sotto dei 2.5s, soglia da non superare perchè l’errore non venga notificato all’interno della Search Console.

Nella vostra Search Console, a riguardo, potreste pertanto aver visto qualcosa del genere:

per cui, in teoria, uno dovrebbe riportare la LCP a meno di 2.5s (e mi permetto di dire: in bocca al lupo). Il problema è che qui non c’è una ricetta fissa per risolvere: bisogna andare a vedere come è fatto il tema, se e dove poter intervenire sui colli di bottiglia che rallentano il rendering, e spesso non basta neanche minificare e fare le cose del “bravo ottimizzatore” che facevamo fino a qualche anno fa, i “bei tempi” in cui bastava un hosting condiviso da 50 € all’anno per avere tutto dalla vita (o quasi). Serve un approccio più elastico, sicuramente, e bisognerebbe a volte essere disposti a sacrificare qualcosa per poter risolvere il problema.

Cosa che consiglierei comunque di fare, in prospettiva, dato che – a quanto pare – le nuove metriche entreranno pienamente a far parte dei segnali di ranking di Google a partire dal prossimo anno.

Fonti: web.dev