CDN per Shopware 6: cosa mettere in cache e cosa no

Un CDN davanti a Shopware 6 rende in due punti: i file statici come CSS del tema, JavaScript e immagini dei prodotti, che possono restare a lungo sull'edge, e le pagine HTML per gli ospiti nello stato predefinito di Shopware, che richiedono durate brevi e un piano per svuotare la cache. Tutto ciò che è personale, da carrello e checkout alle pagine account, dai clienti loggati agli ospiti che hanno cambiato valuta, deve andare direttamente al tuo server Shopware. Questa guida ti mostra dove tracciare il confine, come svuotare la cache e come testare il tutto.

L'ottimizzazione del negozio in sé (cache HTTP, worker, OPcache, importazioni) è trattata nella nostra guida alle prestazioni di Shopware 6. Qui ci concentriamo sul livello che sta davanti.

CDN per gli asset o CDN per l'intero sito

CDN per gli asset. Shopware può generare gli URL dei file pubblici su un hostname separato. Nella configurazione del filesystem (in inglese) imposti un url per il filesystem public, e i filesystem di tema, asset e sitemap lo ereditano per impostazione predefinita. Questo cambia solo gli URL nella pagina. Il CDN continua a prelevare i file dal tuo server o dal tuo bucket, e ogni richiesta HTML arriva comunque a Shopware.

CDN per l'intero sito. Tutto il dominio passa dal CDN, configurato tramite nameserver o DNS a seconda del fornitore. L'edge vede ogni richiesta, HTML compreso, e può filtrare il traffico malevolo prima che raggiunga il tuo server. Il guadagno è maggiore, e lo è anche la responsabilità: il CDN deve sapere esattamente quali risposte può memorizzare.

I file statici sono la parte facile

I file del tema compilato si prestano a lunghe durate sull'edge: a ogni compilazione Shopware scrive CSS e JavaScript in una nuova cartella sotto theme/, con un nome basato su un hash nuovo, quindi gli URL cambiano. Immagini e miniature dei prodotti cambiano di rado e spesso rappresentano la maggior parte dei byte di una pagina. La nostra guida su come ottimizzare le immagini per il web tratta formati e dimensioni.

L'eccezione è un file sostituito mantenendo lo stesso URL, per esempio un'immagine CMS con il nome del file invariato. Quando la sostituisci, svuota la cache di quell'URL.

Quali pagine di Shopware si possono mettere in cache

Shopware non mette in cache una sola pagina uguale per tutti. Secondo la documentazione sulla cache HTTP (in inglese), imposta un cookie sw-cache-hash non appena lo stato di un visitatore si discosta da quello predefinito, cioè: nessun cliente loggato, valuta predefinita e carrello vuoto. L'hash codifica stato di login, valuta, regime fiscale e le regole rilevanti per la cache che sono state applicate, e Shopware tiene una variante di cache separata per ogni hash. I visitatori nello stato predefinito condividono un'unica variante.

Un CDN che usa solo l'URL come chiave di cache non sa nulla di queste varianti. Per l'HTML la regola è quindi: metti in cache solo ciò che vede un ospite nello stato predefinito, e manda a Shopware ogni richiesta con sw-cache-hash.

Anche i prezzi per gruppo di clienti e gli altri contenuti basati su regole finiscono nell'hash, quindi questi visitatori non devono mai ricevere la pagina predefinita in cache.

Rispetta Cache-Control e cookie

L'edge non dovrebbe tirare a indovinare cosa si può mettere in cache, perché Shopware lo dice già. Con la cache HTTP attiva, le risposte memorizzabili dello storefront portano una durata per le cache condivise (s-maxage); la documentazione sul reverse proxy mostra come esempio Cache-Control: public, s-maxage=7200. Le risposte per clienti loggati o con il carrello pieno non ricevono questi header.

Qualunque CDN usi, valgono due regole:

1. Memorizza solo ciò che Shopware segna come pubblico. Non memorizzare mai risposte con private, no-cache o no-store, e non memorizzare mai una risposta che imposta un cookie. Una regola generica "metti tutto in cache" scavalca le decisioni di Shopware ed è proprio così che un cliente finisce per vedere il carrello di un altro.
2. Salta la cache dell'edge per le richieste con sw-cache-hash, oppure includi quel cookie nella chiave di cache. Se il CDN lo ignora, un ospite che ha cambiato valuta può ricevere dall'edge la pagina nella valuta predefinita. Peggio ancora, la sua variante potrebbe essere memorizzata e servita a tutti gli altri.

