Full-page caching van een Hyvä-webshop met Cloudflare, op een veilige manier

Een snel thema helpt, maar een gecachete pagina helpt meer. De snelste serverrespons is die nooit bij PHP aankomt.

Hyvä-webshops lenen zich goed voor caching, omdat de HTML slank is en persoonlijke data apart wordt geladen. Dat maakt nog niet elke cacheregel veilig.

In dit artikel leggen we uit hoe we kijken naar full-page caching op Hyvä met Cloudflare ervoor, en welke fouten we hebben gezien.

Twee cachelagen, twee taken

Tussen de bezoeker en PHP zitten meestal twee lagen:

• De full-page cache van Magento. Magento slaat gerenderde pagina's op en serveert ze zonder de volledige applicatie te draaien. We gebruiken Redis of Valkey als cache-backend. Varnish is een andere gangbare optie.
• De CDN. Cloudflare staat vóór de server, termineert TLS dicht bij de bezoeker en cachet statische bestanden.

De cache van Magento kent store views, valuta en klantgroepen. Cloudflare niet, tenzij je het vertelt.

Daarom is de full-page cache van Magento de basislaag, en is edge-caching van HTML een optionele stap daarbovenop.

Waarom Hyvä cachen makkelijker maakt

Een gecachete pagina moet er voor iedereen die hem krijgt hetzelfde uitzien. Alles wat persoonlijk is, zoals de minicart of de naam van de klant, moet achteraf worden toegevoegd.

Magento lost dit op met private content, ook wel customer sections genoemd. Luma laadt die via Knockout en RequireJS.

Hyvä laadt dezelfde sectiedata met een kleine hoeveelheid eigen JavaScript en verstuurt daarna een private-content-loaded -event. Alpine.js-componenten luisteren daarnaar en vullen de persoonlijke delen in.

<div x-data="{ count: 0 }"
     @private-content-loaded.window="count = $event.detail.data.cart?.summary_count || 0">
    <span x-text="count"></span>
</div>

Het resultaat is een pagina die als geheel gecachet kan worden, met daarna een lichte request voor de persoonlijke delen.

Maatwerktemplates moeten dit patroon volgen. Als een developer klantdata rechtstreeks in een PHTML-template zet, breekt dat blok de caching of, erger nog, toont het de data van de ene klant aan een andere.

Wat Cloudflare altijd moet cachen

Statische bestanden en media zijn het makkelijke deel en leveren de grootste winst met het minste risico.

• Static content onder pub/static. In production mode bevatten de URL's een gedeployde versie, dus je kunt lange cachetijden gebruiken.
• Product- en thema-afbeeldingen onder pub/media. Cache ze lang, en purge na een volledige resize van de afbeeldingen.
• Lettertypen. Zelf gehoste lettertypen horen bij de static content en worden daarmee gecachet.

Op een Hyvä-webshop dekt dit de meeste requests die een pagina doet, omdat een Hyvä-pagina sowieso relatief weinig requests doet.

HTML veilig cachen aan de edge

Cloudflare cachet standaard geen HTML. Je kunt dat aanzetten met cache rules, maar dan neem je verantwoordelijkheden over die Magento normaal regelt.

Kies je voor deze route, dan zijn dit de minimale regels:

• Bypass voor alles wat persoonlijk of transactioneel is. Winkelwagen, checkout, klantaccount, verlanglijst, admin, de REST- en GraphQL-endpoints en de requests voor customer sections mogen nooit vanaf de edge worden geserveerd.
• Bypass als de bezoeker een andere context heeft. Magento zet de X-Magento-Vary -cookie als de context afwijkt van de standaard, bijvoorbeeld wanneer iemand is ingelogd of een andere valuta gebruikt. Requests met die cookie moeten naar de origin gaan.
• Cache alleen GET-requests met een succesvol antwoord.
• Houd store views gescheiden. Delen talen een domein, dan moet de URL duidelijk maken welke store view het is, anders worden pagina's in de ene taal geserveerd aan bezoekers van een andere.
• Korte cachetijden voor HTML. Prijzen en voorraad veranderen. Een korte edge-cachetijd beperkt de schade als een purge wordt gemist.

