Prestazioni di Shopware 6: cache HTTP, CDN ed errori comuni

Uno storefront Shopware 6 lento raramente è un mistero. Nella maggior parte dei casi la cache HTTP è spenta o viene invalidata di continuo, il lavoro in background gira nel posto sbagliato, oppure il server esegue a ogni richiesta operazioni costose che potrebbe evitare. Questa guida spiega come funziona la cache HTTP di Shopware 6, come verificarla, dove aiuta un CDN e quali sono gli errori di configurazione più comuni.

Come funziona la cache HTTP di Shopware 6

Shopware 6 ha una cache full page integrata per lo storefront. Quando è attiva, la prima richiesta di una pagina (per esempio una categoria o una scheda prodotto) viene generata da PHP e memorizzata, e le richieste successive per la stessa pagina ricevono la copia memorizzata senza eseguire di nuovo l'intera applicazione. È in assoluto la leva più importante per la velocità dello storefront.

Alcuni aspetti determinano quanto bene funziona:

• Deve essere attivata. La cache è controllata dalla variabile d'ambiente SHOPWARE_HTTP_CACHE_ENABLED=1, di solito impostata in .env.local.
• Archiviazione. Per impostazione predefinita la cache si trova sul filesystem, in var/cache. Va bene per un singolo server. Con più server applicativi, la documentazione di Shopware sulle cache (in inglese) consiglia una cache condivisa come Redis.
• Varianti per contesto. Una pagina può apparire diversa a seconda che il visitatore sia loggato, della valuta, del regime fiscale o delle regole di prezzo applicate. Shopware riassume tutto questo nel cookie sw-cache-hash e memorizza una variante separata per ogni hash, così un cliente non vede mai i prezzi di un altro. I visitatori nello stato predefinito (non loggati, valuta predefinita, carrello vuoto) condividono le stesse pagine in cache.
• Invalidazione basata sui tag. Le risposte in cache portano dei tag per i dati da cui sono state generate. Quando modifichi un prodotto, Shopware elimina le pagine in cache che hanno quel tag invece di cancellare tutto. Le route di tipo elenco, come elenchi prodotti, elenchi di categorie e risultati di ricerca, non ricevono il tag di ogni entità che restituiscono e si affidano invece alla loro durata di cache, quindi lì una modifica può metterci un po' a comparire.

Cache integrata o reverse proxy

Per i negozi più grandi Shopware supporta un reverse proxy esterno, cioè Varnish con il modulo XKey oppure Fastly. Il proxy memorizza le pagine e Shopware gli invia richieste di invalidazione con i tag interessati. Da Shopware 6.6 lo configuri sotto shopware.http_cache.reverse_proxy (le versioni precedenti usano storefront.reverse_proxy) e imposti SYMFONY_TRUSTED_PROXIES perché l'applicazione veda gli IP reali dei client. La documentazione sulla reverse HTTP cache (in inglese) descrive la configurazione completa.

Un reverse proxy toglie del tutto il carico a PHP per gli hit in cache, e questo conta nelle ore di punta. È però anche un componente in più da gestire e monitorare. Per molti negozi piccoli e medi basta la cache integrata con Redis.

Verifica se la cache funziona

Prima di cambiare qualsiasi cosa, scopri cosa succede davvero. Apri due volte una pagina di categoria in una finestra privata e confronta i tempi di risposta nella scheda Rete del browser. Una cache funzionante mostra un calo netto alla seconda richiesta. Da riga di comando:

curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://shop.example.com/some-category/
curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://shop.example.com/some-category/
curl -sI https://shop.example.com/some-category/ | grep -i cache-control

Se entrambe le richieste sono ugualmente lente, la cache è disattivata, viene aggirata da un cookie oppure viene invalidata tra una richiesta e l'altra. Controlla anche l'header Cache-Control: dice a qualsiasi proxy o CDN davanti a Shopware se può memorizzare la pagina.

