Cloudflare cache voor WooCommerce: snelle webshop zonder kapotte winkelwagen

Cloudflare cache WooCommerce werkt prima, zolang je de dynamische pagina’s uitsluit.

Een typisch voorbeeldscenario uit mijn werkpraktijk: een shopeigenaar zet Cloudflare cache aan voor snelheidswinst, en kort daarna meldt iemand dat de winkelwagen producten van een andere bezoeker laat zien. Geen hack, geen plugin-conflict. Cloudflare cache stond verkeerd ingesteld, waardoor één bezoeker zijn winkelwagen-pagina aan de hele wereld liet zien, een paar uur lang. Tot iemand het zag en alarm sloeg.

Het is het soort fout dat begrijpelijk is. Cloudflare wordt vaak aangezet voor de snelheid, en de standaardinstellingen werken prima voor een blog of bedrijfssite. Maar een WooCommerce-shop heeft dynamische pagina’s die per bezoeker verschillen: winkelwagen, checkout, mijn account, soms productpagina’s met klantspecifieke prijzen. Die pagina’s mogen nooit gecached worden, en als ze dat per ongeluk wel worden, heb je een probleem.

Dit artikel laat zien hoe je Cloudflare cache zo opzet dat hij je shop sneller maakt zonder dat de winkelwagen-functionaliteit kapot gaat. Welke pagina’s en cookies je uitsluit, hoe je dat doet via Cache Rules in plaats van de oudere Page Rules, en hoe je achteraf test of het echt werkt. Aan het eind staat ook wanneer Cloudflare cache niet de juiste keuze is en je beter een server-side cache als LiteSpeed of FastCGI Cache pakt.

Cloudflare cache WooCommerce: waarom je het wilt

Een webshop heeft meestal twee soorten pagina’s. Statische pagina’s: de homepage, categoriepagina’s, productpagina’s voor anonieme bezoekers, de blog. Die zien er voor iedere bezoeker hetzelfde uit. En dynamische pagina’s: winkelwagen, checkout, mijn account, eventueel productpagina’s met gepersonaliseerde prijzen of voorraadinfo.

De statische pagina’s zijn precies waar cache zinvol is. Een productpagina hoeft niet bij elke bezoeker opnieuw door PHP en WooCommerce gegenereerd te worden. Eén keer maken, vervolgens duizend keer serveren vanuit Cloudflare’s netwerk in 30 milliseconden. Dat scheelt server-belasting en het scheelt laadtijd voor de bezoeker.

Cloudflare’s gratis plan ondersteunt de basis-cachefunctionaliteit. Voor een doorsnee MKB-shop met enkele duizenden bezoekers per maand is dat ruim voldoende. Pro- en Business-plannen voegen extra cachetypes en regels toe, maar voor de meeste shops is gratis genoeg.

Wat er fout kan gaan zonder de juiste instellingen

Het scenario van die ene shop is geen uitzondering. Wat zonder de juiste cookies-uitsluiting kan gebeuren:

• Bezoeker A logt in en bekijkt “Mijn account”. Cloudflare ziet een normale URL en cached de pagina, inclusief A’s persoonlijke gegevens.
• Bezoeker B opent dezelfde URL en krijgt A’s gegevens te zien. Of een winkelwagen waar producten in zitten die hij nooit heeft toegevoegd. Of een checkout met andermans adres.

Dit is een privacy-incident en, afhankelijk van de inhoud, een AVG-melding waard. Niet om paniek te zaaien: het is goed oplosbaar. Maar het is wel een reden om de basisinstellingen niet “even snel” aan te zetten zonder de cookies-laag erbij te denken.

De oude weg: Page Rules

Vroeger gebruikte je Page Rules om bepaalde URL’s uit te sluiten van caching. Voor WooCommerce werd het volgende aangeraden:

• /cart/* → Cache Level: Bypass
• /checkout/* → Cache Level: Bypass
• /my-account/* → Cache Level: Bypass

Dat werkt nog steeds. Page Rules zijn alleen aan de oude kant: je hebt op het gratis plan maar drie Page Rules, en de logica is beperkt. Sinds 2023 heeft Cloudflare Cache Rules als opvolger, met meer flexibiliteit en meer rules op het gratis plan (10 stuks). Voor nieuwe setups gebruik ik altijd Cache Rules.

Cache Rules opzetten

Cache Rules vind je onder Caching > Cache Rules in het Cloudflare-dashboard. Je maakt regels per URL-patroon of per cookie-aanwezigheid.

Regel 1: dynamische WooCommerce-pagina’s uitsluiten.

Naam: “Bypass cache for cart, checkout, my-account”

Expressie:

(http.request.uri.path contains "/cart") or
(http.request.uri.path contains "/checkout") or
(http.request.uri.path contains "/my-account") or
(http.request.uri.path contains "/wc-api") or
(http.request.uri.path contains "/wp-admin") or
(http.request.uri.path contains "/wp-login")

Actie: Bypass cache (en eventueel “Disable Apps”).

Hiermee zorg je dat de URL’s die altijd dynamisch moeten zijn, nooit gecached worden.

Regel 2: cookies-gebaseerde uitsluiting.

Naam: “Bypass cache for logged-in or shopping users”

Expressie:

(any(http.request.cookies["wordpress_logged_in_*"][*] != "")) or
(any(http.request.cookies["woocommerce_items_in_cart"][*] != "")) or
(any(http.request.cookies["woocommerce_cart_hash"][*] != "")) or
(any(http.request.cookies["wp_woocommerce_session_*"][*] != "")) or
(any(http.request.cookies["no_cache"][*] != ""))

Actie: Bypass cache.

Dit is de cruciale laag. Een ingelogde gebruiker (wordpress_logged_in_*) ziet vaak een andere navigatie, persoonlijke gegevens, of een ander winkelmandje. Een bezoeker met items in de cart (woocommerce_items_in_cart of woocommerce_cart_hash) heeft een sessie. Die mag nooit een gecachte pagina krijgen die voor anderen is bedoeld.

Het no_cache-cookie is een eigen escape: zet hem in een PHP-functie wanneer je een specifieke pagina niet wil cachen om welke reden dan ook. Handig voor uitzonderingen.

TTL en Edge Cache

Voor pagina’s die wel gecached mogen worden, regel je hoe lang Cloudflare ze bewaart. Onder Caching > Configuration staat de “Browser Cache TTL” (hoe lang de bezoeker zijn lokale kopie bewaart) en de “Edge Cache TTL” (hoe lang Cloudflare een kopie bewaart op zijn netwerk).

Voor een actieve webshop gebruik ik meestal:

• Browser Cache TTL: 4 uur (genoeg om herhaalde bezoeken snel te maken, kort genoeg om wijzigingen snel zichtbaar te krijgen)
• Edge Cache TTL: 1 maand voor statische assets (CSS, JS, afbeeldingen), korter (1 tot 4 uur) voor HTML-pagina’s

Statische assets identificeer je apart in een Cache Rule:

Naam: “Long cache for static assets”

Expressie:

(http.request.uri.path matches "\.(css|js|jpg|jpeg|png|gif|webp|woff|woff2|svg|ico)$")

Actie: Cache eligible, Edge TTL 1 maand.

Cloudflare APO: wel of niet?

Cloudflare biedt een betaalde extra “Automatic Platform Optimization (APO) for WordPress”. Dat is een module die WordPress-pagina’s specifiek gericht cached, inclusief automatische cookie-detectie. Het kost rond de 5 dollar per maand.

In mijn ervaring is APO handig voor mensen die geen tijd willen besteden aan handmatige regels. Het werkt redelijk goed met WooCommerce, mits je de juiste plugin-instellingen aanzet. Maar het is geen vervanging voor begrip van wat er gebeurt: ik heb shops gezien waar APO actief was, maar toch het winkelwagen-probleem kreeg omdat een aangepaste plugin een ongebruikelijk cookie gebruikte dat APO niet herkende.

Voor een eenvoudige shop is APO een prima keus. Voor een complexe shop, of voor wie controle wil houden, blijven handmatige Cache Rules de beste optie.

Hoe je test of het werkt

Testen is verplicht. Niet “ik heb het aangezet en het lijkt goed”. Echt testen, met DevTools open.

Test 1: een productpagina (mag gecached zijn).

1. Open in een privé-venster een productpagina.
2. Open DevTools (F12), tab Network.
3. Refresh de pagina.
4. Klik op de eerste request (het HTML-document).
5. Bekijk de response headers. Zoek naar cf-cache-status.

Verwacht: cf-cache-status: HIT na de eerste paar verzoeken, of in elk geval MISS gevolgd door HIT op een volgende request.

Test 2: de winkelwagen-pagina (mag NOOIT gecached zijn).

1. Voeg een product toe aan je winkelwagen.
2. Open /cart/ in een privé-venster.
3. DevTools, Network, refresh.
4. Bekijk cf-cache-status.

Verwacht: cf-cache-status: BYPASS of DYNAMIC. Krijg je HIT, dan zit er een gat in je Cache Rules en moet je het meteen oplossen.

Test 3: een ingelogde gebruiker.

1. Log in op je shop als testklant.
2. Open de homepage of een productpagina.
3. DevTools, cf-cache-status.

Verwacht: BYPASS of DYNAMIC. Ingelogde gebruikers krijgen vaak een ander menu en mogen geen gecachte HTML zien.

Doe deze drie tests altijd na een wijziging. Niet alleen op een laptop, maar ook op een mobiele browser, want sommige themes serveren andere HTML aan mobiele bezoekers.

Cloudflare en je server-side cache

Veel WooCommerce-shops gebruiken naast Cloudflare ook een lokale cache: WP Rocket, LiteSpeed Cache, FastCGI Cache, of WP Super Cache. Die twee bijten elkaar niet, maar je moet ze afstemmen.

In mijn werk werkt deze opzet vaak:

• Lokale cache (WP Rocket of LiteSpeed) doet de page cache aan de server-kant. Pagina’s worden naar statische HTML geschreven en direct door de webserver geserveerd, zonder PHP. Dat is razendsnel en bespaart server-CPU.
• Cloudflare cache zit voor de webserver. Hij vangt de eerste hit op en serveert dan vanaf zijn netwerk. De lokale cache wordt pas geraakt als Cloudflare nog geen kopie heeft.

De cookies-regels die ik hierboven beschreef, gelden voor allebei. WP Rocket en LiteSpeed hebben eigen instellingen voor uitgesloten cookies; die moeten matchen met je Cache Rules.

Wat ik niet doe: alleen Cloudflare gebruiken zonder lokale cache, behalve voor zeer kleine shops. Een lokale cache is gratis (in de juiste plugin) en geeft je een vangnet wanneer Cloudflare onverhoopt iets verkeerd doet.

Wanneer Cloudflare cache niet de juiste keus is

Niet elke shop heeft baat bij Cloudflare cache. Een paar situaties waarin ik soms adviseer om het uit te laten:

• Zeer dynamische shops waar bijna elke pagina per bezoeker verschilt (B2B met klantspecifieke prijzen, abonnementsshops met member-portalen). Hier is het cachebare oppervlak zo klein dat het beheer-overhead het niet waard is.
• Shops op LiteSpeed met een sterk geconfigureerde server-side cache. De winst van Cloudflare bovenop een goede LiteSpeed-cache is vaak verwaarloosbaar.
• Internationale shops met heel andere voorraad/prijzen per regio. Cloudflare’s edge-cache verspreidt globaal, en dat botst met regiospecifieke pagina’s.

In die gevallen gebruik ik Cloudflare nog wel voor SSL, DDoS-bescherming en DNS, maar zet ik de cache-laag op “Standard” zonder eigen regels. De Cloudflare Cache-documentatie gaat in detail op wat de verschillende cache levels betekenen.

Wat het kost om dit goed neer te zetten

Voor een doorsnee WooCommerce-shop met een paar honderd producten en geen bijzondere checkout-flow ben ik twee tot vier uur bezig. Cloudflare-account doorlopen, Cache Rules aanleggen, testen, en de lokale cache afstemmen. Dat zit op het standaard uurtarief van 70 euro per uur, dus 140 tot 280 euro voor de hele setup.

Bij sites met meerdere lagen (custom cookies, gepersonaliseerde productpagina’s, B2B-portal naast B2C-shop) kan het oplopen naar zes tot acht uur. Dan is het ook geen “cache aanzetten” meer, maar een uitgebreid optimalisatie-project. Dat doe ik graag, maar dan met een urenraming vooraf zodat je niet voor verrassingen komt.

Verbeteren boven herbouwen geldt ook hier: als je bestaande setup grotendeels werkt en alleen de cookies-uitsluiting mist, dan is dat een uur werk, niet een nieuwe configuratie van nul.

Meer over snelheidsoptimalisatie staat in de categorie webshop optimalisatie. De koppeling tussen shop en je verzending behandel ik in PostNL koppelen aan WooCommerce.