Start je gratis proefperiode van 7 dagenGeen creditcard nodig

Platforms

CDN voor Shopware 6: wat mag in de cache en wat niet

Zo zet je een CDN voor een Shopware 6-storefront: welke antwoorden aan de edge gecachet mogen worden, hoe je de cache leegt en hoe je alles test.

10 min lezen

Een CDN vóór Shopware 6 levert op twee plekken winst op: bij statische bestanden zoals CSS, JavaScript van het thema en productafbeeldingen, die lang aan de edge kunnen blijven, en bij HTML-pagina's voor gasten in de standaardtoestand van Shopware, die een korte levensduur en een plan voor het legen van de cache nodig hebben. Alles wat persoonlijk is, van winkelwagen en checkout tot accountpagina's, ingelogde klanten en gasten die van valuta zijn gewisseld, moet rechtstreeks naar je Shopware-server. In deze gids lees je waar je die grens trekt, hoe je de cache leegt en hoe je alles test.

Het afstellen van de webshop zelf (HTTP-cache, workers, OPcache, imports) behandelen we in onze gids over Shopware 6-prestaties. Hier gaat het om de laag die ervoor staat.

Asset-CDN of full-site CDN

Asset-CDN. Shopware kan de URL's van openbare bestanden op een aparte hostnaam genereren. In de configuratie van het bestandssysteem (Engelstalig) stel je een url in voor het bestandssysteem public, en de bestandssystemen voor thema, assets en sitemap nemen die standaard over. Daarmee veranderen alleen de URL's in de pagina. Het CDN haalt de bestanden nog steeds op van je server of bucket, en elk HTML-verzoek komt nog steeds bij Shopware uit.

Full-site CDN. Het hele domein loopt via het CDN, ingesteld via nameservers of DNS, afhankelijk van de aanbieder. De edge ziet elk verzoek, inclusief HTML, en kan schadelijk verkeer filteren voordat het je server bereikt. De winst is groter, en de verantwoordelijkheid ook: het CDN moet precies weten welke antwoorden het mag opslaan.

Statische bestanden zijn het makkelijke deel

Gecompileerde themabestanden kunnen prima lang aan de edge blijven: bij elke compilatie schrijft Shopware CSS en JavaScript naar een nieuwe map onder theme/ met een nieuwe hash in de naam, zodat de URL's veranderen. Productafbeeldingen en thumbnails veranderen zelden en vormen vaak het grootste deel van de bytes op een pagina. Onze gids over afbeeldingen optimaliseren voor het web behandelt formaten en afmetingen.

De uitzondering is een bestand dat onder dezelfde URL wordt vervangen, zoals een CMS-afbeelding met een ongewijzigde bestandsnaam. Leeg de cache van die URL als je het bestand verwisselt.

Welke Shopware-pagina's je veilig kunt cachen

Shopware cachet niet één pagina voor iedereen. Volgens de documentatie over de HTTP-cache (Engelstalig) zet het een cookie sw-cache-hash zodra de toestand van een bezoeker afwijkt van de standaard, en die standaard is: geen ingelogde klant, de standaardvaluta en een lege winkelwagen. De hash legt de inlogstatus, de valuta, de btw-weergave en de cacherelevante regels vast die van toepassing zijn, en Shopware houdt per hash een aparte cachevariant bij. Bezoekers in de standaardtoestand delen één variant.

Een CDN dat zijn cache alleen op de URL baseert, weet niets van die varianten. De regel voor HTML is dus: cache alleen wat een gast in de standaardtoestand ziet, en stuur elk verzoek met sw-cache-hash door naar Shopware.

VerzoekCachen aan de edge?Waarom
Themabestanden, media, thumbnailsJa, lange levensduurVoor iedereen gelijk, thema-URL's veranderen bij compileren
Home-, categorie-, product- en CMS-pagina's voor gasten zonder sw-cache-hashJa, korte levensduurGedeeld door alle bezoekers in de standaardtoestand, Shopware cachet ze ook
Dezelfde pagina's met een cookie sw-cache-hashNee, bypassPrijzen, valuta of btw-weergave kunnen per variant verschillen
/checkout/cart, /checkout/confirm, /checkout/finish, winkelwagenwidgetsNeePersoonlijk, Shopware markeert deze routes niet als cachebaar
/account en alles daaronder, inclusief /account/loginNeePersoonsgegevens en formulieren
Zoekresultaten (/search)Meestal nietEindeloze URL-varianten, Shopware cachet de zoekpagina zelf niet
Elk POST-verzoekNooitShopware behandelt alleen GET-verzoeken als cachebaar

Prijzen per klantgroep en andere inhoud die door regels wordt bepaald, komen ook in de hash terecht, dus zulke bezoekers mogen nooit de gecachete standaardpagina krijgen.

Respecteer Cache-Control en cookies

