WordPressIl contesto
Managed Server SRL è un’azienda italiana di hosting gestito e sistemistica Linux ad alte prestazioni. Il sito aziendale gira su WordPress con tema Astra e page builder Elementor, e su uno stack server curato: nginx con TLS, HTTP/2 e HTTP/3, Varnish come cache delle pagine, PHP-FPM e MariaDB, con Autoptimize per l’aggregazione di CSS e JavaScript. La home page è composta da 34 sezioni e circa 3.300 elementi del DOM.
Il caso è particolare: il sito era già veloce per gli utenti reali. L’obiettivo non era superare le Core Web Vitals, ma ottenere un punteggio di laboratorio coerente con l’esperienza reale, senza ricorrere a servizi di ottimizzazione che rimandano il JavaScript oltre la finestra di misura e fanno comportare la pagina in modo diverso durante i test. Il lavoro è documentato nel dettaglio nella cronaca dell’ottimizzazione pubblicata da Managed Server.
Cosa dicevano i dati
I dati sul campo del Chrome UX Report erano già ottimi: LCP 0,7 secondi, INP 73 millisecondi e CLS 0. PageSpeed Insights su mobile, invece, oscillava tra 76 e 86 punti, con First Contentful Paint tra 2,0 e 2,4 secondi, Largest Contentful Paint tra 3,8 e 5,3 secondi, Speed Index tra 3,3 e 5,0 secondi, Total Blocking Time tra 0 e 100 millisecondi e CLS a 0. Su desktop il punteggio era già tra 97 e 100.
La distanza tra campo e laboratorio si spiega con le condizioni della prova: un dispositivo mobile emulato con processore rallentato e rete lenta rende evidenti costi che gli utenti reali, con dispositivi e connessioni migliori, quasi non percepiscono. Sono però costi reali per la coda degli utenti più lenti, e per questo valeva la pena eliminarli.
La diagnosi
Le analisi con Lighthouse in locale, sul JSON grezzo di PageSpeed Insights e sulle tracce di Chrome DevTools hanno isolato poche cause, con un peso preciso:
- documento HTML pesante: 128 KB compressi, di cui 71 KB di SVG in linea nella sola home mobile, quasi un quarto del documento; una singola icona pesava circa 100 KB non compressi;
- ritardo di rendering dell’LCP tra 1.050 e 2.112 millisecondi: l’elemento principale era pronto, ma il browser lo disegnava tardi per il CSS bloccante e il lavoro di layout;
- JavaScript che forzava il layout di sezioni non visibili, come lo script che allarga le sezioni a tutta pagina;
- font e preload non ottimali: 14 facce latin-ext di Open Sans inutilizzate e un preload di un font sotto la piega che peggiorava l’LCP di 170 millisecondi.
Gli interventi sul server
- Microcache di nginx davanti a Varnish, con aggiornamento in background e copia precedente come riserva: meno richieste a Varnish e PHP-FPM e più resilienza;
- compressione spostata nel backend, eliminando 30-40 millisecondi di CPU sul frontend: Brotli 9 e Zstandard 15 per l’HTML, Brotli 11 e Zstandard 19 per i file di Autoptimize, che hanno una cache lunga;
- correzione di un errore intermittente di lettura tra nginx e il backend, presente in circa l’1,5% delle richieste e dovuto a connessioni keepalive scadute, risolto con
keepalive_timeout 0sul backend; - memoria di Varnish portata da 512 MB a 2 GB;
- riscaldamento della cache per 781 URL, due dispositivi e tre codifiche, 4.386 richieste in circa tre ore e un quarto, eseguite con calma: 24 HIT su 24 nelle verifiche a campione, con risposte tra 22 e 48 millisecondi.
Gli interventi sull’applicazione
- SVG fuori dal documento, la leva principale: le icone in linea sono state spostate in file separati, caricati quando servono, e l’HTML compresso è sceso da 128 a 62 KB;
- CSS critico per pagina e dispositivo, generato con Penthouse su 47 pagine in versione mobile e desktop, con JavaScript attivo per applicare le classi di Astra: da circa 130 KB a 55-60 KB;
content-visibility: autosulle sezioni sotto la piega, concontain-intrinsic-sizemisurata per ogni sezione e dispositivo, così da non generare spostamenti; il piè di pagina mobile, alto 4.400 pixel, esce dal rendering iniziale;- layout senza JavaScript: lo script di Elementor che allargava le sezioni è stato sostituito da CSS; delle 18 sezioni interessate, 15 erano già larghe quanto la finestra e 3 sono state risolte con
width: 100vwemargin-left: calc(50% - 50vw); - font: rimosse le facce inutilizzate, un’icona di Font Awesome da 10 KB sostituita da un SVG da 457 byte, preload mantenuti solo dove misurabilmente utili;
- JavaScript differito con misura: jQuery differito con un piccolo shim di compatibilità, rimossi wp-i18n e wp-hooks dove non usati, banner dei cookie, tooltip e chat caricati dopo, analytics nel rispetto del consenso, senza rinviare l’inizializzazione dei componenti visibili.
I risultati
Il primo ciclo di interventi, circa 20 ore di lavoro, ha portato il punteggio mobile a 98 con un LCP di 2,3 secondi e il ritardo di rendering dell’LCP da oltre un secondo a 130 millisecondi. Con le rifiniture successive, la misura attuale di PageSpeed Insights su mobile è di 100 punti:
| Metrica (laboratorio, mobile) | Prima | Dopo |
|---|---|---|
| Punteggio PageSpeed Insights | 76-86 | 100 |
| First Contentful Paint | 2,0-2,4 s | 1,2 s |
| Largest Contentful Paint | 3,8-5,3 s | 1,7 s |
| Total Blocking Time | 0-100 ms | 0 ms |
| Cumulative Layout Shift | 0 | 0 |
| Speed Index | 3,3-5,0 s | 1,8 s |
| HTML compresso | 128 KB | 62 KB |
I dati sul campo sono rimasti verdi, come prima. Il punto del caso è proprio questo: il punteggio ora descrive un sito realmente veloce, ottenuto riducendo il lavoro del browser e non spostandolo fuori dalla finestra di misura.
Come manteniamo il risultato
Il CSS critico va rigenerato quando cambia il layout di una pagina, e ogni nuova sezione sotto la piega richiede la sua misura di contain-intrinsic-size. Ogni modifica viene verificata con più esecuzioni di Lighthouse, perché una singola prova non basta a distinguere un miglioramento dal rumore, e i dati del Chrome UX Report restano il riferimento finale. Restano aperti alcuni punti volutamente rinviati, come un CSS critico limitato alla sola prima piega, che farebbe guadagnare 35-50 millisecondi al prezzo di un rischio di spostamenti, e l’allineamento delle metriche dei font sulla pagina dei prezzi.