Hoe wij caching gebruiken om websites bliksemsnel te maken 25 augustus 2026

Bij elke aanvraag heeft de site veel informatie nodig nog voordat er ook maar één pixel van een pagina gebouwd kan worden. Die informatie die zelden verandert zoals configuratie en routering. Ze telkens opnieuw uit de database halen is verspilling van serverkracht. Daarom schrijven we die gegevens weg als kant-en-klare PHP-bestanden, één set per taal, en lezen we die in plaats van de database te bevragen.

Waarom hier gewone bestanden en geen geavanceerde cacheserver? Het antwoord is opcache. PHP leest normaal een bronbestand en compileert het naar bytecode voor het uitgevoerd kan worden, bij elke aanvraag opnieuw. Opcache doet die compilatie één keer en houdt het resultaat in het geheugen, zodat PHP bij de volgende aanvraag meteen kan uitvoeren. Door onze gegevens weg te schrijven als PHP-code liften we mee op dat mechanisme: na de eerste aanvraag zit de routetabel al klaar in het geheugen als gecompileerde bytecode. Geen databasequery, geen netwerkoproep. Voor kleine, veelgevraagde gegevens die zelden wijzigen is niets sneller.

Belangrijk detail: alles is hier gescheiden per taal. Een Nederlandse, Franse en Engelse versie van een site kunnen dus nooit door elkaar lopen. Voor de meertalige sites die wij bouwen maakt dat een groot verschil.

Dit is de laag waar onze developers dagelijks mee werken, en ze is bewust saai in gebruik. Een developer vraagt een stuk data op, geeft aan hoe lang het hergebruikt mag worden, en beschrijft hoe het opgehaald moet worden als het er nog niet is. Zit het in de cache, dan komt het meteen terug. Zo niet, dan wordt het opgehaald, opgeslagen en teruggegeven. De omliggende code hoeft nooit te weten welk van de twee er gebeurde.

In de praktijk vangt deze laag alles op wat een bezoeker op bijna elke pagina ziet, maar dat zelden verandert: de navigatie en menu's, de footer, de blokken op de homepagina, winkellocaties, betaalmethodes, productcategorieën, merken en elk contentblok dat onze klant in het CMS opbouwt.

Weet wat je niet moet cachen

Niet alles hoort in de cache. Een productoverzicht met filters, of een live zoekopdracht, heeft een bijna oneindig aantal mogelijke varianten. Elke variant cachen vult de cache met items die nooit een tweede keer opgevraagd worden. Dat kost opslag en levert niets op.

Daarom kan onze codebase voorwaardelijk cachen: de propere categoriepagina waar iedereen op landt gaat in de cache, terwijl een zwaar gefilterd of doorzocht resultaat de cache gewoon overslaat. Goede caching draait evenveel om beslissen wat je weglaat als om wat je bewaart.

Afbeeldingen die via ons CMS worden geüpload, bewaren we als originelen. De verkleinde en geoptimaliseerde versies die de website effectief toont, worden één keer aangemaakt en apart opgeslagen.

Elke pagina geeft vooraf aan welke afmetingen ze nodig heeft, zodat een overzichtspagina exact de thumbnailformaten krijgt die ze zal tonen. Bezoekers downloaden dus nooit een veel te groot origineel, en het verkleinwerk gebeurt nooit twee keer. Een achtergrondproces houdt dit in sync en ruimt versies op waarvan het origineel verwijderd is.

Naast het verkleinen kunnen we de bestanden ook omvormen naar het webvriendelijke fotoformaat webp. Deze bestanden zijn zeer klein en laden razendsnel in. Goed voor de snelheid van jouw website en voor jouw vindbaarheid in Google, dubbele win dus.

Snelheidswinst klinkt abstract tot je ze meet. Daarom hebben we de caching van verschillende van onze recentste websites doorgemeten: telkens de volledige laadtijd van product- en overzichtspagina's, één keer met caching en één keer zonder.

Het patroon was duidelijk. Gemiddeld laadden de pagina's met caching twee keer zo snel, wat neerkomt op zowat een halvering van de laadtijd. De grootste winst zat bij de zwaardere productdetailpagina's, net de pagina's waar de meeste gegevens bij elkaar gezocht moeten worden.

Hoeveel je precies wint, hangt af van hoe zwaar een pagina is. Een eenvoudige pagina die al vlot laadde, versnelt minder spectaculair dan een gegevensrijke productpagina. Maar de richting is overal dezelfde: caching maakt je website merkbaar sneller, en die snelheid voelt een bezoeker meteen. Omdat laadsnelheid meetelt voor je vindbaarheid, werkt diezelfde winst ook door in Google en AI-tools.

Een snelle website is geen toeval. Ze komt van een bewuste keuze om verschillende componenten van een website apart aan te pakken: opstartconfiguratie, databasegegevens en afbeeldingen krijgen elk hun eigen behandeling. We beginnen bewust eenvoudig, houden zicht op wat er gebeurt, en maken telkens de afweging tussen snelheid en up-to-date content.