WooCommerceIl contesto
Miloon, il negozio online di ZVM SRL, è un e-commerce specializzato in cosmetica coreana: skincare, make-up e cura del corpo di una trentina di marchi, con un catalogo di circa 2.400 prodotti venduto in tre lingue (italiano, francese e inglese). Il negozio gira su WooCommerce con un tema commerciale basato su page builder e un mega menu che organizza i prodotti per esigenza della pelle, ingrediente e marchio.
Come molti negozi cresciuti in fretta, nel tempo si erano accumulate funzioni aggiunte una alla volta: lista dei desideri, filtri AJAX, programma a punti, badge promozionali, lista d’attesa per i prodotti esauriti, recensioni verificate, notifiche push, barra degli avvisi, pagamento a rate e una dozzina di tag di marketing gestiti da Google Tag Manager. Nessuna di queste era superflua per il business; il problema era il modo in cui venivano caricate.
Cosa dicevano i dati
Il traffico arriva per oltre l’80% da smartphone, spesso da campagne social, e i dati CrUX da mobile raccontavano un sito lento proprio dove conta: LCP a 4,4 secondi, INP a 410 millisecondi e CLS a 0,22 al 75° percentile. Le pagine prodotto e le categorie superavano le soglie di tutte e tre le metriche; la home, pesante di slider promozionali, era la peggiore per LCP.
Il punteggio di laboratorio oscillava molto tra un test e l’altro e non spiegava da solo il problema: per questo abbiamo affiancato ai dati CrUX il monitoraggio degli utenti reali (RUM) con attribuzione delle metriche, così da sapere quale elemento era l’LCP, quale interazione era lenta e cosa si spostava.
La diagnosi
In due settimane di analisi sono emerse cause diverse per ciascuna metrica, sia lato server sia lato applicazione:
- TTFB alto e irregolare: 1,3 secondi al 75° percentile. La cache di pagina veniva scavalcata da un cookie di sessione impostato a ogni visitatore, anche senza nulla nel carrello; il database aveva oltre 4 MB di opzioni caricate a ogni richiesta e centinaia di migliaia di azioni programmate già completate.
- LCP ritardato: l’immagine principale era la prima slide di un carosello inizializzato in JavaScript, caricata in lazy load e senza priorità, dopo 38 fogli di stile e più di 140 script.
- INP da interazioni pesanti: apertura del mega menu, aggiunta al carrello e filtri delle categorie attivavano lunghi task del thread principale, aggravati da pixel e widget di terze parti eseguiti tutti al caricamento.
- CLS da elementi iniettati: barra degli avvisi, badge delle recensioni, banner dei cookie e badge promozionali comparivano dopo il primo rendering, spingendo in basso il contenuto.
Gli interventi sul server
Il primo lavoro è stato rendere la risposta del server veloce e prevedibile, perché ogni millisecondo di TTFB si somma a LCP.
- Aggiornamento da PHP 7.4 a PHP 8.3 con OPcache dimensionata sul codice reale e JIT disattivato dopo i test.
- Cache di pagina a livello di web server con regole di esclusione basate sui cookie del carrello e della sessione cliente, non su qualunque cookie: i visitatori anonimi ricevono sempre la pagina in cache.
- Object cache persistente con Redis per ridurre le query ripetute su prodotti, varianti e traduzioni.
- Pulizia del database: opzioni caricate a ogni richiesta da 4,1 MB a 0,6 MB, sessioni scadute e azioni programmate completate rimosse con una routine periodica.
- HTTP/3, compressione Brotli e intestazioni di cache corrette per immagini, font e file statici.
Gli interventi sull’applicazione
Sul front-end l’obiettivo era mantenere tutte le funzioni di marketing, cambiando solo il momento e il modo in cui si caricano.
- Nella home il carosello è stato sostituito da un’immagine principale statica, servita in AVIF e WebP con
srcset, precaricata e confetchpriority="high"; le altre promozioni sono scese sotto la piega. - Font ospitati in locale, ridotti ai soli pesi usati e con metriche di ripiego allineate, per evitare sia il testo invisibile sia lo spostamento al cambio del font.
- Script e stili dei plugin caricati solo dove servono: la lista dei desideri e la lista d’attesa nelle pagine prodotto, i filtri AJAX nelle categorie, il pagamento a rate nel carrello e nel checkout. Sei plugin non più usati sono stati rimossi.
- Tag di marketing riorganizzati in Google Tag Manager: quelli non necessari al primo rendering partono dopo il caricamento o alla prima interazione, nel rispetto del consenso raccolto dal banner dei cookie.
- Mega menu reso lato server e aperto con CSS, filtri delle categorie con richieste raggruppate e aggiornamento del DOM limitato alla sola griglia dei prodotti.
- Spazio riservato in anticipo per barra degli avvisi, badge delle recensioni e badge promozionali, così nessun elemento sposta il contenuto dopo la comparsa.
I risultati
I dati CrUX sono una media mobile di 28 giorni: abbiamo quindi confrontato la finestra precedente agli interventi con quella chiusa quattro settimane dopo l’ultimo rilascio, sempre da mobile e al 75° percentile.
| Metrica (mobile, p75) | Prima | Dopo |
|---|---|---|
| TTFB | 1,3 s | 0,4 s |
| LCP | 4,4 s | 2,3 s |
| INP | 410 ms | 180 ms |
| CLS | 0,22 | 0,04 |
Tutte e tre le Core Web Vitals sono rientrate nella fascia “buona” su mobile e la valutazione CrUX dell’origine è passata da “non superata” a “superata”. Nello stesso periodo il tasso di conversione da smartphone è cresciuto, ma la stagionalità delle promozioni non permette di attribuirlo ai soli interventi di performance: per questo non lo usiamo come risultato del progetto.
Come manteniamo il risultato
Un e-commerce cambia ogni settimana: nuove campagne, nuovi plugin, nuovi tag. Per non tornare indietro abbiamo lasciato attivo il monitoraggio RUM con avvisi sulle soglie delle Core Web Vitals, un controllo Lighthouse automatico prima di ogni rilascio e una breve lista di regole condivise con il team marketing su immagini, banner e nuovi script. Ogni mese rivediamo insieme i dati e le eventuali regressioni.