Responsive Webdesign: Ein praktischer Leitfaden
Responsives Design bedeutet eine Website, die bei jeder Breite funktioniert, nicht eine separate Mobilversion. In der Praxis sind die meisten Websites auf dem Papier responsiv und an bestimmten Stellen kaputt — eine Tabelle, die horizontales Scrollen erzwingt, eine Navigation, die ein Drittel des Bildschirms frisst, ein Formular, das unter iOS unvorhersehbar zoomt.
Dieser Leitfaden behandelt die Herangehensweise, wo die echten Fehler liegen und wie man darauf testet.
Vom schmalen Ende her gestalten#
Schmal anzufangen erzwingt die Prioritätsentscheidungen. Bei 320 Pixeln ist Platz für eine Sache auf einmal, also müssen Sie entscheiden, welche das ist; ein Design danach zu verbreitern heißt vor allem, den Dingen mehr Raum zu geben.
Der umgekehrte Weg — bei 1440 gestalten und dann Dinge entfernen — erzeugt mobile Layouts, die der Desktop mit ausgeblendeten Teilen sind, und so landet wichtiger Inhalt auf display:none auf dem Gerät, das die meisten Besucher nutzen.
- Beginnen Sie Layouts bei 320–360 px, den schmalsten real verbreiteten Geräten.
- Blenden Sie mobil nie Inhalte aus, die ein mobiler Besucher braucht; verschieben oder einklappen stattdessen.
- Lassen Sie den Inhalt die Breakpoints bestimmen — setzen Sie einen, wo das Layout bricht, nicht bei Gerätenamen.
- Testen Sie mit Browser-Textgröße auf 200 %: Das ist eine verbreitete Barrierefreiheits-Einstellung und bricht mehr Layouts als jedes Handy.
Nach Geräten benannte Breakpoints altern schlecht. „Tablet“ hat in zehn Jahren sechs verschiedene Breiten bedeutet; „der Punkt, an dem das Karten-Raster hässlich wird“ ändert sich nicht.
Die Elemente, die tatsächlich brechen#
Eine Handvoll Komponenten verursacht die meisten Responsive-Fehler, und sie sind vorhersehbar genug, um sie gezielt zu prüfen.
| Element | Fehler | Lösung |
|---|---|---|
| Tabellen | Horizontales Scrollen der ganzen Seite | Scroll-Container oder Umstapeln als Karten mit Datenbeschriftung |
| Lange Wörter / URLs | Seite scrollt seitwärts | overflow-wrap und min-width:0 bei Flex- und Grid-Kindern |
| Bilder | Überlauf oder Layoutverschiebung | max-width:100 %, explizite width- und height-Attribute |
| Navigation | Nimmt ein Drittel des Bildschirms | Einklappen oder Hauptpunkte in eine untere Leiste |
| Formulare | iOS zoomt hinein und wieder heraus geht nicht | Schriftgröße mindestens 16 px in Eingabefeldern |
| Fixierte Elemente | Verdecken den Inhalt, auf den sie verweisen | In scroll-padding und Body-Padding einrechnen |
| Modale Dialoge | Lassen sich auf kleinen Bildschirmen nicht schließen | Mobil formatfüllend mit sichtbarem Schließen-Element |
Bilder und Medien#
Bilder sind meist das Größte auf einer Seite und die häufigste Quelle von Layoutverschiebung. Drei Attribute beheben das meiste davon und kosten nichts.
- Setzen Sie immer width- und height-Attribute, damit der Browser den Platz reserviert, bevor die Datei ankommt.
- Liefern Sie moderne Formate — WebP oder AVIF — mit Fallback, wo Sie noch eines brauchen.
- Nutzen Sie srcset und sizes, damit ein Handy eine handygroße Datei lädt und kein 2000-px-Hero.
- Laden Sie Bilder unterhalb der Falz verzögert, aber nie das größte sichtbare Bild: Das ist Ihr LCP-Element.
- Geben Sie dem Hauptbild fetchpriority="high", damit es nicht hinter dekorativen Assets in der Warteschlange steht.
- Setzen Sie bei Hintergrundbildern ein Seitenverhältnis, damit der Container vor dem Laden nicht kollabiert.
Touch, nicht nur Breite#
Responsiv geht es nicht nur um Layout. Ein schmaler Viewport bedeutet meist einen Finger statt einer Maus, und Fingereingabe hat andere Anforderungen, die breitenbasierte Media Queries allein nicht abdecken.
- Touch-Ziele mindestens 44 × 44 px mit Abstand dazwischen; benachbarte 30-px-Links werden ständig danebengetippt.
- Nichts Wichtiges hinter Hover — ein reines Hover-Menü ist per Touch unerreichbar.
- Nutzen Sie pointer:coarse-Media-Queries, um Hover-Effekte zu entfernen, die nach einem Tap hängenbleiben.
- Halten Sie primäre Aktionen bei hohen Handys in Daumenreichweite; die obere rechte Ecke ist einhändig am schwersten zu erreichen.
- Beachten Sie prefers-reduced-motion: Parallax und große Übergänge verursachen bei manchen Nutzern echtes Unwohlsein.
Häufige Fragen
Wie viele Breakpoints brauche ich?
Meist drei bis fünf, und sie sollten aus Ihrem Inhalt kommen statt aus einer Geräteliste. Setzen Sie einen, wo das Layout beim Verbreitern des Fensters falsch aussieht, nicht weil ein bestimmtes Handy existiert. Websites mit einem Dutzend Breakpoints kompensieren fast immer ein Layout, das von vornherein nicht fluide war.
Ist eine separate Mobilseite jemals richtig?
Selten. Sie bedeutet zwei Codebasen, zwei URL-Sätze, zwei Deployments und eine zu pflegende Canonical-Beziehung, und sie endet meist damit, dass eine der beiden still zurückfällt. Die Fälle, in denen es noch passiert, sind Altsysteme, die sich nicht responsiv machen lassen, und selbst dann ist es ein Notbehelf statt eines Plans.
Wie teste ich responsives Design richtig?
Die Geräte-Emulation im Browser findet Layoutprobleme, aber nicht Touch-, Netzwerk- oder Plattformverhalten. Testen Sie auf mindestens einem echten Android der unteren Mittelklasse und einem iPhone, über Mobilfunk statt Büro-WLAN. Wiederholen Sie dann die Hauptseiten mit Browser-Textgröße auf 200 %, denn dort fallen die meisten Layouts tatsächlich auseinander.
Was ist mit Datentabellen auf Handys?
Zwei brauchbare Optionen: die Tabelle in einen horizontal scrollenden Container mit sichtbarem Hinweis und fixierter erster Spalte setzen, oder jede Zeile als Karte umstapeln, in der jede Zelle ihre eigene Spaltenbeschriftung trägt. Der Scroll-Container erhält die Vergleichbarkeit; der Kartenstapel liest sich leichter. Entscheiden Sie danach, ob Besucher Zeilen vergleichen oder einzeln lesen.
responsive webdesignmobilfreundliche websitebreakpointsmobile first designresponsive bildertouch ziele
