Alles wissen of selectief wissen
Alles wissen leegt de hele cache van een zone in één aanroep en past na een deploy waarbij veel bestanden zijn veranderd. Selectief wissen leegt alleen de opgegeven URL's, hostnames, tags of prefixen, houdt de rest van de cache warm en past bij één gewijzigd bestand.
Laatst bijgewerkt:
Cloudflare kent vijf manieren om gecachte inhoud ongeldig te maken. Sinds 3 april 2025 zijn alle vijf beschikbaar op elk abonnement, ook het gratis. Vóór die datum waren er drie voorbehouden aan Enterprise, en daarom beweren oudere artikelen nog vaak het tegendeel.
De vijf methoden vergeleken
| Methode | Wat het leegt | Waarvoor geschikt | Abonnementen |
|---|---|---|---|
| Alles wissen | De hele cache van één zone | Een deploy die veel bestanden raakte, of als je niet weet wat er is veranderd | Alle |
| Per URL | Precies de opgegeven URL's | Een bestand dat je net hebt vervangen | Alle |
| Per hostname | Alles wat vanaf een hostname wordt geserveerd | Een herbouwd subdomein, bijvoorbeeld img.example.com | Alle |
| Per prefix | Alles onder een URL-pad | Een hele sectie, bijvoorbeeld example.com/blog/ | Alle |
| Per tag | Alles met een Cache-Tag-header | Inhoud die logisch bij elkaar hoort in plaats van per pad | Alle |
Wanneer je alles wist
Alles wissen is één API-aanroep, vraagt geen bestandslijst en kan niets over het hoofd zien. Dat is de hele aantrekkingskracht, en die is echt: na het opnieuw bouwen van een statische site waarbij van elk bestand de hash is veranderd, is het opsommen van wijzigingen verspild werk.
De prijs is dat de cache-hitratio van die zone naar nul zakt. Elk bezoek na de purge gaat naar je origin tot de cache weer gevuld is. Op een kleine site merkt niemand dat. Op een site met serieus verkeer is het een belastingpiek op je origin die je zelf hebt veroorzaakt, en als die origin één bescheiden server is, is precies die piek wat hem onderuithaalt.
Wanneer je selectief wist
Selectief wissen houdt de rest van de cache warm. Je hebt één stylesheet gewijzigd; er is geen reden waarom elke productfoto op de site opnieuw bij de origin moet worden opgehaald.
Daar staat tegenover dat je nauwkeurig moet zijn. Een purge per URL matcht exact de URL die je opgeeft, inclusief querystring en protocol. Dit zijn drie verschillende cache-items:
https://example.com/style.csshttps://example.com/style.css?v=2https://www.example.com/style.css
De eerste wissen doet niets voor de andere twee. Dit is verreweg de meest voorkomende reden waarom mensen concluderen dat «purgen niet werkt»: het werkte, op een URL die niemand opvraagt.
Hostname, prefix en tag
Tussen «één exacte URL» en «de hele zone» zitten drie tussenopties, en ze worden te weinig gebruikt omdat ze jarenlang Enterprise-geld kostten:
- Hostname is de botste van de drie en vraagt geen voorbereiding. Alles onder
cdn.example.comopnieuw gebouwd? Eén aanroep. - Prefix werkt op URL-paden, dus
example.com/blog/wist alle artikelen zonder de winkel aan te raken. - Tag is de krachtigste en de enige die voorbereiding vraagt: je origin moet een
Cache-Tag-header meesturen. Daarna wis je «alles rond product 4471», ongeacht over hoeveel URL's dat verspreid is.
Een keuze van vijf seconden
- Weet je precies welke bestanden zijn veranderd en zijn het er minder dan honderd? Wis per URL.
- Is een heel subdomein of een hele sectie veranderd? Wis per hostname of per prefix.
- Stuurt je origin al
Cache-Tagmee? Wis per tag. - Anders, of als je twijfelt en de site is klein? Wis alles.
Hoe FlarePurge het aanpakt
FlarePurge dekt de volledige purge en het selectief wissen per URL en per hostname, die samen de overgrote meerderheid van echte purges beslaan. Je plakt je URL's en de app verdeelt ze zelf in batches, dus een lijst van 90 URL's wordt drie API-aanroepen zonder dat je erover nadenkt.
Ook massaal wissen kan: alle favoriete zones in één keer, of alle zones van een heel account achter één bevestiging, met begrensde gelijktijdigheid zodat je niet tegen de limieten van Cloudflare aanloopt. Die limieten staan hier.