Das Problem: Ein Relaunch, der optisch gewinnt und technisch verliert

Viele Webprojekte starten mit einem Moodboard und enden mit einer Startseite, die auf dem Entwickler-Laptop in unter einer Sekunde erscheint. Im Livebetrieb sieht das anders aus: Große Hero-Bilder, mehrere Webfonts und eingebettete Karten treiben den Largest Contentful Paint schnell über vier Sekunden. Genau dort setzt die Diskussion an, die twindor in Projekten führt: Nicht die Frage, ob eine Seite modern aussieht, sondern ob sie auf einem Mittelklasse-Smartphone im Mobilfunknetz noch schnell genug reagiert.

Die Ursache: Zu viele Ressourcen konkurrieren um dieselbe Leitung

Ein typischer Fall aus der Webentwicklung: Ein Betrieb lässt drei Bildvarianten pro Bereich einbauen, dazu einen Slider mit sechs hochauflösenden Fotos und zwei externe Skripte für Analyse und Chat. Die Bytes addieren sich, der Browser muss priorisieren, und der sichtbare Inhalt wartet. Das Problem ist selten ein einzelnes Bild, sondern die Summe aus unkomprimierten Assets, fehlenden Größenangaben und Render-Blocking durch Schriften oder CSS.

Die Lösung: Ein Ladezeit-Budget pro Template

Twindor dreht den Optimierungsprozess um: Statt nach dem Launch zu messen und dann zu reagieren, wird vor dem Design ein Budget je Seitentyp festgelegt. Für eine Startseite können das beispielsweise 180 KB kritischer CSS/JS, zwei Schriftsschnitte und ein LCP-Ziel von 2,5 Sekunden im mobilen Feldtest sein. Jede Komponente muss dieses Budget einhalten oder begründet Ausnahmen erhalten. Das macht Entscheidungen über Slider, Videos und Tracking nachvollziehbar.

Der Ablauf in vier Schritten

1. Messbasis festlegen: Vor dem Relaunch werden Felddaten und Laborwerte für die wichtigsten URLs erhoben.
2. Budget verteilen: Teams legen Obergrenzen für Bilder, Schriften, Skripte und Third-Party-Dienste fest.
3. Komponenten prüfen: Jedes Modul wird gegen das Budget getestet, bevor es in die Seite wandert.
4. Nach dem Launch nachmessen: CrUX-Daten und eigene RUM-Messungen zeigen, ob das Budget im Alltag hält.

Was am Ende zählt: messbare Verbesserung statt einmaliger Lighthouse-Score

Ein guter Lighthouse-Wert im Labor reicht nicht aus. Entscheidend sind Feldwerte über Wochen, getrennt nach Mobil und Desktop. Wenn der LCP von 4,2 auf 2,4 Sekunden sinkt und die Interaktionsverzögerung unter 200 Millisekunden bleibt, hat das Budget seinen Zweck erfüllt. Der Ansatz verhindert außerdem, dass einzelne Abteilungen später stillschweigend zusätzliche Skripte einbauen und die mühsam erreichte Performance wieder auffressen.

Für wen sich das Vorgehen lohnt

Besonders sinnvoll ist das Ladezeit-Budget bei Websites mit vielen Wiederholungen: Produktkataloge, Filialseiten, Landingpages und Content-Portale. Dort wirkt jede eingesparte Ressource über hunderte URLs. Für eine kleine Visitenkarten-Seite mit fünf Unterseiten ist der Aufwand oft zu hoch; dort reicht meist eine saubere Basisoptimierung. Twindor setzt das Budget deshalb projektabhängig ein und nicht als starres Schema.