De edge hoort niet te raden wat cachebaar is, want Shopware geeft dat al aan. Staat de HTTP-cache aan, dan krijgen cachebare storefront-antwoorden een levensduur voor gedeelde caches mee (s-maxage); de documentatie over reverse proxy's toont Cache-Control: public, s-maxage=7200 als voorbeeld. Antwoorden voor ingelogde klanten of gevulde winkelwagens krijgen die headers niet.

Welk CDN je ook gebruikt, er gelden twee regels:

  1. Sla alleen op wat Shopware als openbaar markeert. Sla nooit antwoorden op met private, no-cache of no-store, en nooit een antwoord dat een cookie zet. Een algemene regel die "alles cachet" gaat voorbij aan de beslissingen van Shopware, en zo krijgt de ene klant de winkelwagen van een andere te zien.
  2. Laat verzoeken met sw-cache-hash de edge-cache omzeilen, of neem die cookie op in de cachesleutel. Negeert het CDN de cookie, dan kan een gast die van valuta is gewisseld de pagina in de standaardvaluta van de edge krijgen. Erger nog: zijn variant kan worden opgeslagen en aan iedereen worden geleverd.

Wil je levensduren aanpassen, doe dat dan in Shopware en niet aan de edge. Nieuwere versies bieden HTTP-cachingbeleid (Engelstalig) met instructies zoals s_maxage en stale_while_revalidate per onderdeel of route. De documentatie noemt dit experimenteel en gepland als standaard voor Shopware 6.8, dus controleer je versie.

Varnish, Fastly en een generiek CDN

Shopware ondersteunt officieel twee reverse proxy's: Varnish met de XKey-module en Fastly. Beide zijn gekoppeld aan de invalidatie: gecachete antwoorden krijgen tags (surrogate keys) mee voor de data waaruit ze zijn opgebouwd, en bewerk je een product, dan stuurt Shopware de proxy een invalidatieverzoek voor precies die tags. Sinds Shopware 6.6 stel je dat in onder shopware.http_cache.reverse_proxy. De documentatie over de reverse HTTP-cache (Engelstalig) beschrijft de volledige installatie.

Een generiek CDN maakt geen deel uit van die kringloop. De tag-invalidatie van Shopware bereikt de eigen cache en een geconfigureerde reverse proxy, maar geen edge-netwerk dat Shopware niet kent. Een gecachete categoriepagina blijft aan de edge staan tot de levensduur verloopt of tot jij de cache leegt.

Een proxy met tags geeft je precieze invalidatie voor grote catalogi die snel veranderen, maar het is weer een systeem dat je moet draaien. Een generiek full-site CDN voeg je eenvoudiger toe en brengt levering vanaf de edge en bescherming mee, maar hoe actueel je HTML is, hangt af van korte levensduren en je eigen purges. Sommige webshops combineren beide.

De cache legen zonder tags

Korte levensduur voor HTML. Houd HTML voor gasten minuten in plaats van uren aan de edge, terwijl themabestanden en afbeeldingen veel langer blijven. Een verouderde kopie aan de edge verdwijnt dan na hooguit één levensduur, ook zonder purge. De ingebouwde cache van Shopware vangt de extra misses op.

URL's legen na grotere wijzigingen. Start er een actie, veranderen de prijzen in een hele categorie of pas je de navigatie aan, leeg dan de cache van de betrokken URL's. Wijzigingen die op elke pagina te zien zijn, zoals het hoofdmenu, de footer of een opnieuw gecompileerd thema, rechtvaardigen het legen van het hele domein, het liefst buiten de piekuren.

Purges vanuit je scripts. De meeste CDN's, fast.site inbegrepen, bieden een API om de cache te legen. Laat je ERP- of prijsimport eindigen met een aanroep die de geraakte URL's leegt, en laat je deploymentpipeline na theme:compile de cache legen.

Echte IP-adressen van bezoekers en vertrouwde proxy's

Achter een CDN komt elk verzoek bij Shopware binnen vanaf een edge-server. Het echte IP-adres van de bezoeker reist mee in een header zoals X-Forwarded-For, en Symfony leest die alleen uit bij proxy's die je vertrouwt via SYMFONY_TRUSTED_PROXIES in je .env (de naam van de variabele sinds Shopware 6.6). Schakel je een CDN en Varnish achter elkaar, vertrouw dan beide stappen.

Dat is niet alleen van belang voor je logs. Betaal- en fraudeplug-ins controleren vaak het IP-adres van de bezoeker, en de rate limiters van Shopware voor inloggen, wachtwoordherstel en het contactformulier worden minder precies als alle verzoeken van een paar adressen lijken te komen.

Zo test je je CDN-opzet voor Shopware

1. Twee keer een verzoek als gast. Het tweede verzoek moet van de edge komen:

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'

