Magento caching correct instellen in 8 stappen

Een Magento-shop die na een kleine contentwijziging traag wordt, oude prijzen toont of ineens een lege categoriepagina geeft, heeft zelden alleen een ‘cacheprobleem’. Meestal is Magento caching correct instellen onderdeel van een grotere technische afspraak: welke data mag tijdelijk worden bewaard, waar staat die cache, wanneer wordt hij ongeldig en wie controleert dat na een deployment?

Dat klinkt technisch, maar de impact is commercieel. Een snelle categoriepagina helpt conversie en SEO. Een klant die na het inloggen de gegevens van een andere bezoeker ziet, is een ernstig privacy-incident. En een marketeer die na elke bannerwijziging moet wachten op een developer, verliest tijd die beter naar campagnes gaat. Goed ingestelde caching maakt een shop sneller zonder dat actualiteit, personalisatie of beheer eronder lijden.

Waarom Magento-cache meer is dan een knop in het beheer

Magento heeft verschillende cachelagen die elk iets anders doen. De configuratiecache bewaart bijvoorbeeld instellingen, layouts en XML-configuratie. De full-page cache bewaart complete openbare pagina’s. Redis kan daarnaast de Magento-cache en sessies opslaan in geheugen, terwijl PHP OPcache gecompileerde PHP-code vasthoudt. Daarbovenop kunnen CDN-cache, browsercache en Varnish actief zijn.

De fout ontstaat vaak wanneer al die lagen als één cache worden behandeld. Iemand klikt op ‘Flush Magento Cache’, een ander leegt Varnish en een derde start Redis opnieuw. De shop is dan misschien tijdelijk weer goed, maar de oorzaak is niet opgelost. Bovendien kan een volledige flush tijdens piekverkeer ervoor zorgen dat alle pagina’s tegelijk opnieuw moeten worden opgebouwd. Dat geeft juist vertraging op het moment dat je klanten wilt helpen.

De basisregel is eenvoudig: leeg alleen wat nodig is, en zorg dat Magento zelf weet wanneer content gewijzigd is. Product-, categorie- en CMS-updates moeten via cache-tags de juiste pagina’s ongeldig maken. Handmatig legen is een hulpmiddel, geen dagelijks beheerproces.

Magento caching correct instellen begint met productie

Zet een live Magento-omgeving altijd in production mode. In developer mode is Magento ingericht op ontwikkeling: bestanden en configuratie worden vaker verwerkt en fouten zijn uitgebreider zichtbaar. Dat is handig op een lokale Docker-omgeving of acceptatie, maar niet voor klanten die door je catalogus klikken.

Controleer dit via de command line met bin/magento deploy:mode:show. Staat de shop niet in production mode, plan de wijziging dan zorgvuldig. Een omschakeling kan compilatie en het genereren van statische bestanden vereisen. Doe dit niet zomaar midden op een drukke werkdag.

Ook de server moet bij die productiemodus passen. PHP OPcache hoort aan te staan en voldoende geheugen te hebben. Composer-dependencies, gegenereerde code en statische assets moeten bij een deployment voorspelbaar worden opgebouwd. Een cacheconfiguratie kan nog zo netjes zijn, maar als je deployment half afgemaakte bestanden op productie achterlaat, krijgt de bezoeker alsnog fouten of een trage shop.

Kies Varnish voor de full-page cache

Voor een serieuze Magento 2-shop is Varnish doorgaans de juiste full-page cache. Varnish serveert openbare pagina’s vanuit geheugen, nog voordat PHP en Magento worden aangesproken. Dat scheelt serverbelasting en maakt vooral categorie-, product- en CMS-pagina’s veel sneller bij herhaald bezoek.

Magento kan ook de ingebouwde full-page cache gebruiken, maar die draait binnen de applicatie en is minder geschikt voor schaalbaar productiegebruik. Voor een kleine shop met beperkt verkeer kan dit tijdelijk werken. Verwacht je campagnes, veel filters, een groot assortiment of B2B-verkeer, dan is Varnish de logische keuze.

Stel Varnish niet los van Magento in. Genereer de VCL-configuratie vanuit de Magento-configuratie die bij jouw versie past en laad die in Varnish. Controleer vervolgens of Magento de juiste host en poort gebruikt. Een veelvoorkomende misser is dat Varnish wel draait, maar Magento hem niet aanstuurt of verkeer via een verkeerde reverse proxy-route loopt.

Let ook op persoonlijke delen van de shop. Winkelwagen, klantaccount, checkout en bepaalde gepersonaliseerde blokken mogen nooit als openbare pagina worden gecachet. Magento werkt hiervoor met private content en secties die de browser afzonderlijk ophaalt. Eigen maatwerk in de header, minicart of klantprijsweergave moet dat patroon volgen. Anders krijg je snel verouderde aantallen, verkeerde prijzen of gegevens die niet bij de juiste klant horen.

Gebruik Redis apart voor cache en sessies

Redis is de gebruikelijke keuze voor Magento-cache en sessieopslag. Het is snel, werkt in geheugen en voorkomt dat Magento voor elke cacheactie terugvalt op het bestandssysteem. Zeker bij meerdere webservers is een gedeelde Redis-opslag praktisch noodzakelijk.

Gebruik bij voorkeur aparte Redis-databases of duidelijke prefixes voor Magento-cache, full-page cache en sessies. Nog beter: isoleer omgevingen. Een acceptatieshop mag nooit dezelfde Redis-instantie of namespace gebruiken als productie. Eén verkeerd flush-commando mag niet kunnen leiden tot uitgelogde klanten in je live shop.

