Responsives Webdesign: die vier Bausteine, inhaltsbasierte Breakpoints und der Prüfablauf

Responsives Webdesign ist keine Eigenschaft, die eine Website auf einem bestimmten Gerät hat. Es ist die Fähigkeit eines Layouts, sich über ein durchgehendes Spektrum von Breiten hinweg sinnvoll zu verhalten: von der schmalsten Spalte bis zum breiten Desktopfenster, ohne horizontales Scrollen, ohne abgeschnittene Inhalte, ohne Elemente, die einander überlagern. Ein Layout, das auf drei bekannten Gerätebreiten überzeugt und bei allen Breiten dazwischen bricht, ist nicht responsiv, sondern nur an drei Stellen getestet.

Technisch steht das Ganze auf vier Bausteinen: dem Meta-Viewport-Tag, das auf Mobilgeräten überhaupt erst die richtige Layoutbreite herstellt; einem Fluid Grid, das verfügbaren Platz verteilt statt ihn festzuschreiben; Media Queries, die das Layout an inhaltlich begründeten Punkten umbauen; und responsiven Bildern, die sich sowohl in der Darstellung als auch in der ausgelieferten Datei an den Kontext anpassen. Darüber liegen die Layoutwerkzeuge Flexbox und CSS Grid sowie Container Queries, die eine Komponente von der Fensterbreite entkoppeln und an ihren tatsächlichen Einbauort binden.

Dieser Text erklärt die vier Bausteine, zeigt wie Breakpoints aus dem Inhalt statt aus Gerätelisten entstehen, ordnet Flexbox, Grid, Media Queries und Container Queries gegeneinander ein und endet mit einem Prüfablauf plus benannter Ursachenliste für den häufigsten Befund: Die Seite scrollt seitlich.

Was responsives Webdesign technisch bedeutet

Der Begriff geht auf Ethan Marcottes Artikel “Responsive Web Design” zurück, erschienen am 25. Mai 2010 im Magazin A List Apart. Marcotte benennt dort drei technische Bestandteile: flexible Grids, flexible Bilder und Media Queries. Das Meta-Viewport-Tag kam in der Praxis als vierter, notwendiger Baustein hinzu, weil die anderen drei auf Smartphones ohne dieses Tag ins Leere laufen.

Google beschreibt das Muster aus Auslieferungssicht: Eine einzige URL liefert denselben HTML-Code an alle Geräte, und nur die Darstellung variiert per CSS. Das grenzt responsives Webdesign gegen zwei andere Muster ab, gegen dynamisches Ausliefern (gleiche URL, serverseitig unterschiedliches HTML) und gegen getrennte mobile URLs. Die deutschsprachige Wikipedia formuliert dieselbe Sache von der Anzeigeseite her: Der grafische Aufbau einer responsiven Website erfolgt anhand der Anforderungen des jeweiligen Geräts, mit dem sie betrachtet wird.

Responsiv und adaptiv sind dabei nicht dasselbe: Ein responsives Layout skaliert fließend innerhalb des verfügbaren Raums, ein adaptives wechselt zwischen mehreren fest definierten Fassungen. Die ausführliche Gegenüberstellung gehört in den eigenen Ratgeber zum adaptiven Webdesign.

Baustein 1: Das Meta-Viewport-Tag

Mobile Browser berechnen eine Seite im Zweifel mit einem fiktiven Desktop-Viewport von rund 980 CSS-Pixeln und zeigen das Ergebnis dann verkleinert an. Dieses Verhalten stammt aus einer Zeit, in der es kaum mobile Layouts gab, und sollte alte Seiten wenigstens vollständig sichtbar machen. Für ein responsives Layout ist es fatal, weil CSS dann nicht mit der wirklich verfügbaren Breite rechnet.

Deshalb gehört in den head jeder responsiven Seite:

<meta name="viewport" content="width=device-width, initial-scale=1">

