Responsive Design mobile first: CSS, Breakpoints, Aufwand

Responsive Design mobile first heißt: Sie schreiben das Layout zuerst für den schmalsten Bildschirm und erweitern es dann mit min-width-Media-Queries für breitere Viewports. Mobile First ist also kein Gegenmodell zu Responsive Design, sondern die Reihenfolge, in der man es baut. Desktop First ist dieselbe Technik in umgekehrter Richtung: großes Layout als Basis, Abbau per max-width. Der Unterschied zeigt sich weniger in der Codemenge als darin, was passiert, wenn ein Breakpoint fehlt oder kaputtgeht.

Mobile First ist eine Reihenfolge, kein Gegenmodell

Viele Artikel stellen beides als Entweder-oder dar. Der Blog des Deutschen Instituts für Marketing (DIM) etwa beschreibt responsives Design als Ansatz, der mit der Desktop-Ansicht startet und für kleinere Geräte angepasst wird, während Mobile First auf dem kleinen Bildschirm beginnt (Marketinginstitut, Mobile-First-Strategie). Diese Lesart ist verbreitet. Technisch beschreibt sie aber nur zwei Startpunkte derselben Methode.

Was Responsive Design technisch meint

Responsive Design bezeichnet ein Layout, das sich über flexible Raster, relative Einheiten und Media Queries an die verfügbare Breite anpasst – mit einem einzigen HTML-Dokument für alle Geräte. Eine Media Query ist eine CSS-Bedingung, die Regeln nur ab oder bis zu einer bestimmten Viewport-Breite anwendet. Ob die Basisregeln für 360 oder für 1440 Pixel geschrieben sind, legt der Begriff nicht fest.

Was Mobile First daran ändert

Mobile First legt genau das fest: Die Basis ist die einspaltige, schmale Ansicht. Jeder Breakpoint fügt etwas hinzu, keiner nimmt etwas zurück. Die Konsequenz reicht über CSS hinaus. Wer mit 360 Pixeln Breite anfängt, muss früh entscheiden, welcher Inhalt zuerst kommt. Diese Entscheidung landet dann auch im Desktop-Layout, statt dort nachträglich verschoben zu werden.

Derselbe Baustein, zweimal geschrieben

Ein Kartenraster mit drei Spalten auf dem Desktop, zwei auf dem Tablet, einer auf dem Telefon. Zuerst Desktop First:

.cards {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  gap: 2rem;
  padding: 3rem;
}
.card { padding: 2rem; font-size: 1.125rem; }
.card__actions { display: flex; justify-content: flex-end; }

@media (max-width: 900px) {
  .cards { grid-template-columns: repeat(2, 1fr); gap: 1.5rem; padding: 2rem; }
}
@media (max-width: 600px) {
  .cards { grid-template-columns: 1fr; gap: 1rem; padding: 1rem; }
  .card { padding: 1rem; font-size: 1rem; }
  .card__actions { flex-direction: column; }
}

Dann Mobile First:

.cards {
  display: grid;
  grid-template-columns: 1fr;
  gap: 1rem;
  padding: 1rem;
}
.card { padding: 1rem; font-size: 1rem; }
.card__actions { display: flex; flex-direction: column; }

@media (min-width: 600px) {
  .cards { grid-template-columns: repeat(2, 1fr); gap: 1.5rem; padding: 2rem; }
  .card__actions { flex-direction: row; justify-content: flex-end; }
}
@media (min-width: 900px) {
  .cards { grid-template-columns: repeat(3, 1fr); gap: 2rem; padding: 3rem; }
  .card { padding: 2rem; font-size: 1.125rem; }
}

Gezählt:

Die Codemenge ist praktisch gleich. Das Argument für Mobile First ist nicht „weniger CSS“.

Es ist die Fehlerrichtung. Greifen im Desktop-First-Code die Media Queries nicht – Tippfehler in der Query, falsch sortierte Datei, ein Build-Schritt, der Media Queries zusammenführt –, rechnet das Telefon mit 48 px Innenabstand links und rechts und zwei 32-px-Lücken: (360 − 96 − 64) / 3 ≈ 67 Pixel pro Karte. Unlesbar. Im Mobile-First-Code bekommt ein breiter Bildschirm im selben Fehlerfall eine einzelne, sehr breite Spalte. Hässlich, aber benutzbar.

