Herausforderungen mit Blitz Cache bei komplexen Craft CMS Multisites

Serverlast und Ressourcenbedarf

Bei großen Multisite-Projekten kann Blitz die Server ordentlich fordern. Das Generieren und Aktualisieren tausender statischer Seiten kostet viel CPU und RAM. Vor allem das Aufwärmen des Caches (also das Vorab-Rendern aller Seiten) und das Invalidieren bei Änderungen können zum Flaschenhals werden. In einem Setup mit rund 10.000 cachebaren Seiten entstand z. B. ein Cache von 2,4 GB. Das Leeren oder Neuberechnen hat dort regelmäßig zu Timeouts geführt – auch über die URL-API oder das Backend-Utility.

Hintergrundprozesse wie Cache-Clear-Jobs können je nach Umfang stundenlang laufen oder sich aufstauen. Ein Fall zeigte, dass schon eine kleine Änderung in einem großen System einen Job über zwei Stunden beschäftigt hat. Laut Dokumentation liegt das oft an PHP-Limits (Timeouts, zu wenig RAM). Die Empfehlung: Craft-Queue als Daemon laufen lassen und die PHP-Limits anpassen. Ohne diese Optimierung kann Blitz zwar Seiten schneller ausliefern, bringt den Server beim Aktualisieren aber ins Schwitzen.

Besonders problematisch wird’s beim Neuaufbau des Caches nach Änderungen. Wenn Inhalte stark miteinander verknüpft sind oder Templates ohne Eager Loading arbeiten, steigt die Zahl der Datenbank-Abfragen massiv. Blitz 4.4 reduziert zwar die nötigen Queries, doch bleibt der Vorgang aufwendig. Ein Extrembeispiel: 130 Sites in einer Installation. Schon eine Änderung an globalen Inhalten löste dort dutzende Timeouts aus, weil der Cache für alle Sites gleichzeitig erneuert wurde. Das zeigt: Bei sehr großen Setups kann Blitz schnell an technische Grenzen stoßen.

Cache-Invalidierung bei häufigen Änderungen

Ein weiteres Thema ist die Cache-Invalidierung. Wenn Redakteure Inhalte ändern, will Blitz automatisch die betroffenen Seiten aktualisieren. Bei vielen und häufigen Änderungen führt das aber zu Dauerbetrieb – Caches werden ständig gelöscht und neu aufgebaut. Das kann zu Verzögerungen führen, etwa wenn neue Inhalte erst mit Verspätung im Frontend erscheinen.

Geplante Veröffentlichungen sind ein typisches Beispiel: In einem Fall wurde ein Beitrag pünktlich freigeschaltet, erschien aber nicht, weil der Cache noch nicht erneuert war. Die alte Version blieb online. Zwar kann man mit Cronjobs gegensteuern, das bringt aber zusätzlichen Setup-Aufwand.

Bei vielen Redakteuren auf unterschiedlichen Sites entsteht ein weiteres Problem: laufend ändert jemand etwas – Blitz reagiert, indem ständig irgendwo der Cache neu gebaut wird. Das belastet Queue und Datenbank dauerhaft. Manche Entwickler empfehlen deshalb, die automatische Invalidierung zu entschärfen, z. B. über geplante Updates alle X Minuten. Das reduziert die Last, macht Änderungen aber weniger direkt sichtbar.

Dynamik und Template-Kompatibilität

Blitz ist ein statischer Cache – personalisierte Inhalte sind damit erstmal außen vor. Inhalte, die sich je nach Nutzer unterscheiden (z. B. Begrüßungen, Warenkörbe), lassen sich so nicht direkt cachen. Blitz würde dann für alle Nutzer das gleiche HTML ausspielen – inklusive fremder Sessions. Solche dynamischen Bereiche müssen daher gezielt ausgenommen und per JavaScript oder AJAX nachgeladen werden.

