TYPO3 Performance optimieren: Caching, Datenbank, Extbase und CDN – die wichtigsten Stellschrauben

Warum Performance in TYPO3 oft „gefühlt“ schlecht ist – und wie Sie systematisch vorgehen

TYPO3 ist im Kern sehr performant, aber in realen Projekten entstehen Engpässe meist durch eine Kombination aus unpassender Cache-Strategie, teuren Datenbankabfragen, Extbase-Overhead, zu großen Assets und fehlender Edge-Auslieferung. Wer „einfach nur mehr Server“ bucht, bekämpft Symptome. Wer sauber misst und die richtigen Stellschrauben dreht, reduziert Ladezeiten nachhaltig und stabil – und verbessert gleichzeitig Wartbarkeit und Betrieb.

Dieser Leitfaden richtet sich an TYPO3-Entwickler und technische Projektverantwortliche. Er führt Schritt für Schritt durch Messung, typische Bottlenecks und konkrete Maßnahmen: Caching (Core/Framework/Reverse Proxy), Datenbank-Optimierung, Extbase-Fallstricke, CDN sowie Bild- und Asset-Strategien. Als Messgrößen nutzen wir u. a. TTFB (Serverantwort), LCP (Largest Contentful Paint) und CLS (Cumulative Layout Shift).

Schritt 1: Messen statt raten – Baseline und Zielwerte definieren

Bevor Sie optimieren, brauchen Sie eine reproduzierbare Baseline. Sonst „optimieren“ Sie möglicherweise nur den Cache-Warmup oder verschieben die Last von PHP zur Datenbank.

1.1 Mess-Setup (Minimal-Workflow)

• TTFB: Mit Browser DevTools (Network) oder synthetisch (z. B. curl). Wichtig: einmal „cold“ (Cache leer) und einmal „warm“ (Cache gefüllt) messen.

• LCP/CLS: Mit Lighthouse/Chrome DevTools oder CrUX/PSI. Achten Sie darauf, ob LCP ein Bild, ein Hero-Block oder Text ist.

• TYPO3-seitig: Admin Panel (Performance/Queries), Logging von DB-Queries, optional Profiler (XHProf/Blackfire) für Hotspots.

Typischer Zielkorridor (stark abhängig von Projekt/Region): TTFB warm < 200–400 ms, LCP < 2,5 s, CLS < 0,1. Für Backends und nicht-cachebare Seiten gelten andere Erwartungen – dort zählen vor allem Query-Zahl und PHP-Zeit.

1.2 Schnelltest per Kommandozeile

Für eine schnelle TTFB-Indikation (ohne Rendering) können Sie die Serverantwortzeit messen. Nutzen Sie dabei immer dieselbe URL und testen Sie mit/ohne Cache-Warmup.

Schritt 2: TYPO3-Caching richtig konfigurieren – der größte Hebel für TTFB

Wenn TYPO3-Seiten cachebar sind, ist Caching fast immer der stärkste Performance-Hebel. Häufige Probleme sind: zu viele „no_cache“-Pfadvarianten, unabsichtliche User-spezifische Inhalte, falsch gesetzte Cache-Tags oder ein Cache-Backend, das unter Last nicht skaliert.

2.1 Cachebarkeit prüfen (und wiederherstellen)

• Seiten/Plugins: Prüfen Sie, ob Plugins unnötig „USER_INT“ nutzen oder durch Session/FE-User-Checks die Seite uncachebar machen.

• Variantenexplosion: Parameter, Sprache, Device-Varianten, A/B-Tests können Cache-Varianten vervielfachen. Reduzieren Sie unnötige Variationen.

• Cache-Tags: Stellen Sie sicher, dass Inhalte korrekt invalidiert werden (z. B. bei Datensatz-Updates). Zu aggressive Invalidierung kann den Cache permanent „kalt“ halten.

2.2 Cache-Backends: Datenbank vs. Redis

Das Standard-DB-Backend ist für kleine Installationen ok, wird aber bei hoher Last und vielen Cache-Operationen schnell zum Bottleneck (Locking, I/O, große Cache-Tabellen). Redis ist in TYPO3-Projekten ein gängiger Schritt, um Cache-Operationen zu beschleunigen und die Datenbank zu entlasten.

Ein typischer Ansatz ist, Core-Caches (z. B. pages, hash, extbase) auf Redis zu legen. Achten Sie dabei auf Persistenz/Memory-Policy und Monitoring (Evictions). Beispielkonfiguration (als Orientierung, projektspezifisch anpassen):

In der Praxis gehört dazu eine PHP-Konfiguration (Redis-Extension), ein Redis-Service (lokal oder managed) und eine TYPO3-Cache-Konfiguration. Prüfen Sie nach der Umstellung: Cache-Hit-Rate, Redis-Memory, Evictions, Latenzen.

2.3 Reverse Proxy / HTTP-Cache (Varnish/Nginx) für maximale TTFB

Wenn Ihre Seiten überwiegend öffentlich und cachebar sind, bringt ein Reverse Proxy vor PHP-FPM den größten TTFB-Gewinn. TYPO3 liefert dafür Cache-Header, aber Sie müssen das Zusammenspiel sauber konfigurieren:

• Cache-Control/Surrogate-Control: Klare TTL-Strategie (kurz + Purge) oder länger + Tag-basiertes Purging.

• Purge-Strategie: Purge bei Content-Änderungen (z. B. über Cache-Tags/URLs). Ohne Purge werden TTLs oft zu kurz gewählt, was die Hit-Rate zerstört.

• Cookies: Viele Set-Cookie-Header machen Seiten im Proxy uncachebar. Entfernen Sie unnötige Cookies für anonyme Nutzer.

Caveat: Reverse Proxy-Caching ist nur so gut wie Ihre Cacheability. Wenn jede Seite personalisiert ist, müssen Sie stärker auf Fragment-Caching, ESI oder konsequente Trennung von personalisierten Endpunkten setzen.

2.4 TYPO3 Context & Production-Settings

Stellen Sie sicher, dass die Instanz im richtigen Context läuft (Production). Development-Settings (Debug, kein Caching, ausführliches Logging) sind ein häufiger Grund für „mysteriös“ langsame Systeme.

Flush ist kein Performance-Feature, aber wichtig für reproduzierbare Tests (cold/warm). Messen Sie nach einem Flush gezielt: erster Request (cold) vs. Folge-Requests (warm). Wenn warm kaum schneller ist, ist die Seite vermutlich uncachebar oder der Cache wird ständig invalidiert.

Schritt 3: Datenbank-Performance – Queries reduzieren, Indizes nutzen, Last verlagern

TYPO3-Performance-Probleme sind oft Query-getrieben: zu viele Abfragen pro Request, fehlende Indizes, teure JOINs, oder „N+1“-Muster durch Extbase/Repository-Logik. Ziel ist nicht nur „schnellere Queries“, sondern vor allem weniger Queries.

3.1 Query-Transparenz herstellen

• Admin Panel: Query-Anzahl und -Zeit pro Request prüfen. Achten Sie auf Ausreißer.

• DB-Logging: Slow Query Log aktivieren (MySQL/MariaDB) und echte Produktionslast betrachten.

• EXPLAIN: Für die Top-Queries prüfen, ob Indizes genutzt werden.

Typische Warnsignale: 200+ Queries auf einer Seite, einzelne Queries > 100 ms, oder viele ähnliche Queries mit nur leicht variierenden Parametern.

3.2 Indizes und Datenmodell

• Indizes auf Filterspalten: Häufige WHERE-Spalten (pid, sys_language_uid, deleted, hidden, starttime/endtime, sorting, category relations) brauchen passende Indizes.

• Relationstabellen: m:n-Tabellen (z. B. Kategorien) werden schnell teuer. Prüfen Sie Indizes auf beiden Fremdschlüsseln.

• Große Tabellen: Archivieren Sie alte Datensätze (z. B. Logs, historische Imports), wenn sie nicht mehr im Frontend gebraucht werden.

Caveat: Indizes sind kein Allheilmittel. Zu viele Indizes verlangsamen Writes. Optimieren Sie anhand realer Query-Profile, nicht „auf Verdacht“.

3.3 TYPO3-spezifische DB-Fallen

• Workspace/Versioning: Kann zusätzliche Join-Logik erzeugen. Prüfen Sie, ob Workspaces im Frontend wirklich relevant sind.

• Sprachen/Fallbacks: Mehrsprachigkeit erhöht Query-Komplexität. Achten Sie auf saubere Sprachkonfiguration und vermeiden Sie unnötige Fallback-Kaskaden.

• Site-Handling/Route Enhancers: Viele dynamische Routen können zusätzliche Lookups verursachen. Caching der Routen und saubere Slug-Strategien helfen.

Schritt 4: Extbase Performance Tipps – typische Bottlenecks und konkrete Gegenmaßnahmen

Extbase ist produktiv und bequem, kann aber bei großen Datenmengen oder ungünstiger Repository-Nutzung schnell teuer werden. Die häufigsten Probleme sind: zu viele Objekt-Hydrations, Lazy-Loading-Kaskaden und unkontrollierte Query-Erzeugung.

4.1 N+1 vermeiden (Lazy Loading bewusst einsetzen)

• Symptom: Eine Liste von 50 Datensätzen lädt pro Datensatz weitere Relationen nach (z. B. Kategorien, Bilder, Autoren) – Ergebnis: hunderte Queries.

• Gegenmaßnahme: Relationen gezielt vorladen (wo sinnvoll), Rendering so umbauen, dass nicht pro Item zusätzliche Daten nachgeladen werden, oder auf flachere DTOs/Arrays für Listenansichten setzen.

4.2 QuerySettings und Constraints sauber halten

• Nur benötigte Felder: Extbase hydriert standardmäßig komplette Objekte. Für reine Listen/Teaser kann ein schlankeres Modell oder eine Query über QueryBuilder sinnvoll sein.

• Limit/Offset: Paginieren Sie konsequent. „Alle Datensätze laden und im PHP filtern“ ist ein Klassiker.

• Sorting: Sortierung in SQL statt in PHP. Prüfen Sie, ob die Sortierspalte indexiert ist.

4.3 Caching auf Anwendungsebene

Nicht alles muss pro Request aus der DB kommen. Typische Kandidaten für Application-Caching:

• Navigationen, Footer-Teaser, „Top“-Listen, Aggregationen (Counts), Konfigurationen aus TypoScript/Settings, externe API-Responses.

• Cache-Tags so setzen, dass bei Content-Änderungen gezielt invalidiert wird (statt globaler Flush).

Caveat: Application-Caching ohne saubere Invalidierung führt zu „stale content“-Bugs. Nutzen Sie Cache-Tags und definieren Sie klare TTLs für Daten, die nicht streng konsistent sein müssen.

Schritt 5: CDN einbinden, Bilder und Assets optimieren – Core Web Vitals verbessern

Wenn TTFB gut ist, aber LCP/CLS schlecht bleiben, liegt das Problem meist im Frontend: große Bilder, blockierende CSS/JS, fehlende Dimensionen, zu viele Third-Party-Skripte oder fehlende Edge-Auslieferung.

5.1 CDN-Strategie (statisch zuerst)

• Startpunkt: Liefern Sie statische Assets (Bilder, CSS, JS, Fonts) über ein CDN aus. Das reduziert Latenz und entlastet den Origin.

• Cache-Header: Lange Cachezeiten für versionierte Assets (mit Hash im Dateinamen). Kurze Cachezeiten für nicht-versionierte Ressourcen vermeiden.

• Invalidierung: Bei CDNs ist Purge/Invalidate Teil des Deployments. Ohne sauberes Versioning wird das schnell fehleranfällig.

TYPO3-seitig ist wichtig, dass Asset-URLs stabil versioniert sind (z. B. durch Build-Pipeline) und dass Sie keine unnötigen Query-Parameter erzeugen, die CDN-Caching verhindern.

5.2 Bilder: LCP senken ohne Qualitätsverlust

• Hero/LCP-Bild: Priorisieren Sie das LCP-Element. Reduzieren Sie Dateigröße (WebP/AVIF), passende Dimensionen, sinnvolle Kompression.

• Responsive Images: Nutzen Sie mehrere Größen, damit Mobile nicht Desktop-Bilder lädt.

• Lazy Loading: Für Below-the-fold ja, für das LCP-Element nein (sonst verschlechtern Sie LCP).

• CLS vermeiden: Breite/Höhe bzw. Aspect Ratio definieren, damit Layout nicht springt.

5.3 CSS/JS: Render-Blocking reduzieren

• Critical CSS: Für wichtige Templates kann Critical CSS LCP deutlich verbessern. Aber halten Sie es klein und automatisieren Sie es (sonst Wartungshölle).

• JS-Budget: Reduzieren Sie Third-Party-Skripte. Viele Performance-Probleme kommen nicht aus TYPO3, sondern aus Tag-Managern, Chat-Widgets, Tracking.

• HTTP/2/3: Viele kleine Assets sind weniger schlimm als früher, aber unnötige Libraries bleiben teuer (Parse/Execute).

Schritt 6: Typische Bottlenecks in bestehenden TYPO3-Instanzen (Checkliste)

• Warm-Cache ist nicht schneller als Cold-Cache: Seite uncachebar, Cache wird invalidiert, oder Reverse Proxy/CDN greift nicht.

• Viele Cookies für anonyme Nutzer: Proxy/CDN caching fällt aus.

• Extbase Listen mit Relationen: N+1 Queries, zu viel Hydration.

• Fehlende DB-Indizes: Besonders bei großen Tabellen und m:n-Relationen.

• Zu große Bilder im Above-the-fold: LCP schlecht trotz guter TTFB.

• Layout Shifts: Fehlende Bilddimensionen, nachladende Fonts, dynamische Banner.

• Debug/Dev-Context in Produktion: Logging/Debug-Ausgaben und deaktivierte Caches.

Schritt 7: Ein pragmatischer Optimierungsplan (2–5 Tage, realistisch)

Tag 1: Messen & Hypothesen

• TTFB cold/warm, LCP/CLS aufnehmen (3–5 repräsentative Seiten).

• Admin Panel: Query-Anzahl/-Zeit, auffällige Plugins/Content-Elemente identifizieren.

• Server: PHP-FPM, CPU, DB-Load, Cache-Hit-Rate prüfen.

Tag 2: Caching stabilisieren

• Cacheability herstellen (USER_INT vermeiden, Cookies reduzieren).

• Cache-Backend prüfen (DB vs. Redis), Cache-Invalidierung analysieren.

• Optional Reverse Proxy-Konzept skizzieren (wenn hoher Public-Traffic).

Tag 3: DB/Extbase Hotspots

• Top 10 Slow Queries: EXPLAIN, Indizes, Query-Reduktion.

• Extbase-Listen refactoren (N+1, Pagination, QueryBuilder für „read-heavy“ Views).

Tag 4–5: Assets/CDN/Web Vitals

• LCP-Element optimieren (Bildformat, Größe, Priorisierung).

• CLS fixen (Dimensionen, Fonts, dynamische Elemente).

• CDN für statische Assets, sauberes Versioning, Cache-Header.

Messmethoden nach der Optimierung: Was „gut“ wirklich bedeutet

Nach jeder Maßnahme messen Sie erneut und dokumentieren: TTFB warm/cold, LCP, CLS, Query-Anzahl, Serverlast. Achten Sie darauf, dass Verbesserungen nicht nur im Labor (Lighthouse) auftreten, sondern auch in Felddaten (CrUX), sobald genug Traffic vorhanden ist.

• TTFB: Verbessert sich meist durch Caching/Reverse Proxy/Redis.

• LCP: Verbessert sich meist durch Bild/Asset-Optimierung und weniger Render-Blocking.

• CLS: Verbessert sich durch stabile Layouts (Dimensionen, Fonts, Platzhalter).

Fazit: TYPO3 Performance optimieren heißt Engpässe isolieren – nicht „alles tun“

Die wirksamsten Maßnahmen sind selten exotisch: Cachebarkeit herstellen, Cache-Backends skalierbar machen (z. B. Redis), Query-Zahl reduzieren, Extbase-N+1 vermeiden und LCP/CLS über Bilder/Assets/CDN verbessern. Wenn Sie in dieser Reihenfolge vorgehen und jede Änderung messbar machen, reduzieren Sie Ladezeiten nachhaltig – und vermeiden typische Nebenwirkungen wie stale content, Cache-Variantenexplosion oder schwer wartbare „Micro-Optimierungen“.