Per un confronto strutturato prima e dopo, lato server la metrica da seguire è il TTFB. La nostra guida su come ridurre il TTFB approfondisce il lato server e quello applicativo.

Errori di configurazione comuni

Questi sono i problemi che più spesso spiegano un negozio Shopware 6 lento.

Modalità dev o debug attivo

APP_ENV=dev attiva il profiler e le funzioni di debug, che rallentano ogni richiesta. I negozi in produzione hanno bisogno di APP_ENV=prod. In produzione imposta anche il livello di log su error o simile, perché un logging dettagliato scrive a ogni richiesta.

L'admin worker gestisce i job in background

Per impostazione predefinita, Shopware può elaborare i messaggi in coda (indicizzazione, email, importazioni) tramite l'amministrazione mentre un utente admin ha il backend aperto. È comodo in sviluppo, ma in produzione rende il lavoro in background imprevedibile e carica il server web. La documentazione sulla message queue (in inglese) è chiara: in produzione la coda va elaborata tramite CLI. Imposta shopware.admin_worker.enable_admin_worker: false in config/packages/shopware.yaml ed esegui bin/console messenger:consume async come processo in background tenuto in vita da systemd o supervisor, più bin/console scheduled-task:run per le attività pianificate.

Tempeste di invalidazione della cache

Sincronizzazioni con l'ERP, aggiornamenti di magazzino e importazioni di prezzi toccano molti prodotti alla volta. Ogni modifica invalida pagine in cache, quindi un'importazione che gira ogni pochi minuti può tenere la cache quasi sempre vuota. Le opzioni: raggruppare le importazioni in meno esecuzioni, scrivere solo i campi che sono cambiati davvero e usare l'invalidazione ritardata. Shopware raccoglie così i tag da invalidare e li elabora più tardi in un'attività in background. Per impostazione predefinita quell'elenco sta nel database; la documentazione sulle ottimizzazioni delle prestazioni (in inglese) consiglia Redis come archivio ovunque tu possa usarlo.

Estensioni che rompono la cache

I plugin possono impostare cookie, aggiungere blocchi personalizzati o cambiare il contesto a ogni richiesta. Ognuna di queste cose può portare a una variante di cache separata per ogni visitatore, il che equivale a non avere cache. Se il cache hit rate è crollato dopo l'installazione di un'estensione, testa con l'estensione disattivata su una copia di staging.

Ricerca MySQL su un catalogo grande

Con cataloghi grandi, la ricerca prodotti e gli elenchi filtrati sono costosi in MySQL. Shopware supporta Elasticsearch o OpenSearch per ricerca ed elenchi nello storefront. I risultati di ricerca di solito non vengono messi in cache come pagina intera, quindi questo incide direttamente sulle pagine in cui gli utenti scrivono e filtrano.

PHP e OPcache

Assicurati che OPcache sia attivo e dimensionato per il codice di Shopware. In produzione, opcache.validate_timestamps=0 evita i controlli sui file a ogni richiesta (in quel caso devi resettare OPcache a ogni deploy). Usa una versione di PHP aggiornata e supportata dalla tua release di Shopware.

Immagini e asset del tema pesanti

Immagini prodotto prese direttamente dalla fotocamera, miniature mancanti o enormi banner hero penalizzano il Largest Contentful Paint. Lascia che Shopware generi le miniature, carica immagini con dimensioni sensate e valuta formati moderni. La nostra guida su come ottimizzare le immagini per il web entra nei dettagli.

Dove aiuta un CDN (e dove no)

Un CDN si mette tra i tuoi visitatori e il tuo server Shopware e serve i contenuti da punti più vicini a loro.

Cosa non risolve un CDN: le richieste lente non in cache. Se il checkout impiega diversi secondi per colpa di un plugin di pagamento lento o di un database sovraccarico, il CDN fa passare quel tempo così com'è. Prima sistema l'origine, poi aggiungi il livello edge.

Un ordine di lavoro sensato

