Il sito veloce, senza codice

Aggiornamento del 2 dicembre 2020 basato sulla nuova versione di GTmetrix!

Nota: durante l’edizione 2020 del WordCamp Italia, svoltasi lo scorso 17 ottobre, ho partecipato con un intervento su come velocizzare il proprio sito senza leggere o scrivere codice. Questo articolo è stato creato come una libera trascrizione di quell’intervento, che si basava sullo strumento di test e misurazione GTmetrix.

Esattamente un mese dopo il mio intervento, GTmetrix ha avuto un sostanziale aggiornamento che integra le metriche di performance di Google Lighthouse e introduce i nuovi Core Web Vitals. Ecco quindi la presentazione aggiornata con il nuovo GTmetrix che trovate su Slideshare e, ovviamente, qui sotto 👇

L’importanza della performance

L’importanza di avere un sito veloce è un argomento non certo nuovo per noi addetti ai lavori; al contrario molte aziende e imprenditori ne sembrano ancora inconsapevoli o non le stanno dando, a mio avviso, la giusta importanza.

Eppure queste stesse aziende assumono creatori di contenuti, Social Media Manager o copywriter, affinché creino materiali di marketing e campagne accattivanti.

Allora, nelle campagne online il sito ha spesso un ruolo centrale: le campagne possono anche essere mirabolanti, ma se un utente clicca e finisce su una pagina di atterraggio che ci mette 10 secondi a caricarsi, quasi sicuramente perderemo gran parte delle conversioni. Questo rende vani gli sforzi e il duro lavoro fatto sulle campagne, e vi assicuro che succede più spesso di quanto si pensi.

Le conseguenze sono due.

La prima conseguenza – come già detto – è di marketing: quanto traffico, quanti potenziali clienti ci perdiamo per una cattiva esperienza di navigazione?

La seconda è di posizionamento: come sapete Google – che attraverso i telefoni Android e il browser Chrome può raccogliere e analizzare dati di navigazione effettivi – si propone come avvocato difensore dell’esperienza utente e da tempo ha inserito la velocità del sito tra i fattori che influenzano il posizionamento sul motore di ricerca.

Nel 2016 Google, nel documento “The Need for Mobile Speed” (link in fondo all’articolo) aveva rilevato che la media dei tempi di caricamento dei siti sui cellulari in era di circa 15 secondi, mentre oltre la metà degli utenti mobili scappava dal sito se il caricamento si protraeva oltre i 3 secondi.

Nel 2019 la situazione è migliorata, ma non abbastanza: i tempi medi di caricamento superano una media di 10 secondi. Chrome ha quindi promesso che in futuro segnalerà con un badge i siti che di solito si caricano lentamente.

Inoltre, nel continuo sforzo per migliorare la qualità dei siti web premiando quelli che offrono una migliore esperienza utente, Google ha ultimamente creato un set di misurazioni dal titolo-ombrello di Core Web Vitals (segnali vitali).

A partire dal maggio 2021, i Core Web Vitals – aggiunti di recente ai report forniti da Google Search Console – influenzeranno il posizionamento su Google. Uno dei segnali vitali è appunto la velocità di caricamento.

Per i motivi appena spiegati, diventa necessario sensibilizzare non solo gli sviluppatori, ma anche le aziende e i proprietari dei siti web.

Ecco quindi la sfida di oggi: incoraggiare tutti i proprietari di siti web a misurare la velocità del proprio sito e ad agire con i primi passi di ottimizzazione.

Come misurare la velocità del sito e comprendere i risultati

Il primo passo verso un sito veloce è quello di misurare la sua velocità. Per farlo usiamo uno fra gli strumenti gratuiti più popolari: GTmetrix.

GTmetrix è uno strumento di test potente che cronometra tutti i passaggi e le risorse richiamate dal browser durante il caricamento di ogni pagina.

Un buon test di velocità non ha il solo scopo di sapere quanto è veloce il sito ma serve anche per capire cosa, eventualmente, lo rallenta. E’ l’hosting? È un plugin pesante? Sono le immagini troppo grandi? O una combinazione di queste cose?

Impostazioni prima del test

Per impostare il test di velocità affinché sia il più possibile veritiero è opportuno partire dalle basi. Ecco il metodo che suggerisco:

In WordPress:

• Disattivare plugin di cache e di ottimizzazione, se presenti. Se abbiamo attivato cache e plugin di ottimizzazione è meglio disattivarli perché vogliamo vederci chiaro su quali elementi vengono richiamati e sul peso reale di questi elementi 

