CDN voor WooCommerce: een installatiegids

Een WooCommerce-winkel draait goed achter een CDN als de edge de statische bestanden en de cataloguspagina's voor gasten levert, terwijl alles wat persoonlijk of transactioneel is rechtstreeks naar je server gaat: winkelwagen, checkout, de accountomgeving, bezoekers met een actieve winkelwagen, AJAX- en API-aanroepen en callbacks van betaalproviders. Het grootste deel van het werk zit in het goed instellen van die uitzonderingen, prijzen actueel houden met gerichte purges en een echte bestelling testen. Voor de rest van de prestaties van je webshop (cachingplug-ins, database, achtergrondtaken) lees je de gids over WooCommerce sneller maken.

Twee manieren om een CDN vóór een webshop te zetten

• Asset-CDN. Een plug-in herschrijft de URL's van afbeeldingen, CSS en JavaScript naar een CDN-hostnaam, terwijl elke pagina nog steeds van je server komt. Weinig risico, want geen enkele pagina wordt tussen klanten gedeeld, maar het traagste deel, het opbouwen van de HTML, blijft onaangeroerd.
• Full-site proxy. Elk verzoek gaat via de edge, HTML inbegrepen, dus een gecachete productpagina komt nooit bij PHP of de database uit. Daar zit de grotere winst, en daar vraagt WooCommerce om zorgvuldigheid: de edge is een gedeelde cache, en één verkeerde regel betekent dat klant B de winkelwagen van klant A ziet.

De rest van deze gids gaat over de tweede opzet. Vergelijk je nog aanbieders, dan behandelt de gids over een CDN voor WordPress kiezen de criteria.

Wat de edge veilig kan cachen

"Alleen voor gasten" is het sleutelwoord. Dezelfde product-URL kan er voor een ingelogde klant of voor iemand met artikelen in de winkelwagen anders uitzien, en de edge moet die verzoeken van elkaar kunnen onderscheiden.

Querystrings

Trackingparameters zoals utm_source maken per variant een aparte cache-entry aan, zodat een campagne ongemerkt hits in misses kan veranderen. Parameters die de inhoud veranderen, zoals orderby of filters uit de gelaagde navigatie, hebben terecht hun eigen entries nodig.

Wat altijd je server moet bereiken

Pagina's

De handleiding van WooCommerce over het configureren van cachingplug-ins (Engelstalig) noemt Cart, Checkout en My Account als pagina's die je moet uitsluiten. Dat geldt ook voor alles daaronder, zoals /checkout/order-received/ na de betaling en de bestel- en adrespagina's onder /my-account/. Heb je deze pagina's hernoemd of draai je een meertalige webshop, dan telt elke slug en elke taalversie.

WooCommerce helpt je hierbij: op de winkelwagen-, checkout- en accountpagina's stuurt het Cache-Control-headers mee die caching verbieden. Een CDN dat de headers van de origin respecteert, slaat ze dus niet op. Controleer wel of een caching- of beveiligingsplug-in op je site die headers niet overschrijft.

Cookies

Headers dekken alleen die drie pagina's af. Een productpagina die wordt bekeken door iemand met een volle winkelwagen heeft gewone, cachebare headers, maar kan wel zijn minicart tonen. De bypass moet dus ook van cookies afhangen. WooCommerce noemt deze:

• woocommerce_cart_hash en woocommerce_items_in_cart (gezet zodra er iets in de winkelwagen ligt)
• wp_woocommerce_session_* (de klantsessie)
• woocommerce_recently_viewed en store_notice[notice id] (alleen relevant als je de widget voor recent bekeken producten of de winkelmelding gebruikt)

Voeg daar de inlogcookie van WordPress aan toe, wordpress_logged_in_*, zodat ingelogde klanten en medewerkers altijd verse pagina's krijgen.

Endpoints

• ?wc-ajax=-verzoeken, voor toevoegen aan de winkelwagen, kortingscodes toepassen en de checkout vernieuwen
• /wp-admin/, admin-ajax.php en wp-login.php
• Links met ?add-to-cart=
• De Store API (Engelstalig) onder /wp-json/wc/store/v1/, waarop de blokgebaseerde winkelwagen en checkout draaien. De antwoorden weerspiegelen de sessie van de huidige klant.
• De geauthenticeerde REST API onder /wp-json/wc/v3/, die ERP-, voorraad- en marktplaatskoppelingen gebruiken
• Callbacks van betaalproviders (daarover hieronder meer)

De minicart op gecachete pagina's

