Aus dem Relaunch
Was wir beim Relaunch unserer Website gelernt haben.
Seit Kurzem veröffentlichen wir hier ein- bis zweimal im Monat einen Fachartikel. Es schreibt die Crew, jeweils die Person, die ein Thema in unseren Projekten verantwortet, von TYPO3 über Kundenportale bis zum Betrieb. Den Anfang hat Annalena mit den Werkzeugen im Vertrieb gemacht. Im zweiten Artikel geht es um das Projekt, bei dem ich am wenigsten schönreden kann: unsere eigene Website. Seit September 2026 liefert TYPO3 dort nur noch die Inhalte, und eine Angular-Anwendung setzt daraus die Seite zusammen.
Die Antwort vorweg
Headless-TYPO3 mit Angular lohnt sich, wenn deine Website mehr können soll als Seiten zeigen, etwa Anmeldung, Filter oder Rechner, und die Redaktion trotzdem in TYPO3 arbeiten will. Für eine Website, die vor allem Texte und Bilder zeigt, ist ein klassisches TYPO3 der kürzere Weg, und das sage ich als jemand, der gerade den längeren gegangen ist.
Wir sind ihn mit Absicht gegangen. Unsere Website sollte zeigen, wie wir große TYPO3-Auftritte heute aufsetzen, und sie sollte sich so anfühlen wie unser Portal, das ebenfalls in Angular entwickelt ist.
Was an dieser Kombination hakt, hakt deshalb zuerst bei uns. Ein paar dieser Stellen erzähle ich hier, weil man aus ihnen mehr lernt als aus jedem Architekturbild.
Was headless bei uns heißt
In einem klassischen TYPO3 erzeugt TYPO3 die fertige HTML-Seite selbst, mit eigenen Vorlagen für Layout und Darstellung. Bei uns liefert TYPO3 jede Seite nur noch als Daten, also als geordnete Liste aus Überschriften, Texten, Bildern und Knöpfen im Format JSON.
Davor sitzt eine Angular-Anwendung, die diese Daten abholt und daraus die Seite zusammensetzt. Du kannst das selbst nachsehen: Setzt du in eine Adresse unserer Website hinter den Domainnamen ein /api, bekommst du dieselbe Seite als Daten.
Für die Redaktion ändert das wenig. Wer einen Text ändert, arbeitet im TYPO3-Backend, also in der gewohnten Redaktionsoberfläche, mit Inhaltsbausteinen aus Content Blocks, die feste Felder haben.
Wenig heißt allerdings nicht nichts. Ein Bild, das aus einer bereits verkleinerten Fassung neu hochgeladen wird, landet als Kachel von 100 mal 100 Pixeln auf der Seite.
Auf einem großen Schirm sieht das aus wie ein Mosaik. Seitdem verknüpfen wir vorhandene Bilder mit ihrer Originaldatei, statt sie neu hochzuladen.
Die festen Felder haben einen Nebeneffekt, den ich anfangs unterschätzt habe: Was eine feste Form hat, lässt sich messen. Bei uns prüft ein Skript jede Seite gegen unsere Redaktionsregeln, von der Satzlänge bis zum Gewicht der Bilder.
Die Seite, die für Suchmaschinen leer war
Eine Angular-Anwendung setzt die Seite normalerweise erst im Browser zusammen. Ein Mensch merkt davon nichts, viele Sammler von Suchmaschinen und Antwortdiensten führen aber kein JavaScript aus und sehen nur ein leeres Gerüst.
Bis zum Livegang half uns dafür eine schlanke Ersatzseite mit dem Text jeder Seite, die vor allem für Sammler gedacht war. Seit Ende September 2026 rendert ein eigener Dienst jede Seite auf dem Server vor, das nennt sich Server-Side Rendering, und die Ersatzseite ist nur noch der Notnagel.
Der Browser bekommt damit eine fertige Seite und muss sie nur noch bedienbar machen, also Klicks und Übergänge anschließen. Diesen Schritt nennt Angular Hydration, und er kommt weiter unten noch einmal vor.
Drei Untiefen beim Livegang
Der Livegang des Server-Renderings war der Teil des Relaunchs, bei dem ich am meisten gelernt habe, meistens gegen meinen Willen. Drei Funde aus den ersten Tagen zeigen gut, wo eine Headless-Architektur anders scheitert als ein klassisches TYPO3.
Erstens kam nach dem Umschalten trotzdem jede Seite als Browser-Fassung heraus. Traefik, der Eingangsrouter vor unseren Diensten, setzt drei Kopfzeilen mit der ursprünglichen Adresse der Anfrage.
Angular lehnt solche Kopfzeilen ab, solange man ihnen nicht ausdrücklich vertraut, und rendert dann still im Browser, ohne Fehlermeldung. Unsere Gesundheitsprüfung meldete die ganze Zeit Grün, weil sie ihre eigenen, harmlosen Kopfzeilen mitschickte.
Seitdem prüft sie mit den Kopfzeilen der echten Anfrage, und jede Antwort trägt einen Vermerk, ob die Seite auf dem Server oder im Browser entstand. Eine Prüfung, die Grün meldet, während nichts funktioniert, ist schlimmer als gar keine.
Zweitens zeigten die vorgerenderten Seiten keine Bilder. Der Render-Dienst fragt TYPO3 im internen Netz ab, und TYPO3 setzt Bildadressen aus dem Namen zusammen, unter dem es gefragt wurde.
So stand in jeder Seite eine interne Adresse, die der Browser dank unserer Sicherheitsregeln zu Recht sperrte. Heute schreibt der Dienst solche Adressen auf die öffentliche Domain um, bevor er die Seite ausliefert.
Drittens, und das war der gemeinste Fund, landete die interne Adresse auch im Zwischenspeicher für die Seitendaten. Wer im Browser zur Startseite zurückwechselte, bekam die Fassung, die der Render-Dienst dort abgelegt hatte, samt gesperrter Bilder.
Beim ersten Aufruf trat der Fehler nie auf, nur beim Wechsel innerhalb der Website. Seitdem gehört der Hostname zum Schlüssel des Speichers, und jede Anfrage bekommt ihre eigene Fassung.
Wie wir auf 100 Punkte kamen
PageSpeed Insights von Google misst, wie schnell eine Seite auf einem gedrosselten Handy und an einem Desktop-Rechner steht, und vergibt bis zu 100 Punkte. Unsere Website erreicht dort heute mobil wie am Desktop die 100, mit einzelnen Läufen bei 99.
Hingekommen sind wir über eine Reihe eher unspektakulärer Schritte:
- Formular und Terminplaner laden erst, wenn eine Seite sie braucht. Der Code für den ersten Aufruf schrumpfte damit von 712 auf 590 KB.
- Jedes Bild geht als WebP hinaus und trägt Breite und Höhe, damit beim Laden nichts verrutscht.
- Die Bausteine einer Seite werden erst bedienbar, wenn sie ins Bild scrollen; Angular nennt das inkrementelle Hydration. Die Zeit, in der das Handy blockiert, fiel live von 210 auf 60 Millisekunden.
- Der Seitencache von TYPO3 arbeitet wieder.
Der letzte Punkt war mein Fund der Woche vor dem Livegang. Der Cache hatte null Einträge, weil unsere Schnittstelle jede Anfrage beantwortete, bevor TYPO3 an die Stelle kam, an der es speichert.
Jede Seite entstand bei jedem Aufruf neu, je nach Seite in 0,39 bis 1,23 Sekunden. Jetzt speichern wir das Ergebnis und reichen jeden am Speicher vorbei, der mehr sieht als die Öffentlichkeit, etwa eine Redakteurin in der Vorschau eines Entwurfs.
Und dann war da das Wasserlicht. Oben auf unseren Seiten schimmert ein bewegtes Licht, das die Grafikkarte berechnet, doch die Desktop-Messung von PageSpeed läuft ohne Grafikkarte.
Also rechnete der Prozessor das Licht in Software nach. Das Ergebnis waren 78 Punkte und fast 15 Sekunden Arbeit im Hauptthread, für einen Effekt, den auf diesem Rechner nie ein Mensch sieht.
Seitdem prüft die Seite vorher, ob eine echte Grafikkarte da ist, und lässt das Wasser sonst still.
Was wir wieder so machen würden, und was nicht
Ich würde unsere Website wieder headless aufsetzen. Die Trennung zwingt zu festen Inhaltsbausteinen, und die sind der Grund, warum wir Texte, Bilder und Tempo heute messen statt schätzen.
Für die meisten Unternehmenswebsites würde ich es trotzdem nicht empfehlen. Keiner der Fehler oben kann in einem klassischen TYPO3 passieren, weil es dort weder einen Render-Dienst noch einen zweiten Zwischenspeicher gibt.
Den Render-Dienst betreiben wir auf Servern bei Hetzner in Deutschland, die wir selbst betreuen, neben TYPO3 und der Angular-Anwendung. Das ist ein weiterer Dienst, der überwacht, aktualisiert und bei jedem Speichern der Redaktion geleert werden will.
Headless lohnt sich, wenn die Oberfläche selbst ein Teil deines Angebots ist, etwa ein Kundenportal mit Anmeldung oder eine Website mit eigener Bedienlogik. Dann arbeitet die Redaktion im gewohnten TYPO3, und die Oberfläche kann alles, was Angular kann.
Signal senden
Fragen zum Relaunch? Sprich direkt mit Tim.
Headless TYPO3 Angular Betrieb
Tim Rücker
Nächster Schritt
Headless oder klassisch, was passt zu deinem Vorhaben?
Wie wir TYPO3 für Kunden aufsetzen, beschreibt die TYPO3-Agentur, und wann wir Angular einsetzen, die Angular-Entwicklung. Unsere Website selbst zeigt die Referenz zur bytediver-Website mit Screens.