Blitz bietet dafür Platzhalter und Sprig-Support, aber das ist nicht trivial. Ein Beispiel: Ein Shop lädt Preisinfos per AJAX, um sie nur für eingeloggte Nutzer anzuzeigen. Wenn die Konfiguration nicht passt, zeigt die Seite den Gast-Zustand statt der eingeloggten Version – oder vergisst, den richtigen CSRF-Token zu aktualisieren. Bei modernen JS-Frameworks (z. B. mit PJAX-Navigation) muss man zusätzlich dafür sorgen, dass Blitz sein Inject-Skript richtig triggert – sonst bleiben Formulare mit veralteten Tokens stehen.

Auch spezielle Template-Strukturen sind ein Thema. Wenn viele relationale Queries im Spiel sind, kann Blitz die Abhängigkeiten kaum noch effizient tracken – in einem Fall wuchs die Tracking-Tabelle auf über 886.000 Einträge an. Abhilfe schafft das Deaktivieren des Trackings, was aber bedeutet: Entwickler müssen die Abhängigkeiten dann manuell pflegen.

Multisite-Herausforderungen

In Multisites verdoppeln oder verdreifachen sich die Probleme. Jede Site bringt eigene URLs, Inhalte und Caches mit. Blitz muss das alles getrennt verwalten. Die Konfiguration wird aufwendiger, z. B. was URI-Muster, Base-URLs oder Deployment-Ziele betrifft. Fehler in der Konfiguration führen schnell dazu, dass nur die Haupt-Site korrekt gecacht wird.

Ein bekanntes Problem ist die unvollständige Invalidierung bei Eintragsänderungen: Wird z. B. die deutsche Version eines Beitrags deaktiviert, blieb die statische Seite manchmal trotzdem bestehen – die Seite war faktisch offline, aber der Cache lieferte sie weiter aus. Erst manuelles Löschen half. Das ist inzwischen gefixt (ab Blitz 4.13.0), zeigt aber die Tücken komplexer Strukturen.

Auch globale Inhalte betreffen alle Sites – ändert ein Redakteur ein globales Feld, leert Blitz alle Caches. Das kann Teams überraschen, die nur für eine Sprachversion zuständig sind. Wirklich granulare Steuerung pro Site gibt es nur eingeschränkt. Bei 130 Sites kann eine kleine Änderung also 130 Clear-Vorgänge auslösen. Auch beim Deployment muss man aufpassen: Jede Site braucht eigene Pfade, Domains oder CDN-Ziele.

Wartung und Skalierung

Blitz ist kein „Install-and-forget“-Plugin. Je größer das Setup, desto mehr Pflege braucht es. Dazu gehören:

• Cache-Clears besser per CLI als im Backend (wegen Timeouts)
• Cronjobs für geplante Refreshs
• Deaktivieren des File-Zählens im Control Panel bei großen Caches
• Manuelles Tracking oder Abhängigkeiten über „source tags“ festlegen
• Regelmäßige Plugin-Updates im Blick behalten (z. B. Fixes für Header oder Multisite-Handling)

Skalierbar ist Blitz – aber nicht kostenlos. Große Setups brauchen mehr Hardware und eine durchdachte Konfiguration. In manchen Fällen sind serverseitige Alternativen wie Nginx FastCGI oder externe CDNs einfacher. Blitz unterstützt solche Kombinationen (z. B. durch Purge-Integration mit Cloudflare), aber auch das muss gepflegt werden.

Wann Blitz weniger sinnvoll ist

In der Community gilt Blitz als stark – aber nicht für alles. Abgeraten wird:

• Bei stark personalisiertem Content (z. B. Login-Bereiche, Shops mit Nutzerpreisen)
• Wenn Inhalte im Minutentakt aktualisiert werden
• Wenn bereits externe Caching-Systeme oder CDNs im Einsatz sind
• Bei extremen Setups mit tausenden Sites, wo Performance und Wartung aus dem Ruder laufen
• In E-Commerce-Projekten mit viel dynamischem Verhalten (z. B. Warenkorb, Checkout)

Dann lohnt sich oft eher Fragment-Caching, Sprig, gute Query-Optimierung – oder ein anderer Caching-Ansatz ganz ohne statisches Full-Page-Caching.