Perché Shopware 6 diventa lento e quali impostazioni della documentazione Shopware aiutano, e in che ordine: HTTP cache, Redis, queue worker, OpenSearch, immagini, PHP. Con valori obiettivo e costi per shop in Italia.
Le leve più efficaci sono nel backend, non nel tema. Una HTTP cache attiva, Redis al posto del file system, l’Admin Worker disattivato con veri queue worker e, oltre qualche migliaio di prodotti, OpenSearch portano nella maggior parte degli shop Shopware 6 più risultati di qualsiasi ottimizzazione frontend.
Misuri con dati sul campo, non solo con Lighthouse. Google valuta i Core Web Vitals al 75° percentile degli utenti reali: LCP al massimo 2,5 secondi, INP al massimo 200 millisecondi, CLS al massimo 0,1.
Preveda da 1.500 a 4.000 € per audit e interventi di base. Redis, OpenSearch, CDN per le immagini e pulizia del tema costano, a seconda dello shop, da 5.000 a 15.000 € in più; un cluster con Varnish di più. Sono valori basati sui nostri progetti, non prezzi di listino.
Prima di fondare solution25 abbiamo portato un nostro negozio online a oltre 500 ordini al giorno e abbiamo imparato quanto fatturato costa ogni secondo di caricamento. Dal 2017 gestiamo e ottimizziamo shop Shopware per merchant, anche in Italia: dallo shop starter su un singolo server fino al cluster con Varnish e OpenSearch.
Uno shop lento perde visitatori e ordini, e Google valuta la velocità tramite i Core Web Vitals. Questo articolo si rivolge a titolari di e-commerce, responsabili e-commerce e sviluppatori in Italia il cui shop Shopware 6 è lento o deve reggere più carico in vista di una campagna.
Dopo la lettura potrà ottimizzare le prestazioni di Shopware in modo mirato: individuare da solo la causa delle pagine lente, ordinare gli interventi per efficacia e impegno e decidere che cosa affidare all’hosting provider, all’agenzia o al team interno. Tutte le indicazioni si riferiscono a Shopware 6.7 e alla documentazione Shopware; tutti i prezzi sono aggiornati a ottobre 2026, IVA esclusa.
Prima di modificare qualsiasi impostazione serve una misurazione di partenza. Altrimenti nessuno saprà poi se l’ottimizzazione ha funzionato.
Google valuta le pagine con tre metriche definite da web.dev. Conta sempre il 75° percentile delle visualizzazioni di pagina, separato tra mobile e desktop.
| Metrica | Buono | Scarso | Che cosa misura nello shop | Causa tipica in Shopware |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | fino a 2,5 s | oltre 4,0 s | Quando viene visualizzato l’elemento visibile più grande, di solito l’immagine principale o del prodotto | Risposta del server senza cache, immagini troppo pesanti, slider senza priorità |
| INP (Interaction to Next Paint) | fino a 200 ms | oltre 500 ms | Quanto velocemente la pagina reagisce ai clic, ad esempio nel carrello off-canvas o nei filtri | Troppo JavaScript da plugin, strumenti di consenso e tracking nel thread principale |
| CLS (Cumulative Layout Shift) | fino a 0,1 | oltre 0,25 | Quanto si spostano i contenuti durante il caricamento | Immagini senza spazio riservato, font caricati in ritardo, banner inseriti dopo |
I valori obiettivo provengono dagli articoli su LCP, INP e CLS di web.dev. Nel 2024 INP ha sostituito la precedente metrica First Input Delay. Chi analizza ancora i valori FID misura una metrica che Google non utilizza più.
PageSpeed Insights mostra due cose diverse. In alto ci sono i dati sul campo del Chrome User Experience Report, cioè utenti reali degli ultimi 28 giorni al 75° percentile. Sotto segue un test di laboratorio Lighthouse che simula uno smartphone di fascia media su rete mobile.
Per il ranking contano i dati sul campo. Un punteggio Lighthouse di 95 sulla homepage non dice nulla sulla pagina di categoria su cui atterra la maggior parte dei visitatori.
Il tempo al primo byte (TTFB) separa i problemi del server da quelli del frontend. PageSpeed Insights considera buono un valore fino a 800 millisecondi. Uno shop Shopware la cui pagina arriva dalla HTTP cache risponde, secondo la nostra esperienza, in meno di 100 millisecondi; una pagina di categoria non in cache con molti filtri richiede spesso da 500 a 1.500 millisecondi.
Misuri la stessa URL due volte di seguito. Se la seconda richiesta non è nettamente più veloce, la HTTP cache non è attiva o viene svuotata di continuo. Nei nostri audit è la causa singola più frequente di uno shop Shopware lento.
Google documenta su web.dev diversi casi di studio. Vodafone ha aumentato il fatturato dell’8 % dopo aver migliorato l’LCP del 31 %, e la BBC perdeva il 10 % degli utenti per ogni secondo di caricamento in più. I numeri non sono trasferibili a ogni shop, la tendenza sì.
Shopware 6 non è lento di per sé. Shopware stesso misura per la 6.7, nello scenario di benchmark senza caching, un tempo di risposta di 231 millisecondi, sotto il quale resta il 95 % di tutte le richieste (p95). Uno shop diventa lento per gestione e configurazione, quasi sempre per uno di questi sei motivi.
L’ordine seguente si è dimostrato valido nei nostri progetti. Gli impegni indicati sono valori basati su progetti di agenzia, con tariffe orarie come le descriviamo nell’articolo sui costi di Shopware.
| Intervento | Agisce soprattutto su | Impegno | Per chi |
|---|---|---|---|
| 1. Attivare la HTTP cache e verificarne l’invalidazione | TTFB, LCP | da 1 a 2 giorni | Ogni shop |
| 2. Disattivare l’Admin Worker, configurare queue worker e cronjob | TTFB, stabilità | da 0,5 a 1 giorno | Ogni shop |
| 3. Redis per cache, sessioni e Delayed Invalidation | TTFB, cache hit rate | da 1 a 2 giorni | Da traffico medio in su |
| 4. Versione PHP, OPcache e impostazioni MySQL | TTFB delle pagine non in cache | da 0,5 a 1 giorno | Ogni shop |
| 5. Immagini: thumbnail, lazy loading, WebP, CDN | LCP, volume di dati | da 1 a 3 giorni | Ogni shop |
| 6. Audit dei plugin e riduzione degli script di terze parti | INP, LCP | da 2 a 5 giorni | Shop con più di 10 plugin |
| 7. OpenSearch o Elasticsearch | Listing, filtri, ricerca | da 3 a 5 giorni più hosting | Da qualche migliaio di prodotti |
| 8. Varnish o Fastly come reverse proxy | Picchi di carico, TTFB | da 2 a 5 giorni più hosting | Campagne, traffico elevato, cluster |
La nostra valutazione: consigliamo di realizzare gli interventi da 1 a 4 prima di investire in server più grandi o in Varnish. Insieme richiedono da tre a sei giorni ed eliminano le cause che troviamo più spesso negli audit; più hardware rende uno shop senza cache funzionante più costoso, ma non molto più veloce.
Shopware 6 include una full page cache che si attiva con SHOPWARE_HTTP_CACHE_ENABLED=1 nel file .env. La documentazione sulla cache la definisce indispensabile in produzione. Se è attiva lo vede nell’amministrazione in Impostazioni, Sistema, Cache e indici.
Due stati escludono di default una pagina dalla cache: clienti loggati e carrelli pieni (shopware.cache.invalidation.http_cache con i valori logged-in e cart-filled). Chi non mostra contenuti personalizzati può, secondo la documentazione sui performance tweaks, svuotare questa lista in config/packages/prod/shopware.yaml e ottenere hit rate nettamente più alti.
Da Shopware 6.7 header e footer vengono caricati tramite ESI (Edge Side Includes) come blocchi separati e messi in cache indipendentemente dal resto della pagina, come indicano le release notes della 6.7.0.0. Una modifica al menu non deve quindi più invalidare ogni pagina prodotto in cache.
Dalla 6.7 l’invalidazione ritardata della cache è attiva di default (shopware.cache.invalidation.delay_enabled: true). Invece di eliminare subito le voci di cache a ogni modifica di prodotto, Shopware raccoglie i tag interessati e li elabora ogni cinque minuti tramite l’attività pianificata shopware.invalidate_cache. L’intervallo si trova nella colonna run_interval della tabella scheduled_task.
Come archivio Shopware usa di default MySQL. La documentazione raccomanda Redis (shopware.cache.invalidation.delay_options.storage: redis), perché l’adapter MySQL può causare deadlock con molte scritture simultanee, ad esempio negli import dall’ERP con migliaia di variazioni di giacenza.
La cache integrata gira in PHP, quindi ogni hit costa un processo PHP. Un reverse proxy davanti allo shop risponde con le pagine in cache senza toccare Shopware. Secondo la documentazione, Shopware supporta Varnish dalla versione 6.0 con il modulo xkey per l’eliminazione mirata tramite cache tag, obbligatorio dalla 6.7, e Fastly da Shopware 6.4.11.0.
Dalla 6.6 la configurazione si trova in shopware.http_cache.reverse_proxy con enabled: true, use_varnish_xkey: true e l’elenco degli host Varnish. Attivi i soft purge, così che durante l’aggiornamento i clienti ricevano la pagina precedente, e inserisca il proxy in SYMFONY_TRUSTED_PROXIES. Se l’header di risposta Age resta stabilmente a 0, il proxy non sta mettendo in cache.
Che cosa porta lo mostra Shopware nei suoi benchmark sulla 6.7: nello scenario flash sale con Varnish il numero di ordini al secondo è cresciuto del 108 % rispetto alla 6.6, la latenza p99 è scesa da 1.000 a 425 millisecondi. Come funziona Varnish in un servizio gestito lo descriviamo nell’articolo su Shopware PaaS su Platform.sh.
Importante per gli script di deployment: dalla 6.7 cache:clear non svuota più la HTTP cache. Per questo esistono cache:clear:http (dalla 6.6.10) e cache:clear:all (dalla 6.6.8).
Figura: dalla cache la risposta del server resta ben al di sotto della soglia, mentre le pagine di categoria non in cache spesso la superano; verifichi quindi per prima cosa la HTTP cache. Soglia: Google PageSpeed Insights; valori di cache e categoria: dati basati sui progetti di solution25, aggiornati a ottobre 2026
Di default Shopware scrive l’object cache in var/cache e le sessioni nell’handler standard di PHP. Secondo la documentazione sulla cache, per un singolo server è sufficiente. Con più server, molti cache tag o volumi di ordini elevati, Redis è la scelta migliore.
La documentazione su Redis raccomanda di separare i dati in base alla loro durata, perché un’istanza Redis conosce una sola strategia di eviction. Un’istanza con allkeys-lru che memorizza anche i carrelli, sotto carico elimina proprio quei carrelli.
| Tipo di dati | Esempi | Persistenza | Eviction policy |
|---|---|---|---|
| Volatili | HTTP cache, object cache, Delayed Invalidation | nessuna, la perdita al riavvio non è critica | volatile-lru |
| Persistenti, con scadenza | Sessioni | snapshot RDB e/o AOF | allkeys-lru |
| Persistenti, critici | Carrelli, sequenze numeriche, lock store, increment storage | snapshot RDB e/o AOF | volatile-lru |
L’adapter tag-aware di Symfony crea gli indici dei tag senza TTL. Queste chiavi si accumulano per mesi, finché Redis, nonostante volatile-lru, non può più eliminare nulla e si ferma per out of memory. Verifichi la quota di chiavi persistenti con redis-cli INFO keyspace e ripulisca di notte i tag orfani, ad esempio con frosh:redis-tag:cleanup dei FroshTools.
Shopware gestisce in modo asincrono indicizzazione, thumbnail, e-mail, sitemap e invalidazione della cache tramite la Symfony Message Queue. Di default questa coda è elaborata dall’Admin Worker: finché un amministratore è loggato, il suo browser interroga il sistema ogni 20 secondi e avvia l’elaborazione. La documentazione sulla message queue avverte che con più utenti admin questo genera un carico CPU elevato e penalizza PHP-FPM.
bin/console messenger:consume async low_priority --time-limit=60 --memory-limit=128M, monitorati da systemd o supervisor. Un worker dedicato al transport failed è obbligatorio, altrimenti i messaggi non riusciti restano in sospeso.*/5 * * * * php bin/console scheduled-task:run --no-wait (dalla 6.5.5.0) mette in coda le attività in scadenza. La configurazione è spiegata nel nostro articolo su cronjob e attività pianificate in Shopware.Due indexer si possono disattivare se non servono: il Product Stream Indexer (shopware.product_stream.indexing: false, dalla 6.6.10.0) e la generazione pianificata della sitemap (shopware.sitemap.scheduled_task.enabled: false, dalla 6.7.1.0, in alternativa sitemap:generate di notte via cron). Senza Product Stream Indexer i gruppi di prodotti dinamici si aggiornano solo alla scadenza della HTTP cache.
In Shopware 6 listing, filtri e ricerca passano di default da MySQL. La documentazione Shopware raccomanda un motore di ricerca a partire da diverse migliaia di record. Nei nostri progetti la differenza diventa evidente da circa 5.000 prodotti con molte proprietà e varianti; con 50.000 prodotti OpenSearch non ha alternative.
Il collegamento avviene con poche variabili: OPENSEARCH_URL per gli host, SHOPWARE_ES_ENABLED=1 per la ricerca, SHOPWARE_ES_INDEXING_ENABLED=1 per l’indicizzazione e SHOPWARE_ES_INDEX_PREFIX per il nome dell’indice. L’indicizzazione con bin/console es:index passa dalla message queue e richiede quindi i worker della sezione precedente.
Imposti SHOPWARE_ES_THROW_EXCEPTION=1. Senza questa impostazione, in caso di errore del motore di ricerca Shopware torna silenziosamente a MySQL e Lei si accorge del guasto solo dai tempi di caricamento. Con la 6.7.2.0 Shopware ha inoltre rivisto ordinamento e query per OpenSearch e nelle release notes indica tempi di query fino all’85 % più brevi.
Shopware considera un singolo nodo un ambiente di test e indica tre nodi con ruolo master come minimo per l’alta disponibilità. Negli shop di medie dimensioni gestiamo comunque spesso una singola istanza OpenSearch con 2-4 GB di RAM, in quel caso con monitoraggio. Installazione ed errori tipici sono descritti nell’articolo su Elasticsearch e OpenSearch per Shopware 6.
Su quasi ogni pagina di uno shop l’elemento LCP è un’immagine. Secondo la documentazione sui media, al caricamento Shopware genera di default tre dimensioni di thumbnail (400, 800 e 1920 pixel), configurabili per ogni cartella media insieme al livello di qualità. Dopo una modifica, bin/console media:generate-thumbnails rigenera i file.
Il template delle thumbnail dello storefront costruisce automaticamente srcset e sizes, così il browser carica la dimensione adatta a ogni viewport; dalla 6.7.12 anche per il breakpoint XXL. Di default carica le immagini con loading=”eager”, mentre i riquadri prodotto nel listing usano loading=”lazy”. Nei Suoi elementi CMS personalizzati il lazy loading va impostato manualmente, e solo sotto l’area visibile.
Per l’immagine principale vale il contrario: dalla 6.7.2.0 la configurazione CMS di slider e galleria immagini offre un’impostazione fetchpriority con cui il browser carica per prima la prima immagine. Shopware lo motiva esplicitamente nelle release notes con l’LCP.
Il template non restituisce attributi width e height. Riservi lo spazio per le immagini nel tema via CSS (aspect-ratio), altrimenti il layout salta durante il caricamento e il CLS peggiora.
Shopware accetta WebP in upload, ma non converte da solo JPG e PNG in formati moderni. Le strade sono tre: caricare le immagini prodotto già in WebP, usare un’estensione dello Shopware Store per la conversione oppure esternalizzare l’elaborazione delle immagini.
La terza strada è prevista nel core dalla 6.6.4.0: con shopware.media.remote_thumbnails.enable: true Shopware non genera più file thumbnail, ma costruisce URL secondo uno schema come {mediaUrl}/{mediaPath}?width={width}, risolti da una CDN per immagini o da un servizio come imgproxy. Il servizio consegna WebP o AVIF a seconda del browser. Fonte: documentazione sulle remote thumbnails.
Una CDN si collega tramite l’URL del file system pubblico (shopware.filesystem.public.url); dopo vanno eseguiti bin/console asset:install e theme:compile. Per gli asset dalla CDN Shopware raccomanda un header Cache-Control come public, max-age=86400. Per gli shop che vendono in Italia, una CDN con nodi in Italia avvicina immagini e file ai clienti, indipendentemente da dove si trova il server dello shop. Fonte: documentazione sul file system.
Con la 6.7, secondo i dati di Shopware, il JavaScript dello storefront è stato ridotto del 25 % e il CSS del 24 %. Quello che rallenta ancora arriva quasi sempre da plugin, personalizzazioni del tema e script di terze parti.
Dalla 6.7.12 Shopware può caricare nel listing solo dati prodotto ridotti, con un estratto della descrizione senza HTML di massimo 512 caratteri. L’impostazione core.listing.partialDataLoading (Impostazioni, Prodotti) è attiva nelle nuove installazioni, non negli shop esistenti. La attivi solo se tema ed estensioni non richiedono altri campi prodotto nel listing. Fonte: release notes 6.7.12.0.
Dalla 6.7.2.0 la navigazione carica dinamicamente i livelli di categoria attivi. La profondità di navigazione nel canale di vendita determina quindi soprattutto la navigazione nell’header e può essere ridotta per guadagnare velocità.
Secondo la guida all’aggiornamento, Shopware 6.7 supporta PHP 8.2, 8.3 e 8.4 e, dalla 6.7.6.0 (gennaio 2026), secondo Shopware anche PHP 8.5. Usi la versione più recente compatibile con i Suoi plugin.
La documentazione sui performance tweaks indica per la produzione impostazioni PHP concrete: zend.assertions=-1, opcache.enable_file_override=1, opcache.interned_strings_buffer=20, opcache.validate_timestamps=0, zend.detect_unicode=0, realpath_cache_ttl=3600 e opcache.max_accelerated_files di almeno 20000. Con validate_timestamps=0 deve ricaricare PHP-FPM dopo ogni deployment, altrimenti continua a girare il codice vecchio. Secondo la documentazione il preloading di OPcache porta un ulteriore 2-5 %, ma disattiva l’Extension Manager.
A questo si aggiungono dettagli con effetto: esportare il file .env in un file PHP con bin/console dotenv:dump prod, disattivare i Symfony Secrets non usati e impostare Monolog in produzione su level: error, anche per l’handler business_event_handler_buffer. Con l’estensione PHP zstd, dalla 6.6.4.0 cache e carrello vengono compressi più velocemente che con gzip (shopware.cache.cache_compression_method: zstd).
Shopware 6.7 richiede MySQL dalla 8.0.17 (escluse 8.0.20 e 8.0.21) o MariaDB dalla 10.11 (escluse 10.11.5 e 11.0.3). La documentazione sui performance tweaks cita esplicitamente due valori del server: group_concat_max_len di almeno 320000 e un sql_mode senza ONLY_FULL_GROUP_BY. Altrimenti Shopware imposta entrambi i valori a ogni connessione.
Dimensioni innodb_buffer_pool_size in modo che i dati di lavoro dello shop ci stiano dentro: secondo la nostra esperienza da 2 a 4 GB per cataloghi fino a 20.000 prodotti. Per shop molto grandi Shopware supporta repliche di lettura tramite DATABASE_REPLICA_0_URL, che spostano le query di listing dal database server in scrittura.
Le dimensioni seguenti sono valori basati sui nostri progetti per un hosting Shopware specializzato in Germania, non indicazioni di Shopware. Corrispondono ai livelli della nostra guida all’hosting Shopware, dove trova anche provider e prezzi. Per i merchant italiani valgono gli stessi ordini di grandezza; i prezzi dei provider locali possono differire.
Non ogni shop ha bisogno di Varnish e OpenSearch. Tre profili coprono la maggior parte dei merchant, in Italia come in Germania, che si rivolgono a noi con uno shop lento.
Tutti gli importi sono valori basati su progetti di agenzia, IVA esclusa. Uno shop con 40 plugin e tema personalizzato costa di più da ripulire rispetto a uno shop con tema standard.
Nello shop Shopware del marchio cosmetico Banana Beauty, tempi di caricamento lenti e un’ottimizzazione mobile limitata frenavano conversioni e coinvolgimento. Dopo caching, compressione delle immagini, lazy loading e una CDN, secondo il case study i tempi di caricamento sono scesi del 40 % su tutti i dispositivi.
Per Miniature Market, rivenditore di giochi da tavolo e miniature con migliaia di articoli, il precedente shop Magento incontrava colli di bottiglia nei picchi di domanda legati alle nuove uscite. In Shopware 6 abbiamo ottimizzato ricerca e filtri con Elasticsearch, migliorato il caching delle categorie, distribuito gli asset tramite CDN e simulato le grandi uscite con test di carico e di stress. Secondo il case study, da allora lo shop offre risultati di ricerca più rapidi, filtri più fluidi e tempi di caricamento migliori, e gli abbandoni del carrello sono diminuiti.
Un’ottimizzazione dura più o meno fino al plugin successivo, per questo serve un controllo continuo dei risultati.
Nella maggior parte degli audit la HTTP cache è disattivata o viene svuotata di continuo, l’Admin Worker elabora la coda nel browser e troppi plugin e script di terze parti si caricano su ogni pagina. Una doppia richiesta della stessa pagina di categoria mostra in pochi secondi se manca la cache.
LCP fino a 2,5 secondi, INP fino a 200 millisecondi e CLS fino a 0,1, sempre al 75° percentile degli utenti mobile. La risposta del server (TTFB) è considerata buona fino a 800 millisecondi; dalla cache uno shop Shopware dovrebbe rispondere in meno di 100 millisecondi.
Non necessariamente: la HTTP cache integrata basta a molti shop fino a fatturati annui a sei cifre anche elevati. Varnish o Fastly convengono con picchi di carico dovuti a campagne o con più application server; da Shopware 6.7 è obbligatorio il modulo xkey.
Secondo i benchmark di Shopware sì: con Varnish il numero di ordini al secondo è cresciuto del 108 % e il JavaScript dello storefront si è ridotto del 25 %. Secondo endoflife.date la versione 6.6 riceve aggiornamenti di sicurezza fino al 28 febbraio 2028, ma nessuno di questi miglioramenti.
No. Shopware 5 è fuori supporto dal 31 luglio 2024 e non riceve più aggiornamenti di sicurezza regolari; il budget è investito meglio nella migrazione a Shopware 6.
Raramente sulle cause. Le estensioni per conversione delle immagini, cache warmup o lazy loading migliorano singoli aspetti, ma non sostituiscono né un’impostazione del server né un queue worker.
Il meno possibile. Con la Delayed Invalidation Shopware aggiorna da solo le pagine modificate ogni cinque minuti, mentre un cache:clear notturno butta via la full page cache e rende lo shop lento per tutti al mattino. Uno svuotamento completo appartiene ai deployment, non al cron.
Sì. Seguiamo merchant in Italia dalle nostre sedi di Brema, Prishtina e New York; audit e ottimizzazione possono essere svolti da remoto.
Vuole sapere quali degli interventi descritti mancano nel Suo shop e che cosa porterebbero? La nostra analisi dello shop gratuita misura tempi di caricamento e Core Web Vitals con dati di laboratorio e sul campo, scansiona il Suo shop e fornisce entro due giorni lavorativi un elenco di errori ordinato per priorità. Non richiede l’accesso al Suo server. Il servizio è disponibile anche per i merchant in Italia.
Per un audit delle prestazioni con profiling, test di carico e piano di realizzazione ci scriva. Le diremo in anticipo se l’impegno conviene per il Suo shop.
Maggiori informazioni sul nostro metodo di lavoro, sulle certificazioni e sulle sedi si trovano alla pagina Agenzia Shopware solution25.
Besar Bilalli è cofondatore e co-CEO di solution25, l’agenzia Shopware con sede a Brema. Prima di fondare l’agenzia nel 2017 ha costruito insieme a Besnik Bilalli un proprio negozio online senza capitale iniziale, portandolo a oltre 500 ordini al giorno. Da allora affianca i merchant nei progetti Shopware, dalla scelta del sistema alla gestione operativa. Risponde volentieri di persona alle domande sull’articolo: ci contatti.
Responsabile per contenuto e aggiornamento: Besar Bilalli. Aggiornato a: ottobre 2026. Prossima revisione dei contenuti: gennaio 2027.