CDN configuratie voor e-commerce — Cloudflare vs Fastly vs CloudFront

CDN configuratie voor e-commerce — Cloudflare vs Fastly vs CloudFront

Een slecht geconfigureerde CDN vertraagt je webshop in plaats van te versnellen. Wij zien het regelmatig bij klanten die binnenkomen: een CDN actief, maar HTML-pagina's worden gecached inclusief de persoonlijke header, of checkout-pagina's leveren stale content. Het resultaat: buggy gedrag, conversieverlies, gefrustreerde klanten.

Een CDN correct inzetten voor e-commerce is geen kwestie van een knop omzetten. Het vraagt om doordachte cache-regels, begrip van wat je wel en niet kunt cachen, en een keuze voor de provider die bij jouw stack past.

Onderzoek van Google laat zien dat een vertraging van 100ms de conversie met gemiddeld 1% verlaagt. Op een webshop met €500k jaaromzet is dat €5.000 per 100ms. Een CDN die correct is geconfigureerd compenseert latency voor bezoekers buiten je serverregio, verlaagt de server-load, en verbetering van Time to First Byte met 30-60% is realistisch. Maar alleen als de fundamenten kloppen.

Wat cachet een CDN — en wat niet

De basisregel: statische assets cache je agressief, HTML cache je met mate, en gepersonaliseerde content cache je nooit op de edge.

Statische assets: maximale cache-TTL

CSS, JavaScript, fonts, en images hebben na een productie-build een unieke hash in de bestandsnaam (app.a3f9d2.js). Die kun je jarenlang cachen. Gebruik een Cache-Control-header als:

Cache-Control: public, max-age=31536000, immutable

De immutable-flag vertelt de browser dat het bestand nooit wijzigt — geen revalidatie nodig. Op CDN-niveau stel je de TTL eveneens in op een jaar. Bij Cloudflare heet dit een "Edge Cache TTL"-regel; bij CloudFront configureer je het via een Cache Policy.

HTML-pagina's: kort cachen of bypass

Categorie- en productpagina's zijn interessant. Ze zijn grotendeels identiek voor elke bezoeker, maar bevatten vaak een mini-cart, een inlogstatus, of een "recent bekeken"-blok. Twee aanpakken:

# Nginx: stale-while-revalidate voor categoriepagina's
location /categorie/ {
    proxy_cache_valid 200 60s;
    add_header Cache-Control "public, s-maxage=60, stale-while-revalidate=30";
}

Checkout en account: altijd bypass

Cart, checkout, account, en orderpagina's mogen nooit gecached worden op de edge. Gebruik een expliciete bypass-regel op URL-patroon én op cookies.

Bypass cache als: URL bevat /checkout/ OF /cart/ OF /account/
Bypass cache als: cookie aanwezig is: session, PHPSESSID, customer_token

Bij Magento en Hyva-projecten voeg je standaard een no-store-header toe op die routes. Wij hanteren dit als vaste baseline in onze Magento-deployments — geen discussie.

Personalisatie aan de edge

Personalisatie en CDN-caching lijken tegenstrijdig. Dat zijn ze ook, tenzij je slim segmenteert.

De aanpak die wij gebruiken: zet een anonieme cache-variant neer op de edge, en gebruik client-side JavaScript (of een Edge Worker) om persoonlijke data in te laden. Zo profiteer je van de CDN-snelheid voor de HTML-shell, zonder gepersonaliseerde content te lekken naar de verkeerde bezoeker.

Bij Shopify Plus is dit ingebakken via hun "Ajax Cart" en section-rendering API. Bij een custom Laravel-webshop bouw je dit zelf. De structuur:

• Edge levert gecachte HTML-shell
• Client haalt /api/cart en /api/customer op via een gecachte-bypass route
• Fragmenten worden client-side gerenderd

Dit patroon schaalt goed en houdt je cache-hit ratio hoog — doorgaans 85-95% op categorie- en productpagina's.

Image optimization aan de edge

Images zijn verantwoordelijk voor gemiddeld 40-60% van het totale paginagewicht op e-commerce sites. De meeste CDN's bieden tegenwoordig image optimization als feature.

In de praktijk: voor een Magento-webshop met een bestaande Hyvä-frontend is Cloudflare Polish de snelste win — weinig configuratie, direct resultaat. Voor een headless setup met eigen image pipeline kijk je eerder naar Fastly of een dedicated image CDN.

Cloudflare vs Fastly vs CloudFront: vergelijking

