Einführung
Was Cache Rocket ist, welches Problem es löst und wie du dich in dieser Dokumentation zurechtfindest.
5 Min. Lesezeit
Cache Rocket hält die Caches deiner Website und deiner APIs warm. Es ruft deine URLs nach einem Zeitplan auf, so wie es eine echte Besucherin täte, damit die teure Arbeit des Seitenaufbaus schon erledigt ist, bevor jemand danach fragt.
Für den Einstieg installierst du nichts auf deinem Server. Du weist nach, dass dir eine Domain gehört, erstellst einen Warmer, und Cache Rocket macht den Rest über gewöhnliche HTTP-Anfragen.
Auf kostenpflichtigen Plänen bietet Cache Rocket außerdem [Managed CDN](/documentation/managed-cdn) und Cloud-Medienoptimierung — Bildformate, Critical CSS, LQIP und PageSpeed Insights — vor allem über das WordPress-Plugin, zusätzlich zu CDN-Integrationen für Purge → Rewarm an Ihrem bestehenden Edge.
Das Problem: die erste Besucherin zahlt
Fast jede schnelle Website ist schnell, weil irgendetwas gecacht wird — ein CDN-Edge-Knoten, ein Reverse Proxy wie nginx oder Varnish, ein WordPress-Seitencache oder der Render-Cache deines Frameworks. Caches sind wunderbar, aber sie laufen alle ab.
Läuft eine gecachte Kopie ab, ist sie weg. Die nächste Person, die diese Seite anfragt, bekommt nicht die schnelle gecachte Version. Ihre Anfrage fällt bis zu deinem Origin-Server durch, der die Seite von Grund auf neu bauen muss: Code ausführen, Datenbank abfragen, Template rendern, ausliefern. Diese Person wartet. Wir nennen das eine kalte Seite, und die Verzögerung ist die *Cold-Start-Strafe*.
Es ist schlimmer, als es klingt, denn kalte Anfragen treffen genau die Menschen, die dir am wichtigsten sind:
- Die Leserin, die dreißig Sekunden nach Veröffentlichung auf deinen neuen Artikel klickt.
- Der Kunde, der über eine Werbekampagne auf einer Landingpage landet, die die ganze Nacht unberührt blieb.
- Alle gleichzeitig, direkt nach einem Deploy, bei dem jeder Cache auf einmal geleert wurde.
- Besucher in einer Region, deren CDN-Edge diese Seite noch nie ausgeliefert hat.
Die Lösung: vorher aufwärmen
Cache Rocket beseitigt die Cold-Start-Strafe, indem es selbst die erste Besucherin ist. Es ruft deine URLs auf, bevor echte Menschen das tun, und zwingt damit jede Cache-Schicht vor deinem Origin, eine frische Kopie zu speichern. Wenn dann ein Mensch kommt, liegt die Seite bereits im Cache und wird sofort ausgeliefert.
Das ist die ganze Idee. Alles andere existiert, um sie praktikabel zu machen: entscheiden, *welche* URLs, *wie oft*, *von wo*, *wie schnell* — und nachweisen, dass es wirklich funktioniert hat.
Cache Rocket ersetzt deinen Cache nicht
Es ist kein CDN und kein Caching-Plugin. Es arbeitet *mit* dem, was du schon betreibst — Cloudflare, Fastly, Bunny, KeyCDN, nginx, Varnish, WP Rocket, Next.js. Wenn sich eine Cache-Schicht füllt, sobald eine URL angefragt wird, kann Cache Rocket sie gefüllt halten.
Was du aufwärmen kannst
Websites
Crawle Seiten ab Einstiegs-URLs und Sitemaps und folge Links bis zu einer Tiefe, die du wählst.
APIs
Wärme REST- und GraphQL-Endpunkte mit echten Methoden, Headern, Cookies und Bodies auf.
WordPress
Verwalte Warmer im wp-admin mit dem offiziellen Plugin, plus optionaler lokaler Optimierung.
Nach jedem Deploy
Starte das Aufwärmen aus Vercel, Netlify, Shopify oder jedem CI-Job, damit Releases nie kalt live gehen.
Ist Cache Rocket das Richtige für dich?
Es hilft am meisten, wenn Seiten teuer im Aufbau sind und der Verkehr ungleichmäßig genug ist, dass Caches zwischen Besuchen kalt werden.
| Du betreibst… | Was Aufwärmen für dich tut |
|---|---|
| Eine Content-Website oder ein Blog | Neue Beiträge und ältere Evergreen-Artikel bleiben sofort da, statt für den Ersten langsam zu sein. |
| Einen Onlineshop | Kategorieübersichten, Produktseiten und Kampagnen-Landingpages sind vor einer Verkehrsspitze bereit, nicht danach. |
| Eine Marketing-Website | Landingpages bezahlter Anzeigen begrüßen einen Klick nie mit langsamer Time-to-First-Byte, was deine Conversion schützt. |
| Eine headless oder API-getriebene App | Teure JSON- und GraphQL-Antworten bleiben am Edge und im Gateway gecacht, auch zwischen Client-Spitzen. |
| Websites für Kunden (Agentur) | Jeder Kunde lebt in einem eigenen Workspace mit eigenen Warmern, Hostnames und Alerts. |
Weniger hilft es, wenn deine Seiten bereits statische Dateien von der Platte ohne Ablauf sind, oder wenn jede Antwort pro Nutzer personalisiert und damit ohnehin nicht cachebar ist.
Wie du diese Dokumentation nutzt
Die Seiten sind für die Reihenfolge geschrieben, aber jede steht für sich. Wenn du ganz neu bist, ist das der schnellste Weg:
- 1
Lies Funktionsweise
Zehn Minuten darüber, was bei einem Aufwärmlauf wirklich passiert. Lohnt sich, bevor du Einstellungen änderst.
- 2
Folge dem Schnellstart
Eine begleitete Ersteinrichtung: Konto anlegen, Hostname verifizieren, ersten Warmer bauen und bestätigen, dass es funktioniert hat.
- 3
Überflieg Grundbegriffe
Der Wortschatz — Einstiegs-URLs, Tiefe, Intervalle, Wärme-Score. Die übrige Dokumentation setzt diese Begriffe voraus.
- 4
Dann geh in die Tiefe, wo du sie brauchst
Die Seitenleiste ist nach Aufgaben gruppiert: Einrichtung, Aufwärmen, Monitoring, Integrationen, Konto und Hilfe.
Suchst du eine bestimmte Einstellung?
Warmer-Einstellungen ist eine Feld-für-Feld-Referenz jeder Option im Warmer-Formular, inklusive Wirkung und Empfehlung, wann du sie änderst.
Verwendete Konventionen
Alles in Monospace tippst oder kopierst du genau so. Bildschirme in deinem Konto schreiben wir als Konto → Warmer, passend zu den Bezeichnungen in der Seitenleiste, wenn du angemeldet bist.