width=device-width setzt die Layoutbreite auf die tatsächliche Gerätebreite, initial-scale=1 legt den anfänglichen Zoomfaktor fest. Erst damit greifen Media Queries auf Smartphones so, wie sie geschrieben wurden. Fehlt das Tag, sieht das typischerweise so aus: Die Seite erscheint stark verkleinert, Text ist nur durch manuelles Zoomen lesbar, die einspaltige Mobilfassung bleibt mehrspaltig, und eine @media (max-width: 30rem)-Regel wirkt scheinbar gar nicht, weil der Browser intern mit fast 1000 Pixeln Breite arbeitet.

Von user-scalable=no und niedrigen maximum-scale-Werten ist abzuraten: Sie nehmen Nutzerinnen und Nutzern die Zoommöglichkeit, was besonders Menschen mit eingeschränktem Sehvermögen trifft.

Baustein 2: Das Fluid Grid

Ein Fluid Grid ist ein Layoutsystem, dessen Spalten, Spuren und Abstände auf den vorhandenen Platz reagieren, statt ihn festzulegen. Der Unterschied zeigt sich schon am äußeren Seitencontainer:

.page {
  width: min(100% - 2rem, 75rem);
  margin-inline: auto;
}

Der Container nimmt die verfügbare Breite abzüglich eines Randes, wächst aber nicht über 75rem hinaus. Beide Grenzen stecken in einer Regel, ohne Media Query. Genau das ist das Prinzip: flexibel im Kleinen, begrenzt im Großen.

Auf Rasterebene übernimmt CSS Grid dieselbe Logik:

.card-grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(min(100%, 18rem), 1fr));
  gap: 1.5rem;
}

Der Browser legt so viele Spalten an, wie bei einer Mindestbreite von 18rem hineinpassen, und reduziert die Spaltenzahl selbstständig, wenn der Platz nicht reicht. Das innere min(100%, 18rem) verhindert, dass die geforderten 18rem in einem noch schmaleren Container selbst zur Überbreite werden. Für diesen grundlegenden Umbruch ist kein einziger Breakpoint nötig.

Eine Regel, die in fast jedem Überlaufproblem auftaucht, betrifft die Kindelemente von Grid und Flexbox:

.card,
.content {
  min-width: 0;
}

Grid- und Flex-Elemente haben standardmäßig eine automatische Mindestgröße, die sich am intrinsischen Inhalt orientiert. Eine lange URL, ein Codeblock oder ein zusammengesetztes Substantiv drückt das Element damit über seine Spur hinaus, obwohl 1fr eigentlich “teile den freien Platz” bedeutet. min-width: 0 (bei vertikalen Achsen min-height: 0) hebt diese Sperre auf.

Einheiten nach Aufgabe wählen

Fluid heißt nicht “alles in Prozent”. Die Einheiten lösen unterschiedliche Aufgaben:

• % bezieht sich auf das Bezugselement und eignet sich für Anteile innerhalb eines bekannten Containers.
• fr verteilt freien Platz in einem Grid, nachdem Abstände und feste Anteile abgezogen sind.
• rem hängt an der Schriftgröße des Wurzelelements und skaliert damit mit der Nutzereinstellung. Deshalb sind Breakpoints in rem robuster als in px.
• vw bezieht sich auf die Viewportbreite und braucht fast immer eine Begrenzung.
• ch begrenzt Textspalten nach ungefährer Zeichenzahl, etwa max-width: 65ch.
• min(), max() und clamp() verbinden flexible und feste Grenzen in einem Wert.

Für Typografie ist clamp() das direkteste Werkzeug. Die Funktion nimmt einen Minimal-, einen Vorzugs- und einen Maximalwert und erlaubt damit fließend skalierende Schriftgrößen ohne zusätzliche Media Query:

h1 {
  font-size: clamp(2rem, 1.2rem + 3vw, 4.5rem);
  line-height: 1.05;
}

Der rem-Anteil im mittleren Wert ist kein Schmuck: Ein reiner vw-Ausdruck würde beim Browserzoom nicht mitwachsen, weil die Viewportbreite in CSS-Pixeln konstant bleibt. Fließende Werte ersetzen trotzdem keine gestalterische Entscheidung. Eine Zeile, die über die gesamte Breite eines 27-Zoll-Monitors läuft, bleibt schwer lesbar, egal wie sauber die Schriftgröße interpoliert.