Bij een klassiek thema vult het script voor cart fragments het aantal in de minicart op een gecachete pagina achteraf in: het roept ?wc-ajax=get_refreshed_fragments aan en bewaart het resultaat in de sessieopslag van de browser. Blokthema's laden winkelwagengegevens via hun eigen verzoeken, en die moeten net zo goed ongecachet blijven. De pagina kan juist gecachet worden omdat het persoonlijke deel via een apart, ongecachet verzoek binnenkomt. Wordt dat verzoek gecachet, dan ziet elke bezoeker hetzelfde aantal in de winkelwagen. Of je cart fragments überhaupt nodig hebt, lees je in de gids over WooCommerce sneller maken.

Prijzen, valuta en locaties

Een gedeelde cache werkt alleen als alles wat een pagina verandert zichtbaar is in de URL of wordt afgevangen door een bypass. Cookies en IP-adressen zijn onzichtbaar voor een cachesleutel die op de URL is gebaseerd.

• Geolocatie. Met gewoon "Geolocate" als standaardlocatie van klanten worden prijzen op de server voor het land van de bezoeker opgebouwd. Achter een gedeelde cache bepaalt het land van de eerste bezoeker dus wat iedereen ziet. De documentatie over de algemene instellingen (Engelstalig) van WooCommerce beschrijft voor dit geval "Geolocate (with page caching support)": die bepaalt de locatie via AJAX en voegt een parameter ?v= toe aan URL's. Elke variant wordt een eigen cache-entry, dus reken op meer misses.
• Valutawisselaars. Veel ervan bewaren de gekozen valuta in een cookie. Leidt die cookie niet tot een bypass, dan toont een gecachete pagina de valuta waarin hij voor het eerst is opgebouwd. Kies liever een wisselaar die de valuta in de URL zet of de prijzen in de browser laadt, en lees de documentatie over caching.
• Klantspecifieke prijzen. Groothandels- of rolgebaseerde prijzen zijn meestal alleen zichtbaar voor ingelogde gebruikers, en die omzeilen de cache toch al. Zorg dat de prijsweergave echt van het inloggen afhangt en niet van een aparte cookie.

Voorraad en prijzen actueel houden

Kies de levensduur van HTML op basis van wat een verouderde pagina je kost. Een contentpagina kan uren in de cache blijven; een productpagina met snel wisselende voorraad moet eerder verlopen of bij elke wijziging worden geleegd.

• Een los product bewerken. Leeg de cache van de product-URL, de categoriepagina's waarop het product staat, de winkelpagina en de homepage als het product daar wordt uitgelicht.
• Imports en ERP-synchronisaties. Laat de importtaak via de API van je CDN precies de URL's legen van de producten die zijn veranderd, in plaats van te wachten tot de pagina's verlopen.
• Geplande acties. Een actieprijs die om middernacht ingaat, komt niet vanzelf op een gecachete pagina terecht. Plan voor dat moment een purge in.
• Wijzigingen voor de hele site. Leeg na een thema-update of een actie voor de hele webshop alles, en warm daarna je belangrijkste categorieën en bestsellers op.

Of het legen automatisch gebeurt, hangt af van je opzet. Controleer hoe dan ook na een wijziging steekproefsgewijs de response-headers.

Callbacks van betaalproviders en de firewall

Betaalproviders bevestigen betalingen door je webshop rechtstreeks vanaf hun server aan te roepen. De Payment Gateway API (Engelstalig) van WooCommerce verwerkt die via wc-api-URL's, in de vorm /wc-api/<callback>/ of /?wc-api=<callback>. Veel plug-ins van betaalproviders registreren daarnaast webhookroutes onder /wp-json/. Mislukt een callback, dan blijven bestellingen op "in afwachting van betaling" staan, ook al heeft de klant betaald.

Deze verzoeken mogen nooit gecachet worden, en net zo belangrijk: ze mogen nooit geblokkeerd worden.

• Landenregels. De servers van een provider kunnen aanroepen vanuit een land dat je voor de hele site blokkeert of een challenge geeft.
• CAPTCHA-challenges. Een server kan geen CAPTCHA oplossen, dus beperk challengeregels tot paden die mensen gebruiken.
• Rate limits. Webhooks kunnen in golven binnenkomen, bijvoorbeeld na een reeks terugbetalingen. Stem de limieten per IP daarop af.
• Botregels. Callbacks en ERP-koppelingen zijn geautomatiseerde clients. Controleer of botregels ze niet aanmerken.

