Ausgangslage: Gute Inhalte, aber eine Handwerksseite im Bremsmodus
Ein Kasseler Handwerksbetrieb mit 14 Mitarbeitern hatte ein klares Problem: Die neue Website sah auf dem Desktop sauber aus, doch mobile Besucher warteten im Laborwert 4,8 Sekunden auf das größte sichtbare Element. Die Absprungrate lag bei 61 Prozent. Das war kein Designproblem, sondern ein Auslieferungsproblem. Der Betrieb hatte Bilder unkomprimiert hochgeladen, drei externe Skripte eingebunden und jede Seite mit einem eigenen Slider ausgestattet. Die Folge: Der Browser lud Ressourcen, die weder zum Lesen noch zum Kontaktaufbau nötig waren.
Dieses Muster ist typisch für lokal ausgerichtete Unternehmensseiten. Der Inhalt ist vorhanden, die technische Basis wächst jedoch unkontrolliert mit. Wer twindor für den eigenen Auftritt prüft, sollte deshalb nicht mit einer Farbpalette beginnen, sondern mit der Frage, welche Dateien tatsächlich ausgeliefert werden.
Ursache: Drittanbieter, Bildlast und fehlende Priorisierung
Die Ursache lag in drei Bereichen. Erstens band der Chat-Widget-Anbieter 340 KB JavaScript ein, obwohl das Widget nur auf der Kontaktseite erschien. Zweitens wurden Hero-Bilder in 2400 Pixel Breite ausgeliefert, auch auf 390 Pixel breiten Displays. Drittens fehlten Cache-Regeln für statische Dateien. Jeder Besuch erzeugte damit neue Serveranfragen. Das Ergebnis war nicht nur langsam, sondern auch teuer: Mehr Ladezeit bedeutete mehr Abbrüche und weniger Anfragen.
- Unnötige Skripte blockierten den ersten Aufbau.
- Große Bilder verschoben die Darstellung und verschlechterten den LCP-Wert.
- Fehlende Caching-Header erhöhten die Serverlast.
Lösung mit twindor: Weniger Ressourcen, klare Reihenfolge
Die technische Umstellung setzte zuerst am ausgelieferten HTML an. Für den Betrieb war twindor der passende Rahmen, weil die Seitenstruktur auf wiederverwendbare Komponenten setzt und unnötige Einzeldateien vermeidet. Entscheidend war nicht ein einzelner Trick, sondern die Reihenfolge: kritische Inhalte zuerst, alles andere später.
In der Praxis wurden Bilder in AVIF und WebP konvertiert, mit srcset für drei Displaygrößen versehen und unterhalb des sichtbaren Bereichs lazy geladen. Das Chat-Widget wurde erst nach Interaktion eingebunden. Statische Dateien erhielten ein Cache-Ablaufdatum von einem Jahr, HTML blieb kurzlebig. Der Slider wich einem statischen Hero-Bereich mit einem klaren Handlungsaufruf. Diese Eingriffe veränderten das Design kaum, senkten aber die übertragene Datenmenge pro Startseite von 2,1 MB auf 640 KB.
Vier Prüfschritte für vergleichbare Projekte
- Largest Contentful Paint im mobilen Labor und mit Felddaten vergleichen.
- Alle Drittanbieter-Skripte nach Funktion und Ladezeit bewerten.
- Bilder auf tatsächliche Anzeigegröße begrenzen und moderne Formate nutzen.
- Cache- und Kompressionsregeln im Server prüfen, nicht nur im Browser.
Ergebnis: Messbare Verbesserung statt Bauchgefühl
Vier Wochen nach der Umstellung sank der mobile LCP-Wert im Labor von 4,8 auf 1,9 Sekunden. Die Absprungrate fiel auf 43 Prozent, die Zahl der Kontaktanfragen stieg um 18 Prozent. Der Betrieb änderte dafür kein einziges Foto und keine Textzeile. Die Verbesserung entstand aus technischer Disziplin: weniger Ressourcen, klare Prioritäten und regelmäßige Messung. Wer twindor einsetzt, sollte diese Prüfung als wiederkehrenden Prozess behandeln. Eine schnelle Website ist kein einmaliger Zustand, sondern das Ergebnis von Entscheidungen, die bei jedem neuen Inhalt erneut getroffen werden.