Baustein 3: Media Queries und inhaltsbasierte Breakpoints

Media Queries wenden CSS-Regeln nur an, wenn eine Bedingung erfüllt ist. Sie sind seit dem 19. Juni 2012 als CSS Media Queries Level 3 eine W3C Recommendation, also ein verabschiedeter Standard und keine Browser-Erweiterung.

Ein Mobile-First-Aufbau beginnt bei der schmalsten sinnvollen Darstellung und erweitert nach oben:

.article-layout {
  display: grid;
  gap: 2rem;
}

@media (min-width: 48rem) {
  .article-layout {
    grid-template-columns: minmax(0, 2fr) minmax(14rem, 1fr);
  }
}

Ohne die Query stehen Hauptinhalt und Seitenleiste untereinander. Sobald genug Platz für beide nebeneinander da ist, entstehen zwei Spuren. minmax(0, 2fr) statt 2fr ist wieder dieselbe Vorsichtsmaßnahme gegen die automatische Mindestgröße. Mobile First heißt hier nur, dass die Basisregeln für wenig Platz geschrieben und mit min-width ergänzt werden. Es heißt nicht, dass die Desktopfassung nachrangig ist.

Breakpoints finden, nicht übernehmen

MDN empfiehlt, Breakpoints dort zu setzen, wo der Inhalt bricht, statt sie an konkreten Gerätemodellen auszurichten. Der Grund ist praktischer Natur: Gerätebreiten ändern sich, Fenster werden frei skaliert, geteilte Bildschirme und eingebettete Ansichten erzeugen Breiten, die in keiner Geräteliste stehen. Ein Breakpoint bei “iPhone” sagt nichts darüber, welches Layoutproblem er löst.

Der Weg zu einem inhaltsbasierten Breakpoint ist immer derselbe:

1. Die Komponente in ihrer schmalsten funktionierenden Form aufbauen.
2. Den Viewport langsam verbreitern und beobachten, ab wann eine andere Anordnung nachweislich besser funktioniert.
3. Von dort wieder verkleinern und prüfen, ab wann die breitere Variante zu eng wird. Zwischen beiden Punkten liegt der brauchbare Bereich.
4. Den Wert in rem festschreiben, damit er beim Zoomen und bei größerer Grundschrift mitgeht.
5. Die Breiten unmittelbar ober- und unterhalb des Breakpoints erneut ansehen, nicht nur die Zielbreiten.

Ein Breakpoint ist begründet, wenn Navigationspunkte nicht mehr in eine Zeile passen, eine Spalte für Text oder Formularfelder zu schmal wird, Überschriften unkontrolliert umbrechen, Beschriftungen mit ihren Schaltflächen kollidieren oder eine Seitenleiste dem Hauptinhalt zu viel Raum entzieht. Er ist nicht begründet, weil ein verbreitetes Gerät zufällig eine bestimmte Breite hat.

Baustein 4: Responsive Bilder

Der erste Schritt ist reine Darstellung: Ein Bild darf seinen Container nicht überschreiten.

img {
  display: block;
  max-width: 100%;
  height: auto;
}

max-width: 100% deckelt die Breite, height: auto erhält das Seitenverhältnis. Diese zwei Zeilen machen das Bild flexibel, sagen dem Browser aber nichts darüber, welche Datei er laden soll. Dafür gibt es srcset und sizes, beides Teil des HTML-Standards der WHATWG:

<img
  src="motiv-800.jpg"
  srcset="motiv-480.jpg 480w, motiv-800.jpg 800w, motiv-1280.jpg 1280w"
  sizes="(min-width: 64rem) 50vw, 100vw"
  width="1280"
  height="720"
  alt="Beschreibung des dargestellten Motivs"
>

