Shopware 6-prestaties: HTTP-cache, CDN en veelgemaakte fouten

Een trage Shopware 6-storefront is zelden een raadsel. Meestal staat de HTTP-cache uit of wordt hij voortdurend ongeldig gemaakt, draaien achtergrondtaken op de verkeerde plek of doet de server bij elk verzoek zwaar werk dat hij zou kunnen overslaan. In deze gids lees je hoe de HTTP-cache van Shopware 6 werkt, hoe je hem controleert, waar een CDN helpt en welke configuratiefouten het vaakst voorkomen.

Zo werkt de HTTP-cache van Shopware 6

Shopware 6 heeft een ingebouwde full-page cache voor de storefront. Staat die aan, dan wordt het eerste verzoek voor een pagina (bijvoorbeeld een categorie- of productdetailpagina) door PHP opgebouwd en opgeslagen. Volgende verzoeken voor dezelfde pagina krijgen de opgeslagen kopie, zonder dat de hele applicatie opnieuw draait. Dat is verreweg de grootste hefboom voor de snelheid van je storefront.

Hoe goed dat werkt, hangt van een paar dingen af:

• Hij moet aanstaan. De cache wordt geregeld met de omgevingsvariabele SHOPWARE_HTTP_CACHE_ENABLED=1, meestal in .env.local.
• Opslag. Standaard staat de cache op het bestandssysteem onder var/cache. Voor één server is dat prima. Draai je meerdere app-servers, dan raadt de cachingdocumentatie van Shopware (Engelstalig) een gedeelde cache zoals Redis aan.
• Varianten per context. Een pagina kan er anders uitzien afhankelijk van of de bezoeker is ingelogd, welke valuta en btw-instelling gelden en welke prijsregels van toepassing zijn. Shopware vat dat samen in de cookie sw-cache-hash en bewaart per hash een aparte variant, zodat de ene klant nooit de prijzen van een andere klant ziet. Bezoekers in de standaardtoestand (niet ingelogd, standaardvaluta, lege winkelwagen) delen dezelfde gecachete pagina's.
• Invalidatie via tags. Gecachete antwoorden krijgen tags mee voor de data waaruit ze zijn opgebouwd. Wijzig je een product, dan gooit Shopware alleen de gecachete pagina's met die tag weg in plaats van alles te wissen. Lijstroutes zoals productoverzichten, categorieoverzichten en zoekresultaten krijgen niet de tags van elke entiteit die ze tonen en leunen op hun cacheduur. Een wijziging kan daar dus even duren voordat hij zichtbaar is.

Ingebouwde cache of reverse proxy

Voor grotere webshops ondersteunt Shopware een externe reverse proxy, namelijk Varnish met de XKey-module of Fastly. De proxy bewaart de pagina's en Shopware stuurt hem invalidatieverzoeken met de betrokken tags. Sinds Shopware 6.6 configureer je dat onder shopware.http_cache.reverse_proxy (oudere versies gebruiken storefront.reverse_proxy) en stel je SYMFONY_TRUSTED_PROXIES in, zodat de applicatie de echte IP-adressen van bezoekers ziet. De volledige installatie staat in de documentatie over de reverse HTTP-cache (Engelstalig).

Een reverse proxy haalt bij gecachete hits alle belasting bij PHP weg, en dat telt in piekuren. Het is wel een extra onderdeel dat je moet draaien en bewaken. Voor veel kleine en middelgrote webshops volstaat de ingebouwde cache met Redis.

Controleer of de cache werkt

Zoek eerst uit wat er echt gebeurt voordat je iets verandert. Open een categoriepagina twee keer in een privévenster en vergelijk de responstijden op het netwerktabblad van je browser. Werkt de cache, dan is het tweede verzoek duidelijk sneller. Op de commandline:

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

Zijn beide verzoeken even traag, dan staat de cache uit, wordt hij door een cookie omzeild of wordt hij tussen de twee verzoeken ongeldig gemaakt. Kijk ook naar de header Cache-Control. Die vertelt elke proxy of elk CDN vóór Shopware of de pagina opgeslagen mag worden.

