TYPO3 ist langsam: wo die Zeit verloren geht
Fast jede TYPO3-Bremse lässt sich auf eine Frage zurückführen: Kommt diese Seite aus dem Cache, oder wird sie bei jedem Aufruf neu gerechnet?
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die meisten Optimierungsversuche fangen an der falschen Stelle an
Wenn eine Website als langsam gemeldet wird, beginnt die Suche meist bei den Bildern. Das ist nicht falsch, aber es beantwortet die Frage nicht, denn Bilder erklären nur einen Teil und nie den Fall, in dem der Browser sekundenlang wartet, bevor überhaupt etwas ankommt. Diese Wartezeit vor dem ersten Byte entsteht auf dem Server, und dort entscheidet fast immer eine einzige Sache: ob die Seite aus dem Cache kommt.
Der Unterschied ist erheblich. Eine zwischengespeicherte Seite wird im Wesentlichen aus der Datenbank gelesen und ausgeliefert. Eine nicht zwischengespeicherte Seite durchläuft bei jedem Aufruf die vollständige Erzeugung: Menüs aufbauen, Datensätze holen, Bilder prüfen, Erweiterungen ausführen. Auf einer gut gefüllten Installation liegen zwischen beiden Zuständen keine Prozente, sondern Größenordnungen, und genau deshalb ist diese Frage die erste, die du beantwortest.
Der Schaden zeigt sich zuerst dort, wo es wehtut. Unter Last vervielfacht sich der Effekt, weil jeder gleichzeitige Aufruf dieselbe Arbeit erneut auslöst, bis die Datenbank blockiert. Genau deshalb sind solche Installationen im Alltag unauffällig und brechen ausgerechnet dann ein, wenn eine Kampagne läuft oder eine Pressemeldung Wirkung zeigt.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Symptom, Ursache, Lösung
Symptom
Eine Detailseite braucht bei jedem Aufruf gleich lang, auch beim zweiten und dritten Mal, während die Startseite sofort da ist.
Ursache
Diese Seite wird tatsächlich bei jedem Aufruf neu gebaut, und dafür gibt es genau drei Auslöser. Entweder steht in der TypoScript-Konfiguration ein pauschales config.no_cache, oder die Seite selbst trägt in ihren Eigenschaften den Schalter, der das Zwischenspeichern abschaltet, oder eine Erweiterung auf dieser Seite setzt den Zustand zur Laufzeit, weil sie personalisierte Inhalte ausgibt. Ein einzelner nicht zwischengespeicherter Baustein reicht dafür ausdrücklich nicht: Der wird außerhalb des Seitenaufbaus gerendert, während der Rest der Seite weiter aus dem Zwischenspeicher kommt. Deshalb ist ein solcher Baustein die Lösung und nicht die Ursache.
Lösung
Such zuerst nach einem gesetzten no_cache in der Konfiguration und entferne es, denn als Dauerlösung ist es nie richtig. Prüf danach die Plugins auf der Seite: Braucht wirklich die ganze Ausgabe einen frischen Stand, oder nur ein kleiner Teil davon? Wenn nur ein Teil dynamisch sein muss, gehört genau dieser Teil in einen nicht zwischengespeicherten Baustein und der Rest bleibt im Cache.
Symptom
Eine Übersicht mit Filtern und Suche wird langsamer, je mehr Datensätze dazukommen, und ab einigen tausend Einträgen wartet man deutlich.
Ursache
Die Abfrage holt mehr Daten als gebraucht werden, oder sie läuft mehrfach. Typisch ist das Auslesen aller Datensätze mit anschließendem Filtern im Code statt in der Datenbank. Dazu kommt der Fall, dass in der Ausgabe je Zeile eine weitere Abfrage abgesetzt wird, was bei zehn Zeilen niemand merkt und bei zweitausend die Seite lahmlegt.
Lösung
Lass filtern, sortieren und begrenzen dort passieren, wo die Daten liegen, und gib nur so viele Datensätze aus, wie auf eine Seite gehören. Wenn eine Übersicht seitenweise blättert, muss auch die Abfrage seitenweise arbeiten. Bleibt es danach zäh, prüf die Indizes auf den Feldern, nach denen tatsächlich gefiltert und sortiert wird.
Symptom
Seiten mit dem vollständigen Hauptmenü sind spürbar langsamer als Seiten ohne, und es wird schlimmer, seit der Seitenbaum gewachsen ist.
Ursache
Das Menü läuft über einen sehr großen Teil des Seitenbaums, und für jede Seite werden dabei Zugriffsrechte, Sprachfassung und Sichtbarkeit geprüft. Solange die Seite selbst zwischengespeichert wird, fällt das kaum auf. Auf einer Seite, die aus dem Cache herausgefallen ist, schlägt der Aufwand dagegen bei jedem einzelnen Aufruf zu.
Lösung
Begrenz das Menü auf die Ebenen, die tatsächlich angezeigt werden, statt den gesamten Baum einzulesen und den Rest per Gestaltung auszublenden. Prüf außerdem, ob große Zweige über Menüeinstellungen ausgeschlossen werden können. Und behandle die Ursache dahinter: Ein Menü ist selten das eigentliche Problem, sondern der Verstärker eines Cache-Problems.
Symptom
Die Website ist meistens schnell und wird gelegentlich für Minuten zäh, ohne dass jemand etwas geändert hat.
Ursache
Beim Seitenaufbau wird ein fremder Dienst angesprochen, etwa eine Bewertungsplattform, ein Kartendienst, eine Wechselkursabfrage oder eine Schnittstelle zu einem anderen System im Haus. Antwortet dieser Dienst langsam, wartet der Seitenaufbau mit. Damit hängt die eigene Ladezeit an der Verfügbarkeit eines Systems, über das ihr nicht bestimmt.
Lösung
Nimm solche Aufrufe aus dem Seitenaufbau heraus. Entweder holt eine geplante Aufgabe die Daten regelmäßig ab und legt sie lokal ab, dann liest die Seite nur noch den gespeicherten Stand, oder der Inhalt wird erst im Browser nachgeladen und die Seite steht auch ohne ihn. Wo ein direkter Aufruf unvermeidlich ist, gehört ein knappes Zeitlimit dazu und eine Ausgabe, die auch ohne Antwort funktioniert.
Symptom
Backups dauern immer länger, die Datenbank wächst schneller als die Inhalte, und das Backend wirkt träge.
Ursache
Die Tabellen des Caching-Systems und die Protokolltabellen wachsen im laufenden Betrieb und werden nicht aufgeräumt. Abgelaufene Einträge verschwinden nicht von selbst, sondern erst, wenn jemand sie entfernen lässt. In Installationen, in denen nie eine Aufräumaufgabe eingerichtet wurde, macht dieser Ballast irgendwann den größten Teil der Datenbank aus.
Lösung
Richte im Scheduler zwei Aufgaben ein und lass sie täglich laufen. Die erste ist die Garbage Collection des Caching Frameworks, sie entfernt abgelaufene Einträge aus den Cache-Tabellen. Die zweite ist die Table Garbage Collection, mit der du für sys_log und sys_history festlegst, wie lange Einträge aufgehoben werden. Für beide gilt: Sie räumen nur auf, was abgelaufen ist, und nicht das, was einmal ohne Ablaufdatum entstanden ist. Wenn eine Installation über Jahre nie aufgeräumt wurde, gehört deshalb ein einmaliges vollständiges Leeren des Zwischenspeichers davor. Das ist Wartung und keine Optimierung, aber es ist der Punkt, an dem die meisten Installationen über Jahre nichts tun.
Fünf Prüfschritte in der richtigen Reihenfolge
- 01 Miss zuerst die Zeit bis zum ersten Byte, getrennt vom Rest der Ladezeit.
- 02 Ruf dieselbe Seite zweimal auf und vergleich die Wartezeit beider Aufrufe.
- 03 Stell fest, ob die Seite aus dem Cache kommt oder jedes Mal neu gebaut wird.
- 04 Such nach Bausteinen, die bewusst nicht zwischengespeichert werden.
- 05 Prüf zuletzt Bilder und fremde Skripte, denn die wirken erst im Browser.
Was du danach beurteilen kannst
Ziel ist nicht eine Liste von Einstellungen, sondern eine Reihenfolge beim Suchen. Wer sie einhält, findet die Ursache meist in einer halben Stunde, statt tagelang an Symptomen zu drehen.
Server und Browser trennen
Du unterscheidest die Wartezeit bis zum ersten Byte von der Zeit, die der Browser danach mit Bildern und Skripten verbringt. Beide haben völlig verschiedene Ursachen und Lösungen.
Den Cache-Status feststellen
Du prüfst je Seitentyp, ob eine Auslieferung aus dem Cache stattfindet, statt es zu vermuten. Damit fällt die Hälfte der möglichen Ursachen sofort weg.
Nicht zwischenspeicherbare Inhalte erkennen
Du weißt, dass einzelne Bausteine eine ganze Seite aus dem Cache nehmen können, und findest die Stelle, an der das eingestellt wurde.
Teure Abfragen lokalisieren
Du erkennst Listen, Suchen und Menüs, die über sehr viele Datensätze laufen, und beurteilst, ob die Menge oder die Wiederholung das Problem ist.
Fremde Dienste aus dem Rendering halten
Du siehst, warum ein externer Aufruf während des Seitenaufbaus die eigene Ladezeit an die Verfügbarkeit eines fremden Systems bindet.
Die Datenbank im Blick behalten
Du weißt, dass Cache- und Protokolltabellen ohne Aufräumen wachsen, und was das für Backups und für das Backend bedeutet.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Erst messen, wo die Zeit vergeht
Zwei Zahlen genügen für den Anfang. Die erste ist die Wartezeit bis zum ersten Byte, also die Zeit zwischen dem Absenden der Anfrage und dem Eintreffen der ersten Antwort. Sie entsteht vollständig auf dem Server und ist der Wert, an dem sich TYPO3 messen lassen muss. Die zweite ist die Zeit danach, bis die Seite fertig dargestellt ist. Sie entsteht im Browser und hängt an Bildern, Schriften, Skripten und allem, was von fremden Adressen nachgeladen wird.
Diese Trennung erspart die meisten Irrwege. Liegt die Wartezeit bis zum ersten Byte im Bereich weniger hundert Millisekunden und die Seite fühlt sich trotzdem langsam an, brauchst du an TYPO3 nichts zu ändern. Dann geht es um Bildgrößen, Formate, die Zahl der eingebundenen Skripte und um eingebettete Dienste, die den Aufbau blockieren. Dauert dagegen schon das erste Byte über eine Sekunde, ist die Ursache auf dem Server, und alle Bildoptimierungen der Welt ändern daran nichts.
Für die Prüfung im laufenden System bringt TYPO3 das Admin Panel als Systemerweiterung mit. Angemeldete Backend-Benutzer sehen damit im Frontend, ob die aufgerufene Seite aus dem Cache kam und wie lange die Erzeugung gedauert hat. Das ist der schnellste Weg, die entscheidende Frage zu beantworten, ohne sich durch Protokolle zu arbeiten.
Die eine Frage, die fast alles entscheidet
TYPO3 speichert erzeugte Seiten zwischen und liefert sie beim nächsten Aufruf aus diesem Zwischenspeicher aus. Der Vergleich zweier aufeinanderfolgender Aufrufe derselben Seite zeigt deshalb sofort, woran man ist: Ist der zweite Aufruf deutlich schneller als der erste, funktioniert das Zwischenspeichern. Sind beide gleich langsam, kommt die Seite bei jedem Aufruf frisch aus der Erzeugung, und genau das ist die Ursache, nach der du suchst.
Der häufigste Auslöser ist eine Einstellung, die einmal gesetzt wurde, um ein anderes Problem zu lösen. Irgendwann war ein Inhalt nicht aktuell, jemand hat das Zwischenspeichern für diese Seite oder gleich für die ganze Website abgeschaltet, das Problem war weg und die Einstellung blieb. Das ist die teuerste Zeile Konfiguration, die eine TYPO3-Installation enthalten kann, und sie steht in überraschend vielen.
Der zweite Auslöser sind einzelne Bausteine, die bei jedem Aufruf neu gerechnet werden sollen, weil sie personalisierte oder ständig wechselnde Inhalte zeigen. Das ist das richtige Mittel dafür, es hat aber einen Preis, den viele unterschätzen. Eine Seite ohne solche Bausteine liefert TYPO3 in einem Zug aus dem Zwischenspeicher aus. Sobald einer darin steckt, muss das System für jeden Aufruf hochfahren, den zwischengespeicherten Teil holen und den dynamischen Teil daneben rendern. Das ist immer noch um ein Vielfaches billiger als ein vollständiger Neuaufbau, aber es ist eben nicht mehr umsonst. Die Faustregel lautet deshalb, den dynamischen Anteil so klein wie möglich zu schneiden, statt eine ganze Seite dafür aus der Zwischenspeicherung zu nehmen.
Was mit TYPO3 nichts zu tun hat, aber so aussieht
Ein erheblicher Teil der gefühlten Langsamkeit entsteht nach der Auslieferung. Ein Bild, das in voller Kameraauflösung im Beitrag liegt und erst im Browser auf Spaltenbreite geschrumpft wird, kostet mehr Zeit als jede Datenbankabfrage der Seite. Dasselbe gilt für eine Handvoll eingebundener Dienste für Statistik, Chat, Karten und Videos, die jeweils eigene Verbindungen aufbauen und eigene Skripte nachladen.
Diese Punkte sind ehrlicherweise keine TYPO3-Themen, aber sie sind die häufigste Ursache für schlechte Werte in Messwerkzeugen. Wer sie angeht, verbessert die Ladezeit deutlicher als mit den meisten serverseitigen Maßnahmen, und die Redaktion kann den größten Teil davon selbst erledigen, indem sie Bilder in vernünftiger Größe hochlädt und eingebettete Inhalte sparsam einsetzt.
Ebenfalls nicht in diese Betrachtung gehören Hosting und Serverkonfiguration. Sie können eine langsame Installation weiter verlangsamen, machen aber eine Installation, die bei jedem Aufruf alles neu berechnet, nicht schnell. Deshalb bleibt die Reihenfolge: erst messen, dann die Cache-Frage klären, dann die Datenmengen, und erst danach über Infrastruktur reden.
Was du bei der Redaktion und bei Erweiterungen mitdenken solltest
Auf großen Websites ist die Frage nicht nur, wie schnell eine Seite gebaut wird, sondern wie oft. Wird der gesamte Zwischenspeicher nach jeder Änderung verworfen, muss jede Seite beim nächsten Aufruf einmal neu entstehen, und bei tausenden Seiten summiert sich das zu einer spürbaren Phase mit erhöhter Last. Deshalb lohnt es sich, mit der Redaktion darüber zu sprechen, welcher Umfang beim Leeren wirklich nötig ist.
Bei Erweiterungen ist der wichtigste Punkt die Frage, was pro Aufruf passiert. Eine Erweiterung, die bei jedem Seitenaufruf eine externe Adresse anfragt, eine Datei schreibt oder eine große Tabelle durchsucht, ist auf einer kleinen Website unauffällig und auf einer besuchten Website ein echtes Problem. Diese Frage gehört in die Auswahl einer Erweiterung, nicht in die Fehlersuche danach.
Und schließlich lohnt der Blick auf die Bildbearbeitung. TYPO3 erzeugt Bildvarianten beim ersten Bedarf und legt sie ab. Werden diese Ableitungen regelmäßig gelöscht, etwa weil ein Aufräumskript zu viel entfernt, erzeugt das System sie immer wieder neu, und der erste Aufruf jeder Seite mit Bildern wird dauerhaft teuer. Das ist eine Ursache, die man nur findet, wenn man weiß, dass es sie gibt.
Dazu passende Kurse
Für die Ursachen, die tiefer in Konfiguration und Rendering liegen, lohnt es sich, TYPO3 im Aufbaukurs vertiefen und die Zusammenhänge einmal geschlossen durchzugehen.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Sehr kompetente und freundliche Trainerin. Die Inhalte wurden gut strukturiert und anhand von anschaulichen Beispielen vermittelt.
Häufige Fragen
Ist TYPO3 grundsätzlich langsamer als andere Systeme?
Ab wann ist eine Antwortzeit zu langsam?
Hilft ein stärkerer Server?
Wie finden wir heraus, welche Erweiterung bremst?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem TYPO3-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Wer versteht, wie TYPO3 rendert, sucht nicht lange
Zwischenspeicherung, TypoScript und die Ausgabe von Erweiterungen hängen eng zusammen, und wer diesen Zusammenhang einmal von innen gesehen hat, findet solche Ursachen in Minuten statt in Tagen.