Was ist Responsive Design?

Den Begriff prägte der Designer Ethan Marcotte in einem Artikel, der am 25. Mai 2010 bei A List Apart erschien. Dort definierte er die drei technischen Säulen: flexible Grids, flexible Bilder und Media Queries. Vor diesem Artikel existierte jedes dieser Mittel für sich. Marcotte war derjenige, der sie zu einem einzigen Gestaltungsansatz für ein Web mit vielen unterschiedlichen Geräten zusammenführte.

Responsive Design ist eine Entwicklungstechnik: dasselbe HTML-Dokument, ohne doppelten Code und ohne eigene Version pro Gerät, ändert seine Darstellung je nach Bildschirmbreite über CSS-Regeln. Der Browser lädt dieselbe Seite, egal ob am Smartphone oder am Desktop-Rechner geöffnet. Was sich ändert, ist die Anordnung des Inhalts, nicht der Inhalt selbst.

Das zentrale Werkzeug sind Media Queries, CSS-Regeln, die einen Stilblock nur dann anwenden, wenn eine Bedingung erfüllt ist, meist die Fensterbreite. Die Punkte, an denen sich das Layout ändert, heißen Breakpoints. Dazu kommen flexible Grids (mit Flexbox oder CSS Grid, die verfügbaren Platz in Anteilen statt in festen Pixeln verteilen) und fließende Bilder, die sich ohne Überlauf an ihren Container anpassen.

Breakpoints am Inhalt auszurichten statt an bestimmten Geräten liefert meist bessere Ergebnisse, als sich an konkreten Smartphone- oder Tablet-Breiten zu orientieren: Ein Gerätekatalog, der sich jedes Jahr ändert, macht jeden Breakpoint schnell veraltet, der für ein bestimmtes Gerät gedacht war. Ein Breakpoint dagegen, der genau dort sitzt, wo das Layout selbst zu kippen beginnt, ein Menü das sich staucht oder ein Text der zu schmal wird, funktioniert weiter, egal welche Geräte gerade auf dem Markt sind.

Ein einfaches Beispiel: ein Bild in voller Breite auf dem Smartphone und ein horizontales Menü ab Tablet-Breite, beides definiert im selben Stylesheet.

<style>
  .menu {
    display: block; /* gestapelt, Standard für Smartphone */
  }
  img {
    max-width: 100%;
    height: auto;
  }

  @media screen and (min-width: 768px) {
    .menu {
      display: flex; /* horizontal ab Tablet/Desktop */
    }
  }
</style>

Damit der mobile Browser dieses Verhalten überhaupt respektiert, braucht es zusätzlich den Viewport-Tag im head des Dokuments. Er wird häufig vergessen: ohne ihn rendert das Smartphone die Seite wie eine Desktop-Version und skaliert sie danach herunter, wodurch die Media Queries wirkungslos bleiben.

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

Dieser Tag stammt ursprünglich nicht von einem offiziellen Web-Standard, sondern von Apple: Er wurde mit dem Safari-Browser des ersten iPhones eingeführt, damit Websites, die für Desktop-Breiten gebaut waren, sich auf dem kleinen Bildschirm sinnvoll darstellen ließen. Andere mobile Browser übernahmen die gleiche Syntax später als De-facto-Standard, weshalb sie bis heute funktioniert, obwohl sie nie förmlich in einer W3C-Spezifikation verankert wurde.

Hier werden häufig zwei Ebenen vermischt, die getrennt zu betrachten sind. Responsive Design ist eine Entwicklungstechnik: sie legt fest, wie eine Seite auf welchem Bildschirm aussieht, und das entscheidet das Entwicklungsteam. Die Mobile-First-Indexierung ist ein Google-Prozess: sie legt fest, welche Version einer Seite Google als Quelle für Crawling, Index und Ranking heranzieht, und diese Entscheidung trifft Google, nicht das Entwicklungsteam.

Eine responsive Website macht es deutlich leichter, Mobile-First-Anforderungen zu erfüllen, weil das HTML in beiden Fällen identisch ist und kein Inhalt beim Wechsel zwischen Ansichten verloren geht. Trotzdem sind beide Begriffe keine Synonyme: Eine Website kann responsive sein und trotzdem bei Mobile-First scheitern, etwa wenn ein Textblock per CSS auf kleinen Bildschirmen ausgeblendet wird und dieser Block dadurch nie Teil dessen wird, was Google crawlt.

Ein Beispiel macht den Unterschied greifbar. Wenn ein Online-Shop seine Produktseite per CSS so umbaut, dass sie auf jedem Bildschirm gut aussieht, ist das Responsive-Design-Arbeit, die das Entwicklungsteam entscheidet, ohne dass Google dabei mitredet. Fängt Google dagegen an, in der Suche den Preis oder die Beschreibung anzuzeigen, die auf der mobilen Version derselben Seite steht, und nicht die der Desktop-Version, dann ist das Mobile-First-Indexierung, und keine CSS-Entscheidung ändert daran etwas: Entscheidend ist allein, welcher Inhalt im finalen HTML in der Version steht, die der Googlebot Smartphone crawlt.

