Introductie
Wat Cache Rocket is, welk probleem het oplost, en hoe je je weg vindt in deze documentatie.
5 min leestijd
Cache Rocket houdt je website- en API-caches warm. Het bezoekt je URL's volgens een schema, net zoals een echte bezoeker zou doen, zodat het dure werk van het opbouwen van een pagina al gedaan is voordat iemand erom vraagt.
Je installeert niets op je server om te beginnen. Je verifieert dat je een domein bezit, maakt een warmer aan, en Cache Rocket doet de rest via gewone HTTP-requests.
Op betaalde plannen biedt Cache Rocket ook [Managed CDN](/documentation/managed-cdn) en cloud Media-optimalisatie — beeldformaten, Critical CSS, LQIP en PageSpeed Insights — vooral via de WordPress-plugin, naast CDN-integraties voor purge → rewarm op je bestaande edge.
Het probleem: de eerste bezoeker betaalt
Bijna elke snelle website is snel omdat er iets gecachet wordt — een CDN-edge, een reverse proxy zoals nginx of Varnish, een WordPress-paginacache, of de rendercache van je framework. Caches zijn geweldig, maar ze verlopen allemaal.
Als een gecachete kopie verloopt, is die weg. De volgende persoon die om die pagina vraagt, krijgt niet de snelle gecachete versie. Hun request valt door naar je origin-server, die de pagina helemaal opnieuw moet opbouwen: code uitvoeren, de database bevragen, de template renderen en terugsturen. Die persoon wacht. Dat noemen we een koude pagina, en die vertraging is de *cold-start-penalty*.
Het is erger dan het klinkt, want koude requests komen precies terecht bij de mensen om wie je het meest geeft:
- De lezer die dertig seconden na publicatie op je nieuwe artikel klikt.
- De shopper die via een advertentiecampagne op een landingspagina komt die de hele nacht onaangeraakt bleef.
- Iedereen tegelijk, direct na een deploy waarbij elke cache in één klap geleegd is.
- Bezoekers in een regio waarvan de CDN-edge die pagina nog nooit geserveerd heeft.
De oplossing: warm het eerst op
Cache Rocket haalt de cold-start-penalty weg door zelf de eerste bezoeker te zijn. Het vraagt je URL's op vóór echte mensen dat doen, waardoor elke cachelaag vóór je origin een verse kopie opslaat. Tegen de tijd dat er een mens komt, staat de pagina al in de cache en wordt die direct geserveerd.
Dat is het hele idee. Al het andere bestaat om dat idee praktisch te maken: bepalen *welke* URL's, *hoe vaak*, *vanwaar*, *hoe snel*, en aantonen dat het echt gewerkt heeft.
Cache Rocket vervangt je cache niet
Het is geen CDN en geen cacheplugin. Het werkt *samen* met wat je al draait — Cloudflare, Fastly, Bunny, KeyCDN, nginx, Varnish, WP Rocket, Next.js. Als een cachelaag zich vult wanneer een URL wordt opgevraagd, kan Cache Rocket die gevuld houden.
Wat je kunt opwarmen
Websites
Crawl pagina's vanaf entry-URL's en sitemaps, en volg links tot een diepte die jij kiest.
API's
Warm REST- en GraphQL-endpoints op met echte methodes, headers, cookies en bodies.
WordPress
Beheer warmers vanuit wp-admin met de officiële plugin, plus optionele lokale optimalisatie.
Na elke deploy
Start opwarmen vanuit Vercel, Netlify, Shopify of elke CI-job, zodat releases nooit koud live gaan.
Is Cache Rocket iets voor jou?
Het helpt het meest wanneer pagina's duur zijn om op te bouwen en het verkeer ongelijkmatig genoeg is dat caches tussen bezoekers door koud worden.
| Jij draait… | Wat opwarmen voor je doet |
|---|---|
| Een contentsite of blog | Nieuwe posts en oudere evergreen-artikelen blijven direct laden, in plaats van traag te zijn voor wie er als eerste op klikt. |
| Een webshop | Categorieoverzichten, productpagina's en campagnelandingspagina's zijn klaar vóór een verkeerspiek, niet erna. |
| Een marketingsite | Landingspagina's van betaalde advertenties begroeten een klik nooit met een trage first byte, wat je conversie beschermt. |
| Een headless of API-gedreven app | Dure JSON- en GraphQL-responses blijven gecachet aan de edge en in je gateway tussen client-pieken door. |
| Sites voor klanten (bureau) | Elke klant zit in een eigen workspace met eigen warmers, hostnames en alerts. |
Het helpt minder als je pagina's al statische bestanden van schijf zijn zonder vervaltijd, of als elke response per gebruiker gepersonaliseerd is en daardoor sowieso niet cachebaar.
Hoe je deze documentatie gebruikt
De pagina's zijn geschreven om op volgorde te lezen, maar elke pagina staat op zichzelf. Ben je helemaal nieuw, dan is dit de snelste route:
- 1
Lees Hoe het werkt
Tien minuten over wat er echt gebeurt tijdens een warm-run. De moeite waard voordat je instellingen gaat aanpassen.
- 2
Volg de Snelstart
Een begeleide eerste installatie: account aanmaken, hostname verifiëren, je eerste warmer bouwen en bevestigen dat het werkte.
- 3
Scan Kernbegrippen
De woordenschat — entry-URL's, diepte, intervallen, warmtescore. De rest van de documentatie gaat uit van deze termen.
- 4
Duik daarna dieper waar nodig
De zijbalk is gegroepeerd per taak: Installatie, Opwarmen, Monitoring, Integraties, Account en Hulp.
Zoek je een specifieke instelling?
Warmer-instellingen is een veld-voor-veld referentie van elke optie op het warmerformulier, inclusief wat het doet en wanneer je het aanpast.
Gebruikte conventies
Alles in monospace typ of plak je precies zo over. Schermen in je account schrijven we als Account → Warmers, wat overeenkomt met de labels in de zijbalk als je bent ingelogd.