Responsive Design

Die drei Bausteine

Responsive Design besteht bis heute aus denselben drei Teilen, die Ethan Marcotte 2010 zusammengeführt hat: ein flexibles Raster, flexible Medien und Media Queries. Dazu kommt eine Zeile im Kopfbereich, ohne die alles andere wirkungslos bleibt:

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

Fehlt sie, rendert ein Smartphone die Seite in einer simulierten Desktop-Breite und skaliert sie herunter — der Text wird unlesbar klein, und keine Media Query greift.

Moderne CSS-Layouts brauchen dafür oft gar keine Breakpoints mehr:

/* Karten brechen von selbst um, sobald 260px nicht mehr passen */
.karten {
  display: grid;
  gap: 1.5rem;
  grid-template-columns: repeat(auto-fit, minmax(260px, 1fr));
}

/* Schriftgröße wächst mit dem Viewport, mit hartem Minimum und Maximum */
h1 { font-size: clamp(1.9rem, 5vw, 3.4rem); }

/* Media Query nur dort, wo sich die Anordnung wirklich ändern soll */
@media (min-width: 900px) {
  .seite { grid-template-columns: 2fr 1fr; }
}

Der Unterschied zu früher: auto-fit, minmax() und clamp() erledigen einen großen Teil der Anpassung ohne feste Schwellen. Media Queries bleiben für echte Layoutwechsel — Spalte neben Spalte statt untereinander, Navigation offen statt hinter einem Menü.

Mobile-first ist nicht nur eine Reihenfolge

Google erfasst und bewertet Websites mit dem Smartphone-Crawler; die Umstellung auf die reine mobile Erfassung ist seit Mitte 2024 abgeschlossen (Stand September 2026). Daraus folgt der wichtigste Satz dieses Eintrags: Was in der mobilen Ansicht fehlt, existiert für Google nicht.

Das betrifft nicht nur Text. Ausgeblendete Abschnitte, nur am Desktop geladene Bilder, strukturierte Daten, die im mobilen Template fehlen, interne Links in einer Sidebar, die mobil nicht ausgeliefert wird — all das verschwindet aus der Bewertung. Inhaltsgleichheit zwischen den Ansichten ist damit keine Stilfrage, sondern eine Grundbedingung.

Mobile-first im Entwurf heißt außerdem, die Reihenfolge ernst zu nehmen. Auf 375 Pixel Breite passt genau eine Botschaft in den sichtbaren Bereich. Was dort steht, entscheidet darüber, ob weitergescrollt wird — worauf es bei einer Landingpage besonders ankommt.

Woran es in der Praxis scheitert

Immer wieder dieselben Punkte, in dieser Häufigkeit:

• Horizontaler Überlauf. Ein zu breites Element — meist eine Tabelle, ein eingebettetes Video oder ein Bild mit fester Pixelbreite — macht die ganze Seite seitlich verschiebbar. Abhilfe: max-width: 100% auf Medien, breite Tabellen in einen eigenen Container mit overflow-x: auto.
• Zu kleine Klickziele. Links, die eng untereinanderstehen, sind mit dem Daumen nicht sicher zu treffen. Als Orientierung gelten rund 44 bis 48 Pixel Höhe und ausreichend Abstand.
• Formulare ohne mobilen Test. Falscher Eingabetyp, keine Autofill-Angaben, ein Absenden-Button unter der Tastatur. Hier gehen die meisten Anfragen verloren.
• Bilder ohne width und height. Ohne reservierten Platz verspringt das Layout beim Laden — das schlägt direkt auf die Core Web Vitals durch.
• Overlays und Banner. Cookie-Hinweis plus Newsletter-Fenster plus Chat-Widget verdecken auf kleinen Displays die halbe Seite.

Was Sie selbst prüfen können

Eine Viertelstunde, kein Werkzeugkasten nötig:

1. Die Seite auf 320 Pixel Breite ansehen. Lässt sie sich seitlich schieben, gibt es einen Überlauf.
2. Auf 200 Prozent zoomen. Bleibt alles lesbar und bedienbar, ist auch für viele Nutzer mit Sehschwäche gesorgt.
3. Das Kontaktformular auf dem eigenen Handy ausfüllen — vollständig, bis zur Bestätigungsseite.
4. Jeden Breakpoint einzeln durchgehen, nicht nur einen. Fehler sitzen meistens genau dazwischen.
5. PageSpeed Insights mit der mobilen Ansicht laufen lassen, nicht mit der Desktop-Ansicht.

Findet sich dabei mehr als eine Kleinigkeit, ist das selten ein CSS-Problem, sondern ein Aufbauproblem: Die Seite wurde für den Desktop gedacht und mobil nur zusammengeschoben. Dann lohnt der saubere Neuaufbau mehr als das Nachbessern — als Relaunch oder als neues Webdesign. Wenn die Darstellung stimmt, aber die Seite trotzdem träge wirkt, liegt es an Ladezeit und Skripten — siehe Ladezeit-Optimierung.