Op een niet-geoptimaliseerde PrestaShop 8 of 9 shop overschrijdt de TTFB (Time To First Byte) courant de 800 ms op shared hosting en blijft hij rond 400 ms op een middenklasse VPS. Direct effect op de LCP (slechte Core Web Vitals score), op het crawlbudget van Googlebot en op het bouncepercentage. En dat in 2026, terwijl de Google-benchmark op 200 ms TTFB en 2,5 s LCP ligt.
Cache is geen nicheonderwerp en niet voorbehouden aan grote volumes. Het is de optimalisatie met de hoogste ROI op PrestaShop, en tegelijk degene die het slechtst wordt uitgevoerd: verwarring tussen PHP-cache, objectcache, HTTP-cache en reverse proxy; weinig efficiënte standaardconfiguraties; stapels modules die elkaar in de weg zitten. Dit artikel maakt de balans op van de vier lagen van een nette stack en geeft de beslisregel Redis / Memcached / Varnish naargelang het shopprofiel.
De vier cachelagen van een PrestaShop-shop
Een shop serveert elke pagina door meerdere cachelagen te stapelen. De lagen kennen betekent vermijden dat u er meer stapelt dan nodig: elke laag voegt complexiteit toe en purgepunten om te beheersen.
1. PHP opcode cache
OPcache cachet de bytecode van de geïnterpreteerde .php bestanden. Onmisbaar: zonder OPcache herinterpreteert elke request duizenden PrestaShop-bestanden. Typische winst: 30 tot 50% TTFB. Het is gratis, native in PHP, en het is de eerste reflex om in productie te valideren via php -i | grep opcache. Te dimensioneren: minimum 256 MB voor PrestaShop 8/9, opcache.validate_timestamps=0 in productie met handmatige recycling bij de deploy.
2. Objectcache (in-memory key-value)
PrestaShop cachet bepaalde applicatieresultaten: gebruikerssessies, Smarty-metadata (templatepaden, hookconfiguratie), resultaten van repetitieve queries. Standaard lopen die caches via het bestandssysteem, wat traag is. In serieuze productie verplaatst men ze naar een in-memory database: Redis of Memcached.
3. HTTP-cache en reverse proxy
Boven PrestaShop onderschept een reverse proxy (Varnish, NGINX cache of een CDN edge cache) de HTTP-requests en serveert vooraf gerenderde antwoorden zonder PHP aan te spreken. De optimalisatie met de grootste hefboom: typische winst van 90% van de servertijd op de anonieme pagina’s bij een cache hit.
4. Browsercache en CDN
De statische resources (afbeeldingen, CSS, JS, fonts) moeten headers Cache-Control: public, max-age=31536000, immutable dragen en door een CDN geserveerd worden. Een evidentie in 2026, maar slecht uitgevoerd op 40% van de geauditeerde shops: te korte max-age, niet-geversioneerde resources, slecht geconfigureerde cachevariaties.
Redis versus Memcached: de beslissing in de praktijk
Voor de objectcache domineren twee keuzes: Redis en Memcached. Het debat “welke is sneller” is achterhaald: beide verzadigen ruimschoots de behoeften van een PrestaShop-shop. Het echte verschil zit elders.
Memcached
- Eenvoudiger, minder functies, minder aanvalsoppervlak en minder configuratievalkuilen.
- Uitstekend voor pure vluchtige key-value cache.
- Geen schijfpersistentie: een herstart maakt alles leeg, wat een tijdelijke thundering herd op PHP-FPM produceert.
- Geen geavanceerde structuren (lists, sorted sets, pub-sub): gebruik beperkt tot strikte cache.
Redis
- Rijker: datastructuren (lists, sets, sorted sets), pub-sub, Lua-scripting.
- Optionele persistentie (RDB of AOF): overleeft herstarts.
- Bruikbaar ver voorbij de PrestaShop-cache: sessies over meerdere servers, Symfony Messenger queue, rate limiting.
- Geheugenconfiguratie om te bewaken (maxmemory, eviction policy), anders verbruikt hij meer dan voorzien.
Praktische regel 2026: Redis is de standaardkeuze. Memcached blijft relevant als de shop bewust minimalistisch is en de enige behoefte pure objectcache is. Elke shop die op termijn een jobqueue, API rate limiting of gedeelde sessies over meerdere servers overweegt, wint erbij om meteen met Redis te starten.
Wanneer Varnish zin heeft (en wanneer niet)
Varnish (of NGINX full-page cache) is de optimalisatie met de grootste hefboom op PrestaShop: hij serveert de anonieme pagina’s in enkele milliseconden in plaats van 400-800 ms. Maar Varnish is niet in elke configuratie een game-changer.
Gevallen waarin Varnish alles verandert
- Hoofdzakelijk anoniem verkeer: niet-ingelogde bezoekers, geen per klant gepersonaliseerde prijzen, geen A/B-test met serversleutel. Brede B2C-catalogus.
- Hoog volume geconcentreerd op weinig URL’s: één homepage, 50 categorieën en 500 productpagina’s vertegenwoordigen 80% van het verkeer. De cache doet het meeste werk.
- Voorspelbare seizoenspiek: Black Friday, solden. Varnish absorbeert het verkeer zonder PHP-FPM te verzadigen.
Gevallen waarin Varnish een valkuil is
- B2B-shop met verplichte login: elke pagina is gepersonaliseerd (prijs per klantgroep, meerdere gebruikers, lopende offertes). Varnish serveert alleen de publieke pagina’s (zeldzaam) en de complexiteit overstijgt de winst.
- Server-side personalisatie: AI-aanbevelingen per gebruiker, server-side A/B-testing, dynamische prijzen. De full-page cache maakt alle personalisatie zinloos.
- Anoniem verkeer verspreid over duizenden long-tail URL’s: wordt elke URL één keer per dag bezocht, dan blijft de hit ratio laag en levert Varnish niets op.
Het alternatief: CDN edge cache
In 2026 doen Cloudflare Cache Rules, BunnyCDN Permacache, Fastly en andere edge caches het werk van Varnish op CDN-niveau, zonder extra server. Voordeel: geen laag om te onderhouden, geografische distributie, native WAF-integratie. Nadeel: de fijne purge is minder flexibel dan bij Varnish, en de kosten kunnen oplopen bij grote volumes. Voor 80% van de mid-market shops is de CDN edge cache een superieur alternatief geworden voor een zelfgehoste Varnish.
Reële kosten en ROI van een nette cachestack
Kosten
- OPcache: 0 €. Activeren en goed dimensioneren.
- Redis: 0 € lokaal (dezelfde server als PHP-FPM) tot 15-30 € per maand op een dedicated VPS (Hetzner CX11) of managed Redis (Upstash, Redis Cloud) vanaf 10 € per maand.
- Varnish: 0 € open source, maar 1 tot 3 dagen installatie en tuning door een competente sysadmin. Te budgetteren in tijd, niet in licentie.
- CDN edge cache: Cloudflare Pro 25 $ per maand, BunnyCDN ongeveer 1 $ per overgedragen GB, Fastly vanaf 50 $ per maand op verbruiksbasis.
- Initiële implementatie: 2 tot 5 ontwikkeldagen voor een standaard shop (configuratie, tests, automatische purge via PrestaShop-webhook).
Gemeten ROI
Uit audits van mid-market PrestaShop 8 shops na de uitrol van een nette cachestack:
- De TTFB gaat van 600-800 ms naar 80-150 ms bij een cache hit.
- De LCP zakt van 3,2 s naar 1,4 s op een anonieme productpagina.
- Het mobiele bouncepercentage daalt gemiddeld met 12 tot 18%.
- De mobiele conversie stijgt met 6 tot 12%.
- Het Google-crawlbudget verdubbelt, wat zich in 4-8 weken vertaalt in +15% geïndexeerde URL’s.
De opportuniteitskosten van geen nette cache opzetten, overschrijden vaak 1% van de jaaromzet. Een shop met 1 M€ per jaar verliest typisch 10 tot 20 K€ per jaar aan gedegradeerde prestaties.
De valkuilen om te vermijden
1. Cachemodules stapelen zonder coherentie
Veel shops stapelen: de officiële PrestaShop-cachemodule, een externe Redis-module, een aparte Varnish-module, een CDN-plugin. Zonder heldere hiërarchie invalideren de caches elkaar slecht en annuleren sommige hits de andere. Er is één en slechts één gedocumenteerd cachebeleid nodig, met een helder schema van de cascadepurge.
2. De purge bij events slecht beheren
Wijzigt een prijs, wordt een voorraad bijgewerkt, wordt een productattribuut aangepast, dan moet de betrokken pagina gepurgd worden. PrestaShop heeft geen verenigde hook: men moet actionProductUpdate, actionObjectStockMvtAddAfter en actionObjectCategoryUpdateAfter bedraden en de juiste purge triggeren (Varnish PURGE, Redis DEL, CDN API). Zonder dat ziet de bezoeker een verouderde prijs, wat onder de Omnibus-richtlijn kan vallen.
3. Gepersonaliseerde pagina’s cachen
De winkelwagen, het klantaccount, de checkout en elke pagina met gebruikersdata mogen nooit in de full-page cache belanden. De Varnish- of CDN-regel moet die routes expliciet uitsluiten (/winkelwagen, /mijn-account, /bestelling, /identiteit). Frequente fout: een shop die standaard alles cachet, toont de winkelwagen van een andere klant. Een ernstig incident dat achteraf moeilijk te diagnosticeren is.
4. Niet testen onder belasting
Een nette cache valideert men onder belasting. Een tool als k6 of Locust laat toe 500-1000 gelijktijdige bezoekers te simuleren en de hit ratio, de TTFB onder belasting en de PHP-FPM stabiliteit te meten. Zonder die test ontdekt men de problemen in productie op een piekdag, het slechtste moment om te corrigeren.
5. Multishop en multivaluta vergeten
Een te agressieve cache op een multishop kan dezelfde HTML-pagina aan alle shops serveren, of de EUR-prijs aan een bezoeker in GBP. De cachesleutel moet minstens id_shop, id_lang en id_currency bevatten. Verifieer expliciet de gegenereerde cachesleutel: het is de stille fout die het meeste conversieverlies kost.
De standaard aanbevolen stack in 2026
Voor 80% van de mid-market PrestaShop 8 / 9 shops (omzet 200 K€ tot 5 M€ per jaar):
- OPcache geactiveerd met 256 MB en
opcache.validate_timestamps=0in productie. - Redis als backend voor de PrestaShop-objectcache (sessies, Smarty, metadata). Eén instantie volstaat in de meeste gevallen.
- CDN edge cache (Cloudflare of BunnyCDN) op de publieke catalogus- en CMS-pagina’s, met expliciete uitsluiting van de gebruikersroutes.
- Agressieve browsercache op de statische resources (1 jaar), geversioneerd per hash via het assetsysteem van PrestaShop.
- Geen Varnish, behalve in het specifieke geval van groot en homogeen verkeer waar het tuning- en onderhoudswerk zich rechtvaardigt.
Deze stack rolt u in 2 tot 5 dagen uit, kost 10 tot 30 € per maand aan terugkerende kosten, en levert een prestatiewinst die veel groter is dan wat u kunt halen uit het optimaliseren van de applicatiecode. Vóór elke backend-optimalisatie (modules herbouwen, SQL-queries) blijft het doorlopen van deze vijf punten de eerste rendabele stap.
