HTTP-cache en TTL: werking, strategieën en SEO-impact

HTTP-cache en TTL (Time To Live) zijn twee fundamentele concepten van webprestaties. Cache maakt het mogelijk om tijdelijk resources (afbeeldingen, CSS, JavaScript) dicht bij de gebruiker op te slaan, zodat ze niet bij elk bezoek opnieuw worden gedownload. TTL bepaalt hoe lang een resource in die cache kan blijven voordat deze als verlopen wordt beschouwd. Goed geconfigureerd verminderen deze mechanismen de laadtijden aanzienlijk, ontlasten de oorspronkelijke server en verbeteren de Core Web Vitals — met een directe impact op SEO.

Wat is HTTP-cache?

HTTP-cache is een mechanisme waarmee verschillende componenten in de leveringsketen van een webpagina een lokale kopie kunnen bewaren van gedownloade resources. Wanneer een browser een pagina voor het eerst laadt, downloadt hij elke resource vanaf de server. Als deze resources vergezeld gaan van HTTP-headers die aangeven dat ze gecachet mogen worden, bewaart de browser (en/of de CDN) een kopie. Bij volgende bezoeken wordt de resource geserveerd vanuit deze lokale cache in plaats van opnieuw van de server te worden gedownload — wat dramatisch sneller is.

Er zijn meerdere cacheniveaus in de leveringsketen van een webresource. De browsercache slaat resources rechtstreeks op op het apparaat van de gebruiker — op de harde schijf of in het geheugen. De CDN-cache (of edge cache) slaat resources op op servers van het distributienetwerk, geografisch dicht bij de gebruikers. De servercache (server-side cache of reverse proxy cache, zoals Varnish of Nginx) slaat resources op aan de hostingkant, voordat ze het netwerk bereiken.

Cache-Control-headers: hoe het cachegedrag instellen

De HTTP-header Cache-Control is het voornaamste mechanisme waarmee een server zijn cache-instructies communiceert. Deze wordt meegestuurd met elk HTTP-antwoord en kan meerdere gecombineerde richtlijnen bevatten. Hier zijn de belangrijkste richtlijnen:

• max-age=N: de resource mag N seconden worden gecachet. Voorbeeld: max-age=31536000 = 1 jaar. De meest gebruikte richtlijn voor statische resources.
• s-maxage=N: zoals max-age, maar alleen van toepassing op gedeelde caches (CDN, reverse proxies), niet op de browsercache. Maakt verschillende policies mogelijk voor CDN en browser.
• no-cache: de resource mag worden gecachet, maar de cache moet altijd bij de server controleren of deze nog geldig is voordat hij wordt geserveerd (via ETag of Last-Modified).
• no-store: de resource mag nooit worden gecachet, nergens. Alleen gebruiken voor zeer gevoelige inhoud (persoonsgegevens, transacties).
• public: de resource mag worden gecachet door elke cache, inclusief gedeelde CDN-caches.
• private: de resource mag alleen worden gecachet door de browsercache van de gebruiker, niet door tussenliggende caches.
• immutable: geeft aan dat de resource nooit zal veranderen gedurende zijn levensduur (max-age). De browser stuurt geen validatieverzoek, zelfs niet na het verstrijken van de cache.

Voor statische afbeeldingen van een e-commercewinkel is de optimale richtlijn doorgaans: Cache-Control: public, max-age=31536000, immutable. Deze combinatie geeft aan dat de afbeelding openbaar gecachet mag worden, gedurende een jaar, en dat deze niet zal veranderen. Als de afbeelding wijzigt (nieuwe productfoto), moet de URL veranderen om de cache te omzeilen — een techniek die "cache busting" via URL-versionering wordt genoemd.

TTL (Time To Live): hoe lang een resource in cache bewaren?

De TTL (Time To Live) is de duur gedurende welke een gecachete resource als vers (fresh) wordt beschouwd en rechtstreeks kan worden geserveerd zonder verificatie bij de oorspronkelijke server. Deze wordt uitgedrukt in seconden via de max-age-header. Na deze periode wordt de resource als verlopen (stale) beschouwd — hij kan in sommige gevallen nog worden geserveerd, maar de cache moet hem idealiter opnieuw valideren.

