Oggi proviamo a fare un piccolo punto sulle prime cose da guardare rispetto al codice delle pagine web (e non solo) per evitare un impatto negativo a livello dei core web vitals. Il tema di questo post è materia per sviluppatori esperti in web performance, quindi non ho la pretesa di evadere tutti i possibili motivi per cui un sito web può risultare lento e restituire dei punteggi bassi sul Page speed insights di Google o direttamente a livello della Search Console nella voce sui core web vitals.
Sarà comunque utile confrontarti con il tuo web master su questi primi punti, perché spesso sono quelli su cui è più facile avere il controllo e che possono produrre un vantaggio immediato e importante a fronte di un effort relativamente basso. Quindi bando alle chiacchiere e diamo subito un’occhiata.
Tempo di risposta del server
La primissima cosa da fare è aprire l’inspector del tuo browser e una volta selezionata la pagina web da testare, aggiornare il caricamento e controllare la voce tempistiche. In quest’area puoi visualizzare subito il tempo che serve al server per rispondere alla richiesta. Se questo tempo è superiore al secondo e operi in regime competitivo, sappi che hai un gap importante rispetto ai tuoi concorrenti, che probabilmente richiede un’intervento sistemistico e magari un aggiornamento del piano di hosting. Pensaci sù, perché se il sito web non ha particolari problemi lato codice, può darsi che basti investire pochi euro in più all’anno per migliorare significativamente le cose. Insomma, il gioco vale la candela.
Largest Contentful Paint alto (oltre 2.5s)
L’elemento che guida il parametro LCP è spesso un’immagine. Alcune ottimizzazioni possono aiutare l’immagine a caricare prima. A esempio, puoi aggiungere
<link rel=”preload” as=”image” href=”https://www.nomesito.it/immagine.jpg”>
all’intestazione del documento HTML, facendo sì che i browser richiedano l’immagine prima e con una priorità più alta di quanto non farebbero altrimenti.
file JavaScript che bloccano il rendering della pagina
Spesso per impostazione predefinita, i riferimenti a file JavaScript esterni bloccheranno il rendering della pagina mentre vengono recuperati ed eseguiti. Molte volte questi file possono essere caricati in modo diverso, liberando le pagine per renderle visivamente più rapide.
In questo caso puoi rinviare gli script di blocco del rendering, aggiungendo un attributo defer agli script di blocco della visualizzazione, facendo sì che il browser li recuperi in parallelo durante la visualizzazione della pagina. Gli script rinviati vengono comunque eseguiti nell’ordine in cui sono definiti nel codice.
Le immagini esterne all’area di visualizzazione critica possono essere caricate in lazy load
Quando le immagini vengono caricate in lazy load utilizzando load=”lazy”, liberano il caricamento iniziale per altre attività. In questo passaggio è molto importante capire quali sono le immagini che per Google si trovano nel viewport e quali quelle che ne sono fuori. Non è banale, perché non conosciamo l’ampiezza dell’area che Google prenderà in considerazione come riferimento, giacché questa può cambiare a seconda del browsing, del device e del sistema operativo. Un buon punto di partenza è il render di pagina che Google ci mostra internamente alla search console. Parti da lì.
Risorse precaricate, che però non vengono utilizzate durante il caricamento della pagina
Le risorse precaricate vengono recuperate con una priorità alta, ritardando l’arrivo di altre risorse nella pagina. Nel caso in cui una risorsa precaricata non venga mai effettivamente utilizzata dalla pagina, ciò significa che le richieste potenzialmente critiche verranno ritardate, rallentando il caricamento iniziale.
Questo problema si verifica spesso quando ad esempio abbiamo nel codice della pagina alcune dipendenze JS che non hanno proprio nulla a che vedere con la pagina stessa. Ecco, non solo le teniamo lì, ma le precarichiamo anche con un rel=preload. Non è follia, è solo automatismo, plugin, tema mal gestito. Rimuovere i pre caricamenti inutilizzati, ma presenti in pagina, sbloccherà le richieste per altre risorse critiche, ma prima di investire tempo e denaro nello sviluppo di questo task, occorrerà capire di quante risorse parliamo e di quanto converrà in termini di costi e benefici.
Font ospitati su host di terze parti
Il caricamento dei font su domini di terze parti può richiedere più tempo a causa dei passaggi DNS e di connessione che non sono necessari quando i font sono ospitati sullo stesso dominio. In questo caso hai tre opzioni:
- caricare i font direttamente sul tuo server, in modo da evadere direttamente le richieste;
- aggiungere un link con rel=”preconnect” per gli host specificati;
- Puoi aggiungere un link con rel=”preload” per i file specificati.
Puoi scegliere una di queste strade per migliorare la velocità percepita di accesso al testo della pagina.
Conclusioni
E mi fermo qui, anche se si potrebbe andare avanti a lungo solo con tutti gli aspetti legati al caching delle risorse e alle dimensioni del DOM, ma questa vuole essere solo una prima checklist per cominciare a esplorare il mondo delle possibilità legate all’ottimizzazione dei caricamenti.
Parlane dunque col tuo sviluppatore e tieni presente che in questo momento storico, con Google che centellina le risorse di scansione, le performance sono molto più importanti di prima.
E lo sono per tutti.
