Come velocizzare WordPress: prima misura, poi ottimizza

Ecco come velocizzare un sito WordPress nella pratica: misura prima, poi ripara in ordine di impatto. Tempo di risposta del server e page cache, poi l'immagine hero pesante, poi CSS e JavaScript render-blocking, poi il database e il carico plugin.

La maggior parte dei siti lenti viene rallentata da due o tre di questi fattori, non da tutti assieme. Avvia PageSpeed Insights sul template più lento del tuo sito, annota quale sia l'elemento Largest Contentful Paint, e procedi lungo questa lista finché il numero non diventa verde.

Partite da una misura di base, altrimenti ottimizzerete la cosa sbagliata

Ottimizzare senza una baseline è superstizione. Prima di toccare un plugin, registrate tre numeri sul template più lento del vostro sito (di solito un articolo con immagine hero grande, oppure una pagina prodotto WooCommerce): Largest Contentful Paint, Interaction to Next Paint e Time to First Byte. Testate con impostazioni mobile, perché è lì che si vede il divario tra «veloce sulla mia macchina» e «veloce per i clienti dei vostri clienti».

I target sono pubblici, non leggenda. La documentazione di Google su LCP tratta 2,5 secondi o meno come buono al 75esimo percentile delle visite reali. INP deve restare sotto 200 millisecondi e lo shift di layout sotto 0,1. Scriveteli su un foglietto accanto allo schermo.

Le metriche da lab come Lighthouse vi danno un banco ripetibile. I dati reali dal Chrome User Experience Report, in cima a PageSpeed Insights, vi dicono cosa hanno ottenuto veramente i visitatori. Quando i due disaccordano, fidate dei dati reali e usate la misurazione da lab per trovarne la causa.

Marginalia: questo ordine di lavoro vale per WordPress 6.5 e successivi. Gli install più vecchi hanno più roba da fixare prima che qualsiasi cosa qui abbia senso.

Sistemi prima di tutto: hosting, PHP e Time to First Byte

Ogni trucco front-end poggia sulla prima risposta. Se l'HTML impiega 1,5 secondi ad arrivare, nessuna compressione di immagini salva il vostro LCP. Il Time to First Byte è il numero che espone un host debole, un ramo PHP obsoleto o una pagina ricostruita da capo a ogni richiesta.

Verificate tre cose in quest'ordine. Lanciate un ramo PHP attualmente supportato, perché ogni release costa misurabilmente meno per richiesta della precedente. Confermate che l'host offra una cache object persistente (Redis o Memcached), perché elimina le letture ripetute dal database per options, menu e query. E guardate al piano stesso: un server condiviso con cento vicini vi limiterebbe esattamente quando il traffico sale.

Se gestite molti siti client, è qui che l'hosting gestito guadagna la sua commissione. Una piattaforma che raggruppa hosting, cache e un target di performance toglie una categoria intera di divinazione. 10Web è un esempio che ospita WordPress su Google Cloud e mira a un score PageSpeed oltre 90 fin da subito, ragionevole default per una piccola agenzia senza dedicato ops.

Evitate la tentazione di comprare un piano più grande prima di aver abilitato la cache. Aggiornare hardware per servire pagine non cachate significa pagare più per fare lo stesso lavoro inutile più veloce.

Attivate la cache full-page e verificate che effettivamente colpisca

WordPress ricostruisce ogni pagina con PHP e MySQL ogni volta che qualcuno la richiede. Una page cache salva l'HTML finito e serve quel file al posto. Per un sito soprattutto in lettura come un blog, un sito brochure o portfolio, questo cambio solo spesso muove il TTFB da secondi a decine di millisecondi.

Scegliete un livello di page cache, uno solo. Impilare una cache a livello host, un plugin cache e una cache CDN senza sapere quale una serve la richiesta è come finire a debuggare contenuti stantii per un pomeriggio intero. Chiedete al vostro host cosa fornisce già prima di installare nulla.

Poi verificate che la cache colpisca. Aprite il pannello rete del browser, ricaricate una pagina pubblica due volte, e leggete gli header di risposta. La maggior parte delle cache segnalano un hit o miss, e molti aggiungono un valore age. Se vedete solo miss, la vostra cache è bypassata da un cookie, una query string o uno stato loggato, e l'«ottimizzazione» è décoration.

I negozi richiedono attenzione extra. Carrello, checkout e pagine account non vanno mai cachate, e i siti WooCommerce di solito dipendono da un plugin cache che conosca quelle esclusioni. Sbagliare le esclusioni e i clienti vedono i carrelli gli uni degli altri, che è un problema peggiore di una pagina lenta.

Riducete il peso dell'immagine hero, il colpevole solito di LCP

Sulla maggior parte delle pagine WordPress lente, l'elemento LCP è un'immagine: un hero, una featured image o un banner full-width. Questo rende il peso dell'immagine la causa singola più comune di uno score che fallisce. Un JPEG 4000×pixel esportato dritto da una fotocamera, visualizzato in una colonna 1200×pixel, spedisce parecchi volte più byte di quello che il layout può usare.

Procedete nella pipeline dell'immagine in quest'ordine:

• Ridimensionate alla dimensione più grande che il layout davvero mostra, non alla dimensione che il designer ha esportato.

• Servite WebP o AVIF, entrambi gestiti da WordPress core da parecchie release.

• Lasciate che core generi le varianti responsive srcset invece di hard-codare un file grande.

• Non lazy-loadate l'hero. Core ha saltato lazy loading sulla prima immagine di contenuto e aggiunto fetchpriority="high" da WordPress 6.3, quindi controllate che il vostro tema o plugin non l'abbia annullato.

• Date a ogni immagine width e height espliciti così il browser riserva lo spazio e lo shift di layout resta vicino a zero.