De keuze van de TTL is een balans tussen twee tegenstrijdige doelstellingen: het gebruik van de cache maximaliseren (lange TTL = minder verzoeken naar de server) en garanderen dat gebruikers actuele inhoud ontvangen (korte TTL = wijzigingen verspreiden zich snel). Voor resources die niet vaak veranderen, zoals productafbeeldingen, is een lange TTL (1 jaar) optimaal. Voor resources die regelmatig veranderen, zoals prijzen of voorraden, is een korte of geen TTL noodzakelijk.

• 1 jaar (31.536.000 seconden): productafbeeldingen, geversioneerde CSS/JS, weblettertypen — stabiele resources met URL-versionering
• 1 maand (2.592.000 seconden): merk- of categorieafbeeldingen die incidenteel worden bijgewerkt
• 1 uur tot 1 dag: semi-dynamische inhoud, categoriepagina's, productlijsten
• 0 of no-store: winkelwagenpagina's, betaalpagina's, ingelogde gebruikersdata — nooit cachen

Cache-invalidatie: hoe omgaan met inhoudswijzigingen

Langetermijncaching roept een voor de hand liggende vraag op: wat gebeurt er wanneer de inhoud verandert? Als een afbeelding 1 jaar wordt gecachet maar je hem na 2 maanden aanpast, blijven bezoekers de oude versie zien gedurende 10 maanden. Hier komen cache-invalidatiestrategieën om de hoek kijken.

De meest betrouwbare strategie is URL-versionering (URL versioning of cache busting). Het principe: de URL van de resource bevat een uniek identificatiekenmerk dat verandert telkens wanneer de resource wijzigt. Bijvoorbeeld /images/product-schoen-v2.webp in plaats van /images/product-schoen.webp. Of via een parameter: /images/product.jpg?v=1705234567. Wanneer de afbeelding wijzigt, verandert de URL, en de cache behandelt deze nieuwe URL als een volledig nieuwe resource — zonder problemen met verouderde inhoud.

Een andere strategie is de CDN-purge-API: moderne CDN's bieden een API die het mogelijk maakt om specifieke URLs of groepen URLs onmiddellijk uit hun cache te verwijderen. Wanneer een handelaar een afbeelding aanpast in zijn back-office, stuurt een API-aanroep naar de CDN een purgeverzoek om de cache voor die specifieke afbeelding direct te invalideren. Volgende bezoeken halen de nieuwe versie rechtstreeks van de oorspronkelijke server op, die vervolgens opnieuw wordt gecachet.

CDN-cache vs. browsercache: aanvulling en verschillen

CDN-cache en browsercache zijn complementair en dienen verschillende doelstellingen. CDN-cache komt alle bezoekers ten goede, zowel nieuwe als terugkerende: een afbeelding die op de Parijse CDN-node is gecachet, wordt snel geserveerd aan elke bezoeker in Frankrijk, ongeacht of hij jouw winkel al eerder heeft bezocht. Browsercache komt alleen terugkerende bezoekers ten goede, op hun eigen apparaat: als een gebruiker de afbeelding al heeft gedownload bij een eerder bezoek, serveert zijn browser hem vanuit de lokale schijf zonder enig netwerkverzoek.

In de praktijk vullen beide cacheniveaus elkaar aan: CDN-cache verlaagt de latentie bij het eerste laden van een pagina (nieuwe bezoeker of verlopen browsercache), terwijl browsercache het netwerk volledig elimineert bij herhaalde bezoeken op hetzelfde apparaat. Een resource met max-age=31536000 wordt slechts eenmaal per jaar per apparaat via het netwerk opgevraagd — een zeer significante prestatiewinst voor vaste bezoekers.

ETag en Last-Modified: conditionele cachevalidatie

Zelfs na een verlopen TTL is de browser niet verplicht een resource volledig opnieuw te downloaden. Hij kan een conditioneel verzoek sturen om te controleren of de resource is gewijzigd: als dat niet het geval is, antwoordt de server met HTTP-code 304 (Not Modified) zonder antwoordbody — dit spaart bandbreedte terwijl de versheid van de gecachete resource wordt bevestigd.