srcset nennt die verfügbaren Varianten mit ihrer intrinsischen Breite, sizes beschreibt, wie breit das Bild im Layout voraussichtlich dargestellt wird. Aus beidem wählt der Browser selbst aus und rechnet dabei die Pixeldichte des Displays ein, weshalb Geräte mit hoher Dichte wie Retina-Displays ohne weiteres Zutun eine größere Variante bekommen. Wichtig ist, dass sizes zum tatsächlichen Layout passt: Eine falsche Angabe führt zu systematisch zu kleinen oder zu großen Dateien, ohne dass es im Layout auffällt. Die Angaben width und height am Element sind kein Rückfall in feste Größen, sondern liefern dem Browser das Seitenverhältnis, damit er den Platz vor dem Laden reservieren kann.

Wenn sich mit dem verfügbaren Platz nicht nur die Auflösung, sondern der Bildausschnitt ändern soll, ist picture das richtige Element:

<picture>
  <source media="(min-width: 60rem)" srcset="motiv-breit.jpg">
  <img src="motiv-hoch.jpg" width="800" height="900" alt="Beschreibung des dargestellten Motivs">
</picture>

Dieser als Art Direction bezeichnete Ansatz lohnt sich, wenn ein breites Motiv in schmaler Spalte seinen Kern verlieren würde, etwa weil das entscheidende Detail am Rand liegt. Für rein dekorative Varianten ist er unnötiger Aufwand.

Flexbox, CSS Grid, Media Queries, Container Queries: wer beantwortet welche Frage

Die vier Techniken werden oft als Alternativen behandelt. Sie beantworten aber verschiedene Fragen und werden in der Regel gemeinsam eingesetzt.

Flexbox ist eindimensional: Es ordnet Kinder in einer Zeile oder Spalte, verteilt Restplatz und kann per flex-wrap umbrechen. CSS Grid ist zweidimensional und stimmt Spalten und Zeilen aufeinander ab. Beide erzeugen für sich genommen schon viel Anpassungsfähigkeit ohne einen einzigen Breakpoint, wie das auto-fit-Beispiel oben zeigt. Was sie nicht beantworten, ist die Frage, wann eine Komponente ihre innere Struktur wechseln soll. Diese Frage beantworten Media Queries auf Seitenebene und Container Queries auf Komponentenebene.

Container Queries: Breakpoints, die den Einbauort kennen

Eine Media Query misst immer den Viewport. Für die Seitenarchitektur ist das richtig, für wiederverwendbare Bausteine ist es die falsche Bezugsgröße. Dieselbe Teaserkarte steht einmal in der breiten Hauptspalte und einmal in einer 20rem schmalen Seitenleiste. Eine Viewport-Query sieht in beiden Fällen nur das große Fenster und schaltet auch in der Seitenleiste auf die zweispaltige Darstellung um, für die dort kein Platz ist. Der übliche Notbehelf sind Sonderklassen pro Einbauort, die mit jedem neuen Kontext wachsen.

Container Queries lösen das an der Wurzel. Sie sind im CSS Containment Module Level 3 spezifiziert und erlauben Layoutentscheidungen anhand der Breite des Elternelements statt anhand des Viewports:

.teaser-region {
  container-type: inline-size;
  container-name: teaser;
}

.teaser-card {
  display: grid;
  gap: 1rem;
}

@container teaser (min-width: 32rem) {
  .teaser-card {
    grid-template-columns: 10rem minmax(0, 1fr);
    align-items: start;
  }
}

Die Karte wechselt in die zweispaltige Fassung, sobald ihr eigener Container mindestens 32rem breit ist, unabhängig davon, ob sie im Hauptbereich, in der Seitenleiste oder in einem Dialog sitzt. Zwei Eigenheiten sind dabei zu kennen. Erstens fragt eine Komponente nie sich selbst ab, sondern immer einen Vorfahren: Der Container ist die .teaser-region, nicht die .teaser-card. Zweitens erzeugt container-type: inline-size eine Größeneindämmung in der Inline-Achse, der Container leitet seine Breite also nicht mehr aus dem Inhalt ab. Innerhalb einer Container Query lässt sich zusätzlich mit Containereinheiten wie cqi rechnen, also relativ zur Inline-Größe des Containers statt zum Fenster.

