Schnelle und anpassbare Website-Designs

Schnell, wartbar, bedienbar – drei Seiten derselben Entscheidung

Diese drei Eigenschaften werden meist getrennt behandelt und hängen doch an denselben Entscheidungen. Eine Seite, die wenig lädt, ist schnell. Eine Seite, die wenig Fremdcode enthält, ist wartbar. Eine Seite, die semantisch aufgebaut ist, ist bedienbar – mit Maus, Tastatur und Screenreader gleichermaßen.

Umgekehrt gilt dasselbe: Wer ein Design über zwölf Plugins zusammensteckt, bekommt alle drei Probleme auf einmal.

Was eine Seite tatsächlich schnell macht

Die Reihenfolge der Hebel, nach tatsächlicher Wirkung:

1. Bilder. Der mit Abstand größte Posten. Ein unkomprimiertes Foto wiegt mehr als der gesamte übrige Seitencode. Richtig dimensionieren, modern komprimieren, width und height setzen, alles unterhalb des ersten Bildschirms mit loading="lazy".
2. Fremde Hosts. Jede Verbindung zu einer weiteren Domain kostet Zeit für DNS, Verbindungsaufbau und Verschlüsselung – bevor ein einziges Byte Inhalt fließt. Schriften, Icons und Skripte lokal auszuliefern ist zugleich ein Geschwindigkeits- und ein Datenschutzargument.
3. Schriften. Eigene Schriftdateien sind der häufigste Grund für spät erscheinenden Text. Der Systemschriftstapel kostet null Bytes und sieht auf jedem Gerät vertraut aus – diese Website nutzt ihn.
4. JavaScript. Nicht die Dateigröße ist das Problem, sondern die Ausführungszeit auf schwachen Geräten.
5. Serverantwort. Erst danach lohnt sich die Optimierung, und meist ist sie eine Frage des Hostings.

Layoutsprünge sind der unterschätzte Teil: Wenn nachgeladene Bilder oder Schriften den Text verschieben, verliert man Leser, die gerade klicken wollten. Feste Seitenverhältnisse für Bildflächen lösen das.

Woran man ein wartbares Design erkennt

Die Prüffrage: Kann jemand, der das Projekt nicht gebaut hat, in einem Jahr eine Farbe ändern, ohne etwas kaputt zu machen?

• Gestaltungswerte an einer Stelle. Farben, Abstände, Schriftgrößen als benannte Variablen, nicht als Zahl an 200 Stellen.
• Eine Quelle je Bauteil. Header und Footer gehören genau einmal in den Code. Sobald sie kopiert vorliegen, laufen sie auseinander – das ist keine Frage des Ob, sondern des Wann.
• Wenig Abhängigkeiten. Jede eingebundene Bibliothek ist ein künftiges Update und ein mögliches Sicherheitsproblem.
• Lesbare Klassennamen. Wer nach einem Jahr raten muss, was eine Klasse tut, ändert lieber nichts – und die Seite veraltet.

cheeseburger.ch ist ein Beispiel für ein Design mit ausgeprägter Handschrift, das trotzdem aus wenigen wiederkehrenden Bausteinen besteht: sehr große Titeltypografie, dunkler Grund, eine Erklärgrafik statt eines Stockfotos.

Bedienbarkeit: das Minimum, das wirklich zählt

• Semantisches HTML. Eine h1 je Seite, danach eine Überschriftenfolge ohne Sprünge. Navigation in nav, Hauptinhalt in main.
• Sichtbarer Fokus. Wer outline: none setzt, ohne Ersatz zu liefern, macht die Seite für Tastaturnutzer unbenutzbar.
• Sprunglink zum Inhalt. Zwei Zeilen Code, große Wirkung.
• Kontraste. Helles Grau auf Weiß sieht in der Vorlage gut aus und ist auf einem Telefon im Sonnenlicht unlesbar.
• Alt-Texte, die das Motiv beschreiben statt Suchbegriffe zu stapeln.
• Das Mobilmenü muss per Tastatur zu öffnen und zu schließen sein und der Fokus danach an einer sinnvollen Stelle stehen.

Das meiste davon ist gleichzeitig technisches SEO. Die Trennung zwischen „für Menschen“ und „für Suchmaschinen“ ist an dieser Stelle künstlich.

Wie viel Animation eine Inhaltsseite verträgt

Animation kann eine Seite gliedern und Aufmerksamkeit führen. Sie kann eine Seite aber auch unbenutzbar machen – und zwar auf eine Art, die im Test nicht auffällt.

Die Regel, die wir uns nach einem eigenen Fehler gegeben haben:

Der Hintergrund: Auf dieser Website standen die Ausgangszustände zunächst im CSS. Ein Prozent-Transform wurde von der Animationsbibliothek als Pixelwert eingelesen, die Animation lief auf eine andere Eigenschaft – und alle maskierten Überschriften blieben dauerhaft unsichtbar, während die Zeitleiste sich als fertig meldete. Die Seite war gebaut, geprüft und live, und der Fehler fiel erst im echten Browser auf.

Daraus folgen drei Punkte, die jede animierte Seite braucht:

1. Ohne JavaScript ist sofort alles sichtbar.
2. prefers-reduced-motion zeigt sofort den Endzustand.
3. Eine Absicherung, die das Ergebnis misst – nicht, ob eine Animation gemeldet hat, sie sei fertig.

Wie man das Ergebnis prüft

Eine Sichtprüfung im eigenen Browser ist zu wenig. Was wir vor jedem Livegang durchgehen:

• Darstellung bei 390, 768 und 1440 Pixeln – kein waagerechter Überlauf, kein abgeschnittener Text
• die Seite mit deaktiviertem JavaScript
• die Seite mit reduzierter Bewegung
• Bedienung nur mit der Tastatur, vom Sprunglink bis zum letzten Footerlink
• die Netzwerkanalyse: geht eine Anfrage an eine fremde Domain?
• ein Blick in die Konsole: gibt es Fehler?

Diese sechs Punkte finden mehr als jedes Bewertungswerkzeug mit Punktzahl. Bei holzrechner.de ist das der Grund, warum die Rechner auch ohne ausgeführtes JavaScript auffindbar bleiben: Die Erklärung steht im ausgelieferten HTML, nicht erst im Skript.