Funktionsweise

Diese Seite erklärt die Mechanik. Du brauchst sie streng genommen nicht, um Cache Rocket zu nutzen, aber wenn du die Ablauflogik verstehst, wird jede Einstellung im Warmer-Formular selbstverständlich statt rätselhaft.

Der Ablauf eines Aufwärmlaufs#

Ein Warmer ist eine gespeicherte Konfiguration, kein laufender Prozess. Er ruht, bis etwas einen Lauf startet. Beginnt ein Lauf, ist das die Reihenfolge:

1. 1

   Warteschlange füllen

   Cache Rocket nimmt deine Einstiegs-URLs und klappt, falls aktiviert, gefundene Sitemaps auf. Das sind die ersten Einträge in der Crawl-Warteschlange.

2. 2

   Berechtigung prüfen

   Jede URL wird gegen deine verifizierten Hostnames geprüft. Alles, was auf eine Domain zeigt, deren Eigentum du nicht nachgewiesen hast, fällt heraus, bevor eine einzige Anfrage rausgeht.

3. 3

   Eine URL abrufen

   Cache Rocket holt die URL über HTTP mit deinen Headern, Cookies und deinem User Agent und erfasst die Antwortzeit. Das ist die erste Ladezeit.

4. 4

   Nochmals abrufen

   Unmittelbar danach wird dieselbe URL ein zweites Mal geholt. Das ist die warme Ladezeit. Weil die erste Anfrage den Cache gefüllt hat, sollte die zweite dramatisch schneller sein.

5. 5

   Weitere URLs entdecken

   Im HTML gefundene Links gehen in die Warteschlange — sofern sie auf einem verifizierten Hostname liegen, nicht ausgeschlossen sind und innerhalb deiner Tiefe liegen.

6. 6

   Innerhalb der Limits wiederholen

   Die Warteschlange wird mit höchstens deinen max. URLs pro Minute abgearbeitet und endet, wenn sie leer ist oder ein Plan-Limit erreicht wird.

7. 7

   Erfassen und benachrichtigen

   Die Ergebnisse fließen in Cache-Zustand. Ist der Lauf gescheitert oder fehlerreich, lösen deine Alerts aus.

Der doppelte Abruf, und warum er zählt#

Jede URL zweimal zu holen ist das Klügste, was Cache Rocket tut, und es erfüllt zwei Zwecke gleichzeitig.

Der erste Zweck ist Aufwärmen. Die erste Anfrage zahlt die Cold-Start-Strafe — sie zwingt deinen Origin, die Seite zu bauen, und jeden Cache davor, das Ergebnis zu speichern. Cache Rocket meldet sich freiwillig als die Besucherin, die wartet, damit ein echter Mensch das nicht muss.

Der zweite Zweck ist Nachweis. Indem beide Anfragen gemessen werden, kann Cache Rocket den Unterschied zeigen. Eine erste Ladezeit von 1.800 ms, gefolgt von einer warmen Ladezeit von 90 ms, ist unmissverständlicher Beleg, dass der Cache gefüllt wurde. Sind beide Werte langsam, funktioniert dein Caching nicht, und Aufwärmen allein rettet dich nicht — was ebenfalls äußerst nützlich zu wissen ist.

Wie URLs gefunden werden#

Ein Warmer findet Arbeit auf drei Wegen, die sich ergänzen:

Einstiegs-URLs

Die Startpunkte, die du selbst einträgst. Werden immer genutzt. Für viele Websites reicht eine einzige — die Startseite.

Sitemaps

Ist Sitemaps einbeziehen aktiv und zeigt eine Einstiegs-URL auf eine .xml-Sitemap, werden alle darin gelisteten URLs ergänzt. Das ist der verlässliche Weg für große Websites, weil dein CMS die Liste für dich pflegt.

Links folgen

Cache Rocket liest das abgerufene HTML und stellt gefundene Links in die Warteschlange, nicht weiter als deine Tiefe erlaubt. So erfasst du Seiten, die in keiner Sitemap stehen.

Tiefe wird in Link-Schritten ab einer Einstiegs-URL gemessen. Deine Startseite ist Tiefe 0. Alles, was direkt von dort verlinkt ist, ist Tiefe 1. Alles, was von *diesen* Seiten verlinkt ist, ist Tiefe 2, und so weiter.

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

Was einen Lauf startet#

Ist ein Aufwärm-Zeitfenster konfiguriert, werden geplante Auto-Starts außerhalb dieser Stunden übersprungen. Manuelle Starts und Deploy-Trigger funktionieren weiterhin.

Die Schutzgrenzen#

Ein Cache-Warmer ist im Kern ein höflicher Roboter, der viele Anfragen an eine Website schickt. Cache Rocket nimmt das ernst und begrenzt ihn auf drei Wegen.

Er berührt nur Domains, die dir gehören

Jeder Hostname muss über DNS oder eine HTTPS-Datei verifiziert sein, bevor er in einem Warmer auftauchen darf. Das ist keine optionale Hürde — ohne sie könnte der Dienst auf den Server einer anderen Person gerichtet und als DDoS-Werkzeug missbraucht werden. Siehe Hostname-Verifizierung.

Er hält ein Tempolimit ein, das du setzt

Max. URLs pro Minute ist eine harte Obergrenze für die Anfragerate. Setze sie auf das, was dein Hosting *zusätzlich* zum echten Verkehr bequem verkraftet. Shared Hosting will vielleicht 5–10; ein gut ausgestatteter Origin hinter einem CDN verkraftet oft mehrere Hundert.

Er bleibt in deinen Plan-Limits

Dein Abo begrenzt URLs pro Minute, Tag, Woche und Monat, ebenso Crawl-Tiefe und Anzahl der Warmer. Ist ein Limit erreicht, endet der Lauf saubere statt überzuschießen. Siehe Pläne und Limits.

Wo die Teile liegen#