Caching ist Pflicht. Aber selten richtig gelöst
Langsame Website. CPU läuft heiß. Nutzer springen ab. Die Ursache liegt oft beim Caching – oder genauer: daran, dass irgendwer mal irgendwas irgendwo aktiviert hat. Das reicht selten. Gerade bei WordPress, Shop-Systemen oder Eigenbauten mit viel PHP-Code taucht das Thema ständig wieder auf. OPcache, Redis, Browser-Cache – jeder kennt die Begriffe. Viele Projekte nutzen sie halbherzig. Gefühlt ist die Konfiguration – einmal gemacht – dann für immer vergessen. Funktioniert. Bis zum nächsten Problem.
Im Alltag geht es meistens nicht um das 'Ob', sondern um das 'Wie'. OPcache beschleunigt PHP, Redis legt Sessions oder Objektdaten ins RAM, Browser-Cache spart Requests. Klingt einfach. Ist es aber nur, wenn alle Zahnräder ineinandergreifen. Sonst: Chaos. Doppeltes Caching. Oder Clients hängen auf uralten Dateien fest.
OPcache – Pflicht für PHP, aber Konfiguration zählt
OPcache ist seit PHP 5.5 dabei – einfach aktivieren reicht meistens nicht. Klar: Der Parser- und Compile-Overhead fällt weg, PHP-Dateien landen direkt aus dem Speicher. Gerade bei Systemen mit vielen kleinen Includes (Frameworks, CMS) spart das schnell Sekunden. Aber: 64 MB Cache-Größe? Für eine kleine WP-Installation vielleicht, für größere Projekte eher zu knapp. Wer mit Standardwerten arbeitet, erlebt gerne, dass Skripte rausfliegen und der Effekt verpufft.
Typische Parameter:
- `opcache.validate_timestamps` – in Entwicklung immer an, live je nach Deployment.
- `opcache.revalidate_freq` – Standard (2 Sekunden) ist meist ok. Entwickler mit CI/CD schrauben hier gerne runter.
Deployment? Klassiker: Nach einem Update läuft der alte Code, weil der Cache nicht gelöscht wurde. Symlinks, gemischte Deployments, eigene Skripte – alles schon gesehen. Debugging macht dann richtig Spaß. Oder eben nicht.
Redis – RAM ist schnell, aber nicht unfehlbar
Redis taucht oft als Session-Backend oder als Datenbank-Cache auf. Alles im RAM, Zugriff flott. Aber: Wenn die Redis-Instanz mal wackelt (Shared Hosting, günstiger VPS ohne vernünftiges Monitoring), dann kracht es. Sessions weg. Daten veraltet. Und manchmal merkt es tagelang niemand.
Fehler aus der Praxis:
- Keine oder zu lange TTL (Time To Live) – irgendwann ist der Cache nur noch Ballast.
- Zu komplexe Caching-Logik, jeder Entwickler cached was anderes. Nachvollziehbarkeit? Fehlanzeige.
Managed Redis-Dienste sind für Agenturen meistens das kleinere Übel. Monitoring inklusive, weniger Kopfschmerzen. TTL sollte Pflicht sein, sonst gammeln die Daten ewig und keiner weiß, was noch aktuell ist.
Browser-Cache – nervig, aber notwendig
Client-seitiger Cache klingt immer so harmlos. Einmal CSS geladen, fertig. In der Praxis: Falsche Header, Nutzer sehen uralte Dateien. Oder der Browser cached gar nichts. HTTP-Header wie `Cache-Control`, `ETag`, `Last-Modified` sind Pflicht. Ohne die richtige Einstellung landet man entweder bei "Bitte F5 drücken!" oder Support-Tickets wie "Die Änderung ist nicht online".
Was funktioniert:
- Statische Assets (CSS, JS, Bilder) über Dateinamen-Hash versionieren. Dann kann max-age ruhig hoch sein. Keine Hashes? Dann hilft nur der gute alte Neu-Laden-Trick.
- Dynamische Inhalte sollten keine langen Cachezeiten bekommen. Sonst gibt es Ärger mit sich ändernden Daten.
Fehlerbeispiel: Nach einem Update bleiben die alten Dateien aktiv, weil Dateinamen gleich geblieben sind. Lösung? Entweder konsequent versionieren – oder sich auf ständiges Erklären einstellen.
30 Jahre Webentwicklung: Was im Alltag hängen bleibt
Caching ist kein neues Thema. In den 90ern noch mit mod_cache, heute mit OPcache und Redis. OPcache hat PHP endlich entlastet – das war ein echter Fortschritt. Redis ist super, aber nur mit Disziplin. Wer alles und jeden Wert in den Cache wirft, verliert schnell die Kontrolle. Besonders in Teams: Jeder cached auf eigene Faust, TTLs stimmen nicht – irgendwann rätselt man, woher die Daten kommen.
Für Agenturen ab 5 Personen: OPcache immer, Redis nur mit Monitoring und klarer Cache-Strategie. Browser-Cache möglichst automatisieren – z.B. via Build-Script. Wer manuell Header setzt oder nach jedem Deployment die Configs anfasst, macht Fehler. Und vergisst irgendwann die eine Zeile, die Ärger bringt.
Kleine Projekte? OPcache genügt oft. Redis ist Luxus, bis Sessions oder Queries bremsen. Dann aber bitte mit Plan und nicht als Allzweckwaffe.
Fazit: Caching gezielt einsetzen – und im Blick behalten
Caching ist kein Sammelbecken für Daten. OPcache muss sein, bringt aber nur was mit passender Einstellung. Redis kann helfen, verlangt aber Disziplin. Browser-Cache spart Ressourcen, aber nur wenn konsequent versioniert und gesteuert wird.
Kurz:
- OPcache aktivieren, regelmäßig prüfen, Parameter anpassen.
- Redis: Nur mit TTL, Monitoring und klarer Verantwortung.
- Browser-Cache: Versionierung automatisieren, Fehlerquellen im Deployment vermeiden.
Wer das beherzigt, hat meist Ruhe. Die meisten Fehler entstehen aus Nachlässigkeit. Und manchmal hilft einfach ein Blick ins Log – bevor wieder jemand fragt, warum die Änderungen nicht sichtbar sind.
bye
mo
Zuletzt bearbeitet: