Migliorare le prestazioni di WordPress è un’attività piuttosto articolata, per certi versi noiosa, ma assolutamente essenziale.
LETTURA CONSIGLIATA
Spesso pensiamo che le prestazioni siano importanti solo dal punto di vista dell’utente che utilizza il sito e anche se questo aspetto è sicuramente vitale, non possiamo dimenticare i benefici che ne possiamo trarre da un punto di vista SEO.
Per spiegarti come ottimizzare le prestazioni di un sito web, ti racconto come ho lavorato su un sito che ho preso in gestione e per il quale, oltre alle normali attività di manutenzione, sono incaricato della gestione marketing.
Cosa sono le prestazioni di un sito web
Istintivamente tendiamo ad accostare il concetto di prestazione a quello di velocità. In realtà le cose sono un po’ più complesse.
Google, per esempio, valuta le prestazioni dei siti web utilizzando il tool LightHouse, il quale suddivide la valutazione in quattro macro aree:
- Performance
- Accessibilità
- Best Practice
- SEO
Ognuna di queste quattro componenti è importante e se per Google è uno dei modi per valutare il ranking da assegnare ai siti web, per gli utenti finali saranno indicatori (percepiti ma non conosciuti) della navigabilità.
Per assegnare il punteggio globale per ciascuna categoria, Lighthouse utilizza più valutazioni, le quali daranno luogo ad altrettanti punteggi.
Personalmente, credo che questo sia, almeno a oggi, il modo più efficace di parlare di prestazioni tecniche. Potremmo parlare anche di altri tipi di prestazione (semantica, persuasiva, ecc…) ma oggi non siamo qui per questo.
Cosa sono i Core Web Vitals
A partire da maggio 2021, Google ha inserito i Core Web Vitals tra i fattori di ranking del suo algoritmo. Ciò significa che ottenere buoni punteggi su queste metriche può influire positivamente sul posizionamento in SERP delle pagine del sito web.
Le metriche che vengono incluse tra i Core Web Vitals sono tre:
- LCP – Largest Contenful Paint: indica il tempo che impiega il sito web a rendere disponibile (utilizzabile) l’elemento più largo che viene visualizzato all’interno dell’Above The Fold della pagina. Vengono prese in considerazione solamente immagini, video o elementi di testo.
- FIP – First Input Delay: indica il tempo che impiega il server per rispondere a un’azione dell’utente (per esempio il click su un link);
- CLS – Cumulative Layout Shift: indica di quanto si muove il layout mentre la pagina è ancora in fase di caricamento.
Mentre LCP e FIP sono misurati in secondi o millisecondi e quindi sono metriche temporali, CLS è una metrica spaziale, che viene misurata sviluppando un coefficiente di movimento.
Tutti i Core Web Vitals sono migliorativi quando sono bassi.
Come eseguire un test con Lighthouse
Per creare un report Lighthouse su una pagina di un sito web puoi utilizzare Google Page Speed Insight oppure, utilizzando i DevTools di Chrome (e derivati), puoi accedere alla tab Lightouse.
Tra i due report non c’è differenza di contenuto, tuttavia mentre Google Page Speed Insight può analizzare solamente a contenuti di libero accesso, con DevTools e Lighthouse puoi prendere in considerazioni anche pagine accessibili solo agli utenti loggati o appartenenti a siti di staging.
Tieni inoltre presente che cache ed estensioni di Chrome possono interferire con le prestazioni delle pagine o cambiarne l’aspetto.
Nessun problema con Google Page Speed Insight, mentre se utilizzi Lighthouse, è molto importante disabilitare la cache (trovi una checkbox nella tab Network dei DevTools) e utilizzare una tab in incognito con tutte le estensioni disattivate.
Quando si svolgono queste attività è molto importante valutare le metriche più importanti del sito (es. frequenza di rimbalzo, pagine visitate per ogni sessione, tasso di conversione nel caso di un ecommerce, ecc…) prima e dopo le modifiche apportate. Ti consiglio quindi di appuntarti data e tipo di interventi svolti, in modo da non dimenticartene e avere un riferimento preciso durante le successive fasi di analisi.
Come organizzare l’ottimizzazione
Come ti ho anticipato, i risultati di un report Lighthouse non ti parlano del sito, bensì di una pagina. Ciò significa che per portare a termine il lavoro, dovremo fare almeno un test per ogni tipologia di pagina presente.
Nel mio caso, il sito ospita:
- post e archivi relativi
- prodotti e archivi relativi
- pagine statiche realizzate con Elementor
- pagine statiche che utilizzano un template di pagina dedicato
- pagina Whishlist generata da un plugin
- pagine carrello, checkout e ordine completato
- pagine del profilo utente
Come ti anticipavo poco sopra, non è necessario lavorare su ogni singola pagina del sito, tuttavia sarà bene testare un campione di elementi per ogni tipologia di elemento.
Discorso a parte naturalmente per le pagine statiche, poiché possono essere molto diverse l’una dall’altra e quindi dovranno essere prese in considerazione separatamente.
In ogni caso non ti preoccupare. Mano a mano che procederai, noterai come gran parte dei problemi che risolverai miglioreranno a cascata anche le tipologie di pagina ancora da trattare. In poche parole, il grosso del lavoro sarà da svolgere durante le prime ottimizzazioni, poi inizierà la discesa (o almeno, diminuirà la pendenza della salita!).
Nel mio caso, decido di iniziare dall’ottimizzazione della scheda prodotto visto che sicuramente è uno degli elementi più importanti per un ecommerce.
La situazione iniziale
Come risulta evidente, i principali problemi del sito sono legati alle performance. In ogni caso, tutti i Core Web Vitals superano il massimo consentito e ottengono punteggi da matita rossa.
La prima cosa su cui voglio concentrarmi è il Total Blocking Time, cercando di migliorarlo eliminando tutte le risorse di blocco non necessarie.
Il sito infatti utilizza Elementor oltre a diversi altri plugin che accodano fogli di stile su tutte le pagine, senza preoccuparsi della loro effettiva utilità. Le schede prodotto, per fare un esempio, non utilizzano il page builder, eppure CSS e Script sono comunque caricati.
Javascript e CSS possono bloccare il caricamento del DOM. Ad esempio: quando il parser legge un tag che fa riferimento a un CSS esterno, il parsing viene bloccato in attesa di risolvere la richiesta per quella risorsa. Siccome il CSSOM, al contrario del DOM, non è incrementale, prima di passare all’istruzione successiva è necessario che tutto il foglio di stile venga processato. Questo perché uno stile potrebbe essere dichiarato e poi sovrascritto all’interno dello stesso file (ad esempio utilizzando la funzione @media).
Prima di cominciare
WordPress è un CMS molto user-friendly e occupa una fetta importante del suo mercato. Questo è sicuramente positivo, perché può vantare su una community molto ampia che rilascia, possiamo dire ogni giorno, temi e plugin che possono arricchire le funzionalità native.
Il problema tuttavia è che non sempre sono sviluppate non dico bene, ma almeno decentemente. Questo comporta che oltre a un carico considerevole sul server, si abbiano diversi problemi con le dimensioni delle pagine che lievitano e una gestione delle risorse non propriamente ottimale.
Ma come se non bastasse, anche i plugin più diffusi possono dare problemi. Prendiamo Elementor. È uno dei visual builder più famosi e in sé lavora molto bene, offrendo anche a un profano la possibilità di creare pagine molto curate.
Tuttavia istanzia tutti i propri stili e script su ogni pagina del sito web, a prescindere che sia stato utilizzato per la sua costruzione oppure no. Un bel problema.
Inoltre, se andiamo a vedere il codice HTML della pagina, noteremo un’alberatura del DOM molto più complessa di quanto ci si aspetterebbe, altro aspetto che va a peggiorare gli score Lighthouse.
Per quanto riguarda le istanze di script e stili possiamo intervenire con Asset CleanUp Pro, e lo vedremo tra pochissimo, ma la semplificazione e l’ottimizzazione del codice è un problema che resta da affrontare manualmente cercando quando possibile di evitare in toto l’uso di un visual builder a favore della scrittura manuale dei contenuti di pagina.
Giusto per capirci, nell’immagine qui sotto puoi vedere le prestazioni della stessa pagina (stesso hosting, stessa struttura, stesse immagini). A sinistra ho utilizzato Elementor, a destra ho scritto il codice HTML.
Asset CleanUp Pro
Impostazioni globali
Una volta installato il plugin possiamo lavorare ad alcune ottimizzazioni globali che già da sole possono aiutarci a migliorare sensibilmente le prestazioni del sito.
Per prima cosa assegno ad ACP il compito di minificare tutti i fogli di stile e gli script. Il sito su cui sto lavorando utilizza il protocollo HTTP/2 quindi non è necessario (anzi, potrebbe essere controproducente) combinare i file per ridurre le chiamate.
Decido inoltre di rendere inline i file CSS con dimensioni inferiori ai 3kb in modo da ridurre il più possibile l’overhead e di usare il defer per gli stili che vengono caricati all’interno del <BODY> delle pagine.
ACP consente di deferire anche i CSS caricati nell'<HEAD>, tuttavia, almeno in questo caso, attivando questa opzione andavo ad aumentare di molto il layout shift, meglio di no.
Per quanto riguarda gli script invece ho optato per una soluzione leggermente più drastica, decidendo di spostarli tutti quanti nel <BODY> in modo da ridurre al massimo le risorse di blocco.
Oltre a quanto già riportato, ho disabilitato su tutto il sito le emoji e le Dashicons nel frontend del sito qualora la toolbar di WordPress non sia visibile (e per inciso ho aggiunto un piccolo script in modo che resti visibile solo agli amministratori del sito).
Da ultimo, ho ripulito il più possibile il codice delle pagine HTML rimuovendo diversi TAG inutili che WordPress parcheggia nel codice senza porsi troppe domande a riguardo (ad esempio: versione del CMS, link tag delle Rest API, ecc…).
Impostazioni sulla scheda prodotto
Prima di dedicarti ai lavori di fino, il mio consiglio è di sgrossare e per farlo in questo caso dobbiamo fare in modo che vengano caricati solamente gli script e i fogli di stile necessari alla pagina in questione.
Con Asset CleanUp Pro possiamo scegliere quali risorse bloccare e quali consentire per ogni tipo di post e pagina. Inoltre, possiamo andare ancora più a fondo, facendo in modo che alcuni plugin vengano disattivati quando l’URI della pagina matcha con una RegEx che impostiamo.
Prima di iniziare il lavoro vero e proprio, conviene abilitare la modalità Test (puoi trovarla nella tab Settings). In questo modo le modifiche che apportiamo saranno visibili solamente agli amministratori e non rischi di compromettere la navigazione per tutti gli utenti.
Vado quindi alla tab CSS & JS Manager > Custom Post Types, seleziono Woocommerce > Product e una volta selezionato un prodotto che utilizzo come test, inizio rimuovendo dalla coda di caricamento tutte le risorse che certamente non vengono utilizzate sulle pagine prodotto.
Se un plugin non è assolutamente necessario (nel mio caso, come ti dicevo, Elementor non è utilizzato sulle schede prodotto) posso utilizzare la tab Plugin Manager per fare in modo che tutto il plugin non venga caricato per alcuni tipi di pagina.
Una volta eliminati tutti gli script e i plugin sicuramente non necessari, inizio a fare qualche test per individuarne altri, concentrandomi maggiormente su quelli più pesanti.
Terminata la selezione, mi occupo di impostare correttamente i parametri async e defer per tutti gli script necessari. Inoltre posso impostare il preload asincrono dei fogli CSS, in modo da non aumentare il tempo di blocco.
È un lavoro piuttosto lungo, quasi tre ore. Ma alla fine sono piuttosto soddisfatto dei risultati. Verifico che tutto funzioni correttamente, disabilito la modalità di Test e quindi ripeto l’audit Lighthouse sulla scheda prodotto che ho ottimizzato.
Ancora molto lontani dalla meta, ma quasi tutte le metriche sono migliorate ed è già un ottimo risultato.
Ottimizzazione degli assets
Non puoi cercare di ottimizzare un sito web senza occuparti delle immagini. Non voglio perderci la testa, quindi almeno per il momento opto per le funzionalità offerte da SiteGround Optimizer. Attivo la compressione delle immagini e, soprattutto, abilito la possibilità di servire immagini WebP, molto più leggere e performanti rispetto alle classiche PNG.
Oltre a questo, deregistro diverse dimensioni che non utilizzo in modo da evitare di generare tantissime thumbnail inutili che occupano solamente spazio su disco. Non è un’ottimizzazione strettamente legata alle prestazioni, tuttavia è importante perché ci permette di risparmiare davvero un sacco di spazio.
Ottimizzazione del codice
Cerco sempre di farmi un’idea del codice che viene eseguito per generare una pagina e per quanto questo tipo di ottimizzazioni portino solitamente a risparmi molto contenuti, ritengo che sia buona norma intervenire anche in questo senso.
Nel caso del sito che stavo analizzando avevo notato due tipi di problemi: il primo un errore in console piuttosto banale. Uno script cercava di utilizzare un oggetto senza prima controllare che quell’oggetto esistesse.
Lato PHP invece c’erano diverse porzioni di codice aggiunte alla scheda prodotto. Alcune non più utili dal momento che le funzioni incaricate di recuperare i dati da mostrare restituivano array vuoti e altre ottimizzabili.
Un piccolo esempio: un ciclo for con una condizione $i < count($items). Il problema di questa forma è che la funzione count viene eseguita a ogni iterazione del ciclo e a meno che le istruzioni contenute nel blocco modifichino effettivamente la lunghezza dell’array, è uno spreco di risorse del tutto inutile.
C’erano inoltre alcuni controlli inutili e diverse chiamate a get_post_meta che potevano essere risparmiate semplicemente assegnando il valore di ritorno a una variabile.
Oltre alle modifiche prestazionali, mi occupo anche di fixare — per quanto possibile — i problemi che vanno a peggiorare i punteggi di SEO, Accessibility e Best Pratices, anche queste molto importanti e spesso trascurate.
Cache e CDN con CloudFlare
Ora che le risorse che vengono istanziate sulla scheda prodotto sono state ottimizzate, passiamo a lavorare su caching e CDN.
Ci sono diversi plugin che possono aiutarti a gestire questi aspetti, tuttavia siccome il sito su cui sto lavorando è ospitato su SiteGround, la scelta a mio avviso migliore è utilizzare il plugin ufficiale dell’hosting (SG Optimizer) il quale, oltre a essere molto semplice da utilizzare, è anche certamente ben ottimizzato per il server in questione.
Oltre alla cache, SG Optimizer mi permette di gestire anche Cloudflare, che va comunque attivato dal pannello di amministrazione dell’hosting.
Una volta completati questi passaggi, provo a ripetere il test.
Conclusione
Il lavoro sulla scheda prodotto è sostanzialmente completato. Ovviamente si potrebbe ancora cercare di limare qualcosa, ma devi capire che spesso il lavoro di ottimizzazione ha una curva di difficoltà esponenziale, per cui è molto più semplice guadagnare i primi 80 punti di quanto non lo sia guadagnare gli ultimi 10.
È quindi buona norma mirare a un risultato funzionale, per quanto non perfetto. In ogni caso per una scheda prodotto che partiva da un indice di Performance a 15, arrivare a 92 è un balzo considerevole e posso sicuramente esserne soddisfatto.
Ora il lavoro va svolto sugli altri tipi di post e sulle pagine statiche. Ma ormai dovresti sapere come si fa, quindi… buona ottimizzazione!