• Disattivare momentaneamente il cookie banner. Se abbiamo attivato un cookie banner è meglio disattivarlo perché in questo modo si identificano tutti gli script, anche quelli che vengono caricati soltanto dopo l’accettazione dei cookie.

Nel browser:

• Attivare una finestra di navigazione in incognito. La navigazione in incognito non carica le eventuali estensioni del browser che falserebbero i tempi del test.

Impostazioni durante il test

Mentre impostiamo GTmetrix dobbiamo tenere a mente che vogliamo simulare il più possibile la modalità di navigazione e l’area geografica dei nostri utenti di riferimento. 

Quindi impostiamo una connessione mobile come LTE o 3G, e scegliamo il server più vicino al nostro pubblico. Queste opzioni si possono impostare registrandosi con un account gratuito.

Attenzione a chi pubblica test con risultati super veloci!

Quando nei risultati di un test non viene specificato il tipo di connessione, il test si è svolto con una connessione illimitata. Ovviamente ci riescono tutti a caricare un sito in un secondo con la connessione illimitata. Il nostro scopo è diverso, vogliamo avere risultati vicini alla vera esperienza degli utenti mobili.

Quando è specificata la connessione, allora i tempi mostrati dai risultati sono più vicini alla realtà.

Come leggere e interpretare i risultati del test

GTmetrix assegna due serie di punteggi di performance. Passando il mouse sul punto di domanda accanto a ogni punteggio, GTmetrix fornisce una spiegazione del suo significato. 

La prima serie (GTmetrix Grade) contiene un voto complessivo e due punteggi di Performance e Structure basati su elaborazioni dei risultati di Lighthouse (l’estensione di Google Chrome integrabile negli strumenti per sviluppatori).

La seconda serie sulla destra espone i più recenti Web Vitals, progettati da Google come indicatori di qualità dell’esperienza utente. Giacché i Web Vitals entreranno tra i fattori di posizionamento nel maggio 2021, consiglio di focalizzarci su di loro e familiarizzare con il loro significato.

Le viste analitiche di GTmetrix

La Speed Visualization e gli indicatori che contano 

Sotto il pannello con i punteggi vi è una serie di viste analitiche. La prima (Summary) viene proposta per default e mostra la rappresentazione visuale delle fasi di caricamento con i relativi tempi. Una analisi ancora più dettagliata dei diversi tempi è disponibile nella vista Performance. 

TTFB e qualità dell’Hosting Provider.

Il primo tempo mostrato è chiamato Time To First Byte (TTFB) ed è quello che meglio di tutti esprime il tempo impiegato dal hosting per dare la prima risposta “OK, la pagina esiste”. Il TTFB è suddiviso a sua volta in sotto-fasi di cui parliamo più avanti.

Mi è capitato di parlare con alcuni proprietari di siti web che, lamentando una generale lentezza di caricamento, saltavano subito alla conclusione di dover sostituire l’hosting. Prima di decidere però è opportuno consultare proprio questo indicatore. 

Gli hosting condivisi di bassa qualità hanno quasi sempre un TTFB superiore a un secondo, che in condizioni di stress può toccare i 2 secondi o anche più. Comprendete che con questi tempi è difficilissimo ottenere tempi soddisfacenti nelle fasi successive del caricamento. Se il sito web è il fulcro delle vostre campagne pubblicitarie è bene scegliere un Hosting Provider con TTFB almeno inferiore ad 1 secondo. Più le pagine sono complesse e pesanti, più potente deve essere l’hosting.

Il TTFB viene suddiviso in sotto-fasi, di cui la prima è il Redirect (reindirizzamento). Se durante il caricamento non avvengono reindirizzamenti, questo indicatore è sempre a zero. Se invece, come nell’esempio, vediamo un risultato superiore allo zero, significa che il sito è stato reindirizzato. Più avanti trovate maggiori dettagli su questo punto.

Largest Contentful Paint (LCP), il nostro obiettivo

I tempi di tutte le fasi successive al Time to First Byte sono anch’essi lievemente influenzati dall’hosting, ma la responsabilità principale sta nella complessità e nel peso dei contenuti della pagina. Di tutte le fasi, quella chiamata Largest Contentful Paint (LCP) indica il tempo impiegato per il rendering dell’elemento più grande nella parte visibile della pagina.

