Ausgangslage: 4,8 Sekunden LCP auf dem Smartphone
Für die mobile Startseite eines Kasseler Dachdeckerbetriebs war die Ausgangslage eindeutig: Google PageSpeed Insights meldete 4,8 Sekunden Largest Contentful Paint, der Absprung auf Mobilgeräten lag laut Analyse bei 61 Prozent. Der Betrieb hatte keine eigene IT-Abteilung; die Website war über Jahre gewachsen und sollte nun ohne komplettes Redesign schneller werden. Genau an dieser Stelle setzte das Projekt twindor an: nicht als neues CMS, sondern als technische Überarbeitung der bestehenden Seite. Die Vorgabe war eng: Der sichtbare Inhalt musste unter zwei Sekunden erscheinen, die bestehenden Formulare und Texte sollten unverändert bleiben.
Ursache: Drei blockierende Ressourcen
Die Messung zeigte drei Hauptbremsen. Erstens lud der Header ein 1,8 MB großes PNG-Logo in Originalgröße, obwohl es mobil nur 96 Pixel breit dargestellt wurde. Zweitens band ein veraltetes Plugin jQuery und zwei Slider-Skripte im Kopf der Seite ein, bevor überhaupt Text sichtbar war. Drittens fehlten Cache-Header für Bilder und Schriften, sodass Wiederbesucher dieselben Dateien erneut herunterluden. Die Ursache war also nicht fehlender Content, sondern eine Rendering-Kette, die den ersten sichtbaren Inhalt verzögerte.
Hinzu kam ein Server, der jede Bildanfrage ohne Komprimierung auslieferte. Die HTML-Antwort selbst war mit 38 KB unauffällig; das Problem lag fast vollständig auf der Client-Seite. Eine Analyse mit deaktiviertem Cache zeigte, dass 62 Prozent der Ladezeit auf Bilder und Skripte entfielen.
Lösung: twindor als technische Überarbeitung
Im Zentrum der twindor-Umsetzung standen vier Eingriffe. Das Logo wurde als SVG mit festen Abmessungen eingebunden, alle Fotos zusätzlich in AVIF und WebP konvertiert und per srcset in den Breiten 480, 960 und 1440 Pixel ausgeliefert. Kritisches CSS für den sichtbaren Bereich kam inline in den Kopf; der Rest wurde asynchron nachgeladen. Die Slider-Skripte ersetzte ein natives CSS-Scroll-Snap-Modul, und die Seite erhielt Cache-Regeln mit einjähriger Laufzeit für statische Assets. Wichtig war die Reihenfolge: erst messen, dann die größten Bytes entfernen, danach Rendering-Pfade kürzen.
Die Umstellung erfolgte auf dem bestehenden TYPO3-System, ohne URL-Änderungen. Für die Bilder wurde ein Build-Schritt ergänzt, der bei jedem Upload automatisch AVIF- und WebP-Varianten erzeugt. So blieb die Redaktion unverändert, während die Auslieferung technisch sauber wurde.
Messung nach dem Umbau
Nach dem Umbau lag der Largest Contentful Paint mobil bei 1,6 Sekunden, der Total Blocking Time sank von 780 auf 90 Millisekunden. Die Seitengröße fiel von 3,4 MB auf 720 KB. Entscheidend war nicht ein einzelner Trick, sondern die Kombination aus kleineren Bildern, weniger JavaScript und einem sauberen Cache. Der Dachdeckerbetrieb behielt dabei seine bestehenden Inhalte und Formulare; die sichtbare Gestaltung blieb nahezu unverändert. Lediglich die Logo-Datei und die Bildformate waren technisch anders aufgebaut.
Ergebnis: Weniger Technik, mehr messbare Wirkung
Vier Wochen nach dem Livegang stieg die mobile Conversion-Rate bei Anfragen von 2,1 auf 3,4 Prozent; die Absprungrate fiel auf 39 Prozent. Für vergleichbare Projekte lässt sich daraus eine Regel ableiten: Zuerst die drei größten Ressourcen identifizieren, dann Rendering-Blocker entfernen und erst danach über neue Features sprechen. twindor zeigt in diesem Fall, dass eine Kasseler Handwerksseite ohne komplettes Redesign deutlich schneller werden kann, wenn die technische Basis stimmt.
Die Übertragbarkeit hängt an zwei Voraussetzungen: Die Seite muss serverseitig erreichbar bleiben, und die Redaktion darf keine ungeprüften Riesenbilder hochladen. Beides lässt sich mit einer kurzen Upload-Prüfung und einem monatlichen PageSpeed-Check absichern. Der Aufwand für den Umbau lag bei etwa drei Personentagen; die laufende Pflege beschränkt sich auf die Prüfung neuer Bildformate.