Per cambiare le durate, modificale in Shopware invece che sull'edge. Le versioni più recenti offrono policy di caching HTTP (in inglese) con direttive come s_maxage e stale_while_revalidate per area o per route. La documentazione le indica come sperimentali e previste come impostazione predefinita per Shopware 6.8, quindi verifica la tua versione.

Varnish, Fastly e un CDN generico

Shopware supporta ufficialmente due reverse proxy: Varnish con il modulo XKey e Fastly. Entrambi sono collegati alla sua invalidazione: le risposte in cache portano dei tag (surrogate key) per i dati da cui sono state generate, e quando modifichi un prodotto Shopware invia al proxy una richiesta di invalidazione proprio per quei tag. Da Shopware 6.6 lo configuri sotto shopware.http_cache.reverse_proxy. La documentazione sulla reverse HTTP cache (in inglese) descrive la configurazione completa.

Un CDN generico non fa parte di questo circuito. L'invalidazione per tag di Shopware raggiunge la sua cache e un reverse proxy configurato, ma non una rete edge che non conosce. Una pagina di categoria in cache sull'edge resta lì finché non scade la sua durata o finché non ne svuoti la cache.

Un proxy basato su tag ti offre un'invalidazione precisa per cataloghi grandi che cambiano spesso, ma è un sistema in più da gestire. Un CDN generico per l'intero sito è più semplice da aggiungere e porta distribuzione dall'edge e protezione, ma l'aggiornamento dell'HTML dipende da durate brevi e dagli svuotamenti che fai tu. Alcuni negozi combinano le due cose.

Una strategia di svuotamento senza tag

Durate brevi per l'HTML. Tieni l'HTML per gli ospiti sull'edge per minuti anziché ore, mentre file del tema e immagini restano molto più a lungo. Così una copia obsoleta sull'edge sparisce al massimo dopo una durata, anche senza svuotamento. La cache integrata di Shopware assorbe i miss in più.

Svuotamento per URL dopo modifiche importanti. Quando parte una promozione, cambiano i prezzi di un'intera categoria o modifichi la navigazione, svuota la cache degli URL coinvolti. Le modifiche che compaiono su ogni pagina, come menu principale, footer o un tema ricompilato, giustificano lo svuotamento dell'intero dominio, idealmente fuori dalle ore di punta.

Svuotamenti dai tuoi script. La maggior parte dei CDN, fast.site compreso, offre un'API per svuotare la cache. Fai terminare l'importazione dall'ERP o dei prezzi con una chiamata che svuota gli URL toccati, e fai svuotare la cache alla tua pipeline di deploy dopo theme:compile.

IP reali dei client e trusted proxy

Dietro un CDN, ogni richiesta arriva a Shopware da un server edge. L'IP reale del visitatore viaggia in un header come X-Forwarded-For, che Symfony legge solo dai proxy di cui ti fidi tramite SYMFONY_TRUSTED_PROXIES nel tuo .env (il nome della variabile da Shopware 6.6). Se metti in catena un CDN e Varnish, dichiara come fidati entrambi i passaggi.

Non conta solo per i log. I plugin di pagamento e antifrode controllano spesso l'IP del client, e i rate limiter di Shopware per login, reimpostazione della password e modulo di contatto diventano meno precisi quando tutte le richieste sembrano arrivare da pochi indirizzi.

Come testare la configurazione del CDN per Shopware

1. Richiesta da ospite, due volte. La seconda richiesta dovrebbe arrivare dall'edge:

curl -sI https://shop.example.com/some-category/ | grep -iE 'cache-control|fs-cache|age|set-cookie'
curl -sI https://shop.example.com/some-category/ | grep -iE 'cache-control|fs-cache|age|set-cookie'

Su fast.site cerca fs-cache: HIT e un fs-cache-age che cresce (vedi come controllare la cache). Gli altri CDN inviano di solito un header Age e un proprio header di stato. Se la pagina non diventa mai un HIT, confronta il suo header Cache-Control con le regole viste sopra.

