CDN per WooCommerce: guida alla configurazione

Un negozio WooCommerce funziona bene dietro un CDN quando l'edge serve i file statici e le pagine del catalogo viste dagli ospiti, mentre tutto ciò che è personale o transazionale va direttamente al tuo server: carrello, checkout, area account, visitatori con un carrello attivo, chiamate AJAX e API e callback dei pagamenti. Impostare bene queste condizioni di bypass, mantenere aggiornati i prezzi con svuotamenti mirati della cache e testare un ordine vero sono la parte principale del lavoro. Per il resto delle prestazioni del negozio (plugin di cache, database, attività in background) leggi la guida su come velocizzare WooCommerce.

Due modi per mettere un CDN davanti a un negozio

• CDN per gli asset. Un plugin riscrive gli URL di immagini, CSS e JavaScript verso un hostname CDN, mentre ogni pagina arriva ancora dal tuo server. Il rischio è basso, perché nessuna pagina viene condivisa tra clienti, ma la parte più lenta, cioè la generazione dell'HTML, resta com'è.
• Proxy per l'intero sito. Ogni richiesta passa dall'edge, HTML compreso, quindi una scheda prodotto in cache non arriva mai a PHP o al database. È lì che si trovano i guadagni maggiori, ed è lì che WooCommerce richiede attenzione: l'edge è una cache condivisa, e basta una regola sbagliata perché il cliente B veda il carrello del cliente A.

Il resto di questa guida riguarda il secondo tipo di configurazione. Se stai ancora confrontando i fornitori, la guida su come scegliere un CDN per WordPress tratta i criteri di scelta.

Cosa può mettere in cache l'edge senza rischi

"Solo per gli ospiti" è la parte fondamentale. Lo stesso URL di un prodotto può apparire diverso a un cliente loggato o a chi ha articoli nel carrello, e l'edge deve saper distinguere queste richieste.

Query string

I parametri di tracciamento come utm_source creano una voce di cache separata per ogni variante, quindi una campagna può trasformare in silenzio gli hit in miss. I parametri che cambiano il contenuto, come orderby o i filtri della navigazione a strati, hanno invece legittimamente bisogno di voci proprie.

Cosa deve sempre arrivare al tuo server

Pagine

La guida di WooCommerce alla configurazione dei plugin di cache (in inglese) indica Carrello, Checkout e Il mio account come pagine da escludere. Questo comprende tutto ciò che sta sotto, come /checkout/order-received/ dopo il pagamento e le pagine di ordini e indirizzi sotto /my-account/. Se hai rinominato queste pagine o gestisci un negozio multilingua, contano ogni slug e ogni versione linguistica.

WooCommerce qui ti aiuta: nelle pagine carrello, checkout e account invia header Cache-Control che vietano la cache. Un CDN che rispetta gli header dell'origine non le memorizzerà. Verifica che un plugin di cache o di sicurezza sul tuo sito non sovrascriva quegli header.

Cookie

Gli header coprono solo quelle tre pagine. Una scheda prodotto vista da qualcuno con il carrello pieno ha header normali e memorizzabili, ma può mostrare il suo mini carrello, quindi il bypass deve dipendere anche dai cookie. Quelli elencati da WooCommerce sono:

