Nach jedem Cache-Flush, jedem Deploy, jedem Plugin-Update ist die erste Anfrage langsam — und genau dann läuft oft schon der erste Kunde rein. Der Cache Warmer crawlt deine URLs vor, parallelisiert höflich mit HTTP/2-Pooling und meldet sich per E-Mail, wenn alles wieder warm ist. Multi-Shop, Multi-Kunde, alles aus einer Hand.
Shopware-Caches werden bei jedem Deploy, jeder Plugin-Aktivierung und jedem Cron-Flush invalidiert. Die erste Anfrage pro Seite muss dann das komplette Template, alle Hooks und alle Listen neu aufbauen — oft 3–10 Sekunden. Der Cache Warmer macht genau diese erste Anfrage, bevor ein echter Besucher sie macht.
Cold-Start nach Flush
Der erste Besucher trifft auf eine 3–10 Sekunden langsame Seite. Bounce-Rate steigt, Conversion fällt, Google-Pagespeed-Score sinkt. Bei viel Traffic sind hunderte Seiten betroffen, bevor sich die Caches stabilisieren.
Warm-Start, automatisch
Direkt nach dem Cache-Flush wird die Sitemap durchgegangen. Kategorien, Produktdetail-Seiten, CMS-Pages, Hersteller-Listen — alles vorgeladen. Der erste echte Besucher bekommt sofort die schnelle, gecachte Version.
Per Webhook aus dem Shopware-Admin, per Cronjob, oder manuell aus dem Dashboard — du entscheidest, wann der Warmer läuft. Auch direkt nach bin/console cache:clear.
Liest sitemap.xml und alle Sitemap-Index-Files. Optional zusätzliche statische URL-Listen pro Shop. Variantenartikel, Kategorien, CMS-Seiten — automatisch erfasst.
Sequentielle Verarbeitung pro Shop, mehrere Shops parallel. Kein DDoS deines eigenen Servers — die Last bleibt im Rahmen, was deine Hardware verträgt.
Erkennt automatisch, ob ein Hit oder Miss vorlag (Varnish, Cloudflare, Shopware Http Cache). Statistik pro Lauf: wie viele Seiten waren schon warm, wie viele wurden neu erzeugt.
Fehlgeschlagene URLs (5xx, Timeout) werden mit Exponential Backoff erneut versucht. Endgültig fehlgeschlagene Calls landen im Report — sortiert nach HTTP-Status.
Jeder Sales Channel, jede Sprache, jede Domain wird separat behandelt — Multi-Shop-Setups sind First-Class-Bürger, kein Workaround.
Agenturen mit zehn Shops, Händler mit drei Marken-Storefronts, Reseller mit Kundenportfolio — alle in einer Instanz. Pro Kunde eigene Konfiguration, eigene Trigger, eigene Reports. Kein eigener Server pro Shop nötig.
Mehrere Shops pro Kunde werden zu einer Gruppe zusammengefasst. Innerhalb der Gruppe laufen Shops sequenziell — der Server des Kunden wird nie gleichzeitig von mehreren Warmer-Läufen getroffen.
Ist ein Kunde Eigentümer von Shop A, B und C, wird zuerst A komplett gewärmt, dann B, dann C — statt alle drei gleichzeitig. So bleiben Last und Bandbreite vorhersehbar.
Während Kunde X gewärmt wird, läuft Kunde Y schon. Die Sequenzialität gilt nur innerhalb einer Gruppe — zwischen Kunden wird parallelisiert.
Kundendaten, URLs, Reports, Statistiken — alles streng pro Kunden-Account isoliert. Auch im Audit-Log werden nur die eigenen Läufe gezeigt.
Concurrency, User-Agent, Auth-Header, Custom-URLs, ignorierte Pfade — alles pro Shop einstellbar. Defaults für die Gruppe, Override pro Shop.
Agentur-Setup: Hauptaccount mit allen Shops, einzelne Mitarbeiter sehen nur die ihnen zugewiesenen Kunden. Read-only oder Read-write konfigurierbar.
Statt für jede URL eine neue TCP- und TLS-Verbindung aufzubauen, hält der Warmer pro Origin einen HTTP/2-Stream offen. Hunderte URLs gehen über eine einzige Verbindung — schneller, sparsamer, und für den Server ein einziger zusammenhängender Stream statt vieler Verbindungen.
HTTP/2-Multiplexing erlaubt mehrere parallele Streams über eine einzige Verbindung. Statt 100 TLS-Handshakes für 100 URLs gibt es einen — Faktor 10-15 schneller bei modernen Hosts.
Spricht der Origin kein HTTP/2 (alte Proxies, manche Plesk-Setups), fällt der Warmer automatisch auf HTTP/1.1 mit Connection-Keepalive zurück. Kein Eingriff, kein manuelles Toggeln.
Default 4 parallele Requests pro Shop — anpassbar auf 1 (für sehr schwache Server) bis 16 (für dicke Maschinen). Pro Lauf statistisch ausgewertet, ob die Concurrency zu hoch oder zu niedrig war.
Optional einen Sleep zwischen den Requests einbauen — für sehr empfindliche Shared-Hostings. Auch dynamisches Sleep abhängig vom letzten Response-Code möglich.
Standard-User-Agent StoneWaterCacheWarmer/1.x — in Server-Logs eindeutig identifizierbar, von Suchmaschinen-Bots klar trennbar. Pro Shop überschreibbar.
Staging-Umgebungen mit HTTP-Auth? Ein Token im Header? Kein Problem — pro Shop konfigurierbar. Credentials werden AES-256-GCM-verschlüsselt gespeichert.
Die Sitemap kennt deine öffentlichen URLs am besten — Shopware generiert sie ohnehin pro Verkaufskanal. Der Warmer liest sie, dedupliziert, sortiert nach Priorität und arbeitet sie ab. Wer zusätzliche URLs braucht (Filter-Kombinationen, Login-Bereiche, API-Endpunkte), kann sie pro Shop ergänzen.
Shopware splittet bei großen Shops die Sitemap in mehrere Files (sitemap-product-1.xml, sitemap-category-1.xml …). Der Warmer folgt dem Sitemap-Index automatisch und holt alle Sub-Sitemaps.
URLs mit hoher <priority>-Angabe werden zuerst gewärmt — typischerweise Startseite und Top-Kategorien. Auch changefreq wird berücksichtigt, wenn aktiviert.
Account-Login, Service-Seiten, Landingpages außerhalb der Sitemap — als URL-Liste pro Shop ergänzbar. Mit Variablen für mehrsprachige Pfade.
Filter-Kombinationen mit GET-Parametern, Suchergebnis-URLs, Checkout-Schritte — alles per Glob-Pattern ausschließbar. Default-Ignores für typische Shopware-Pfade vorkonfiguriert.
Wenn dieselbe URL in mehreren Sub-Sitemaps oder in Custom-URLs auftaucht, wird sie nur einmal gewärmt. Query-Parameter werden normalisiert nach konfigurierbarem Regelset.
Sitemap wird nicht bei jedem Lauf neu geparst — es wird gecacht, bis sich der lastmod-Header ändert oder du explizit ein Re-Read triggerst. Spart Last bei stündlichen Läufen.
Der Cache Warmer ist nicht an einen festen Zeitpunkt gebunden. Drei Trigger-Mechanismen, alle gleichzeitig nutzbar — z.B. nächtlicher Cron für SEO-Frische, Webhook nach Deploy für Code-Releases, manueller Push nach Bulk-Update im PIM.
Standard-Cron-Syntax (0 3 * * *) pro Shop. Auch komplexe Pläne („täglich 3 Uhr, plus jede Stunde im Black-Friday-Zeitraum") möglich.
Ein einfacher HTTP-POST auf https://admin.cache-warmer.de/webhook/{token} startet einen Lauf. Direkt aus dem Deploy-Pipeline, aus einem Shopware-Plugin, oder aus einem Cron-Skript.
Optional: Companion-Plugin für Shopware 6.5/6.6/6.7, das den Warmer direkt nach cache:clear, Plugin-Update oder Theme-Recompile per Webhook anstößt.
„Jetzt warmen" — ein Klick pro Shop oder pro Gruppe. Mit Vorschau, wie viele URLs erfasst werden, bevor der Lauf startet.
Läuft schon ein Warmer-Run für einen Shop, wird der nächste Trigger nicht zu einem zweiten parallelen Lauf — sondern entweder in die Queue gestellt oder dedupliziert.
Versehentlich einen Lauf zur Mittagszeit gestartet? Mit einem Klick abbrechen — laufende Requests werden zu Ende geführt, neue nicht mehr gestartet.
Du willst nicht jeden Morgen ins Dashboard schauen. Der Warmer schickt nach jedem Lauf eine knappe E-Mail: wie viele URLs, wie viele Fehler, durchschnittliche Antwortzeit, Cache-Hit-Rate. Per Shop oder per Kunde, mit Schwellwerten für „nur bei Problemen melden".
Zusammenfassung in einer kompakten HTML-Mail: gesamte URLs, Fehler, Top-3-langsamste Seiten, gesamte Laufzeit. Versand direkt per Server-Sendmail — kein externer Mailservice nötig.
Hat ein Kunde fünf Shops, bekommt er eine einzige Mail mit allen fünf Reports zusammengefasst — statt fünf separater Mails. Wahlweise abends als Tagessummary oder live nach jedem Lauf.
Default: Mail nur bei Fehlerquote > 1 % oder bei 5xx-Antworten. Geräuscharm im Normalbetrieb, laut bei echten Problemen. Schwellwerte pro Shop konfigurierbar.
Technik bekommt die Fehler-Details, Marketing bekommt die Übersicht. Pro Adresse einstellbar, welche Stufe (Info / Warning / Error) sie empfängt.
Wer Slack nutzt: Incoming-Webhook hinterlegen, Reports gehen in den Channel. Oder generischen Webhook für eigene Tools (Discord, Mattermost, Datadog).
Jeder Versand wird gespeichert, im Dashboard nachlesbar. Mit Diff zur vorherigen Mail — siehst du auf einen Blick, ob die Fehlerquote steigt oder fällt.
Das Web-Dashboard unter admin.cache-warmer.de zeigt in Echtzeit, was gerade läuft. Welche Shops sind in der Queue, welche werden gewärmt, welche URLs hingen am längsten? Mit Live-Tail jedes laufenden Runs.
Per Server-Sent-Events bekommst du in der Browser-Ansicht jede gewärmte URL live mit Response-Code, Antwortzeit, Cache-Status. Kein Reload, kein Polling.
Jeder Lauf bleibt 30 Tage mit allen Einzel-URLs, Antwortzeiten und Status-Codes durchsuchbar. Statistiken (Durchschnitt, P95, Median) länger gespeichert.
Wird dein Shop schneller oder langsamer über die Zeit? Charts zeigen P50/P95-Antwortzeiten, Fehlerquote und Cache-Hit-Rate pro Woche, pro Monat, pro Quartal.
Login per Fingerabdruck oder Hardware-Key (FIDO2 / WebAuthn). Klassisches Passwort als Fallback. Pro User 2FA optional erzwingbar.
Alles, was im Dashboard sichtbar ist, gibt es auch per API: Runs starten, Status abfragen, Reports exportieren. Bearer-Token-Auth, pro User mit Scopes.
Klares, ruhiges Design: Orange für Aktionen, Navy für Daten, viel Whitespace. Auf Desktop und Mobile gleich gut bedienbar.
Alle Tarife enthalten die komplette Funktionspalette. Du wählst nur nach Shop-Anzahl und Volumen. Monatlich kündbar, 14 Tage kostenlos testen — ohne Kreditkarte.
Alle Preise zzgl. MwSt. Du brauchst mehr Volumen oder eine maßgeschneiderte Lösung? Schreib uns für ein individuelles Angebot.
Der Cache Warmer entstand für unsere eigenen Kundenshops und wird kontinuierlich um Funktionen erweitert, die im Alltag fehlen. Von der ersten internen Version bis zur aktuellen produktiv-stabilen Build.
cache:clearFast jede Frage zum Setup, zur Sicherheit oder zur Skalierung haben wir in den letzten Monaten schon einmal beantwortet. Wenn deine nicht dabei ist: kurze Mail genügt.
Der Cache Warmer ruft nach einem Cache-Flush automatisch alle URLs deines Shopware-Shops aus der sitemap.xml ab, damit die Caches — HTTP-Cache, Reverse-Proxy, Varnish, Cloudflare — wieder aufgebaut werden. Der erste echte Besucher bekommt dann sofort die schnelle, gecachte Version statt der 3–10 Sekunden langsamen Cold-Start-Antwort.
Im Starter-Tarif einen Shop, im Professional bis zu fünf, im Agency unbegrenzt viele. Pro Kunden-Account können beliebig viele Sub-User mit eigenen Rechten angelegt werden — ideal für Agenturen, die mehrere Kundenshops verwalten.
Nein, nicht zwingend. Der Cache Warmer braucht nur eine erreichbare sitemap.xml. Optional gibt es ein Companion-Plugin für Shopware 6.5/6.6/6.7, das den Warmer automatisch nach jedem cache:clear, Plugin-Update oder Theme-Recompile per Webhook anstößt — sinnvoll, aber kein Muss.
Nur die öffentlichen URLs deines Shops, ihre Antwortzeiten und HTTP-Status-Codes. Keine Seiteninhalte, keine Cookies, keine Kundendaten. Die Server stehen in Deutschland bei Creoline und werden DSGVO-konform betrieben. Gespeicherte HTTP-Auth-Credentials werden AES-256-GCM-verschlüsselt abgelegt.
Ja, im Agency-Tarif ist eine Self-Hosted-Variante enthalten. Du bekommst das Node.js-Paket mit better-sqlite3 und PM2-Konfiguration und kannst es auf deinem eigenen Server (z.B. Plesk-Hosting mit Node-Runtime) deployen. Updates erhältst du im Rahmen des aktiven Abos.
Die Concurrency pro Shop ist von 1 bis 16 parallelen Requests einstellbar. Zusätzlich kann ein Sleep zwischen den Requests konfiguriert werden, der bei 5xx-Antworten dynamisch hochgefahren wird. So bleibt die Last vorhersehbar — kein DDoS deines eigenen Servers. Bei wiederholten Timeouts wird der Lauf automatisch pausiert.
Der Warmer erkennt X-Cache-Header von Varnish, Cloudflare, Shopware HTTP-Cache, Nginx FastCGI-Cache und Plesk-Caching. Im Report wird pro Lauf ausgewiesen, wie viele Seiten als Hit oder Miss ankamen — du siehst sofort, ob dein Cache-Setup richtig greift.
Ja, 14 Tage unverbindlich auf allen Tarifen. Kein Auto-Renewal, keine Kreditkarte nötig — Trial-Account anlegen, Sitemap eintragen, ersten Lauf starten. Wenn er passt, regulär weiterbuchen; wenn nicht, einfach laufen lassen und nichts weiter tun.
Kein Marketing-Stack, sondern Tools, die wir selbst täglich nutzen. Alles läuft auf einem einzigen Creoline-Server, beobachtbar, debug-bar, ohne Vendor-Lock-in zu einem Cloud-Provider.
Solange ein Shop eine sitemap.xml liefert, kann der Warmer ihn crawlen. Shopware-spezifisch ist nur das optionale Companion-Plugin.
Single-Binary-Deployment auf Plesk-Nodejs-Runtime. Datenbank ist eine lokale SQLite-Datei — kein externer DB-Server nötig, kein Lock-in.
Der Warmer läuft auf unseren Creoline-Servern in Deutschland. Es werden nur die URLs deines Shops, ihre Antwortzeiten und Status-Codes gespeichert — keine Seiteninhalte, keine Cookies, keine Customer-Daten.
Optional auch als Self-Hosted-Variante auf deinem eigenen Server installierbar.
Single-Node-Service mit PM2-Cluster-Modus für Lastverteilung. Run-State in lokaler SQLite, Pre-Fetch-Cache der Sitemap auf der Filesystem-Ebene. HTTP/2-Pools mit Origin-bound Connection-Limits.
Logs werden via PM2 rotiert (täglich, 14 Tage), Audit-Trail in der DB länger gespeichert.
Egal ob ein einzelner Shop oder ein Agentur-Portfolio mit fünfzig Storefronts — der Cache Warmer macht den ersten Besuch nach jedem Cache-Flush genauso schnell wie den hundertsten. Schreib uns für einen Testzugang oder eine kurze Demo.