Indice dei contenuti dell'articolo:
L’importanza della velocità di un sito web è ormai indiscussa, soprattutto dopo l’avvento dei Google Core Web Vitals, che hanno confermato eloquentemente che la velocità di un sito è fattore di ranking.
Con questa consapevolezza sarebbe fuorviante, inappropriato, inopportuno e controproducente non soffermarsi su una tematica così importante, in grado di decretare il fallimento del tuo sito (e della tua persona), oppure un business proficuo e gratificante in grado di garantirti uno stile di vita agiato e soddisfacente.
Siamo seri, se sei in prima pagina e hai un sito veloce e scattante, farai affari. Diversamente se il tuo sito è lento e non è posizionato, il tuo sito sarà solo un costo, una spesa, un passivo e non una macchina da soldi.
Detto e puntualizzato il concetto sopra, chiediamoci se veramente abbiamo la più pallida idea di cosa significa avere un sito veloce. La maggior parte degli addetti ai lavori che oggi parlando di velocità non hanno la più pallida idea di cosa raccontino ai loro clienti e persino a loro stessi.
Non vogliamo peccare di presunzione, ma sempre più spesso si vedono hoster e sistemisti occuparsi solo della loro branca, così come sviluppatori e developer disinteressarsi completamente delle implicazioni sistemistiche sul risultato finale.
In altri contesti, ed altri articoli che trovate online invece ci si limita a consigliare un Hosting WordPress piuttosto che l’altro, spesso con conflitti di interessi imbarazzanti come recensioni false e provvigioni non dichiarate.
Da parte nostra invece basta sapere che WordPress era lento prima dell’avvento dei Core Web Vitals, e WordPress è lento anche dopo di essi. Semplicemente abbiamo avuto delle metriche di misurazione che hanno permesso anche all’uomo comune di comprendere cosa vada bene e cosa non vada bene.
Tuttavia questa voglia di semplificare, con un banale punteggio, non ha permesso di comprendere facilmente cosa sia veloce e cosa sia lento in un sito WordPress, e pertanto ci troviamo addetti ai lavori che non hanno capito nulla su come si ottimizzi un sito Web e su come si debba necessariamente prestare alla componente Server, se si vuol partire bene e finire meglio.
Noi parliamo per ovvi motivi commerciali di WordPress lento, ma sia chiaro che i concetti teorici che andremo ad esprimere sono applicabili ed adattabili a qualsiasi altro CMS o linguaggio server side.
WordPress Lento. Comprendere il problema scomponendolo
E’ stato sempre inutile nella vita partire dal risolvere un problema senza averne prima capito l’origine e le cause. In questo articolo vogliamo separare la problematica parlando della velocità della generazione della pagina HTML e della velocità che il browser impiega nel ricomporre le risorse che vede indicate nella pagina HTML.
Un po’ come dire che per realizzare un piatto culinario esotico, dobbiamo prima ordinare gli ingredienti, aspettare che ci vengano consegnati, e poi solo successivamente iniziare con l’elaborazione della ricetta che produrrà il piatto esotico pronto e finito da gustare.
Problemi lato server e TTFB.
E’ facile capire che se la realizzazione di una ricetta elaborata impiega di suo mezz’ora, ma il cercare gli ingredienti, e portarli in cucina ci occupasse mezza mattinata, il tempo di realizzazione del piatto equivale al tempo che abbiamo impiegato a trovare e comprare gli ingredienti sommato al tempo di realizzazione della ricetta.
A volte insomma, il tempo di recupero dell’HTML lato server può essere molto più lungo del tempo che il browser impiega a scaricare le risorse e ricomporle proprio come se fosse un puzzle.
Il problema del recupero dell’HTML è quello che viene misurato tecnicamente nel valore del Time To First Byte.
Questo valore che abbiamo ampiamente discusso nell’articolo di cui trovate il link sopra, è quello che si può brevemente definire con velocità server, influenzato da codice PHP non performante, query lente al database MySQL, ed inefficienza di tutto quello realizzato sopra a questa architettura PHP + MySQL.
Che possa essere un plugin, un tema, una funzione, uno snippet di codice, la problematica per ciò che è realizzato in PHP e MySQL sarà sempre ricercabile in PHP e MySQL. Che siano plugin, temi, funzioni, pezzi di codice, questo lo sappiamo noi, che abbiamo voluto astrarre dei concetti architetturali con delle sovrastrutture organizzative, ma a livello server side, a livello di interprete PHP non cambia nulla, ne è dato sapere se quello che sta girando sia un modulo, un plugin, un tema o altro. Codice PHP è codice PHP, query MySQL è query MySQL.
Fine dei discorsi, fine delle amenità varie e della “filosofia informatica”, utile solo ad ingrassare le parcelle dei consulenti e diminuire il portafogli dei clienti e committenti.
Queste problematiche vanno ovviamente individuate e profilate con operazioni di debug e profilazione, l’utilizzo di slow query log nel debug delle query lente, ecc… ecc…
L’utilizzo di hardware performante, efficiente, a bassa latenza ed alto throughput è sicuramente un valore aggiunto coadiuvante nel raggiungimento degli obiettivi preposti, ovvero avere un tempo di elaborazione il più basso possibile.
Una query che impiega 100ms invece di 200ms è una query performante il doppio, che alla fine della filiera della generazione della pagina HTML da restituire al browser ci permetterà di avere un sito veloce forse il doppio, o forse no, ma comunque sicuramente più veloce.
Non parliamo di plugin ? Non parliamo dei 10 segreti per velocizzare WordPress ?
Come velocizzare WordPress in 10 trucchi ?
Non esistono “plugin” miracolosi, non esistono “modi” segreti, esistono invece competenze ed approcci nonchè combinazioni di procedure e task che migliorano ogni aspetto del vostro stack software e server.
Siamo ormai umanamente stanchi di vedere “elenchi” di cose da fare scritte da gente che non ha mai installato una distribuzione linux in vita loro, che non hanno mai scritto del codice in linguaggio C o che non conoscono il funzionamento del protocollo TCP/IP, magari proponendovi la separazione di server applicativo e server DB magari con connessione ad un gigabit.
Siamo stanchi che veniate truffati da gente che ha in portfolio siti del salumiere sotto casa, e che magari nel raggiungere il fatidico 90 di punteggio su Google PageSpeed Mobile, ha compromesso il corretto funzionamento del pixel di Facebook e del tracciamento delle campagne, magari fregandosene del TTFB e della latenza del DNS estremamente alta.
Di certo vi imbatterete in individui che miglioreranno anche sensibilmente la velocità ed il TTFB utilizzando plugin di Cache come WordPress SuperCache, W3 Total Cache o plugin commerciali come WP Rocket ad esempio e dimostrazione alla mano, vi sentirete anche magari pienamente soddisfatti.
Pochi si spingerebbero oltre a questi plugin, non essendo appunto sistemisti competenti. Andare a ricompilare il kernel con i giusti valori di tuning a livello TCP/IP, il giusto supporto a livello webserver come ad esempio il supporto di TCP BBR , il supporto della compressione Brotli, o 0-RTT con il supporto Early data, ed un cache statica lato server come Varnish Cache in grado di lavorare egregiamente anche con traffico proveniente dai social network.
Pertanto otterrete probabilmente un buon risultato ma non il migliore, e considerando la competizione sempre più agguerrita per posizionarsi nei primi risultati non ha alcun senso a ricorrere alle mezze misure.
Problemi lato client, problemi lato browser e rendering HTML
Ora che siamo in possesso dell’HTML della pagina che vogliamo visualizzare, dobbiamo iniziare a scaricare le risorse contenute in essa. Immaginiamo che questa pagina HTML, sia una classica Homepage bella lunga, con centinaia di risorse e di immagini, di cui alcune nell’header, alcune nello slideshow iniziale, alcune invece nel corpo centrale del testo e molte altre nel footer finale.
Quale sarebbe opportuno iniziare a caricare subito nell’immediato ? Ovviamente quelle che vedremo per prima e dunque, le parti inerenti all’header ed al menù, lo slideshow e solo seguentemente elementi di immagine del contenuto che andremo a leggere (forse) o del footer, ammesso che abbiamo interesse a proseguire nella lettura completa fino ad arrivare al footer.
E’ qui che entra in gioco approcci come il Critical CSS, il lazy loading delle risorse, la rimozione del CSS e dei JS non utilizzati, nonchè il garantire il miglior peso possibile per le risorse, nonchè una importante efficienza lato rete e networking, aspetti questi ampiamente trattati nella sezione dei Core Web Vitals.
Questi aspetti vanno normalmente visti dagli sviluppatori che tuttavia non riescono spesso a colmare le problematiche sopra descritte lato server e dunque la ricetta migliore è quella di unire sviluppatori e sistemisti competenti alla risoluzione delle problematiche di velocità del sito.
Diffidate sempre dai classici approcci “Installi un plugin, fai 3 click e hai risolto”. Non è così che funziona e rischiate di fare più danni che altro, o quanto meno pensare di aver fatto bene per poi non rendervi conto che magari il traffico che arriva da Facebook o da Instagram o dalle campagne Google vi taglia la Cache come un ferro arroventato in un panetto di burro e i valori pessimi di navigazione dell’utente vengono inviati a Google che li utilizza per generare e stilare la reportistica sui dati CRUX dei Core Web Vitals che verranno giudicati insufficienti e dunque verrete penalizzati o quanto meno non premiati.
Conclusioni
Se avete un sito WordPress lento e volete velocizzarlo, dovete necessariamente conseguire i due obiettivi sopra indicati : avere un server che restituisca HTML nell’ordine di 200 – 300ms al massimo; che questo HTML e risorse annesse come JS e CSS siano strutturate in modo da avere il minimo delle informazioni necessarie al rendering della pagina, il minimo dello spazio occupato (compressione efficace), e che il markup sia progettato col fine di scaricare nell’immediato le risorse che dobbiamo far vedere per prima (ad esempio Critical CSS).
Soddisfare entrambi i requisiti vi darà un vantaggio importante sia a livello di usabilità utente e dunque User Experience, nonchè vantaggi a livello SEO essendo ormai la velocità di un sito un fattore di indicizzazione.