De ETag (Entity Tag) is een unieke identificator die door de server wordt gegenereerd voor een specifieke versie van een resource — doorgaans een hash van de bestandsinhoud. Wanneer de browser een conditioneel verzoek doet, stuurt hij de ETag van zijn gecachete versie mee in de If-None-Match-header. Als de server dezelfde ETag heeft (de resource is niet gewijzigd), antwoordt hij met 304; anders stuurt hij de nieuwe versie met een nieuwe ETag.

De Last-Modified-header werkt op vergelijkbare wijze: de server geeft de datum van de laatste wijziging van de resource aan, en de browser stuurt deze mee in If-Modified-Since bij conditionele verzoeken. Deze validatiemechanismen houden de cache up-to-date zonder bandbreedte te verspillen wanneer de inhoud niet is gewijzigd.

Hoe Lexiik cache en invalidatie automatisch beheert

Lexiik implementeert een optimale cachestrategie voor afbeeldingen van PrestaShop-winkels en lost automatisch het invalidatieprobleem op dat langetermijncaching normaal gesproken riskant maakt. Elke afbeelding die op Cloudflare R2 wordt geüpload, ontvangt Cache-Control: public, max-age=31536000, immutable headers — een jaar cache op alle Cloudflare edge nodes en in de browsers van bezoekers.

Het invalidatieprobleem wordt automatisch door Lexiik afgehandeld via twee mechanismen. Ten eerste URL-versionering: afbeeldingen die via Lexiik CDN worden geserveerd, gebruiken identificatoren in hun URLs die automatisch veranderen wanneer de afbeelding wordt gewijzigd in de PrestaShop back-office. Ten tweede automatische aanroep van de Cloudflare purge-API: wanneer een afbeelding wijzigt, stuurt Lexiik een purgeverzoek naar Cloudflare om de CDN-cache voor die specifieke afbeelding onmiddellijk te invalideren, zonder andere afbeeldingen te beïnvloeden. Bezoekers ontvangen de nieuwe afbeelding bij hun volgende bezoek, zonder ooit een verouderde versie te zien.

Waarom langetermijncache de SEO verbetert

Een TTL van één jaar op productafbeeldingen verbetert de SEO via meerdere directe en indirecte mechanismen. Direct: afbeeldingen die worden geladen vanuit de cache (CDN of browser) verschijnen in tientallen of honderden milliseconden, tegenover meerdere seconden voor een volledige netwerkdownload. Dit verbetert de LCP — de Core Web Vital-metriek die het meest direct verband houdt met afbeeldingen — en kan een pagina van een "Slecht" naar een "Goed" score brengen volgens de Google-drempelwaarden.

Indirect vermindert een efficiënte cache het aantal HTTP-verzoeken naar jouw oorspronkelijke server. Minder serverbelasting = betere TTFB (Time To First Byte) voor de dynamische HTML-inhoud die jouw PrestaShop genereert. Een TTFB onder de 200 ms wordt aanbevolen door Google; een server die overbelast is door afbeeldingsverzoeken kan een verslechterde TTFB hebben die alle prestatiemetrieken beïnvloedt.

Tot slot creëert een goed geconfigureerde browsercache voor terugkerende bezoekers — die vaak het meest geneigd zijn te converteren — een vrijwel directe browse-ervaring. Productpagina's lijken onmiddellijk te laden en afbeeldingen zijn al aanwezig in het geheugen. Deze vloeiende ervaring vergemakkelijkt het aankooptraject en vermindert uitval, met een positieve impact op gedragsmetrieken die Google in overweging kan nemen.

• Verbeterde LCP: afbeeldingen worden geladen vanuit de lokale cache of CDN in enkele milliseconden
• Verbeterde TTFB: minder verzoeken naar de oorspronkelijke server = minder serverbelasting = HTML sneller geleverd
• Betere PageSpeed-score: Google Lighthouse bestraft het ontbreken van een langetermijncachebeleid
• Bandbreedtebesparing: minder overgedragen data = lagere kosten en betere prestaties op mobiel
• Verbeterde ervaring voor vaste bezoekers: vrijwel directe navigatie voor terugkerende klanten