Sessies verdienen extra aandacht. Als Redis opnieuw start of sessies onverwacht verlopen, worden klanten uitgelogd en kunnen winkelwagens verdwijnen. Kies daarom een passende session lifetime en zorg voor monitoring op geheugengebruik, evictions en beschikbaarheid. Redis die volloopt, ruimt afhankelijk van de instelling gegevens op. Dat is niet het soort automatisering dat je in een checkout wilt ontdekken.

Welke Magento-cachetypen laat je aan?

In Magento zie je onder Cache Management meerdere cachetypen. In productie horen vrijwel alle standaard cachetypen ingeschakeld te staan. Uitzonderingen zijn meestal tijdelijk en hebben een duidelijke reden, bijvoorbeeld onderzoek naar een fout op acceptatie.

Deze onderdelen verdienen de meeste aandacht:

• Configuration, Layout en Block HTML output versnellen het verwerken van instellingen, paginaopbouw en herbruikbare blokken.
• Page Cache bewaart volledige openbare pagina’s en heeft de grootste invloed op de ervaren snelheid van storefront-pagina’s.
• Collections Data en Reflection Data voorkomen onnodige herberekeningen binnen Magento.
• Compiled Config en EAV-types zijn belangrijk voor de configuratie en productattributen van Magento.
• Full Page Cache in Redis of Varnish moet passen bij je gekozen architectuur. Gebruik geen dubbelzinnige opzet zonder te begrijpen welke laag uiteindelijk antwoord geeft.

Controleer de status met bin/magento cache:status. Zie je cachetypen die onverwacht uitstaan, zet ze gericht aan met bin/magento cache:enable. Dat is veiliger dan blind alles leegmaken.

Schoonmaken, flushen en invalidatie zijn niet hetzelfde

bin/magento cache:clean verwijdert verlopen en ongeldig gemaakte cache-items van Magento. Dit is meestal de veilige eerste actie na een gerichte wijziging. bin/magento cache:flush leegt de volledige Magento-cacheopslag. Als Redis ook door andere toepassingen wordt gebruikt en de scheiding ontbreekt, kan dat breder effect hebben dan bedoeld.

Een Varnish-purge werkt weer anders. Magento hoort na een product-, categorie- of CMS-wijziging tags te versturen waarmee Varnish alleen relevante pagina’s ongeldig maakt. Werkt dat niet, dan is de verleiding groot om heel Varnish te legen. Doe dat alleen bij een beheerst incident. Zoek eerst uit waarom de invalidatie niet doorkomt: een foutieve VCL, proxy-configuratie, custom module of ontbrekende cache-tags in maatwerk zijn bekende oorzaken.

Hetzelfde geldt voor imports. Een PIM-, ERP- of prijsimport kan duizenden producten aanpassen. Als die import per record de cache laat opschonen, maakt hij de shop onnodig druk. Slimme integraties bundelen wijzigingen, gebruiken indexers correct en voeren noodzakelijke invalidatie na afloop gecontroleerd uit. Bij grote catalogi maakt dat het verschil tussen een stabiele shop en een server die tijdens kantooruren staat te hijgen.

Verwar indexers niet met caching

Magento-indexers maken data geschikt voor snelle weergave, bijvoorbeeld prijzen, voorraad, categorieproductrelaties en zoekgegevens. Dat is iets anders dan caching. Als een prijs niet verandert op de productpagina, kan de index achterlopen. Als de juiste prijs intern bestaat maar de pagina toont nog oud HTML, zit je eerder in de full-page cache.

Controleer daarom na imports of deployments ook bin/magento indexer:status. Bij veel updates is ‘Update by Schedule’ vaak verstandiger dan directe verwerking bij iedere afzonderlijke wijziging. Maar ook hier geldt: het hangt af van je proces. Voorraad die bijna realtime moet kloppen, vraagt om een andere inrichting dan een nachtelijke artikelimport voor een B2B-catalogus.

Test caching zoals een klant de shop gebruikt

Een groen vinkje in het beheer zegt niet dat de cache goed werkt. Test ten minste een categoriepagina, productpagina, zoekresultaat, ingelogde klantomgeving, winkelwagen en checkout. Herlaad openbare pagina’s meerdere keren en controleer de response headers of logging om te zien of Varnish daadwerkelijk een hit levert.

Test daarnaast de wijzigingsketen. Pas een CMS-blok aan, wijzig een productprijs en zet een product uit voorraad. Verschijnen de wijzigingen op de juiste plekken, zonder dat je de hele cache leegt? Controleer ook of een ingelogde klant geen oude of openbare content krijgt die niet bij zijn account past.

Na een deployment hoort dit geen handmatig gokwerk te zijn. Neem cache-warming, statische content, indexercontrole en een korte storefront-smoketest op in je releaseproces. Met CI/CD kun je veel van die stappen herhaalbaar maken. Dat voorkomt dat een spoedfix voor een banner eindigt in een vertraagde shop.

Bij managed Magento-omgevingen zoals MageRex hoort deze basis in de infrastructuur geregeld te zijn: gescheiden omgevingen, passende Redis-configuratie, Varnish, monitoring en een deploymentpad dat niet op losse handelingen leunt. De echte winst zit niet in een cacheknop, maar in een stack waarin die knop zelden nodig is.

Een goede praktische afspraak voor je team: als iemand zegt dat ‘de cache weer geleegd moet worden’, vraag dan welke laag oud is, welke wijziging dat veroorzaakte en hoe Magento die laag had moeten invalideren. Dat kost twee minuten extra, maar voorkomt dat tijdelijke noodgrepen vaste werkwijze worden.