2. Route personali. Controlla allo stesso modo /checkout/cart e /account/login. Non devono mai mostrare un HIT.

3. Un checkout completo. In una finestra privata aggiungi un prodotto, controlla che il contatore del carrello si aggiorni e completa il checkout con un metodo di pagamento di prova. Poi annulla l'ordine di prova.

4. Cliente loggato. Accedi con un account di prova, meglio se con prezzi per gruppo di clienti. Le pagine devono mostrare i prezzi di quel cliente, e dopo il logout deve tornare la vista da ospite.

5. Cambio di valuta. Da ospite, passa a una seconda valuta e sfoglia qualche categoria. Poi apri le stesse pagine in una nuova finestra privata: devono mostrare la valuta predefinita. Ripeti nell'ordine inverso. Così scopri un CDN che ignora sw-cache-hash.

Con più canali di vendita o lingue, ripeti i passaggi 1 e 5 per ogni dominio. Per la velocità, confronta prima e dopo i dati degli utenti reali e un test di laboratorio su corewebvitals.page, come descritto in come misurare correttamente la velocità di un sito.

Come ti aiuta fast.site

fast.site è un livello edge per l'intero sito che si mette davanti al tuo hosting Shopware attuale. Tieni il tuo hosting, aggiungi il dominio nella dashboard e ne punti i nameserver a fast.site; la nostra checklist per i nameserver ti aiuta a mantenere intatti record DNS e posta.

Fast Edge Cache™ rispetta gli header Cache-Control inviati dal tuo negozio. Le risposte private e dinamiche come carrello, checkout e sessioni degli utenti loggati mostrano fs-cache: BYPASS, così puoi eseguire direttamente il piano di test descritto sopra. fast.site non riceve le invalidazioni per tag di Shopware. Al loro posto svuoti la cache di singoli URL o dell'intero dominio dalla dashboard, con un registro degli svuotamenti, oppure tramite API dai tuoi script di importazione e deploy. Un cache warmer mantiene pronte le pagine importanti.

Le immagini vengono convertite al volo in WebP (AVIF a seconda del piano), i file di testo vengono compressi con Brotli, e rilevamento DDoS di livello 7, rate limiting e set di regole anti-bot filtrano il traffico sull'edge. Trovi i dettagli nella pagina Shopware.

Misura il risultato sul tuo negozio, con le stesse pagine prima e dopo. Puoi iniziare con una prova gratuita di 7 giorni, senza carta di credito.

Domande frequenti

Shopware 6 ha un CDN integrato?

No. Shopware ha una cache HTTP integrata sul tuo server, e puoi impostare un URL separato per i file pubblici in modo che vengano caricati da un hostname CDN. Come reverse proxy, Shopware integra ufficialmente Varnish con XKey e Fastly.

Posso mettere in cache le pagine HTML di Shopware su un CDN?

Sì, per gli ospiti nello stato predefinito: non loggati, valuta predefinita, carrello vuoto. Il CDN deve rispettare gli header Cache-Control di Shopware, saltare la cache per le richieste con il cookie sw-cache-hash e non mettere mai in cache carrello, checkout o pagine account.

Perché dopo aver aggiunto un CDN il carrello o i prezzi sono sbagliati?

Di solito l'edge mette in cache qualcosa di personale: una risposta che imposta un cookie, una pagina richiesta con sw-cache-hash oppure una route del checkout presa da una regola "metti tutto in cache". Rimuovi la regola, svuota la cache del dominio e ripeti i test.

Mi serve ancora la cache HTTP di Shopware dietro un CDN?

Sì. Ogni miss sull'edge e ogni richiesta con un cookie sw-cache-hash arrivano al tuo server. La cache integrata mantiene veloci queste richieste, e le durate brevi sull'edge funzionano bene solo con un'origine rapida.

Come svuoto la cache del CDN dopo una modifica in Shopware?

I comandi bin/console cache:clear e cache:clear:http di Shopware non raggiungono un CDN generico. Svuota la cache degli URL coinvolti o dell'intero dominio dalla dashboard del CDN, oppure tramite la sua API dallo script che ha fatto la modifica.