In un sito editoriale, una pagina lenta costa lettori. In un negozio online costa ordini, e il collegamento è molto più diretto. Uno studio di Deloitte realizzato con Google nel 2020, su decine di siti di diversi settori, ha rilevato che un miglioramento di appena un decimo di secondo nei tempi di caricamento da mobile si associava, nel retail, a un aumento delle conversioni di circa l’8%. Non è una legge universale, ma conferma ciò che chi gestisce un e-commerce osserva ogni giorno: la velocità non è un dettaglio tecnico, è una voce del conto economico.
WooCommerce è la piattaforma e-commerce più diffusa nel mondo WordPress, ed è anche una di quelle in cui le Core Web Vitals si perdono più facilmente. Non perché sia lenta in sé, ma perché combina le caratteristiche di un CMS con quelle di un’applicazione: pagine pubbliche memorizzabili, pagine personali che non lo sono, sessioni, carrelli, calcoli di prezzi e spedizioni, script di pagamento e un ecosistema di plugin molto ricco. In questo articolo seguiamo il percorso d’acquisto, pagina per pagina, per capire dove si rallenta e cosa fare.
Le pagine di categoria: la vetrina
La pagina di categoria è spesso il primo contatto con il negozio, soprattutto per chi arriva da Google o da una campagna. È una griglia di prodotti con immagini, prezzi, badge e filtri, e i suoi problemi tipici riguardano LCP e CLS.
Per LCP, l’elemento più grande è quasi sempre la prima immagine di prodotto o un banner di categoria. Le regole sono quelle viste per l’LCP: le immagini della prima riga non devono avere il caricamento differito, quella principale può ricevere fetchpriority="high", e tutte devono essere servite nel formato e nella dimensione giusti. Un catalogo con migliaia di foto caricate dai fornitori, spesso da diversi megabyte, è il caso ideale per la conversione automatica in WebP o AVIF e per dimensioni responsive corrette.
Per CLS, i colpevoli ricorrenti sono i filtri a faccette che compaiono dopo il caricamento, i badge di sconto o di disponibilità inseriti via JavaScript, i prezzi aggiornati dopo il primo disegno da plugin di valute o di listini, e i banner promozionali che spingono la griglia verso il basso. Ogni elemento che arriva dopo deve avere uno spazio riservato fin dall’inizio, come spiegato nell’articolo sul CLS. I plugin di filtro più pesanti meritano un’attenzione particolare anche sul lato server: le query sulle tassonomie e sugli attributi dei prodotti, su cataloghi grandi, possono far salire sensibilmente il TTFB delle pagine filtrate, che raramente sono in cache.
La scheda prodotto: dove si decide
La scheda prodotto è la pagina in cui l’utente decide se comprare, ed è spesso la più pesante del negozio: galleria con zoom e lightbox, variazioni, recensioni, prodotti correlati, widget di pagamento rateale, pixel pubblicitari, a volte video. L’immagine principale è quasi sempre l’elemento LCP: deve essere nell’HTML iniziale, non generata da uno slider in JavaScript, e deve avere dimensioni esplicite. Le immagini successive della galleria possono essere caricate in modo differito, lo zoom solo all’interazione.
Le variazioni meritano un discorso a parte. Per i prodotti variabili, WooCommerce inserisce nella pagina i dati di tutte le variazioni, in un attributo che il JavaScript legge per aggiornare prezzo, immagine e disponibilità quando l’utente sceglie taglia o colore. Oltre una certa soglia, 30 variazioni per impostazione predefinita, i dati non vengono più inseriti e ogni scelta genera una richiesta al server. In entrambi i casi l’interazione può diventare lenta: con molti dati, per il lavoro sul thread principale; con le richieste, per l’attesa della risposta. È uno dei punti in cui l’INP di un negozio peggiora più spesso, soprattutto da smartphone di fascia media, ed è anche il momento in cui l’utente è più vicino all’acquisto.
Il pulsante Aggiungi al carrello è l’altra interazione critica. Se il clic avvia una richiesta AJAX, aggiorna il mini carrello, apre un pannello laterale e invia eventi a più piattaforme pubblicitarie, tutto nello stesso compito, l’utente può attendere diverse centinaia di millisecondi senza alcun riscontro visivo. La regola è dare subito un riscontro, come un pulsante che cambia stato, e spostare il resto dopo il disegno.
Il carrello e il problema della cache
Per un visitatore anonimo, le pagine di un negozio possono essere servite dalla cache di pagina, con un TTFB di poche decine di millisecondi, come abbiamo visto parlando di TTFB e cache di pagina. Ma appena l’utente aggiunge un prodotto al carrello, WooCommerce imposta cookie di sessione, come woocommerce_items_in_cart, e la maggior parte delle configurazioni di cache smette di servire pagine memorizzate a quell’utente, su tutto il sito. È una scelta prudente, per evitare di mostrare a qualcuno il carrello di un altro, ma ha una conseguenza paradossale: gli utenti più preziosi, quelli che hanno già scelto qualcosa, navigano sulla versione più lenta del negozio.
Carrello, checkout e area cliente non possono essere messi in cache per definizione. Il loro TTFB dipende interamente da PHP e dal database, e qui fanno la differenza la versione di PHP, una cache degli oggetti come Redis, la pulizia delle opzioni caricate automaticamente, la gestione delle sessioni e l’archiviazione degli ordini ad alte prestazioni (HPOS), che WooCommerce usa per impostazione predefinita sui nuovi negozi e che sposta gli ordini in tabelle dedicate.
I cart fragments
C’è poi un meccanismo che per anni ha penalizzato i negozi WooCommerce anche con la cache attiva: i cosiddetti cart fragments. Per aggiornare il mini carrello nell’intestazione, uno script invia una richiesta AJAX a ?wc-ajax=get_refreshed_fragments, che non può essere memorizzata e richiede l’esecuzione completa di WordPress. La pagina arriva dalla cache in pochi millisecondi, ma subito dopo il server deve comunque lavorare.
Dalla versione 7.8, WooCommerce carica questo script solo dove è effettivamente usato il widget classico del mini carrello, e il mini carrello a blocchi usa un’API diversa e più leggera. Molti temi e plugin, però, lo riattivano su tutte le pagine. La verifica è semplice: nel pannello Network dei DevTools, su una pagina qualsiasi, si cerca la richiesta get_refreshed_fragments. Se compare anche quando il carrello è vuoto, è un costo che si paga a ogni pagina vista, e che durante una promozione con molto traffico può saturare le risorse PHP proprio quando servono per carrello e checkout.
Il checkout: l’ultimo metro
Il checkout è la pagina con il valore più alto per visita e spesso quella meno curata sul piano delle prestazioni. È un modulo con molti campi, ciascuno dei quali può innescare validazioni, calcoli di spedizione e tasse, aggiornamenti del riepilogo; e ospita gli script dei metodi di pagamento, che caricano a loro volta iframe e risorse da domini esterni.
- Aggiornamenti a ogni campo. Nel checkout classico, modificare indirizzo, CAP o metodo di spedizione avvia una richiesta di aggiornamento del riepilogo. Se il server è lento, ogni modifica si traduce in un’attesa visibile. La velocità di questa richiesta dipende dal TTFB delle pagine dinamiche, e quindi dagli stessi interventi descritti sopra.
- Script di pagamento ovunque. Molti plugin di pagamento caricano i propri script su tutte le pagine del sito, anche dove non servono, per mostrare messaggi promozionali o pulsanti di pagamento rapido. Limitarli a scheda prodotto, carrello e checkout, dove servono davvero, alleggerisce tutto il resto.
- Campi e completamento automatico. Completamento degli indirizzi, validazione della partita IVA, controlli in tempo reale: utili, ma ciascuno aggiunge lavoro al thread principale durante la digitazione. Vanno misurati con l’INP, non solo provati a mano su un computer veloce.
- Checkout a blocchi. Il checkout basato sui blocchi, predefinito nelle installazioni recenti, gestisce gli aggiornamenti tramite l’API dedicata del negozio e in genere si comporta meglio del checkout classico, ma va verificata la compatibilità di tutti i plugin che intervengono sul checkout prima della migrazione.
Le terze parti del commercio elettronico
Un negozio online tende ad accumulare più codice di terze parti di qualsiasi altro sito: pixel di più piattaforme pubblicitarie, strumenti di remarketing, widget di recensioni, chat, notifiche di acquisti recenti, pagamenti rateali, programmi fedeltà, test A/B. Ognuno ha una motivazione commerciale, e ognuno sottrae tempo al thread principale. Il metodo per governarli è quello descritto nell’articolo sugli script di terze parti: inventario, misura del costo, rimozione di ciò che non viene più usato, caricamento differito di ciò che non serve subito. In un e-commerce c’è un vantaggio in più: il valore di ogni strumento si può confrontare con il fatturato che contribuisce a generare, e quindi con il costo in conversioni che il suo peso comporta.
Misurare per modello di pagina
Un negozio ha pochi modelli di pagina e molte pagine per modello: una home, alcune decine di categorie, migliaia di prodotti. Le Core Web Vitals vanno quindi lette per gruppo. Search Console raggruppa già le URL simili; un sistema di monitoraggio degli utenti reali permette di andare oltre, separando i dati per modello, per dispositivo e, soprattutto, per stato dell’utente: anonimo, con prodotti nel carrello, cliente collegato. È spesso l’unico modo per vedere che il negozio è veloce per chi entra e lento per chi sta comprando.
Il passo successivo è collegare questi dati alle metriche di business. Confrontare il tasso di conversione delle sessioni con LCP o INP buoni con quello delle sessioni con valori scarsi, sullo stesso modello di pagina, dà una misura concreta di quanto vale migliorare. È anche il modo più efficace per stabilire le priorità: un intervento sulla scheda prodotto con un effetto misurabile sulle conversioni vale più di un punteggio perfetto su una pagina istituzionale.
Da dove partire
- Cache e TTFB. Cache di pagina per gli anonimi, cache degli oggetti per le pagine dinamiche, PHP aggiornato, database pulito, HPOS attivo. Senza questa base, il resto rende poco.
- Richieste non memorizzabili. Verificare i cart fragments e ogni altra richiesta AJAX che parte a ogni pagina.
- Immagini del catalogo. Formati moderni, dimensioni corrette, nessun caricamento differito per le immagini sopra la piega, priorità all’immagine principale della scheda prodotto.
- Interazioni del percorso d’acquisto. Variazioni, aggiunta al carrello, aggiornamento delle quantità, campi del checkout: misurare l’INP e dare riscontro immediato.
- Terze parti e plugin. Limitare gli script alle pagine in cui servono, rimuovere ciò che non porta valore, differire il resto.
- Navigazione interna. Una volta sistemate le basi, Speculation Rules tra categoria e prodotto e compatibilità con la back/forward cache rendono istantanei i passaggi più frequenti, avanti e indietro tra elenco e scheda.
In sintesi
In WooCommerce le Core Web Vitals si perdono lungo tutto il percorso d’acquisto: LCP e CLS nelle categorie, LCP e INP nella scheda prodotto, TTFB e INP in carrello e checkout. Il nodo più sottovalutato è la cache: gli utenti con un carrello attivo, i più vicini all’acquisto, spesso navigano senza cache di pagina e subiscono tutto il peso di PHP e del database, a cui si aggiungono richieste non memorizzabili come i cart fragments.
La strada è misurare per modello di pagina e per stato dell’utente, collegare le metriche alle conversioni e intervenire in ordine: prima la base server, poi le richieste superflue, le immagini, le interazioni e le terze parti. In un negozio online ogni decimo di secondo ha un valore economico misurabile, e sapere dove si perde è il primo passo per recuperarlo.
