Come velocizzare un negozio WooCommerce senza rompere il carrello

Un negozio lento perde vendite due volte: una volta sulla scheda prodotto, quando il visitatore se ne va prima che si carichi, e una volta al checkout, quando un carrello rotto o un campo di pagamento bloccato lo fa scappare. La maggior parte dei consigli sulle performance tratta un negozio come un blog. È esattamente così che i carrelli si svuotano, i prezzi risultano sbagliati e i pulsanti di pagamento smettono di rispondere.

Questa guida è la mappa. Mostra cosa si può ottimizzare su un negozio, cosa non va mai toccato, e rimanda alla guida dettagliata per ogni problema.

Un negozio sono due siti in uno

Il catalogo comprende la home page, le pagine di categoria e le schede prodotto. Ogni visitatore vede la stessa cosa, quindi queste pagine si possono mettere in cache, alleggerire e ritardare come qualsiasi altra pagina.

La transazione comprende il carrello, il checkout e l'account cliente. Ogni visitatore vede il proprio contenuto: i suoi articoli, il suo indirizzo, i suoi ordini. Queste pagine non vanno mai servite da una cache, e le ottimizzazioni che si basano su un'istantanea della pagina non si applicano a loro.

E in mezzo c'è un terzo stato: un visitatore che naviga nel catalogo con articoli nel carrello. La pagina sembra pubblica, ma l'header mostra il suo carrello. WooCommerce segnala quel visitatore con cookie come woocommerce_items_in_cart e wp_woocommerce_session_, e una cache di pagina corretta si fa da parte per lui.

Una cache di pagina che rispetta il carrello

La cache di pagina è il guadagno più grande su un negozio, e l'impostazione più pericolosa. Tre regole:

• Escluda le pagine transazionali: carrello, checkout e tutte le pagine dell'account. Servire un checkout dalla cache può mostrare a un cliente i dati di un altro.
• Bypassi la cache per i visitatori con un carrello o una sessione: altrimenti l'header mostra un carrello vuoto a chi ha appena aggiunto un prodotto, o il contatore del carrello di un altro visitatore.
• Tenga d'occhio le query string: i link add-to-cart, i parametri di tracciamento come utm_source o gclid, e i filtri. Ogni URL distinto può diventare un cache miss.

La trappola della geolocalizzazione. L'opzione «Geolocalizza (con supporto per la cache della pagina)» di WooCommerce aggiunge un parametro v agli URL perché ogni paese abbia la propria versione in cache. Se non le servono prezzi o tasse per paese, questa modalità frammenta la cache per niente. Se le servono, sappia che ogni pagina del catalogo esiste ormai in tante versioni quante sono le località.

Cookie impostati per niente. Un nuovo visitatore con il carrello vuoto non dovrebbe ricevere nessun cookie su una pagina del catalogo. Basta un solo header Set-Cookie perché la maggior parte dei CDN, Cloudflare compreso, rifiuti di mettere la pagina in cache, e perché molte cache di pagina si facciano da parte. I colpevoli abituali: un plugin che avvia una sessione WooCommerce per ogni visitatore (liste dei desideri, selettori di valuta, prodotti visti di recente), o un cookie contatore del carrello scritto anche quando il carrello è vuoto. Lo verifichi come un nuovo visitatore:

# Una pagina del catalogo, come nuovo visitatore con il carrello vuoto: non deve uscire nessuna riga.
curl -s -o /dev/null -D - https://your-store.com/product/any-product/ | grep -i "set-cookie"

Se torna un cookie, trovi il plugin che lo imposta e lo faccia aspettare finché il visitatore non aggiunge davvero qualcosa al carrello.

Cart fragments: la richiesta su ogni pagina

Il mini carrello nell'header viene tenuto aggiornato da una richiesta AJAX, wc-ajax=get_refreshed_fragments, inviata da wc-cart-fragments.js. Non viene mai messa in cache, quindi interroga PHP e il database a ogni visualizzazione di pagina in cui viene eseguita.

Da WooCommerce 7.8, lo script non viene più caricato su ogni pagina per impostazione predefinita: solo dove serve al widget classico del mini carrello. Molti temi lo caricano ancora ovunque. Controlli la scheda Network di una pagina del catalogo: se la richiesta parte su pagine senza mini carrello, limiti lo script alle pagine che ne hanno uno. Non lo rimuova semplicemente dove il mini carrello esiste, altrimenti il contatore del carrello smette di aggiornarsi.

Quando le ottimizzazioni fanno sparire il mini carrello o gli impediscono di aprirsi, la causa e la soluzione sono spiegate nella nostra guida sul mini carrello di WooCommerce.

Immagini dei prodotti: la parte più pesante del catalogo