Damit verteilt sich die Zuständigkeit sauber: Media Queries steuern die Seitenarchitektur, Container Queries die Komponenten, Flexbox und Grid ordnen innerhalb des jeweils vorhandenen Platzes an. Container Queries ersetzen Media Queries also nicht, sie nehmen ihnen die Aufgabe ab, für die sie nie gedacht waren. Und auch Container-Breakpoints werden inhaltsbasiert gewählt: Die Frage ist nicht, wann die Karte auf einem Tablet erscheint, sondern ab welcher Containerbreite Bild, Überschrift und Handlungsfläche nebeneinander funktionieren.

Der Prüfablauf: ist eine bestehende Website wirklich responsiv?

Die folgenden sieben Schritte brauchen nichts außer einem Browser mit Entwicklertools.

1. Meta-Viewport-Tag kontrollieren. Im Quelltext den head nach name="viewport" durchsuchen. Fehlt der Eintrag, steht bereits die Berechnungsgrundlage der Mobilfassung falsch, und alle weiteren Befunde sind Folgefehler. Steht dort user-scalable=no oder ein maximum-scale unter 5, ist der Zoom eingeschränkt.

2. Stufenlos skalieren, nicht Presets durchklicken. Das Fenster oder den responsiven Modus langsam von der schmalsten bis zur größten Breite ziehen. Genau zwischen den bekannten Gerätebreiten zeigen sich zu früh greifende Breakpoints, überlappende Elemente und Sprünge im Layout. Zu beobachten ist: Bleiben alle Inhalte erreichbar, entsteht seitliches Scrollen, überlagern sich Navigation, Text oder Bilder, wechseln Spalten bevor ihr Inhalt zu eng wird, bleiben Formulare und Schaltflächen bedienbar.

3. Horizontales Scrollen bis zum verursachenden Element zurückverfolgen. Seitliches Scrollen der ganzen Seite ist immer ein Defekt. Bewusst scrollbare Bereiche wie breite Tabellen oder Codeblöcke gehören in einen eigenen Container mit overflow-x: auto. Um den Übeltäter zu finden, hilft eine temporäre Regel in den Entwicklertools:

* { outline: 1px solid red; }

Das überbreite Element zeichnet sich damit sichtbar über den Rand hinaus ab. overflow-x: hidden am body ist keine Lösung, sondern verdeckt das Symptom und macht im Zweifel Inhalte unerreichbar.

4. Feste Pixelbreiten an Layoutelementen suchen. Pixel an Rahmen, Symbolen oder Icons sind unkritisch. Problematisch sind sie an Seitencontainern, Spalten und Inhaltsmodulen. Aus width: 1200px wird width: min(100% - 2rem, 75rem), aus min-width: 500px an einer Seitenleiste wird width: 100%; max-width: 31.25rem. Ebenso zu prüfen sind feste Höhen: Sobald eine Beschriftung zweizeilig wird oder die Schrift größer eingestellt ist, ragt der Inhalt heraus.

5. Das Layout unter Belastung testen. Muster-Kurztexte verbergen die Hälfte der Fehler. Aussagekräftig sind: Browserzoom auf 200 Prozent, sehr lange Überschriften, zusätzliche Navigationseinträge, mehrzeilige Fehlermeldungen in Formularen, Karten mit stark unterschiedlichen Textlängen, Bilder mit abweichenden Seitenverhältnissen und Tabellen mit langen Zellinhalten.

6. Bilder und eingebettete Inhalte kontrollieren. Im berechneten CSS prüfen, ob Bilder, Videos, iframe- und SVG-Elemente ihren Container überschreiten können. Für Medien mit festem Seitenverhältnis genügt:

.video {
  width: 100%;
  aspect-ratio: 16 / 9;
}

.video iframe {
  width: 100%;
  height: 100%;
  border: 0;
}

Bei Bildern zusätzlich kontrollieren, ob srcset und sizes vorhanden und plausibel sind. Ein flexibel skaliertes Bild ist layouttechnisch responsiv, lädt aber ohne diese Attribute in jedem Kontext dieselbe Datei.