Bij fast.site zoek je naar fs-cache: HIT en een oplopende fs-cache-age (zie de cache controleren). Andere CDN's sturen meestal een header Age en hun eigen statusheader mee. Wordt de pagina nooit een HIT, vergelijk dan de header Cache-Control met de regels hierboven.

2. Persoonlijke routes. Controleer /checkout/cart en /account/login op dezelfde manier. Die mogen nooit een HIT tonen.

3. Een volledige checkout. Leg in een privévenster een product in de winkelwagen, controleer of de teller van de winkelwagen bijwerkt en rond de checkout af met een testbetaalmethode. Annuleer de testbestelling daarna.

4. Ingelogde klant. Log in met een testaccount, het liefst een met prijzen per klantgroep. De pagina's moeten de prijzen van die klant tonen, en na het uitloggen moet de gastweergave terugkomen.

5. Valuta wisselen. Wissel als gast naar een tweede valuta en blader door een paar categorieën. Open daarna dezelfde pagina's in een nieuw privévenster: die moeten de standaardvaluta tonen. Herhaal het in omgekeerde volgorde. Zo betrap je een CDN dat sw-cache-hash negeert.

Heb je meerdere verkoopkanalen of talen, herhaal dan stap 1 en 5 per domein. Voor de snelheid vergelijk je de gegevens van echte gebruikers en een labmeting op corewebvitals.page voor en na, zoals beschreven in websitesnelheid goed meten.

Zo helpt fast.site je

fast.site is een full-site edge-laag vóór je bestaande Shopware-hosting. Je houdt je hoster, voegt het domein toe in het dashboard en laat de nameservers naar fast.site wijzen; onze checklist voor nameservers helpt je om DNS-records en e-mail intact te houden.

Fast Edge Cache™ respecteert de Cache-Control-headers die je webshop meestuurt. Privé- en dynamische antwoorden zoals winkelwagen, checkout en ingelogde sessies tonen fs-cache: BYPASS, zodat je het testplan hierboven direct kunt uitvoeren. fast.site ontvangt de tag-invalidaties van Shopware niet. In plaats daarvan leeg je de cache van losse URL's of van het hele domein in het dashboard, met een logboek, of via de API vanuit je import- en deploymentscripts. Een cache warmer houdt belangrijke pagina's warm.

Afbeeldingen worden direct naar WebP omgezet (AVIF afhankelijk van je abonnement), tekstbestanden worden met Brotli gecomprimeerd, en Layer 7-DDoS-detectie, rate limiting en botregels filteren het verkeer aan de edge. Op de Shopware-pagina vind je de details.

Meet het resultaat in je eigen webshop, met dezelfde pagina's voor en na. Je kunt beginnen met een gratis proefperiode van 7 dagen, zonder creditcard.

Veelgestelde vragen

Heeft Shopware 6 een ingebouwd CDN?

Nee. Shopware heeft een ingebouwde HTTP-cache op je server, en je kunt een aparte URL instellen voor openbare bestanden, zodat die via een CDN-hostnaam laden. Als reverse proxy integreert Shopware officieel Varnish met XKey en Fastly.

Kan ik HTML-pagina's van Shopware op een CDN cachen?

Ja, voor gasten in de standaardtoestand: niet ingelogd, standaardvaluta, lege winkelwagen. Het CDN moet de Cache-Control-headers van Shopware respecteren, verzoeken met de cookie sw-cache-hash overslaan en nooit winkelwagen-, checkout- of accountpagina's cachen.

Waarom kloppen de winkelwagen of de prijs niet meer sinds ik een CDN gebruik?

Meestal cachet de edge iets persoonlijks: een antwoord dat een cookie zet, een pagina die met sw-cache-hash is opgevraagd, of een checkoutroute die onder een regel valt die "alles cachet". Verwijder die regel, leeg de cache van het domein en herhaal de tests.

Heb ik achter een CDN nog de HTTP-cache van Shopware nodig?

Ja. Elke miss aan de edge en elk verzoek met een cookie sw-cache-hash komt op je server terecht. De ingebouwde cache houdt die verzoeken snel, en korte levensduren aan de edge werken alleen goed met een snelle origin.

Hoe leeg ik de CDN-cache na wijzigingen in Shopware?

bin/console cache:clear en cache:clear:http van Shopware bereiken geen generiek CDN. Leeg de cache van de betrokken URL's of van het hele domein in het dashboard van het CDN, of via de API vanuit het script dat de wijziging heeft gedaan.

Test fast.site met je eigen website

fast.site voegt edge-caching, afbeeldingsoptimalisatie en DDoS-bescherming toe aan je bestaande hosting. Koppel je domein en meet het verschil op je eigen pagina's.

Geef je website 7 dagen. Laat de resultaten beslissen.

Begin met je eigen domein, je eigen verkeer en duidelijkheid over wat daarna gebeurt.