• woocommerce_cart_hash e woocommerce_items_in_cart (impostati quando c'è qualcosa nel carrello)
• wp_woocommerce_session_* (la sessione del cliente)
• woocommerce_recently_viewed e store_notice[notice id] (rilevanti solo se usi il widget dei prodotti visti di recente o l'avviso del negozio)

Aggiungi il cookie di login di WordPress wordpress_logged_in_*, così clienti loggati e staff ricevono sempre pagine aggiornate.

Endpoint

• le richieste ?wc-ajax=, usate per aggiungere al carrello, applicare codici sconto e aggiornare il checkout
• /wp-admin/, admin-ajax.php e wp-login.php
• i link con ?add-to-cart=
• la Store API (in inglese) sotto /wp-json/wc/store/v1/, che alimenta Carrello e Checkout basati sui blocchi. Le sue risposte riflettono la sessione del cliente corrente.
• la REST API autenticata sotto /wp-json/wc/v3/, usata dalle integrazioni con ERP, gestione magazzino e marketplace
• i callback dei pagamenti (ne parliamo più sotto)

Il mini carrello nelle pagine in cache

Con un tema classico, il contatore del mini carrello su una pagina in cache viene compilato in un secondo momento dallo script cart fragments, che chiama ?wc-ajax=get_refreshed_fragments e conserva il risultato nel session storage del browser. I temi a blocchi caricano invece i dati del carrello con richieste proprie, che allo stesso modo devono restare fuori dalla cache. La pagina si può mettere in cache proprio perché la parte personale arriva con una richiesta separata e non in cache. Se quella richiesta finisce in cache, ogni visitatore vede lo stesso contatore del carrello. Se i cart fragments ti servano davvero lo spiega la guida alla velocità di WooCommerce.

Prezzi, valute e posizioni

Una cache condivisa funziona solo se tutto ciò che cambia una pagina è visibile nell'URL o gestito da un bypass. Cookie e indirizzi IP sono invisibili per una chiave di cache basata sull'URL.

• Geolocalizzazione. Con la semplice opzione "Geolocate" come posizione predefinita del cliente, i prezzi vengono generati sul server per il paese del visitatore, quindi dietro una cache condivisa è il paese del primo visitatore a decidere cosa vedono tutti. La documentazione sulle impostazioni generali di WooCommerce (in inglese) descrive per questo caso l'opzione "Geolocate (with page caching support)": geolocalizza tramite AJAX e aggiunge agli URL un parametro ?v=. Ogni variante diventa una voce di cache a sé, quindi aspettati più miss.
• Selettori di valuta. Molti salvano la valuta scelta in un cookie. Se quel cookie non attiva un bypass, una pagina in cache mostra la valuta in cui è stata generata la prima volta. Preferisci un selettore che mette la valuta nell'URL o carica i prezzi lato client, e controlla la sua documentazione sulla cache.
• Prezzi specifici per cliente. I prezzi all'ingrosso o per ruolo di solito vengono mostrati solo agli utenti loggati, che saltano comunque la cache. Assicurati che la visualizzazione dei prezzi dipenda davvero dal login e non da un cookie separato.

Mantenere aggiornati magazzino e prezzi

Scegli la durata dell'HTML in base a quanto ti costa una pagina obsoleta. Una pagina di contenuto può restare in cache per ore; una scheda prodotto con un magazzino che si muove in fretta dovrebbe scadere prima o essere svuotata a ogni modifica.

• Modifiche a un singolo prodotto. Svuota la cache dell'URL del prodotto, delle pagine di categoria in cui compare, della pagina del negozio e della homepage se il prodotto è in evidenza lì.
• Importazioni e sincronizzazioni con l'ERP. Fai in modo che il job di importazione svuoti tramite l'API del CDN la cache degli URL esattamente per i prodotti che ha modificato, invece di aspettare che le pagine scadano.
• Saldi programmati. Un prezzo scontato che parte a mezzanotte non arriva da solo su una pagina in cache. Programma uno svuotamento per quel momento.
• Modifiche su tutto il sito. Dopo un aggiornamento del tema o una promozione su tutto il negozio, svuota tutto, poi preriscalda le categorie principali e i prodotti più venduti.

Se lo svuotamento avvenga in automatico dipende dalla tua configurazione. In ogni caso, dopo una modifica controlla a campione gli header di risposta.

Callback dei pagamenti e firewall

I fornitori di pagamento confermano i pagamenti chiamando il tuo negozio da server a server. La Payment Gateway API di WooCommerce (in inglese) gestisce queste chiamate tramite URL wc-api, nella forma /wc-api/<callback>/ o /?wc-api=<callback>. Molti plugin di gateway registrano anche route di webhook sotto /wp-json/. Se un callback fallisce, gli ordini restano "in attesa di pagamento" anche se il cliente ha pagato.

Queste richieste non devono mai finire in cache e, cosa altrettanto importante, non devono mai essere bloccate:

• Regole per paese. I server di un fornitore possono chiamare da un paese che blocchi o sottoponi a challenge su tutto il sito.
• Challenge CAPTCHA. Un server non può risolvere un CAPTCHA, quindi limita le regole di challenge ai percorsi usati dalle persone.
• Rate limit. I webhook possono arrivare a raffiche, per esempio dopo una serie di rimborsi. Dimensiona di conseguenza i limiti per IP.
• Regole anti-bot. Callback e integrazioni con l'ERP sono client automatici. Controlla che i set di regole anti-bot non li segnalino.

Un piano di test per il passaggio

Eseguilo su un ambiente di staging se puoi, e di nuovo subito dopo il cambio dei nameserver (vedi cambiare i nameserver senza downtime).

1. Scheda prodotto da ospite. Richiedila due volte. La seconda risposta dovrebbe essere un cache hit.
2. Carrello e checkout. Da ospite devono mostrare un bypass o un miss, mai un hit.
3. Carrello attivo. Aggiungi un prodotto e ricarica una scheda prodotto. Non deve essere un hit e il mini carrello deve mostrare il tuo articolo.
4. Due browser. Riempi il carrello nel browser A. Il browser B deve vedere ancora un carrello vuoto.
5. Cliente loggato. Naviga nel negozio e nell'area account. Nulla deve arrivare dalla cache condivisa.
6. Pagamento di prova. Completa un ordine nella sandbox o in modalità test del gateway e verifica che lo stato dell'ordine vada oltre "in attesa di pagamento". È la prova che il callback è arrivato.
7. Svuotamento. Cambia un prezzo, svuota la cache dell'URL e controlla che compaia il nuovo prezzo.

Per il controllo degli header, invia la richiesta una volta senza cookie e una volta con un cookie del carrello:

curl -sI https://shop.example.com/product/example/ | grep -i -E "cache|age"
curl -sI -H "Cookie: woocommerce_items_in_cart=1" https://shop.example.com/product/example/ | grep -i cache

La seconda richiesta non deve tornare come hit. Quando i test funzionali sono superati, confronta la velocità prima e dopo con uno strumento come corewebvitals.page, che mostra i dati sul campo degli utenti reali e un test di laboratorio per mobile e desktop.

Come ti aiuta fast.site

fast.site è un proxy per l'intero sito che si mette davanti al tuo hosting WooCommerce attuale. Tieni il tuo hosting, aggiungi il dominio nella dashboard e punti i nameserver a fast.site. Da quel momento fast.site gestisce il tuo DNS, quindi tutti i record esistenti, compresi i record MX per le email del negozio, devono essere presenti nella zona DNS di fast.site.

Fast Edge Cache™ serve dall'edge le schede prodotto, le categorie e le pagine di contenuto viste dagli ospiti, nelle regioni incluse nel tuo piano, e un cache HIT non raggiunge mai il tuo server. fast.site rispetta gli header Cache-Control della tua origine, e le risposte private o dinamiche come carrello, checkout e sessioni degli utenti loggati mostrano fs-cache: BYPASS, così puoi verificare ogni passaggio del piano di test descritto sopra (vedi come controllare la cache). Dopo importazioni o cambi di prezzo svuoti la cache di singoli URL o dell'intero dominio dalla dashboard, con un registro degli svuotamenti, oppure tramite API dai tuoi script.

Sull'edge, fast.site converte anche le immagini dei prodotti in WebP per i browser che lo supportano (AVIF a seconda del piano) e filtra HTTP flood e bot malevoli prima che raggiungano il negozio, con regole firewall che controlli tu. Trovi i dettagli nella pagina WooCommerce.

Misura il tuo negozio prima e dopo sulle tue pagine, compreso un ordine di prova completo. Puoi iniziare con una prova gratuita di 7 giorni.

Domande frequenti

Serve un CDN per WooCommerce?

Non a tutti i negozi. Se la maggior parte dei clienti è vicina al tuo server e le pagine sono già veloci, un hosting migliore o un CDN per gli asset possono bastare. Un CDN per l'intero sito rende di più con visitatori in più regioni, picchi di traffico dovuti alle campagne o un server in difficoltà.

Un CDN può mettere in cache le schede prodotto di WooCommerce?

Sì, per gli ospiti. Schede prodotto, categorie e pagina del negozio si possono mettere in cache, a patto che le richieste con cookie di carrello o di sessione di WooCommerce e gli utenti loggati saltino la cache. Svuota la cache degli URL dei prodotti quando cambiano prezzo o disponibilità.

Un CDN può rompere il checkout di WooCommerce?

No, se carrello, checkout, pagine account, richieste wc-ajax, Store API e callback dei pagamenti saltano la cache e non vengono bloccati dalle regole del firewall. Dopo ogni modifica alla configurazione, testa un ordine completo con un pagamento in sandbox.

Devo tenere il plugin di cache se uso un CDN?

Spesso sì. Un plugin di cache di pagina accelera le richieste che arrivano comunque al tuo server, come i cache miss. Assicurati che plugin e CDN siano allineati sulle esclusioni, e svuota la cache di entrambi dopo le modifiche.