Hoe het werkt

Deze pagina legt de werking uit. Je hebt hem strikt genomen niet nodig om Cache Rocket te gebruiken, maar als je de run-lus begrijpt, wordt elke instelling op het warmerformulier vanzelfsprekend in plaats van mysterieus.

Het leven van een warm-run#

Een warmer is een opgeslagen configuratie, geen draaiend proces. Hij ligt stil tot iets een run start. Als een run begint, is dit de volgorde:

1. 1

   De wachtrij vullen

   Cache Rocket neemt je entry-URL's en, als dat aanstaat, klapt het gevonden sitemaps uit. Dat worden de eerste items in de crawl-wachtrij.

2. 2

   Toestemming controleren

   Elke URL wordt getoetst aan je geverifieerde hostnames. Alles dat wijst naar een domein waarvan je het eigendom niet hebt aangetoond, valt af vóór er ook maar één request uitgaat.

3. 3

   Een URL opvragen

   Cache Rocket haalt de URL op via HTTP met jouw headers, cookies en user agent, en registreert hoe lang de response duurde. Dit is de eerste laadtijd.

4. 4

   Nog een keer opvragen

   Direct daarna wordt dezelfde URL een tweede keer opgehaald. Dat is de warme laadtijd. Omdat het eerste request de cache vulde, hoort de tweede dramatisch sneller te zijn.

5. 5

   Meer URL's ontdekken

   Links die in de HTML gevonden worden, gaan de wachtrij in — mits ze op een geverifieerde hostname staan, niet uitgesloten zijn, en binnen je dieptelimiet vallen.

6. 6

   Herhalen binnen de limieten

   De wachtrij wordt afgewerkt met maximaal jouw max URL's per minuut, en stopt als de wachtrij leeg is of een planlimiet bereikt wordt.

7. 7

   Vastleggen en waarschuwen

   Resultaten voeden Cachegezondheid. Als de run faalde of veel fouten gaf, gaan je ingestelde Alerts af.

De dubbele fetch, en waarom die ertoe doet#

Elke URL twee keer ophalen is het slimste wat Cache Rocket doet, en het dient twee doelen tegelijk.

Het eerste doel is opwarmen. Het eerste request betaalt de cold-start-penalty — het dwingt je origin de pagina op te bouwen en elke cache ervoor om het resultaat te bewaren. Cache Rocket meldt zich vrijwillig als de bezoeker die wacht, zodat een echt mens dat niet hoeft.

Het tweede doel is bewijs. Door beide requests te timen kan Cache Rocket het verschil laten zien. Een eerste laadtijd van 1.800 ms gevolgd door een warme laadtijd van 90 ms is onmiskenbaar bewijs dat de cache gevuld is. Zijn beide getallen traag, dan werkt je caching niet en gaat opwarmen alleen je niet redden — wat op zich ook uiterst nuttig is om te weten.

Hoe URL's ontdekt worden#

Een warmer vindt werk op drie manieren, die op elkaar stapelen:

Entry-URL's

De startpunten die je zelf invoert. Worden altijd gebruikt. Voor veel sites is één entry-URL — de homepage — genoeg.

Sitemaps

Als Sitemaps meenemen aanstaat en een entry-URL naar een .xml-sitemap wijst, worden alle URL's daaruit toegevoegd. Dit is de betrouwbare manier om grote sites te dekken, omdat je CMS de lijst voor je bijhoudt.

Links volgen

Cache Rocket leest de opgehaalde HTML en zet gevonden links in de wachtrij, niet verder dan je diepte-instelling toestaat. Zo vang je pagina's die in geen enkele sitemap staan.

Diepte wordt gemeten in stappen vanaf een entry-URL. Je homepage is diepte 0. Alles wat daar direct naartoe linkt is diepte 1. Alles wat vanaf *die* pagina's gelinkt wordt is diepte 2, enzovoort.

diepte 0   https://example.com/                     ← entry-URL
diepte 1   https://example.com/blog/
           https://example.com/pricing
           https://example.com/about
diepte 2   https://example.com/blog/warming-101
           https://example.com/blog/cdn-basics
diepte 3   https://example.com/blog/author/sam

Wat een run start#

Als er een opwarmvenster is ingesteld, worden geplande auto-starts buiten die uren overgeslagen. Handmatige starts en deploy-triggers werken gewoon door.

De veiligheidsgrenzen#

Een cache-warmer is in wezen een beleefde robot die veel requests naar een website stuurt. Cache Rocket neemt dat serieus en begrenst hem op drie manieren.

Hij raakt alleen domeinen die van jou zijn

Elke hostname moet via DNS of een HTTPS-bestand geverifieerd zijn voordat die in een warmer mag staan. Dit is geen optionele drempel — zonder dit zou de dienst op de server van iemand anders gericht kunnen worden als DDoS-middel. Zie Hostnameverificatie.

Hij respecteert een snelheidslimiet die jij bepaalt

Max URL's per minuut is een harde bovengrens op het requesttempo. Zet hem op wat je hosting comfortabel aankan *bovenop* echt verkeer. Shared hosting wil misschien 5–10; een goed uitgeruste origin achter een CDN kan vaak enkele honderden aan.

Hij blijft binnen je planlimieten

Je abonnement begrenst URL's per minuut, dag, week en maand, plus crawl-diepte en het aantal warmers. Bij het bereiken van een limiet stopt de run netjes in plaats van door te schieten. Zie Plannen en limieten.

Waar de onderdelen zitten#