1. Imposta APP_ENV=prod, riduci il logging, controlla OPcache.
2. Attiva la cache HTTP e verifica che funzioni per gli ospiti.
3. Sposta i job in background su worker CLI e disattiva l'admin worker.
4. Tieni a bada le importazioni perché non svuotino continuamente la cache.
5. Aggiungi Redis (e, per i negozi grandi, OpenSearch) dove il carico lo richiede.
6. Ottimizza immagini e asset del tema.
7. Metti davanti un livello edge per asset statici, pagine per gli ospiti e protezione.

Misura dopo ogni passaggio, idealmente con le stesse pagine e gli stessi strumenti, così sai cosa ha fatto davvero la differenza. Se gestisci anche WooCommerce, i principi sono simili: vedi velocizzare WooCommerce senza rompere il checkout.

Come ti aiuta fast.site

fast.site si mette davanti al tuo hosting Shopware attuale. Tieni il tuo hosting e la tua configurazione di Shopware, aggiungi il dominio nella dashboard e punti i nameserver del dominio a fast.site.

Fast Edge Cache™ memorizza sull'edge le risposte pubbliche. La scadenza segue gli header Cache-Control inviati dal tuo negozio o regole che imposti tu, e puoi controllare ogni risposta tramite l'header fs-cache (HIT, MISS o BYPASS). Carrello, checkout, account e le altre pagine basate sulla sessione saltano la cache, quindi gli ordini continuano a funzionare come sempre. Dopo modifiche importanti al catalogo puoi svuotare la cache degli URL dalla dashboard o tramite API, e il cache warmer mantiene pronte le pagine importanti.

Inoltre le immagini vengono convertite al volo in WebP per i browser che lo supportano (AVIF a seconda del piano), gli asset testuali vengono compressi con Brotli, e rilevamento DDoS di livello 7, rate limiting e set di regole anti-bot filtrano il traffico prima che raggiunga il tuo server. La pagina Shopware e l'articolo sull'integrazione con Shopware mostrano la configurazione nel dettaglio.

Il test più onesto è il tuo negozio: confronta TTFB e Core Web Vitals prima e dopo. Puoi iniziare con una prova gratuita di 7 giorni, senza carta di credito.

Domande frequenti

Come si attiva la cache HTTP in Shopware 6?

Imposta SHOPWARE_HTTP_CACHE_ENABLED=1 nel tuo .env.local e poi svuota la cache. Assicurati che il negozio giri con APP_ENV=prod. Poi apri due volte una pagina di categoria da ospite e verifica che la seconda richiesta sia nettamente più veloce.

Perché il mio negozio Shopware è lento anche con la cache HTTP attiva?

Le cause più comuni sono invalidazioni frequenti dovute alle importazioni, estensioni che impostano cookie o personalizzano le pagine e pagine lente non in cache come ricerca, carrello e checkout. Verifica se le pagine per gli ospiti vengono davvero servite dalla cache, poi guarda cosa gira nelle richieste non in cache.

Serve Varnish per Shopware 6?

Non necessariamente. Per molti negozi basta la cache integrata, soprattutto con Redis come archivio. Varnish o un altro reverse proxy conviene quando hai più server applicativi o molto traffico, ma aggiunge un'infrastruttura che devi gestire.

Si può usare un CDN con Shopware 6?

Sì. Asset statici e immagini sono facili da servire da un CDN. Anche le pagine HTML per gli ospiti si possono mettere in cache, a patto che il CDN rispetti gli header di cache di Shopware, salti carrello, checkout e pagine account e che tu abbia un modo per svuotare la cache dopo le modifiche.

Come si svuota la cache di Shopware?

Nei negozi self-hosted apri Settings > System > Caches & Indexes nell'amministrazione (i nomi delle voci dipendono dalla lingua impostata) e usa Clear cache, oppure esegui bin/console cache:clear da riga di comando. Se usi un reverse proxy, bin/console cache:clear:http (disponibile da Shopware 6.6.10) svuota quella cache. Svuotare tutto significa spesso che i visitatori successivi trovano una cache vuota, quindi fallo fuori dalle ore di punta.