Prijs in de praktijk

Eerlijk advies: voor 90% van de Nederlandse e-commerce klanten die wij begeleiden is Cloudflare Pro de meest kosteneffectieve keuze. Fastly is alleen interessant als je VCL-niveau controle nodig hebt of al een team hebt dat Varnish beheerst. CloudFront kies je als je origin op AWS staat en je de operationele last wilt minimaliseren door alles in één platform te houden.

Een kanttekening bij CloudFront: de cache-invalidatie duurt langer en de configuratie via AWS Console is verbose. Infrastructure as Code via Terraform helpt, maar voegt ook beheeroverlast toe. Bedenk of die flexibiliteit de moeite waard is als je geen groot devops-team hebt.

Cache-invalidatie: het echte pijnpunt

Cache-invalidatie is een van de twee moeilijkste problemen in de informatica (de andere is het benoemen van variabelen). In e-commerce wordt dit concreet: een prijswijziging die pas na 10 minuten live gaat, of een uitverkocht product dat nog steeds bestelbaar lijkt.

Bij Shopify-klanten is cache-invalidatie minder relevant — Shopify beheert hun eigen CDN (Fastly onder de motorkap). Bij maatwerk Magento- en Laravel-projecten implementeren wij purge-webhooks die bij CMS-saves automatisch de juiste cache-entries invalideert.

Een voorbeeld van zo'n webhook-aanroep vanuit Laravel naar Cloudflare:

// Laravel: Cloudflare cache purge bij productupdate
use Illuminate\Support\Facades\Http;

class ProductObserver
{
    public function updated(Product $product): void
    {
        Http::withHeaders([
            'X-Auth-Email' => config('cdn.cloudflare_email'),
            'X-Auth-Key'   => config('cdn.cloudflare_api_key'),
        ])->delete("https://api.cloudflare.com/client/v4/zones/{$zoneId}/purge_cache", [
            'files' => [
                url("/producten/{$product->slug}"),
                url("/categorie/{$product->category->slug}"),
            ],
        ]);
    }
}

Deze Observer koppel je aan het Eloquent-model. Elke productopdate triggert automatisch een purge van de product- en categoriepagina. Latency van de purge-API van Cloudflare is doorgaans onder de 500ms.

Implementatie-checklist voor e-commerce

Voordat je een CDN live zet, doorloop je deze punten:

• [ ] Statische assets: lange TTL met content-hash in bestandsnaam
• [ ] HTML product/categorie: TTL 30-300 seconden op basis van updatefrequentie
• [ ] Checkout/cart/account: expliciete bypass op URL én cookie
• [ ] Vary-header correct: Vary: Accept-Encoding (nooit Vary: Cookie op gecachte routes)
• [ ] Cache-Control-headers correct vanuit origin (geen private op publieke pagina's)
• [ ] Purge/invalidatie: mechanisme aanwezig voor prijs- en voorraadwijzigingen
• [ ] Image optimization: WebP-conversie actief, geen onnodige formats geserveerd
• [ ] DDoS/WAF: basisbescherming actief
• [ ] Monitoring: cache-hit ratio zichtbaar (doel: >80% op publieke pagina's)

Veelgestelde vragen

Ja, maar je scheidt statisch van dynamisch. Cache de HTML-shell op de edge, laad persoonlijke data (cart, klantinformatie) via separate API-calls die de CDN bypassen. Zo houd je een hoge cache-hit ratio zonder personalisatiefouten.

Wij zien bij klanten typisch een verbetering van 30-60% in Time to First Byte voor bezoekers buiten de serverregio, en een totale paginalaadtijd die 20-40% daalt door asset-caching. De exacte winst hangt af van de uitgangsituatie en hoe agressief je cachet.

Voor een kleinere webshop (<10k bezoekers/maand) is de gratis tier functioneel, maar je mist custom cache-regels, betere analytics en priority support. Cloudflare Pro voor €20-25/maand is voor de meeste webshops de juiste investering.

Gebruik een aparte cookie of request-header als cache-segment. Geef bezoekers in test-variant B een andere cookie mee, en voeg die cookie toe aan de cache-key. Zo serveert de CDN de juiste variant zonder de cache te fragmenteren. Bij Cloudflare doe je dit via Workers; bij Fastly via VCL.

Wil je weten welke CDN-setup het beste past bij jouw Magento-, Shopify- of Laravel-webshop? Neem contact op — wij kijken graag mee naar je huidige configuratie.