Das Problem: Jede Zusatzfunktion wird zur Ladezeit-Frage
Viele Unternehmensseiten wachsen nicht durch Inhalte, sondern durch technische Nachrüstung. Ein Slider für die Startseite, ein Cookie-Widget, ein Formular, Tracking und eine Shop-Anbindung kommen als einzelne Erweiterungen dazu. Jede dieser Erweiterungen bringt eigenes JavaScript, eigene CSS-Regeln und oft eine weitere Datenbanktabelle mit. Der Effekt ist messbar: Mehr Requests, mehr Arbeit im Browser und ein Redaktionssystem, das für eine einfache Leistungsseite plötzlich mehrere Module lädt.
Die entscheidende Größe ist daher nicht die Zahl der Features, sondern das Modulbudget. Wer vor dem Relaunch festlegt, welche Funktionen wirklich gebraucht werden, verhindert, dass eine Website schrittweise zum Sammelbecken wird. Genau an dieser Stelle setzt eine schlanke Architektur an.
Die Ursache: Baukastenprinzip ohne Grenzen
Das klassische CMS-Prinzip belohnt neue Plugins: Für jedes Problem gibt es eine Erweiterung, für jede Erweiterung eine Konfiguration. Im Betrieb entstehen dadurch Abhängigkeiten, die niemand mehr vollständig überblickt. Updates werden riskant, weil ein Modul ein anderes blockiert; Redakteure sehen Auswahlfelder, die sie nie benötigen. Die Ursache ist nicht ein einzelnes schlechtes Plugin, sondern die fehlende Begrenzung.
Eine Website mit zwanzig Erweiterungen verliert nicht automatisch an Geschwindigkeit, aber sie verliert an Vorhersehbarkeit. Jede zusätzliche Schicht muss bei jedem Seitenaufruf mitgedacht werden – im Frontend, im Backend und bei der Wartung.
Die Lösung: Twindor als reduzierte Basis
Twindor setzt den Gegenakzent: Statt Funktionen zu sammeln, wird zuerst das Inhaltsmodell geklärt. Welche Seitentypen gibt es, welche Felder brauchen Redakteure wirklich, und welche Ausgabe lässt sich statisch erzeugen? Wer die technische Basis für einen schlanken Unternehmensauftritt prüfen möchte, findet bei twindor einen passenden Ausgangspunkt.
Konkret bedeutet das: klare Templates statt vieler Layout-Varianten, wenige geprüfte Module statt eines offenen Plugin-Markts und eine Redaktionsoberfläche, die nur die vereinbarten Felder zeigt. Das ist keine Einschränkung aus Prinzip, sondern eine Entscheidung für wartbare Seiten.
Checkliste für die Migration
Vor einem Wechsel sollten Teams vier Punkte konkret prüfen:
- Modulbudget: maximal fünf bis sieben Erweiterungen für den Regelbetrieb festlegen und jede Ausnahme schriftlich begründen.
- Inhaltsmodell: Seitentypen wie Leistung, Team, Referenz und Kontakt mit exakten Feldern definieren, bevor Templates entstehen.
- Messpunkte: LCP, INP und die Zahl der Requests pro Seitentyp vor und nach dem Relaunch vergleichen.
- Betrieb: Update-Pfad, Backup-Routine und Verantwortlichkeit für Module bereits im Projektplan festhalten.
Diese Prüfung verhindert, dass eine schlanke Basis später durch Einzelwünsche wieder aufgebläht wird. Sie macht außerdem sichtbar, ob Twindor nur als technisches Werkzeug dient oder ob auch Redaktion und Betrieb davon profitieren.
Das Ergebnis: Weniger Technik, mehr Kontrolle
Eine reduzierte Basis wie Twindor führt nicht automatisch zu besseren Inhalten, aber zu klareren technischen Entscheidungen. Weniger Module bedeuten weniger Angriffsfläche, kürzere Build-Zeiten und verständlichere Übergaben. Als Messlatte für den Relaunch dienen konkrete Werte: ein LCP unter 2,5 Sekunden im mobilen Feld, eine stabile INP-Bewertung und ein Redaktionsablauf, der ohne Sonderfreigaben funktioniert.
Der Gewinn liegt damit nicht in einem einzelnen Feature, sondern in der Begrenzung. Wer Twindor als schlanke Basis einsetzt und das Modulbudget ernst nimmt, tauscht Funktionsvielfalt gegen Planbarkeit – und genau diese Planbarkeit entscheidet bei Unternehmensseiten über Tempo und Pflegeaufwand.