Voelen deze regels als te veel onderhoud, houd HTML dan buiten de edge-cache. De eigen cache van Magento op een goed afgestelde server is al snel, en statische bestanden aan de edge doen het meeste werk.

Purgen: het deel dat mensen vergeten

Magento purget Cloudflare niet uit zichzelf. Elke cache die je toevoegt, heeft een bijbehorende purgeroutine nodig.

• Na een deploy: flush de cache van Magento en purge Cloudflare, en warm daarna de belangrijkste pagina's op.
• Na een volledige resize van de afbeeldingen: purge per hostname. We hadden ooit afbeeldingen in de CDN gecachet voordat de resize-cache bestond, en de CDN bleef het oude antwoord serveren totdat we purgeden.
• Na wijzigingen in prijs of voorraad: zorg dat de betreffende HTML verloopt, via korte cachetijden of een gerichte purge.

Onze deploystappen beschrijven we in production mode en deploys voor Hyvä-webshops.

Een verstandige standaardinrichting

Voor de meeste Hyvä-webshops beginnen we met een inrichting die snel is en moeilijk fout kan gaan, en voegen we edge-caching van HTML pas toe als daar een duidelijke reden voor is.

• Full-page cache van Magento ingeschakeld, met Redis of Valkey als backend en genoeg geheugen voor de hele catalogus.
• Static content en media gecachet aan de edge met lange cachetijden.
• HTML via Cloudflare doorgegeven aan de cache van Magento, zodat Magento store views, valuta en klantgroepen afhandelt.
• Een warm-up na elke purge voor de homepage, de hoofdcategorieën en de bestverkopende producten.
• Monitoring van de cache-hitrates in Magento en in Cloudflare, zodat een kapotte regel snel opvalt.

Zo blijft de time to first byte voor de meeste bezoekers laag, zonder het risico dat de edge de verkeerde pagina serveert.

Ook maatwerkextensies verdienen een controle. Een module die caching uitschakelt op een veelgebruikt blok, of aan elke response een cookie toevoegt, kan een gecachete webshop ongemerkt in een ongecachete veranderen.

Valkuilen waar we tegenaan liepen

• Logica op basis van headers genegeerd aan de edge. Het instapabonnement van Cloudflare liet de afbeeldingscache niet variëren op de Accept-header, dus onze WebP-negotiation in nginx had geen effect. We hebben de logica daarom naar Magento verplaatst, zoals beschreven in WebP-afbeeldingen serveren achter Cloudflare.
• Beveiligingsregels die tests beïnvloeden. Onze nginx blokkeert bot-user-agents. Labtools die zich als zodanig bekendmaken krijgen een 403, wat eruitziet als een snelle pagina maar geen echt resultaat is.
• De origin testen in plaats van de echte URL. Test altijd de publieke URL achter de CDN, na het purgen en opwarmen van de cache.

Veelgestelde vragen

Heb ik Varnish nodig voor een Hyvä-webshop?

Niet per se. De ingebouwde full-page cache van Magento met Redis of Valkey werkt goed op een server met de juiste capaciteit. Varnish is een prima keuze, vooral bij meer verkeer.

Is het veilig om alle HTML in Cloudflare te cachen?

Alleen met strikte bypass-regels voor persoonlijke pagina's, ingelogde bezoekers en andere contexten, plus een betrouwbare purgeroutine. Zonder die regels houd je HTML-caching in Magento.

Waarom doet de minicart op een gecachete pagina nog steeds een request?

Dat is zo bedoeld. Hyvä laadt customer sections na de pagina, zodat de HTML voor iedereen gecachet kan worden en alleen de persoonlijke delen per bezoeker worden opgehaald.

We richten voor Hyvä geoptimaliseerde servers in met caching, CDN en purgeroutines als onderdeel van onze Hyvä-pakketten. Voor alleen hosting, zie Magento-hosting.