Voor een gestructureerde voor-en-navergelijking is TTFB (Engelstalig) de meetwaarde aan de serverkant. Onze gids over TTFB verlagen gaat dieper in op server en applicatie.

Veelgemaakte configuratiefouten

Deze problemen verklaren het vaakst waarom een Shopware 6-webshop stroperig aanvoelt.

Draaien in dev-modus of met debug aan

APP_ENV=dev schakelt de profiler en debugfuncties in, en die maken elk verzoek trager. Een live webshop hoort op APP_ENV=prod te staan. Zet in productie ook het logniveau op error of iets vergelijkbaars, want uitgebreide logging schrijft bij elk verzoek naar schijf.

De admin worker verwerkt achtergrondtaken

Standaard kan Shopware berichten uit de wachtrij (indexering, e-mails, imports) via de administratie verwerken zolang een beheerder de backend open heeft. Handig tijdens de ontwikkeling, maar in productie wordt achtergrondwerk daardoor onvoorspelbaar en belast het de webserver. De documentatie over de message queue (Engelstalig) is daar duidelijk over: verwerk de wachtrij in productie via de CLI. Zet shopware.admin_worker.enable_admin_worker: false in config/packages/shopware.yaml en laat bin/console messenger:consume async als achtergrondproces draaien, bewaakt door systemd of supervisor, plus bin/console scheduled-task:run voor geplande taken.

Invalidatiestormen

ERP-synchronisaties, voorraadupdates en prijsimports raken veel producten tegelijk. Elke wijziging maakt gecachete pagina's ongeldig, dus een import die om de paar minuten draait, kan je cache vrijwel permanent leeg houden. Mogelijke oplossingen: bundel imports in minder runs, schrijf alleen velden weg die echt veranderd zijn en gebruik vertraagde invalidatie. Shopware verzamelt dan de tags die ongeldig moeten worden en verwerkt ze later in een achtergrondtaak. Standaard staat die lijst in de database; de documentatie over performance tweaks (Engelstalig) raadt Redis als opslag aan waar dat kan.

Extensies die caching breken

Plug-ins kunnen cookies zetten, gepersonaliseerde blokken toevoegen of bij elk verzoek de context veranderen. Elk daarvan kan leiden tot een aparte cachevariant per bezoeker, en dan heb je in feite geen cache. Is je cache-hitratio ingestort na het installeren van een extensie, test dan op een stagingkopie met de extensie uitgeschakeld.

MySQL-zoekopdrachten in een grote catalogus

Bij grotere catalogi zijn productzoekopdrachten en gefilterde overzichten zwaar voor MySQL. Shopware ondersteunt Elasticsearch of OpenSearch voor zoeken en productoverzichten in de storefront. Zoekresultaten worden meestal niet als volledige pagina gecachet, dus dit raakt direct de pagina's waar bezoekers typen en filteren.

PHP en OPcache

Zorg dat OPcache aanstaat en groot genoeg is voor de codebase van Shopware. In productie voorkomt opcache.validate_timestamps=0 dat bij elk verzoek bestanden worden gecontroleerd (je moet OPcache dan wel resetten bij elke deploy). Gebruik een actuele PHP-versie die je Shopware-release ondersteunt.

Zware afbeeldingen en thema-assets

Productfoto's rechtstreeks uit de camera, ontbrekende thumbnails of enorme herobanners schaden de Largest Contentful Paint (Engelstalig). Laat Shopware thumbnails genereren, upload afbeeldingen met redelijke afmetingen en overweeg moderne formaten. Onze gids over afbeeldingen optimaliseren voor het web behandelt de details.

Waar een CDN helpt (en waar niet)

Een CDN zit tussen je bezoekers en je Shopware-server en levert content vanaf locaties dichter bij die bezoekers.

Wat een CDN niet oplost: trage ongecachete verzoeken. Duurt de checkout enkele seconden door een trage betaalplug-in of een overbelaste database, dan geeft het CDN die tijd gewoon door. Los eerst de origin op en voeg daarna de edge-laag toe.

Een logische volgorde van werken