Sotto il fold, il lazy loading è corretto e gratis. Sopra il fold, è un ritardo auto-inferto, e è l'errore che appare più spesso dopo che qualcuno installa un plugin «lazy load tutto».

Per l'e-commerce, il peso viene spesso dalla fotografia di prodotto. Produrre visivi coerenti, right-sized alla fonte è più economico che comprimere cinquanta file oversized dopo, e una piattaforma IA di product photography come Klayn trasforma una foto di prodotto in una serie di scene, così potete pianificare le dimensioni prima che nulla raggiunga la media library.

Tagliate CSS e JavaScript render-blocking alla fonte

Una volta che server e hero sono sistemati, il prossimo ritardo è ciò che il browser deve scaricare ed eseguire prima di dipingere. Ogni stylesheet nell'head blocca il rendering. Ogni script sincrono blocca il parsing. I page builder e i temi multi-purpose sono i soliti colpevoli, perché spediscono stili e script per ogni feature indipendentemente dal fatto che la pagina li usi o no.

I block theme hanno un vantaggio strutturale qui. Core carica gli stili per un block solo quando quel block appare sulla pagina, così un post ordinario non paga per Query Loop o Gallery. Questo è uno dei motivi per cui un lean Full Site Editing theme parte avanti rispetto a un tema legacy con uno slider bundled e un icon font bundled. I page builder classici possono colmare il gap, ma solo se disabilitate i moduli che non usate.

Divi è un buon test case. Divi 5 è stato ricostruito su un'architettura più moderna e spedisce centinaia di moduli, che è esattamente perché le sue impostazioni di performance, come CSS dinamico e CSS critico, meritano uno sguardo attento su ogni sito che consegnate.

Passi pratici, in ordine di rischio:

• Differite JavaScript non-critico e caricate script di terze parti (widget chat, analytics, tag manager) dopo l'interazione dove potete.

• Inline il CSS critico per il contenuto sopra il fold e caricate il resto async, se lo strumento cache lo supporta.

• Self-host dei font, subsettate, e usate font-display: swap così il testo è visibile mentre il font carica.

• Rimuovete o rimpiazzate qualsiasi plugin che carica uno script grande su ogni pagina per una feature usata su uno solo.

• Testate dopo ogni cambio. Il JavaScript deferral aggressivo è la causa numero uno di un menu rotto o un pulsante checkout morto.

Potate lo stack plugin e lasciate respirare il database

Il numero di plugin è una metrica scadente. Quello che conta è cosa ogni plugin carica sul front-end e cosa fa su ogni richiesta. Un plugin scritto male con una query pesante può costare più di trenta ben-comportati. Usate Query Monitor su una copia staging per vedere query lente, il plugin che le ha triggerate, e gli script che ognuno enqueues.

Poi guardate alla tabella options. Plugin rimossi anni fa lasciano spesso righe dietro marcate come autoload, il che significa che WordPress le legge in memoria su ogni richiesta. Site Health inizia a segnalare autoload options quando raggiungono all'incirca 800 KB. Se vedete quell'avviso, auditate le righe più grandi e pulite i resti di plugin che non lanciate più.

Post revisions, expired transients e metadata orfano aggiungono peso col tempo, ma trattate questo come manutenzione piuttosto che fix headline. Backup prima, lanciate la pulizia su staging, e misurate di nuovo. Il guadagno è spesso modesto su un sito piccolo e significativo su un negozio con anni di ordini e sessioni.

Usate una CDN e lo speculative loading per l'ultimo tratto

Una rete di distribuzione di contenuti serve file statici, e spesso l'HTML cachato anche, da una posizione vicino al visitatore. Per un'audience diffusa tra regioni, come un sito in lingua araba letto dal Golfo e dal Nord Africa mentre il server origin siede in Europa, la latenza risparmiata non è cosmetica. La distanza è un costo, e una CDN è il modo più economico per accorciarla.

WordPress 6.8 ha aggiunto qualcosa che non costa nulla: speculative loading. Usa la Speculation Rules API per prefetch di una pagina mentre il visitatore inizia a cliccare, così la prossima navigazione si sente quasi istantanea. Il team core riporta che i siti che usavano la versione plugin precedente hanno migliorato il loro LCP pass rate circa dell'1,9% alla mediana, come descritto nella nota developer di WordPress 6.8 su speculative loading. È piccolo per sito, e viene senza configurazione.

Core lo abilita per visitatori non loggati su siti con pretty permalinks. Se un plugin usa action URLs che cambiano stato su una GET ordinaria, escludete quei path con il filtro wp_speculation_rules_href_exclude_paths prima di rendere l'impostazione più eager. Restate sul default finché non avete controllato i vostri carrelli e la vostra analytics.

Quando smettere di tuning, e quale fix lanciare primo

C'è un punto dove più tuning di WordPress costa più di quanto rende. Se un negozietto spende ogni mese combattendo esclusioni cache, conflitti plugin e upgrade hosting, la domanda onesta è se lo stack si adatta al business. Una piattaforma ospitata come WiziShop scambia una certa flessibilità per un negozio la cui velocità è il problema di qualcun altro, e vale la pena prezzarla contro le ore che fatturate per manutenzione.

Per siti di contenuto, agenzie e progetti RTL, WordPress rimane lo strumento giusto, e tutto quello sopra vale la pena di farlo. Il punto è sapere da quale lato della linea ciascun client siede.

Fate la vostra misura di base sul template più lento oggi. Se il TTFB è sopra 800 millisecondi, cominciate con hosting, PHP e cache. Se il TTFB è salubre ma LCP fallisce, aprite la waterfall e trovate l'hero image. Se entrambi passano e l'interazione è lenta, guardate JavaScript e lo stack plugin. Quale dei tre la vostra pagina peggiore fallisce?