7. Komponenten an mehreren Einbauorten prüfen. Jede wiederverwendbare Komponente einmal in der breiten Hauptspalte, einmal in einer schmalen Seitenleiste und einmal in einem verschachtelten Raster ansehen. Nutzt sie den vorhandenen Platz, bleibt sie stabil wenn die Nachbarspalte ihre Breite ändert, und entscheidet sie anhand ihres Containers oder anhand des Fensters? Der letzte Punkt entscheidet, ob eine Container Query fällig ist.

Fehlerdiagnose: die benannten Ursachen

Fast jeder Befund aus dem Prüfablauf lässt sich auf eine dieser Ursachen zurückführen:

Fehlendes Meta-Viewport-Tag. Der mobile Browser rechnet mit einem fiktiven Desktop-Viewport, Media Queries greifen an den falschen Stellen oder gar nicht.

Feste Pixelbreiten an Layoutcontainern. Ein Element ist breiter als der Viewport und kann nicht schrumpfen. Häufigste Einzelursache für seitliches Scrollen.

width: 100vw in einer Seite mit Scrollleiste. Die Viewporteinheit schließt die Breite der Scrollleiste ein, das Element ist damit um deren Breite zu breit.

Nicht schrumpfende Grid- oder Flex-Kinder. Die automatische Mindestgröße hält intrinsisch breite Inhalte auf voller Breite, min-width: 0 fehlt.

Nicht umbrechende Inhalte. Lange URLs, Codezeilen oder zusammengesetzte Wörter sprengen ihre Spur.

Gerätebasierte Breakpoints. Das Layout ist für drei angenommene Bildschirmgrößen optimiert und bricht bei allen Breiten dazwischen.

Unflexible Medien. Bilder, Videos, Tabellen oder Einbettungen ohne Maximalbreite überschreiten ihren Container.

Viewportabhängige Komponenten. Eine Komponente reagiert auf die Fensterbreite, obwohl ihre eigene Containerbreite die maßgebliche Größe wäre.

Negative Außenabstände und absolut positionierte Elemente, die über den Seitenrand hinausragen.

Versteckte Überläufe. overflow: hidden überdeckt einen dieser Fehler, statt ihn zu beheben.

Wann die Prüfung bestanden ist

Eine Website gilt als technisch responsiv, wenn sie über den gesamten Breitenbereich stufenlos funktioniert: kein seitenweites horizontales Scrollen, alle Inhalte erreichbar und bedienbar, Layoutwechsel die aus dem Platzbedarf des Inhalts hervorgehen und nicht aus Gerätelisten, Medien die ihre Container respektieren, Komponenten die an jedem Einbauort stabil bleiben, und all das auch bei 200 Prozent Zoom und mit längeren Texten als im Entwurf.

Nicht dazu gehört, dass jede Breite gleich aussieht. Responsives Webdesign darf Anordnung, Abstände und Darstellungsform ändern, das ist sein Zweck. Entscheidend ist nur, dass keine Breite wie ein unbehandelter Zwischenzustand wirkt.

Ein Randfakt zur Einordnung: Google hat am 31. Oktober 2023 bekanntgegeben, dass die Umstellung auf Mobile-First-Indexierung abgeschlossen ist. Für die Indexierung zählt damit die Fassung, die der Smartphone-Googlebot ausgeliefert bekommt. Mehr als diese eine Tatsache gehört hier nicht hin: Maßnahmen zur mobilen Suchmaschinenoptimierung und zur Ladezeit sind eigene Themen und beantworten die Frage nicht, ob ein Layout technisch responsiv arbeitet.

Am Ende steht kein Katalog universeller Gerätebreiten, sondern ein Zusammenspiel: ein korrekt gesetzter Viewport, ein Raster aus relativen Maßen mit klaren Grenzen, Media Queries an Punkten die der Inhalt vorgibt, Bilder die sich in Darstellung und Datei anpassen, Flexbox und Grid für die Anordnung, Container Queries für die Unabhängigkeit einzelner Komponenten. Geprüft wird das nicht an einem Smartphone-Preset, sondern stufenlos, in mehreren Einbaukontexten und mit Inhalten, die auch mal zu lang sind.