Insieme al precedente indicatore “First Contentful Paint” è quello che rappresenta più da vicino l’esperienza utente. Per questo motivo il Largest Contentful Paint è il primo dei Web Vitals di Google, che consiglia di mantenerlo sotto i 2 secondi con una connessione mobile.

La Waterfall e i contenuti che rallentano il sito.

Nella vista “Waterfall” vediamo la sequenza di tutti gli elementi caricati nella pagina, il loro tempo di caricamento e le dimensioni. Questi elementi possono provenire da temi, plugin, script esterni o contenuti.

Passando il mouse sopra ogni voce si vedrà il nome di ciascun elemento e con un clic si può vedere il dettaglio della richiesta e della risposta del server. 

La vista è ordinata per default con la sequenza di caricamento, ma si può ordinare per ognuna delle colonne (URL, Status, Domain, Size, ecc) e si può filtrare per tipo di contenuto (HTML, CSS, JS, immagini, font, ecc.). Può essere anche interessante ordinarla per dimensioni, così da vedere all’istante gli elementi più pesanti, tra cui sicuramente troverete le immagini.

L’URL di ciascun elemento visibile nella Waterfall ci fa intuire la sua provenienza, cioè il tema o plugin o il contenuto di cui fa parte.

Esaminando a fondo la Waterfall identifichiamo:

• se c’è un elemento, e qual è, che blocca o rallenta il caricamento
• se ci sono elementi particolarmente pesanti, quindi più lunghi da caricare
• se ci sono elementi provenienti da temi o plugin, non necessari in quella pagina particolare.

Infatti forse non tutti sanno che moltissimi plugin caricano del codice in tutte le pagine, anche dove non è necessario. 

Nella figura sopra è evidenziato un elemento caricato dal plugin Woocommerce in una pagina che, esaminata, non contiene prodotti né altri elementi dello shop. Questo è un tipico esempio di elementi non necessari.

Ma ci sono altri casi conosciuti: ad esempio Contact Form 7, il plugin più famoso per i moduli di contatto, carica il suo codice anche nelle pagine dove non c’è il modulo.

I primi passi verso il sito veloce, senza usare il codice

Fatta l’analisi, sappiamo quali sono i blocchi principali al caricamento della nostra pagina e abbiamo davanti una scelta: ottimizzare il sito in proprio o affidarci ad uno specialista?

Per chi vuole cimentarsi in proprio con l’ottimizzazione del sito, questo articolo propone un metodo, una sequenza – testata qui in NUwebstudio e a mio avviso davvero valida – e alcuni strumenti che non richiedono la conoscenza del codice. L’unico pre-requisito è quello di conoscere i componenti, cioè il tema e i plugin installati nel sito e il compito di ciascuno di questi. La sequenza ha uno scopo preciso e consiste in:

1. Riduzione e compressione delle immagini
2. Pulizia del codice
3. Compressione del codice
4. Attivazione della Cache
5. Opzioni del server

Teniamo presente che qui parliamo di interventi adatti alla maggior parte dei siti aziendali che sono relativamente semplici anche se corposi. Se avete un sito complesso invece è meglio affidare il lavoro ad uno specialista.

Allo stesso modo, è meglio affidare l’ottimizzazione ad uno specialista se non si conosce la materia o se non si ama sperimentare, oppure in presenza di un sito complesso o particolarmente difficoltoso la cui ottimizzazione richiede un vero e proprio lavoro di cesello sul codice.

1. Ridurre e comprimere le immagini

Durante la lettura della Waterfall sicuramente fra i file più pesanti avremo trovato dei file delle immagini, e questo sarà il nostro primo step di ottimizzazione, soprattutto se è compito nostro, come proprietari di un sito, di inserirvi i contenuti.

Le immagini sono uno dei fattori che influenzano maggiormente il peso di una pagina web a causa delle dimensioni dei file. In particolare le immagini Hero o gli slider, che di solito sono posti all’inizio della pagina, hanno una grande influenza sull’indicatore First Contentful Paint e meritano quindi una particolare attenzione.

Abbiamo trattato ampiamente l’argomento delle immagini per il web nell’articolo Tutto sulle immagini per il sito web, a cui vi rimandiamo per approfondire. In questo post ci limitiamo a indicare il metodo giusto per ottimizzare le immagini:

• Ridurre ogni immagine alle dimensioni che occuperà all’interno della pagina
• Comprimere il file il più possibile mantenendo una buona qualità
• Convertire le immagini, se necessario, nel formato più adatto