Breakpoints aus dem Inhalt ableiten, nicht aus Gerätelisten

Breakpoints wie 768 oder 1024 Pixel stammen aus einer Zeit, in der eine Handvoll Gerätegrößen den Markt geprägt haben. Sinnvoller ist die Regel: Ziehen Sie das Browserfenster von schmal nach breit auf und setzen Sie einen Breakpoint genau dort, wo der Inhalt anfängt, schlecht auszusehen. Typische Signale sind Textzeilen, die zu lang werden, Karten, die zu breit und leer wirken, oder eine Navigation, die plötzlich in eine Zeile passt.

Wie viele Breakpoints ein Projekt braucht

In meinen Next.js-Projekten kommen Content-Seiten meist mit zwei globalen Breakpoints aus. Mehr als vier auf Seitenebene sind für mich ein Hinweis, dass einzelne Komponenten ihre eigene Logik bräuchten. Definieren Sie die Werte in rem statt in Pixeln: Dann verschiebt sich der Umbruch mit, wenn jemand im Browser die Schriftgröße erhöht.

Container Queries für Komponenten

Eine Container Query reagiert auf die Breite des umgebenden Elements statt auf das Browserfenster. Für Komponenten, die mal in der Hauptspalte und mal in einer schmalen Seitenleiste stehen, ist das die genauere Bedingung:

.card-list { container-type: inline-size; }

@container (min-width: 36rem) {
  .card { display: grid; grid-template-columns: 8rem 1fr; }
}

Auch hier gilt Mobile First: Die Basis ist die schmale Form, die Query erweitert. Prüfen Sie die Browserunterstützung gegen die Gerätestatistik Ihrer eigenen Analytics, bevor Sie Container Queries als einzige Layoutlogik einsetzen.

Was jenseits von CSS dazugehört

Mobile First endet nicht beim Raster. Drei Punkte entscheiden auf echten Telefonen mehr als die Spaltenzahl.

Touch-Ziele. Buttons und Links brauchen eine Fläche, die ein Finger zuverlässig trifft. WCAG 2.2 behandelt das im Erfolgskriterium 2.5.8 „Target Size (Minimum)“; lesen Sie dort die Mindestgröße und die Ausnahmen nach, bevor Sie Ihre Komponenten-Tokens festlegen.

Hover als einziger Zugang. Menüs, Tooltips oder Aktionen, die nur bei Mausberührung erscheinen, existieren auf Touchgeräten faktisch nicht. Die Media Query (hover: hover) hilft, Hover-Effekte gezielt nur dort einzusetzen, wo es Hover gibt.

Bilder. Mit srcset und sizes lädt das Telefon eine passende Variante statt der Desktop-Datei. Ein sizes="(min-width: 900px) 33vw, 100vw" folgt derselben Logik wie das CSS oben: Basis schmal, Bedingung für breit. Wie sich Bildgrößen auf LCP auswirken, gehört in die Messung der Core Web Vitals – nicht ins Bauchgefühl.

Wenn das Design aus Figma kommt, sollte die schmale Ansicht dort als eigener Frame existieren, nicht als Vermutung des Entwicklers. Welche Zustände in Übergaben typischerweise fehlen, steht in Figma UI/UX Design: die Übergabe an die Entwicklung.

Was der Umbau einer Desktop-first-Site kostet

Wer eine bestehende Site von Desktop First auf Mobile First umstellt, schreibt die Basis jeder Komponente neu. Mein Kalkulationsmodell für eine fiktive Unternehmenssite mit 9 Seitentemplates und 22 Komponenten:

Zum Vergleich: Bei einem Neubau, der von Anfang an Mobile First geschrieben wird, rechne ich für die schmale Ansicht keinen eigenen Block, sondern nur zusätzliche Testzeit. Der Großteil der 72 Stunden entsteht also durch die nachträgliche Umkehr, nicht durch Mobile First selbst.

Daraus folgt eine Entscheidungsregel, mit der ich arbeite: Steht ohnehin ein Relaunch an, wird Mobile First Teil davon. Steht keiner an, und die mobile Ansicht funktioniert nur mit Override-Ketten, aber funktioniert, lohnt sich ein eigenes Umbauprojekt selten. Dann stellen Sie Komponenten einzeln um, sobald Sie sie ohnehin anfassen.