1. Zet APP_ENV=prod, beperk de logging en controleer OPcache.
2. Schakel de HTTP-cache in en bevestig dat hij voor gasten werkt.
3. Verplaats achtergrondtaken naar CLI-workers en schakel de admin worker uit.
4. Tem je imports, zodat ze de cache niet steeds leegspoelen.
5. Voeg Redis toe (en voor grote webshops OpenSearch) waar de belasting daarom vraagt.
6. Optimaliseer afbeeldingen en thema-assets.
7. Zet een edge-laag ervoor voor statische assets, gastpagina's en bescherming.

Meet na elke stap, het liefst met dezelfde pagina's en tools, zodat je weet wat echt verschil maakte. Draai je ook WooCommerce, dan gelden vergelijkbare principes: zie WooCommerce sneller maken zonder de checkout te breken.

Zo helpt fast.site je

fast.site staat vóór je bestaande Shopware-hosting. Je houdt je hoster en je Shopware-installatie, voegt het domein toe in het dashboard en laat de nameservers van je domein naar fast.site wijzen.

Fast Edge Cache™ bewaart openbare antwoorden aan de edge. Hoe lang ze geldig blijven, volgt de Cache-Control-headers die je webshop meestuurt of regels die je zelf instelt, en via de header fs-cache (HIT, MISS of BYPASS) controleer je elk antwoord. Winkelwagen, checkout, account en andere sessiegebonden pagina's omzeilen de cache, zodat bestellingen gewoon blijven werken. Na grotere catalogiwijzigingen leeg je de cache per URL in het dashboard of via de API, en de cache warmer houdt belangrijke pagina's warm.

Daarnaast worden afbeeldingen voor browsers die het ondersteunen direct naar WebP omgezet (AVIF afhankelijk van je abonnement), worden tekstbestanden met Brotli gecomprimeerd en filteren Layer 7-DDoS-detectie, rate limiting en botregels het verkeer voordat het je server bereikt. De Shopware-pagina en het artikel over de Shopware-integratie laten de installatie stap voor stap zien.

De eerlijkste test is je eigen webshop: vergelijk TTFB en Core Web Vitals voor en na. Je kunt beginnen met een gratis proefperiode van 7 dagen, zonder creditcard.

Veelgestelde vragen

Hoe schakel ik de HTTP-cache in Shopware 6 in?

Zet SHOPWARE_HTTP_CACHE_ENABLED=1 in je .env.local en leeg daarna de cache. Zorg dat de webshop draait met APP_ENV=prod. Open vervolgens als gast twee keer een categoriepagina en controleer of het tweede verzoek merkbaar sneller is.

Waarom is mijn Shopware-webshop traag terwijl de HTTP-cache aanstaat?

Veelvoorkomende oorzaken zijn frequente invalidatie door imports, extensies die cookies zetten of pagina's personaliseren, en trage ongecachete pagina's zoals zoeken, winkelwagen en checkout. Controleer of gastpagina's echt uit de cache komen en kijk daarna wat er bij de ongecachete verzoeken draait.

Heb ik Varnish nodig voor Shopware 6?

Niet per se. De ingebouwde cache volstaat voor veel webshops, zeker met Redis als opslag. Varnish of een andere reverse proxy loont als je meerdere app-servers of veel verkeer hebt, maar het is extra infrastructuur die je moet beheren.

Kan ik een CDN gebruiken met Shopware 6?

Ja. Statische assets en afbeeldingen zijn eenvoudig via een CDN te leveren. HTML-pagina's voor gasten kun je ook cachen, zolang het CDN de cacheheaders van Shopware respecteert, winkelwagen-, checkout- en accountpagina's overslaat en je een manier hebt om de cache na wijzigingen te legen.

Hoe leeg ik de cache van Shopware?

In zelf gehoste webshops open je in de administratie Settings > System > Caches & Indexes en gebruik je Clear cache, of je voert bin/console cache:clear uit op de commandline. Gebruik je een reverse proxy, dan leegt bin/console cache:clear:http (beschikbaar sinds Shopware 6.6.10) die cache. Alles legen betekent vaak dat de volgende bezoekers op een koude cache stuiten, dus doe het buiten de piekuren.