Die Details dazu, was Google in diesem Prozess prüft und wie sich das per URL-Prüfung kontrollieren lässt, stehen im eigenen Artikel zur Mobile-First-Indexierung.

Bevor sich Responsive Design durchsetzte, war die übliche Lösung, zwei getrennte Websites zu betreiben: eine unter der Hauptdomain für Desktop und eine unter einer Subdomain wie m.meineseite.de für mobile Geräte, jeweils mit eigenem HTML und oft mit gekürztem Inhalt in der mobilen Version. Dieses Schema, bekannt als separate URLs, findet sich noch auf älteren Websites, gilt heute aber als veraltetes Muster.

Das Problem lag nicht in der Technik, sondern im Pflegeaufwand und in der SEO. Jeder Inhalt existierte doppelt unter zwei verschiedenen URLs, was ohne sauber gesetzte Canonical- und Alternate-Tags zwischen beiden Versionen das Risiko von doppeltem Content mit sich brachte. Zusätzlich brauchte jeder Besuch eine Weiterleitung: Ein Nutzer, der über die Desktop-URL auf die Seite kam, musste auf die m.-Version umgeleitet werden, und umgekehrt bei einem von mobil geteilten Link. Jede Änderung an Inhalt, Preis oder Struktur musste zweimal gepflegt werden, in zwei unabhängigen Vorlagen, mit dem ständigen Risiko, dass eine Version aktualisiert wurde und die andere veraltete.

Es gab noch eine dritte, zwischenzeitliche Option, das Dynamic Serving: eine einzige URL für beide Versionen, wobei der Server anhand des User-Agents erkannte, ob mobil oder Desktop zugriff, und je nachdem ein anderes HTML auslieferte, markiert über den HTTP-Header Vary, damit Crawler wussten, dass sich der Inhalt je nach Gerät unterscheidet. Das löste das Problem der zwei URLs, ließ aber weiterhin zwei Vorlagen zu synchronisieren übrig und brachte ein eigenes Risiko mit sich: Erkannte der Server den User-Agent falsch, konnte er dem Googlebot die falsche Version ausliefern. In der Praxis setzte sich Dynamic Serving nie in der Breite durch, dafür war die serverseitige User-Agent-Erkennung zu fehleranfällig und der Pflegeaufwand kaum geringer als bei zwei getrennten Domains.

Google empfiehlt Responsive Design genau deshalb, weil es alle drei Probleme auf einmal löst: eine URL pro Inhalt, keine Weiterleitung zwischen Versionen nötig, weil es keine zwei Versionen gibt, zwischen denen weitergeleitet werden müsste, und nur eine Vorlage zu pflegen. In den Worten der Google-Search-Central-Dokumentation selbst ist es das Muster, das „am einfachsten zu implementieren und zu pflegen" ist, verglichen mit den anderen Optionen für die Auslieferung an unterschiedliche Geräte. Für die meisten neuen Projekte gibt es heute kaum noch einen Grund, sich für separate URLs oder Dynamic Serving zu entscheiden, außer bei sehr speziellen technischen Rahmenbedingungen, die ein völlig anderes Frontend für Mobil erfordern.

• Immer den Tag <meta name="viewport" content="width=device-width, initial-scale=1"> im head setzen; ohne ihn funktionieren Media Queries auf mobilen Geräten nicht wie erwartet.
• Zuerst für Smartphone gestalten und mit wachsender Bildschirmbreite per Media Query Komplexität ergänzen (Mobile-First-Design), statt von der Desktop-Version auszugehen und sie nachträglich zu kürzen.
• Relative Einheiten (%, rem, vw) statt fester Pixel für Breiten, Abstände und Typografie nutzen, und Bilder mit max-width: 100% begrenzen, damit sie ihren Container nie überlaufen.
• Das Layout bei mehreren realen Bildschirmbreiten testen, nicht nur bei den üblichen Breakpoints; viele Probleme zeigen sich erst bei Zwischenbreiten, die kein Breakpoint abdeckt.
• Für alle Bildschirmgrößen dasselbe HTML behalten: Wenn sekundärer Inhalt auf dem Smartphone ausgeblendet werden soll, per CSS lösen, sodass er im Markup vorhanden bleibt, statt ihn aus dem Dokument zu entfernen.

• Den Viewport-Tag vergessen, wodurch das Smartphone die Seite im Desktop-Maßstab rendert und danach herunterskaliert, wodurch die Media Queries wirkungslos bleiben.
• Inhalte per display: none auf dem Smartphone ausblenden, in der Annahme, das betreffe nur die Ansicht, ohne zu bedenken, dass dieser Inhalt fürs Ranking wegfallen kann, wenn Google ihn gar nicht crawlt.
• Responsive Design mit Mobile-First-Indexierung verwechseln und annehmen, dass eine anpassungsfähige Website automatisch das erfüllt, was Google beim Indexieren bewertet.
• Breakpoints nur für die heute gängigsten Bildschirmgrößen definieren, ohne Spielraum für künftige Geräte mit anderen Breiten.
• Unoptimierte, hochauflösende Bilder unabhängig vom Gerät gleich groß ausliefern, was die Ladezeit im mobilen Netz ausbremst, auch wenn das Layout korrekt aussieht.