Dasselbe gilt für ein MVP einer Web-App: Dort entscheidet der Scope über die Kosten. Wenn Ihre ersten Nutzer überwiegend am Telefon arbeiten, gehört die schmale Ansicht in den Kern des MVP, nicht auf die Liste für später.

Wo Mobile First nicht passt

Ein internes Dispositions-Dashboard mit zwölf Tabellenspalten, das ausschließlich am Arbeitsplatzrechner genutzt wird, profitiert kaum davon, zuerst für 360 Pixel gebaut zu werden. Hier ist eine solide Desktop-Basis mit einer reduzierten Lesansicht für unterwegs oft die ehrlichere Lösung. Entscheiden Sie anhand Ihrer Nutzungsdaten, nicht anhand eines Schlagworts.

Typische Fehler, wenn Mobile First falsch verstanden wird:

• Inhalte verstecken. Google indexiert bei der Mobile-First-Indexierung die mobile Version und empfiehlt, dass sie dieselben Inhalte enthält wie die Desktop-Version (Google Search Central). Was mobil per display: none verschwindet, fehlt zudem für die Nutzer. Platz sparen Sie besser mit Akkordeons oder Tabs als durch Weglassen.
• Desktop vergessen. Eine einspaltige Seite, die auf 1920 Pixel einfach in die Breite gezogen wird, ist kein Mobile First, sondern unfertig. Die Breakpoints nach oben brauchen dieselbe Sorgfalt.
• Nur im Emulator testen. Die Gerätesimulation im Browser zeigt Breiten, aber keine echte Touch-Bedienung, keine eingeblendete Tastatur über einem Formularfeld und kein schwankendes Mobilnetz.

Prüfliste für die Planung im Dezember und Januar

Wenn Sie im Januar über Budgets für das neue Jahr entscheiden, ist der Dezember ein guter Zeitpunkt für eine Bestandsaufnahme. Sechs Prüfungen, die ohne Entwickler starten können:

1. Exportieren Sie die Geräteaufteilung der letzten zwölf Monate aus Ihrer Webanalyse – einmal gesamt, einmal nur für Dezember. Weicht der Monat deutlich ab, planen Sie für diese Spitze.
2. Öffnen Sie Ihre fünf meistbesuchten Seiten auf einem Telefon und notieren Sie, wo Sie zoomen oder seitlich scrollen müssen.
3. Füllen Sie Ihr wichtigstes Formular am Telefon komplett aus. Erscheint die passende Tastatur für E-Mail und Telefonnummer?
4. Suchen Sie im Stylesheet nach max-width-Media-Queries und zählen Sie, wie viele Komponenten betroffen sind. Das ist die Grundlage für die Stundenschätzung oben.
5. Prüfen Sie, ob mobil Inhalte ausgeblendet werden, die auf dem Desktop sichtbar sind.
6. Lassen Sie die Core Web Vitals getrennt nach Mobil und Desktop auswerten, statt einen Gesamtwert zu betrachten.

Hinweis zu Punkt 6: Gemeint ist eine Auswertung pro Gerätetyp, wie sie die gängigen Messwerkzeuge anbieten.

Häufige Fragen

Ist Mobile First dasselbe wie Responsive Design?

Nein. Responsive Design ist die Technik, ein Layout an die verfügbare Breite anzupassen. Mobile First ist die Entscheidung, die schmale Ansicht als Basis zu schreiben und mit min-width zu erweitern. Jede Mobile-First-Site ist responsiv, aber nicht jede responsive Site ist Mobile First.

Wird das CSS mit Mobile First kleiner?

Im Beispiel oben nicht: 17 zu 18 Deklarationen. Der Vorteil liegt in der Fehlerrichtung und darin, dass Breakpoints nur ergänzen statt zurückzusetzen. Das macht den Code leichter zu lesen, wenn Komponenten später erweitert werden.

Lohnt sich die Umstellung einer bestehenden Website?

Als eigenes Projekt meist nur, wenn die mobile Ansicht spürbar Probleme macht oder ein Relaunch ohnehin ansteht. Sonst stellen Sie Komponenten schrittweise um, wenn sie ohnehin geändert werden.