A caccia del Layout Shift

Quest’oggi affrontiamo un aspetto legato al ranking delle pagine HTML del libro on-line. La Search Console di Google mi segnala infatti un valore troppo elevato di CLS (Cumulative Layout Shift) per esse, una metrica appartenente alla famiglia di parametri prestazionali chiamati Web Vitals, lo sforamento dei quali viene punito da Google con una penalizzazione del ranking, facendole retrocedere nell’ambito delle sue SERP. E infatti, da diversi mesi ho assistito ad un dimezzamento di impressioni e visite.

In pratica questo layout shift significa che la visualizzazione della pagina si modifica nell’intervallo d tempo tra quando inizia ad apparire, e quando sono arrivati tutti gli elementi che la compongono, citati nell’HTML della pagina, ma relativi ad oggetti che vengono scaricati dal sito in tempi successivi.

Una categoria di oggetti che arrivano “a parte” sono le immagini, ed in quel caso la colpa è di non aver inserito nell’HTML le loro dimensioni esatte, perché se così fosse stato, il browser avrebbe potuto riservare per le stesse spazio a sufficienza, evitando una riformattazione successiva. In realtà questa mancanza era in parte voluta, per meglio permettere una corretta visualizzazione su devices con diversa dimensione di schermo…

In tutti i modi, ho iniziato a modificare tutti i riferimenti alle immagini in tutti gli HTML, solo che le pagine sono quasi 200 e le immagini un migliaio, così ad un certo punto ho desistito, e mi sono rivolto a ChatGPT HTML Expert, con cui ho ingaggiato un rapporto di consulenza, chiedendogli di scrivere uno script che svolgesse il compito. Lui (?) prima ne ha prodotto uno in Bash che usava imagemagick e l’editor di linea sed con espressioni regolari, ma non funzionava per gli elementi HTML suddivisi su più linee. Gliel’ho fatto notare, ed allora ha utilizzato awk, ancora senza successo. Al che gli ho suggerito che avrebbe prima dovuto eseguire una analisi del DOM della pagina, al che ha prodotto un codice Python basato sulla libreria BeautifulSoup, e finalmente è andata bene! (anche se in qualche occasione il DOM non era tornato come era prima, ed ho dovuto spostare un </div> in disordine)

Solo che… l’analizzatore incorporato in Chromium mi dava ancora un valore troppo elevato di CLS!!!! Aaaargh! Di chi era la colpa? Ma dei font! La pagine del libro online ne usano quattro, per il testo, le formule, il calligrafico nelle formule, ed i titoli. Nel frattempo che il browser scarica i font, la pagina viene mostrata con quelli di sistema, e quando quelli specifici arrivano (il loro download inizia solo nella fase di rendering, quando il browser incontra una regola css che li specifica), la pagina si riformatta, causando il cambiamento di diverse andate a capo, cosicché i paragrafi cambiano lunghezza, e quelli successivi si spostano… 😞 Affronto dunque una nuova fase di studio, e mi imbatto in alcune pagine che spiegano come inserire nel css delle direttive che modificano le dimensioni dei font di sistema, per renderle il più possibili simili a quelle dei font specifici. Peccato che…. questo insieme di regole non sembra essere supportato ne da Firefox ne da Chromium! 😞

E allora, come se ne esce? Cerca che ti ricerca, (Internet è nata per questo, mica per buttar via parte della nostra vita a scrollare i reel di Instagram) scopro che si può anticipare la fase di download dei font, citandoli nella sezione <head> dell’HTML, all’interno di un elemento a cui aggiungere l’attributo rel="preload". A quel punto il browser si fida che quel gli è stato raccomandato verrà usato successivamente, e lo fa passare davanti a tutti (nella coda di download), così al momento opportuno (il rendering viene ritardato) se lo trova già in cache, e la prima visualizzazione della pagina utilizza direttamente i font giusti. Evviva, ce l’abbiamo fattaaaaa!!!

Nella search console di Google viene data l’opportunità di segnalare la correzione del problema, e Google stesso dice di aver bisogno di un mese per verificare il nuovo assetto, che a quanto pare, dipende dall’esperienza dei visitatori. Aspettiamo e speriamo che gli piaccia il mio operato, solo resto con il dubbio di come faccia Google a conoscere l’esperienza dei visitatori, visto le pagine del libro non fanno uso del suo Analytics, ma di un Matomo in-house… lo fa tramite Chrome? Che dunque è vero che ci spia? Ho investigato, ed a quanto pare la spia ha un nome, si chiama Chrome UX Report o, in breve, CrUX!

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *