Unser TYPO3-Backend rennt wie das Frontend — so haben wir es erreicht
TYPO3 sei langsam, alt, kompliziert? Wir haben unser Backend so optimiert, dass es wie ein modernes Frontend reagiert. Ein Blick auf die konkreten Maßnahmen.
Man begegnet ihm regelmäßig, diesem Vorurteil: TYPO3 sei langsam, schwerfällig, eigentlich ein Relikt. Wer das sagt, hat entweder lange nicht mehr hingeschaut — oder nie ein sauber aufgesetztes TYPO3-Backend erlebt. Wir arbeiten täglich damit und können Ihnen sagen: Unser Backend reagiert nicht langsamer als ein modernes SaaS-Produkt. In vielen Redaktionsalltagssituationen ist es sogar spürbar schneller, weil es genau auf Ihre Inhalte und Ihre Struktur zugeschnitten ist.
Das kam nicht von selbst. Wir haben gezielt in Performance investiert. In diesem Beitrag zeigen wir, an welchen Stellschrauben wir gedreht haben — und warum das Ergebnis für Sie als Kunde mehr ist als ein schönes Gefühl beim Klick.
Warum Backend-Performance kein Luxus ist
Das Frontend einer Website wird heute fast überall optimiert. An das Backend denkt man erst, wenn Redakteure Beschwerden äußern. Das ist kurzsichtig. Jede Sekunde, die Ihr Redaktionsteam auf ein ladendes Backend wartet, multipliziert sich über den Tag, über die Woche, über das Jahr. Ein trägeres Backend heißt weniger Inhalte, unsaubere Pflege und im schlimmsten Fall Frustration, die sich in Kündigungen äußert.
Für uns ist Backend-Performance deshalb ein fester Bestandteil von CMS as a Service. Wenn wir ein System betreiben, soll es nicht nur laufen, sondern arbeiten. Und zwar für die Menschen, die täglich damit Geld verdienen.
Die Stellschrauben, an denen wir gedreht haben
Caching-Strategie auf mehreren Ebenen
Caching ist in TYPO3 kein einzelner Schalter, sondern ein System aus mehreren Schichten. Wir haben unsere Cache-Strategie neu aufgezogen: Der TYPO3-eigene Caching-Framework liegt nicht mehr auf der Platte oder in der Datenbank, sondern in einem zentralen Redis-Cluster. Der Backend-User-Cache, der in vielen Projekten zu still genutzt wird, ist bei uns aktiv konfiguriert und wird bei Deployments kontrolliert geleert. Das merken Sie sofort beim Seitenwechsel im Backend — Aufrufe, die vorher halbe Sekunden dauerten, liegen jetzt im Bereich weniger Millisekunden.
Asset-Pipeline für das Backend
Das TYPO3-Backend ist eine Web-Anwendung. Es profitiert von denselben Techniken wie ein modernes Frontend: gebündelte JavaScript- und CSS-Assets, Brotli-Kompression, effizientes Caching im Browser. Wir haben die Asset-Pipeline angepasst, damit Backend-Assets nicht bei jedem Login erneut geladen werden, sondern langlebig cacheable sind.
PHP-OPcache und JIT richtig konfiguriert
Viele Systeme laufen mit einer OPcache-Standardkonfiguration, die für ein durchschnittliches Projekt gedacht ist. Wir haben OPcache bewusst auf unsere typischen TYPO3-Workloads hin abgestimmt — inklusive ausreichend dimensioniertem opcache.memory_consumption, einem zum Extension-Umfang passenden opcache.max_accelerated_files und aktiviertem JIT, wo er sinnvoll wirkt. Das Ergebnis ist messbar: spürbar niedrigere TTFB-Zeiten im Backend unter Last.
HTTP/2 und HTTP/3 überall
Backend-Kommunikation ist heute nicht mehr ein einzelner Request. Es sind viele parallele Aufrufe für Listings, AJAX-Inhalte, Previews. HTTP/2 und, wo möglich, HTTP/3 verkürzen diese parallelen Verbindungen massiv. Beides gehört in unserer Hosting-Basis zum Standard, nicht zur Option.
Critical CSS und Lazy-Loading im Backend
Auch das Backend hat Templates, die Blöcke und Komponenten enthalten, die selten sofort gebraucht werden. Wir trennen kritische von unkritischen Styles, damit die Erstdarstellung schnell wird, und laden weniger wichtige Bereiche asynchron nach. Das ist kein spektakulärer Trick, in Summe aber ein deutlicher Unterschied.
Datenbank-Tuning
Viele Performance-Probleme im TYPO3-Backend sind am Ende Datenbank-Probleme. Wir prüfen Index-Strategien für projektspezifische Tabellen, optimieren Queries in kritischen Pfaden und setzen gezielt auf einen MariaDB- oder MySQL-Setup, der mit dem Extension-Set Ihres Projekts harmoniert. Wo nötig, arbeiten wir mit Lesereplika, um Last von großen Listings wegzunehmen.
Warum Sie davon mehr haben als schnellere Klicks
Schnelleres Backend bedeutet nicht nur besseres Gefühl. Es bedeutet konkret:
Mehr Output pro Arbeitstag in der Redaktion. Ein spürbar schnelleres Backend sorgt für mehr gepflegte Inhalte, weil niemand aus Frust Bearbeitungen verschiebt.
Kleinere Frustrationskurve bei neuen Redakteuren. Wer einsteigt, vergleicht TYPO3 mit Tools, die er täglich privat nutzt. Die Messlatte ist hoch — ein flüssiges Backend hält mit.
Bessere Voraussetzungen für Integrationen. Wenn Ihr CMS-Backend zeitnah auf Eingaben reagiert, sind externe Redaktionsworkflows, Importe und KI-gestützte Werkzeuge souveräner einsetzbar.
Kein Einmal-Effekt, sondern Arbeitsstandard
Wichtig ist uns: Diese Optimierungen sind bei uns nicht das Ergebnis eines einmaligen Tuning-Projekts. Sie sind Teil unseres Standards. Jedes neue TYPO3-Projekt startet mit diesen Voraussetzungen. Bestandssysteme, die wir übernehmen, bringen wir Schritt für Schritt auf dasselbe Niveau — sichtbar in Lighthouse-Messungen, im Monitoring und vor allem im Tagesgefühl Ihres Teams.
Ein Angebot
Wenn Ihr Redaktionsteam heute Ihr TYPO3-Backend nicht als Werkzeug, sondern als Bremsklotz erlebt, lohnt sich ein kurzer Austausch. Wir nehmen uns 30 Minuten und sagen Ihnen, wo in Ihrem Setup die größten Hebel stecken. Kein Pitch, keine abstrakten Empfehlungen — konkrete Einschätzung.
Häufige Fragen
Was uns Kundinnen und Kunden zu diesem Thema am häufigsten fragen — offen beantwortet.
What does this performance work cost us?+
For new projects this is part of our standard and not invoiced separately. For existing systems we classify the levers in a short analysis by effort and impact and build a manageable budget from that. No black-box tuning — every measure is traceable.
Doesn't something break with all that caching?+
Caching is only stable if invalidation is right. We use cache tags consistently and check invalidation on every deployment. The backend therefore never sees stale content — it just sees the current content faster.
How much effort is it to retrofit an existing system?+
It depends on the starting point. The caching and hosting layer can usually be brought up to our level within a few weeks. Database and extension optimisation happens iteratively, prioritised by your editorial team's biggest pain points.
Does this even bring anything for a small team?+
Especially for small teams: if an editor waits 20 fewer minutes a day for load times, that adds up to several working weeks over a year. Performance has impact regardless of team size.
How do you actually measure backend performance?+
We don't measure only synthetically; we use real-user monitoring out of the backend. Relevant metrics are TTFB, time to interactive and the actual click-to-click time of typical editorial workflows — not abstract Lighthouse scores.