Per tutte queste operazioni possiamo usare gli stessi strumenti di fotoritocco che usiamo normalmente. Ci sono inoltre dei compressori dedicati, alcuni da installare sul computer, altri disponibili online. Solitamente i compressori sono anche in grado di convertire il formato grafico se opportuno.

Queste operazioni vanno svolte prima di caricare le immagini nel sito. Per una ulteriore compressione delle immagini possiamo installare un plugin apposito. I plugin migliori, oltre a ridurre e comprimere, adattano automaticamente le immagini alle giuste dimensioni e le servono nel nuovo formato WebP dove supportato.

Due plugin che abbiamo testato e che raccomandiamo, sono ShortPixel e Imagify. E’ importante però non lasciare a loro tutto il lavoro di riduzione e compressione, per non caricare troppo il nostro server e per risparmiare spazio disco.

2. Ripulire il codice

La fase di pulizia del codice consiste nel rimuovere quegli elementi caricati ma inutilizzati.

Questa operazione è di livello più tecnico ma ancora una volta ci vengono in aiuto strumenti che ci evitano di intervenire direttamente sul codice, come ad esempio il plugin Asset Cleanup che mostriamo in questo articolo. Un altro plugin che merita una citazione è l’ottimo Perfmatters.

Asset Cleanup aggiunge un pannello in coda ad ogni pagina pubblicata, nel quale mostra tutti i componenti caricati in quella pagina dal core WordPress, dal tema e dai plugin attivi, e permette di disattivare gli elementi non utilizzati.

La disattivazione è possibile solo nella pagina esaminata oppure in tutto il sito con l’eccezione della pagina esaminata.

Un esempio su tutti: come già detto prima, il plugin Contact Form 7 carica i suoi stili e script in tutte le pagine del sito. Con Asset Cleanup è possibile disattivare gli script e gli stili ovunque, ad eccezione delle pagine dove effettivamente verranno impiegati.

Oltre a questo, Asset Cleanup gestisce anche diverse impostazioni più tecniche per ottimizzare il codice, che vediamo tra poco.

Un vantaggio di Asset Cleanup è che dispone di una modalità di test che anticipa i risultati delle nostre ottimizzazioni senza modificare ciò che vedono gli utenti dall’esterno.

3. Ottimizzare il codice rimanente

Come detto prima, Asset Cleanup controlla anche impostazioni tecniche di ottimizzazione. Infatti, dopo aver ripulito il codice dai componenti inutilizzati possiamo ottimizzare il codice rimanente. Per questa operazione, oltre ad Asset Cleanup esistono molti plugin specializzati. Che cosa fanno?

In breve, ottimizzare il codice significa:

• comprimere il codice dei file di stile, degli script e volendo dello stesso codice html
• concatenare i file di stile e gli script, (ma questa operazione è sconsigliata se si utilizza un hosting moderno o, più precisamente, un hosting che serve le pagine attraverso HTTP/2.
• ritardare l’esecuzione degli script per dare precedenza al caricamento dei contenuti visibili dall’utente accelerando la fase “First Contentful Paint”
• ritardare il caricamento delle immagini non visibili above the fold. A partire da WordPress 5.5 questa funzione è inclusa nel core.

Tra i plugin di ottimizzazione, oltre ad Asset Cleanup, abbiamo testato i seguenti:

• Pagespeed Ninja
• Autoptimize
• Wp Rocket (fa ottimizzazione e cache, che spiego più avanti)
• SG Optimizer (riservato a chi ha hosting Siteground).

4. Attivare una Cache

Nei siti creati con CMS come WordPress, ogni volta che un utente richiede una pagina web avvengono alcune chiamate al relativo database. Queste chiamate possono appesantire il carico sul server e rallentare il caricamento delle pagine. Il compito della Cache è quello di salvare una copia statica di ogni pagina effettuando preventivamente le chiamate al database, e poi servire questa copia statica (più veloce) a chi la richiede.

Alcuni hosting forniscono anche un servizio di cache già configurato per le migliori prestazioni, così che dobbiamo solo assicurarci che sia attivo. In altri casi possiamo usare un plugin che svolge questo compito. Eccone alcuni testati qui in NUwebstudio:

• SG Optimizer (per Siteground)
• WP Fastest Cache
• WP Optimize
• WP Rocket 
• WP Super Cache

Alcuni plugin sono più semplici da configurare, altri richiedono maggiori conoscenze tecniche.

Per questo motivo raccomando sempre tre cose:

1. Prima di installare un plugin di cache è consigliabile aver ripulito e ottimizzato il codice, altrimenti anche la copia in cache sarà ingombrante e lenta
2. Meglio verificare se il proprio hosting fornisce questa opzione, e in caso positivo utilizzare quella per evitare di installare ulteriori plugin
3. La cache va configurata in base alle caratteristiche dell’hosting e del sito web. Una configurazione incompleta o incorretta non migliora la velocità del sito.

5. Impostazioni del server

Da ultimo possiamo utilizzare alcune ottimizzazioni del nostro hosting, ove disponibili. Queste non si attivano dalla bacheca WordPress, ma dal pannello di gestione dell’hosting:

• aggiornare la versione PHP 
• E attivare la compressione GZIP

Entrambe queste opzioni aumentano la performance del server e quindi la velocità di caricamento delle pagine. Se l’hosting le rende disponibili, sono vivamente raccomandate.

I risultati: un esempio interessante

In questo interessante esempio testato sulla home page di un sito semplice e non particolarmente lento, abbiamo dimezzato la metrica Largest Contentful Paint da 2,2 a 1 secondo, migliorato il Total Blocking Time di circa un terzo e mantenuto ottimo il Cumulative Layout Shift che però non è un misuratore di velocità. Abbiamo ottenuto questi risultati usando il metodo esposto in questa guida, senza peraltro poter intervenire sulle impostazioni dell’hosting.

Questi risultati sono stati testati con la simulazione della connessione cellulare 4G, la più diffusa in Italia.

Naturalmente i risultati che è possibile raggiungere dipendono dalla progettazione della pagina in questione: una pagina piena di slider, immagini grandi e animazioni raramente potrà raggiungere un tempo di caricamento veloce o anche accettabile. La progettazione del sito riveste quindi un’importanza fondamentale nei risultati di performance.

Conclusioni

Siamo arrivati in fondo a questa guida. Se avete letto fin qui avete capito che la lentezza delle vostre pagine vi fa perdere contatti, quindi clienti potenziali. Come porre rimedio alla cosa?

1. Siate consapevoli della performance del vostro sito: ricordate che i punteggi di performance rappresentano la qualità dell’esperienza utente. Testate quindi ogni pagina con gli strumenti di GTmetrix e di Google, misurate il TTFB (time to first byte) per capire la performance dell’hosting, misurate i Core Web Vitals e in particolare il LCP (Largest Contentful Paint) e il TBT (Total Blocking Time), rendetevi conto del peso totale della pagina e del numero di componenti caricati. Leggete la Waterfall, osservate quali componenti e quali immagini sono più pesanti o si caricano più lentamente
2. Riducete e comprimete le immagini
3. Disattivate i componenti inutili caricati nella pagina
4. Ottimizzate il codice rimanente con gli strumenti di compressione
5. Attivate la cache
6. Operate sulle impostazioni dell’Hosting, se potete.

Come abbiamo detto, questi sono i primi passi ma l’esperienza utente risulterà sicuramente migliorata.

Da questo lavoro potrebbe derivare qualche riflessione e suggerimento su come migliorare la progettazione delle vostre pagine per offrire un’esperienza di navigazione ricca e utile ma anche chiara e di semplice fruizione, che non sia basata esclusivamente sulla pura estetica.

One more thing…

Dopo tanti consigli, questo è davvero l’ultimo suggerimento:

Quando condividete il link al vostro sito, ad esempio nelle pagine social oppure nella firma di posta elettronica, indicate il link effettivo per rendere la navigazione al vostro sito più veloce.

Ho visto invece molte persone indicare il link al proprio sito come si faceva tempo fa, “www.esempio.it” mentre, ormai da anni:

• un sito può essere servito via http oppure https
• Il nome a dominio può essere o non essere preceduto da WWW.

Allora vi ricordate quando vi parlavo del Time To First Byte? in questo esempio, degli 0,9 secondi del tempo TTFB, quasi la metà sono dovuti ai reindirizzamenti (Status 301) dal dominio cercato a quello effettivo.

Vi invito quindi a controllare, nella Waterfall o semplicemente nella barra degli indirizzi del browser, qual è il link effettivo al vostro sito e a condividere sempre quello.

Fonti e approfondimenti

Google: The Need For Mobile Speed, 2016

Google: Timing for page experience

Foto: Digital Buggu da Pexels