Full page cache

Bij een gewone request bouwt de applicatie de pagina elke keer opnieuw op: database-queries, prijsberekening, menu, blokken, templates. Full page cache slaat de uiteindelijke HTML op. De volgende bezoeker krijgt die kopie direct, zonder dat PHP de hele pagina hoeft te genereren.

Het verschil is groot. Een categoriepagina die zonder cache honderden milliseconden of meer kost, komt uit de cache vaak in enkele tientallen milliseconden. Dat zie je direct terug in de TTFB, en daarmee in FCP en LCP.

Persoonlijke onderdelen, zoals de mini-winkelwagen, de naam van een ingelogde klant of een verlanglijstje, horen niet in de gecachte HTML. Die worden apart geladen, meestal via JavaScript na het laden van de pagina.

De cache heeft een levensduur. In Magento staat de standaard TTL voor publieke content op 86400 seconden, één dag. Wijzigingen via de admin legen de betrokken pagina's daarvoor al eerder via cache-tags. Wijzigingen die buiten Magento om in de database komen, bijvoorbeeld via een directe import, doen dat niet automatisch.

Googlebot krijgt meestal een ongepersonaliseerde pagina en dus de gecachte versie, als die er is. Een goede cache-hitratio betekent een snelle server voor bezoekers en crawlers. Een slechte hitratio betekent dat Googlebot vaak trage, ongecachte pagina's krijgt en de crawlsnelheid verlaagt als de server het niet aankan.

Het tweede punt is juistheid. Na een prijswijziging, voorraadupdate of nieuwe banner moet de cache van die pagina's worden geleegd. Anders tonen bezoekers, crawlers en je productfeed verschillende prijzen.

Let ook op cache warming. Na een deploy of het volledig legen van de cache zijn alle pagina's koud. Een warmer die de belangrijkste categorieën en producten ophaalt, zorgt dat de eerste bezoekers en crawlers niet op de trage versie wachten.

Magento heeft full page cache ingebouwd. Onder Stores > Configuration > Advanced > System > Full Page Cache kies je de Caching Application: Built-in (bestanden of Redis) of Varnish. Voor productie is Varnish de aanbevolen keuze. Magento labelt elke pagina met cache-tags per product en categorie, zodat een productwijziging alleen de betrokken pagina's ongeldig maakt. Persoonlijke data komt via customer sections, zowel in Luma als in Hyvä.

De klassieke Magento-fout is een blok met cacheable="false" in de layout-XML. Eén zo'n blok maakt de hele pagina ongecachet. Extensies doen dat soms op elke pagina, bijvoorbeeld voor een widget in de footer. Controleer in developer mode de header X-Magento-Cache-Debug: HIT of MISS.

Shopify regelt caching zelf. Je kunt er niets aan instellen, maar ook niets aan stukmaken. Laravel heeft geen full page cache out of the box. Pakketten als spatie/laravel-responsecache of een reverse proxy zoals Varnish of een CDN vullen dat gat. Je bepaalt dan zelf welke routes cachebaar zijn.

De cache na elke kleine wijziging volledig leegmaken. Zo is de cache steeds koud en krijgen de eerste bezoekers en Googlebot trage pagina's. Ook fout: query-parameters zoals utm_source die elk een eigen cache-entry maken, waardoor de hitratio instort. Strip trackingparameters voor de cache-sleutel.

En: alleen in Lighthouse meten met een warme cache. Kijk in je serverlogs of monitoring hoe vaak de cache echt raakt.

Check bij elke nieuwe extensie of hij de cacheability van pagina's verandert. Dat is een vaste stap in een goede code review.