Staffbase

Das Hauptproblem war ein Mangel an Konsistenz und ständige Instabilität. Jede WordPress-Instanz hatte ihr eigenes Theme, ein eigenes Set an Plugins und sich überschneidende Anpassungen. Das führte oft dazu, dass sich Plugins nach Updates gegenseitig störten und die gesamte Website viel zu langsam lief. Das gleiche Element konnte je nach Bereich der Website unterschiedlich aussehen. Die Redakteure kämpften entweder mit Page-Buildern oder baten bei jeder neuen Unterseite einen Entwickler um Hilfe.

Es ging also nicht nur um einen frischen Look. Wir haben bestehende Seiten in wiederverwendbare Blöcke zerlegt und jeden nur einmal definiert: welche Felder er hat, welche davon Pflichtfelder sind und wie er auf dem Smartphone aussieht. Heute gibt es fast sechzig dieser Blöcke. Die Redakteure nutzen Storyblok und setzen sie nach Bedarf zusammen — mit der Sicherheit, dass der Code darunter sauber, stabil und schnell bleibt.

Weil die Pflege einer einzigen Anwendung viel einfacher ist als die Verwaltung von zwei separaten Projekten. Ein separates Frontend bedeutet eine zweite Infrastruktur, eine zweite Deployment-Pipeline und ein zweites Projekt, das betreut werden muss. Eine Unternehmenswebsite soll vor allem schnell, gut bei Google sichtbar und leicht zu bearbeiten sein — dafür war eine Architektur aus zwei Anwendungen schlichtweg nicht notwendig.

Storyblok liefert die Inhalte, während Symfony daraus vollständiges HTML direkt auf dem Server rendert. Browser und Google-Bots erhalten sofort eine komplette Seite. Nebenbei haben wir das Storyblok Symfony Bundle sowie den PHP-API-Client erweitert und diese Verbesserungen der Open-Source-Community zur Verfügung gestellt.

Für die Interaktivität sorgt Symfony UX. Jeder Block ist ein Twig-Component mit eigener Klasse und Template, sodass Änderungen an einer zentralen Stelle erfolgen. Die Suche, Event-Filter und das Nachladen von Blogbeiträgen haben wir mit Live Components umgesetzt: Die Komponente wird auf dem Server berechnet, und im Browser wird nahtlos nur der geänderte HTML-Ausschnitt ausgetauscht. Kleine Interaktionen wie Karussells oder Tabs werden von sehr leichten Stimulus-Controllern gesteuert. Der Nutzer bekommt eine flüssige Website, ohne dass wir ein zweites Frontend bauen mussten.

Weil dadurch jedes Interface-Element genau das tut, was die Website erfordert — und kein bisschen mehr. Fertige Bibliotheken oder npm-Pakete bringen eine Menge unnötiger Funktionen und Stylings mit, die niemand nutzt, die der Browser aber trotzdem herunterladen, parsen und ausführen muss. Unsere Komponenten sind leicht und schnell.

Der zweite Grund ist die volle Kontrolle über die Barrierefreiheit (a11y). Jedes Element wurde von der ersten Zeile an mit Blick auf Tastaturbedienung und Screenreader-Unterstützung entwickelt. Wir mussten keinen fremden Code überschreiben oder „reparieren“, um Standards zu erfüllen. Und da die Redaktion Seiten ausschließlich aus diesen vorbereiteten Bausteinen zusammensetzt, ist jede neue Unterseite automatisch barrierefrei und performant.

Farben, Abstände, Typografie und Breakpoints wurden einmal in der Tailwind-Konfiguration definiert, und alle Komponenten greifen ausschließlich auf diese Werte zu. Wenn jemand im Code einen abweichenden Abstand verwendet, fällt das beim Code-Review sofort auf.

Hinzu kommt die Skalierung: Über dreißig Blöcke existieren in fünf Farbvarianten und mehreren Layout-Optionen. Deshalb haben wir einen Styleguide erstellt — eine interne Seite, die jede Komponente in allen möglichen Konfigurationen zeigt. Jeder neue Block wird zuerst dort geprüft, bevor er im Editor für die Redaktion landet.

Mehrschichtig — denn jeder Fehler hat seinen Ort, an dem er am günstigsten zu beheben ist.

Die erste Schicht ist der Block selbst. Jeder Component hat im Code einen Vertrag mit Storyblok: welche Felder erforderlich sind, wie viele Elemente er enthalten darf und welche Themes erlaubt sind. Entspricht der Inhalt nicht diesem Vertrag, erscheint eine Fehlermeldung in der Vorschau, bevor jemand auf „Publish“ klickt. Automatisierte Unit-Tests und Integrationstests für Templates stellen dies sicher, zusammen mit einem vollständigen Set an CI/CD-Checks bei jedem Pull Request: statische Analyse, Linter für Twig und JavaScript und sogar eine Rechtschreibprüfung.

Die zweite Schicht sind die Menschen. Jede Komponente entsteht zuerst im Styleguide, wo wir sie in allen Themes und Varianten, mit den längsten echten Inhalten und auf echten Smartphones testen — unter Berücksichtigung von Besonderheiten wie japanischen Schriftarten oder langen deutschen Überschriften. Danach gelangt sie in eine eigene Vorschau-Umgebung, also eine vollständige Kopie der Website. Dort bewertet das Design das visuelle Ergebnis, während das Redaktionsteam von Staffbase eine echte Seite daraus baut. Wenn ein Redakteur eine Landingpage aus einem neuen Block zusammenstellt und keine Überraschungen erlebt, weiß ich, dass die Komponente bereit ist.

Neue Inhalte entstehen zu den unterschiedlichsten Zeiten, oft wenn kein Entwickler online ist. Als Storyblok-Agentur wussten wir, dass es entscheidend ist, einen sicheren Bearbeitungsprozess zu schaffen, ohne das Risiko, dass unfertige Inhalte auf der Live-Seite landen.

In Storyblok sind Entwürfe (Draft) von veröffentlichten Inhalten (Published) getrennt, was perfekt mit dem integrierten Freigabesystem (Workflow) zusammenspielt. Ein Redakteur baut eine neue Unterseite aus fertigen Blöcken im visuellen Editor auf und hat eine sofortige Echtzeit-Vorschau. Änderungen können von anderen Teammitgliedern überprüft oder für eine automatische Veröffentlichung zu einer bestimmten Uhrzeit geplant werden.

Erst im Moment der Veröffentlichung wird der Cache gezielt erneuert — nur für die betroffenen Seiten und Sprachversionen innerhalb von Sekunden. Für globale Events und Webinare speichern wir die Zeiten wiederum in einer zentralen Zeitzone, und der Browser des Besuchers rechnet sie automatisch in seine lokale Zeit um.

Nach Daten des Chrome User Experience Reports sank der LCP von 4217 auf 1961 Millisekunden und der CLS von 0,31 auf fast null (0,01). Dahinter steckt kein einzelner Trick, sondern die Summe vieler gezielter Entscheidungen.

Eine große Rolle spielt das Caching. Varnish liefert die meisten Seiten direkt aus dem Arbeitsspeicher, sodass der Browser sofort vollständiges HTML erhält. Der zweite Punkt ist ein leichtes Frontend. Alle Bilder laufen durch eine zentrale Komponente, die Format und Größe optimal für den Bildschirm auswählt und vorab Platz im Layout reserviert, damit der Text nicht springt. Standardmäßig werden Bilder erst beim Scrollen geladen — mit einer bewussten Ausnahme: Das Hero-Bild, also das Erste, was der Nutzer sieht, lädt sofort. Das ist entscheidend für den LCP. Da dies fest in der Komponente verankert ist, kann es bei neuen Sektionen niemand vergessen.

Gleiches Prinzip gilt überall: Wir laden nur das, was nötig ist, und erst dann, wenn es gebraucht wird. Videos spielen nur ab, wenn sie auf dem Bildschirm sichtbar sind. HubSpot-Formularskripte werden ausschließlich auf Seiten geladen, die ein Formular enthalten. Google Tag Manager, Cookie-Banner und Analyse-Tools laden in einer festgelegten Reihenfolge und erst nach Einwilligung des Nutzers. Das ist sowohl für die Performance als auch für die DSGVO-Konformität wichtig.

Vom Start bis zum Go-Live vergingen sechs Monate.

Vom ersten Tag an haben wir wie ein integriertes Team gearbeitet, auf der Basis von klarer Kommunikation und schnellem Feedback. Das Daily diente uns hauptsächlich dazu, laufend Blocker zu beseitigen und sicherzustellen, dass wir in die richtige Richtung gehen. Der Rest der Arbeit lief ganz natürlich ab: über laufende Abstimmungen an den Tickets, Pair Programming und gründliche Code-Reviews.

Jede Code-Änderung erzeugte automatisch eine eigene, isolierte Vorschau-Version der Website. Dadurch konnten Design und Redaktion von Staffbase neue Funktionen live testen, bevor sie in Produktion gingen — ohne auf offizielle Demo-Meetings warten zu müssen.

Uns war wichtig, dass das interne Team von Staffbase die Plattform nach dem Launch problemlos weiterentwickeln kann. Wir haben auf einfache und wiederholbare Standards gesetzt: Wenn jede Komponente nach demselben Muster gebaut ist, ist das Hinzufügen des nächsten Blocks für jeden Entwickler intuitiv.

Bevor ich das erste Template schreibe, würde ich eine vollständige Spezifikation aller Komponenten erstellen. Zu Beginn haben wir Blöcke in der Reihenfolge gebaut, wie sie auf den Wireframes benötigt wurden, und den Code erst später vereinheitlicht. Hätten wir gemeinsame Elemente — wie Abstände, Buttons oder Karten-Varianten — von Anfang an festgelegt, hätten wir uns einige Anpassungen gespart.

Der zweite Punkt ist die frühzeitige Planung von Analytics und Datenschutz-Einwilligungen. Cookie-Banner, Tag Manager und Analyse-Tools beeinflussen die Ladezeit und das, was der Nutzer zuerst sieht. Bei uns kamen sie schrittweise im Laufe der Entwicklung hinzu — beim nächsten Mal würde ich sie ab dem ersten Sprint ins Backlog aufnehmen.