• Miniature nelle griglie di categoria: WooCommerce genera diverse dimensioni; il browser sceglie quella giusta solo se l'attributo sizes corrisponde alla griglia. Un attributo sizes sbagliato fa scaricare ai telefoni le miniature pensate per desktop. Veda la nostra guida su srcset e sizes.
• Una priorità mal riposta: da WordPress 6.3, la prima immagine grande di una pagina riceve fetchpriority="high". Su una home page o una pagina di categoria, spesso è la prima miniatura prodotto di una griglia molto sotto la piega, che entra così in concorrenza con la vera immagine principale.
• L'immagine principale del prodotto è di solito il Largest Contentful Paint di una scheda prodotto. Non deve essere caricata in lazy load, e può cambiare tra mobile e desktop: la nostra guida sull'immagine LCP per dispositivo spiega come precaricare quella giusta.
• Gli script di gallerie, zoom e lightbox si caricano su ogni scheda prodotto. Sono buoni candidati per il ritardo, a patto che il pulsante di aggiunta al carrello e i selettori delle varianti continuino a funzionare.

CSS e JavaScript senza rompere il negozio

CSS alleggerito. Gli strumenti di used CSS rendono un solo stato della pagina. Su un negozio, molti elementi compaiono solo dopo un'azione: il mini carrello aperto, una variante selezionata, un errore di quantità, un campo per il codice sconto. I loro stili vengono rimossi. Come trovare e rimettere le regole mancanti è spiegato nella nostra guida sugli stili mancanti. E sulle pagine di carrello, checkout e account, non alleggerisca affatto il CSS: l'istantanea viene presa da utente non connesso, con il carrello vuoto, e perde tutto ciò che vede il cliente.

JavaScript ritardato. Non ritardi mai l'aggiunta al carrello, gli script delle varianti, gli script del checkout o i campi di pagamento (moduli della carta, pulsanti dei wallet): un campo di pagamento che aspetta una prima interazione è un ordine perso. Ritardi ciò che non serve per acquistare: chat, widget di recensioni, pop-up, pixel di marketing. Il metodo per trovare cosa ha rotto un ritardo è nella nostra guida sul ritardo di JavaScript, e un banner di consenso che si carica tardi è trattato nella nostra guida sui banner di consenso.

Spostamenti del layout. Le griglie di prodotti che caricano le immagini senza dimensioni, i badge delle offerte e le stelle delle recensioni che compaiono tardi, e le barre di aggiunta al carrello fisse spostano tutte la pagina. Cause e soluzioni sono nella nostra guida sul CLS.

Le pagine che non vanno mai in cache

Il carrello e il checkout sono sempre generati da PHP per ogni visitatore, quindi la loro velocità è la velocità pura del server e del database. È lì che si vedono l'hosting, la versione di PHP e lo stato di salute del database. Alcuni punti da verificare:

• Le versioni recenti di WooCommerce salvano gli ordini in tabelle dedicate (High-Performance Order Storage), molto più veloci del vecchio salvataggio basato sui post nei negozi con molti ordini.
• Le tabelle delle azioni pianificate e le sessioni cliente scadute possono diventare molto grandi su un negozio con molto traffico; ne verifichi le dimensioni e la pulizia.
• Ogni plugin che si aggancia al carrello o al checkout viene eseguito a ognuna di queste richieste: calcolatori di spedizione, upsell, controlli antifrode. Misuri il checkout con e senza di loro su una copia di staging.

Misurare il negozio, non solo la home page

• Testi una pagina di categoria e una scheda prodotto su mobile, da utente non connesso, come nuovo visitatore.
• Testi di nuovo con un articolo nel carrello: la cache deve farsi da parte e la pagina deve restare veloce.
• Segua l'intero percorso d'acquisto dopo ogni modifica: aggiunta al carrello, cambio di variante, applicazione di un codice sconto, arrivo al passaggio di pagamento. Lo faccia su una copia di staging o in modalità test del suo gateway di pagamento: un ordine di prova su un negozio in produzione è un ordine vero.
• Legga i dati sul campo, non solo il punteggio di laboratorio, come spiegato nella nostra guida sui dati di laboratorio e sul campo, e cambi un'impostazione alla volta, come nel nostro metodo per ottimizzare senza rompere nulla.

Con Mantys Core

In sintesi

• Tracciare prima il confine: il catalogo si ottimizza a fondo, carrello, checkout e account non vanno mai messi in cache né alleggeriti.
• Bypassare la cache di pagina per i visitatori con un carrello, e tenere d'occhio query string e geolocalizzazione.
• Un carrello vuoto non deve ricevere nessun cookie: basta un solo Set-Cookie perché il CDN non metta la pagina in cache.
• Caricare i cart fragments solo dove un mini carrello attivo ne ha bisogno.
• Dimensionare bene le immagini dei prodotti, mantenere l'immagine principale in caricamento immediato e correggere la priorità delle miniature nelle griglie.
• Non ritardare mai gli script di aggiunta al carrello, delle varianti, del checkout o di pagamento; ritardare invece il livello marketing.
• Testare l'intero percorso d'acquisto, in staging o in modalità test, dopo ogni modifica.