Een testplan voor de overstap

Voer het uit op staging als dat kan, en nog een keer direct na de nameserverwijziging (zie nameservers wijzigen zonder downtime).

1. Productpagina als gast. Vraag hem twee keer op. Het tweede antwoord moet een cache hit zijn.
2. Winkelwagen en checkout. Als gast moeten die een bypass of miss tonen, nooit een hit.
3. Actieve winkelwagen. Leg een product in de winkelwagen en herlaad een productpagina. Dat mag geen hit zijn, en de minicart moet je artikel tonen.
4. Twee browsers. Vul de winkelwagen in browser A. Browser B moet nog steeds een lege winkelwagen zien.
5. Ingelogde klant. Blader door de webshop en de accountomgeving. Niets mag uit de gedeelde cache komen.
6. Testbetaling. Rond een bestelling af in de sandbox- of testmodus van de betaalprovider en controleer of de bestelstatus verder gaat dan "in afwachting van betaling". Dat bewijst dat de callback is doorgekomen.
7. Purge. Wijzig een prijs, leeg de cache van de URL en controleer of de nieuwe prijs verschijnt.

Stuur voor de headercontrole het verzoek één keer zonder cookies en één keer met een winkelwagencookie:

curl -sI https://shop.example.com/product/example/ | grep -i -E "cache|age"
curl -sI -H "Cookie: woocommerce_items_in_cart=1" https://shop.example.com/product/example/ | grep -i cache

Het tweede verzoek mag niet als hit terugkomen. Slagen de functionele tests, vergelijk dan de snelheid voor en na met een tool zoals corewebvitals.page, die veldgegevens van echte gebruikers en een labmeting voor mobiel en desktop laat zien.

Zo helpt fast.site je

fast.site is een full-site proxy die vóór je bestaande WooCommerce-hosting staat. Je houdt je hoster, voegt je domein toe in het dashboard en zet je nameservers over naar fast.site. Vanaf dat moment beheert fast.site je DNS, dus alle bestaande records, inclusief de MX-records voor de e-mail van je webshop, moeten in de DNS-zone van fast.site staan.

Fast Edge Cache™ levert product-, categorie- en contentpagina's voor gasten vanaf de edge in de regio's die bij je abonnement horen, en een cache HIT bereikt je server nooit. fast.site respecteert de Cache-Control-headers van je origin, en privé- of dynamische antwoorden zoals winkelwagen, checkout en ingelogde sessies tonen fs-cache: BYPASS. Zo kun je elke stap van het testplan hierboven controleren (zie de cache controleren). Na imports of prijswijzigingen 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 eigen scripts.

Aan de edge zet fast.site productafbeeldingen ook om naar WebP voor browsers die het ondersteunen (AVIF afhankelijk van je abonnement) en filtert het HTTP-floods en schadelijke bots voordat ze je webshop bereiken, met firewallregels die je zelf beheert. De details vind je op de WooCommerce-pagina.

Meet je webshop voor en na op je eigen pagina's, inclusief een volledige testbestelling. Je kunt beginnen met een gratis proefperiode van 7 dagen.

Veelgestelde vragen

Heb ik een CDN nodig voor WooCommerce?

Niet elke webshop heeft er een nodig. Zitten de meeste klanten dicht bij je server en zijn je pagina's al snel, dan volstaat betere hosting of een asset-CDN misschien. Een full-site CDN loont vooral bij bezoekers in meerdere regio's, pieken in het verkeer door campagnes of een server die het zwaar heeft.

Kan een CDN WooCommerce-productpagina's cachen?

Ja, voor gasten. Product-, categorie- en winkelpagina's kun je cachen, zolang verzoeken met winkelwagen- of sessiecookies van WooCommerce en ingelogde gebruikers de cache omzeilen. Leeg de cache van product-URL's als de prijs of voorraad verandert.

Maakt een CDN mijn WooCommerce-checkout kapot?

Niet als winkelwagen, checkout, accountpagina's, wc-ajax-verzoeken, de Store API en callbacks van betaalproviders de cache omzeilen en niet door firewallregels worden geblokkeerd. Test na elke configuratiewijziging een volledige bestelling met een sandboxbetaling.

Moet ik mijn cachingplug-in houden als ik een CDN gebruik?

Vaak wel. Een plug-in voor paginacaching versnelt de verzoeken die je server wel bereiken, zoals cache misses. Zorg dat de plug-in en het CDN dezelfde uitzonderingen hanteren, en leeg na wijzigingen beide caches.