Breakpoints im Responsive Webdesign festlegen: So finden Sie die richtigen

In diesem Leitfaden zeigen wir, Talha Aslan und Team, die Methode aus unseren Webprojekten Schritt für Schritt. Unser Ziel ist keine magische Zahlenliste. Stattdessen möchten wir zeigen, wie Sie den passenden Schwellenwert anhand Ihrer eigenen Seiten finden. Außerdem besprechen wir gängige Breitenbereiche; allerdings sollten Sie diese als Ausgangsidee sehen, nicht als Regel.

Kurz gesagt: Eine responsive Website verkleinert Inhalte nicht einfach. Sie ordnet Spalten, Navigation, Schriftgröße und Abstände neu, je nachdem, was der Inhalt braucht. Breakpoints markieren lediglich, wo jede dieser Änderungen beginnt.

Warum sollten Breakpoints dem Inhalt folgen und nicht den Geräten?

Der Gerätemarkt steht allerdings nie still. Eine heute verbreitete Smartphonebreite weicht morgen einem anderen Modell. Wenn Sie Ihre Breakpoints also an bestimmte Geräte binden, veraltet die Liste mit jeder neuen Generation. Zudem können Breiten zwischen zwei Geräten auf eine Weise brechen, die niemand getestet hat.

Googles Entwicklerplattform web.dev sieht das ebenso. Der Leitfaden zu den Grundlagen des Responsive Webdesigns rät davon ab, Breakpoints nach Geräteklassen, Produkten, Markennamen oder Betriebssystemen zu definieren. Stattdessen empfiehlt er, das Layout dort anzupassen, wo der Inhalt es verlangt.

Der praktische Nutzen ist einfach: Ihre Seite passt sich jeder Breite an, nicht nur einem Smartphone. Zum Beispiel wirkt ein Leistungsbereich mit drei Karten bei einer Breite angenehm. Ziehen Sie das Fenster etwas schmaler, rutschen die Kartentitel in zwei Zeilen, und die Schaltflächen geraten ins Gedränge. Genau dort gehört ein Breakpoint hin, egal welches Gerät diese Breite hat.

• Der geräteorientierte Ansatz schaut auf eine Modellliste und vergisst die Breiten dazwischen.
• Der inhaltsorientierte Ansatz sucht die Stelle, an der das Layout bricht, und setzt dort eine Regel.
• Die zweite Methode bleibt auch dann gültig, wenn neue Geräte erscheinen.

Funktionieren Breakpoints ohne Meta Tag für den Viewport?

Nein, jedenfalls nicht so, wie Sie es erwarten. Ohne Angaben zum Viewport stellen mobile Browser eine Seite meist wie eine breite Desktopseite dar. Danach verkleinern sie sie, bis sie auf den Bildschirm passt. Folglich sehen Ihre Media Queries diese angenommene breite Fläche statt der echten Smartphonebreite.

Deshalb betont der Leitfaden von web.dev, dass Seiten für verschiedene Geräte ein Meta Tag für den Viewport im Kopfbereich des Dokuments brauchen. Setzen Sie die Breite auf die Gerätebreite, richtet sich die Seite nach der Bildschirmbreite in geräteunabhängigen Pixeln. Dann kann der Inhalt umbrechen, und Ihre Breakpoints greifen bei den richtigen Breiten.

Außerdem raten wir von Einstellungen ab, die das Zoomen verhindern. Ein gesperrter Zoom ist für Menschen mit Sehschwäche ein echtes Hindernis. Ein solider Plan macht Zoomen in den meisten Fällen überflüssig; trotzdem sollten Sie Ihren Besuchern diese Wahl nie nehmen.

Es gibt außerdem einen einfachen Test. Öffnen Sie Ihre Website auf einem Smartphone. Wirkt der Text winzig und erscheint eine horizontale Scrollleiste, prüfen Sie zuerst den Viewport. Erst wenn diese Grundlage stimmt, lohnt sich die Feinarbeit an den Werten.

Wie verändert Mobile First Ihre Strategie für Breakpoints?

Beim Mobile First Ansatz schreiben Sie die Basisstile für den schmalsten Bildschirm. Wächst der Bildschirm, ergänzen Sie dann neue Regeln mit Bedingungen für die Mindestbreite. Das heißt, Sie erweitern das schmale Design schrittweise, statt ein Desktopdesign zusammenzudrücken.

Dieser Ansatz senkt meist auch die Zahl der Schwellenwerte. Denn ein einspaltiges Layout funktioniert auf kleinen Bildschirmen für die meisten Inhalte bereits gut. Sie ergänzen also nur Änderungen, die bei mehr Platz wirklich helfen: eine zweite Spalte, ein horizontales Menü oder einen breiteren Bildbereich.

Andererseits können Sie auch beim Desktop beginnen und mit Bedingungen für die Höchstbreite rückwärts korrigieren. Allerdings müssen Sie dann auf kleinen Bildschirmen unnötige Regeln überschreiben, und das Stylesheet wächst unübersichtlich. Einen breiteren Blick auf das Thema bietet unser Artikel Was ist Mobile First Design.

In der Praxis beginnt unser Team auch die Designdatei bei der schmalen Breite. So steht die inhaltliche Priorität von Anfang an fest. Findet ein Element auf dem kleinen Bildschirm keinen Platz, ist es oft auch auf großen Bildschirmen verzichtbar.

Welche Bildschirmbreiten sind üblich und wie sehr sollten Sie ihnen trauen?

Viele CSS Frameworks und Designsysteme bringen eigene voreingestellte Werte mit. Diese Vorgaben helfen zunächst beim schnellen Start. Allerdings nutzt jedes Framework andere Zahlen, und keines kennt Ihren Inhalt. Die folgende Tabelle bietet daher einen groben Denkrahmen, keine exakten Werte.

Pixelwerte haben wir deshalb bewusst weggelassen. Selbst das Beispiel von web.dev wählt die Schwellen nach dem Inhalt und nennt die Entscheidung offen subjektiv. Nutzen Sie die Vorgaben eines Frameworks, testen Sie sie also ebenfalls mit Ihren eigenen Seiten. Passt ein Wert nicht, ändern Sie ihn.

Was unterscheidet Haupt und Nebenbreakpoints?

Hauptbreakpoints markieren große Layoutwechsel. Typische Beispiele sind der Wechsel von einer auf zwei Spalten oder vom kompakten zum horizontalen Menü. Nebenbreakpoints regeln dagegen kleine Anpassungen, ohne das Layout selbst zu ändern. Denken Sie an Schriftgröße, Außenabstand, Innenabstand oder Symbolgröße.

Der Leitfaden von web.dev zeigt diese Trennung deutlich. Sein Beispiel nutzt kleine zusätzliche Schwellen vor und nach dem Hauptwechsel. Zudem begrenzt es ab einem bestimmten Punkt die Breite eines Bereichs, damit dieser auf großen Bildschirmen nicht ausufert.

Der Vorteil dieser Trennung ist ein aufgeräumtes Stylesheet. Hauptbreakpoints teilen Sie auf der gesamten Website. Nebenbreakpoints leben dagegen nur in der Komponente, die sie braucht. Somit müssen Sie nie das ganze Seitenlayout ändern, nur um die Überschrift einer einzelnen Karte zu korrigieren.

Ein Beispielszenario: Eine Unternehmenswebsite kommt oft mit zwei Hauptbreakpoints aus. Der eine schaltet auf zwei Spalten, der andere blendet das horizontale Menü ein. Daneben können Komponenten wie eine Preistabelle oder eine Galerie eigene kleine Schwellen haben. Eine geringe Anzahl hält zudem die Wartung günstig.

Wie finden Sie die Stelle, an der Ihr Inhalt bricht?

Die inhaltsorientierte Methode ist einfacher, als sie klingt. Sie brauchen nur einen Browser, seine Entwicklertools und etwas Geduld. In unseren Projekten folgt das Team dieser Reihenfolge.

1. Öffnen Sie die Seite in der schmalsten Breite und prüfen Sie das einspaltige Layout.
2. Ziehen Sie das Fenster langsam breiter und behalten Sie den Inhalt im Blick.
3. Notieren Sie die Breite, an der Zeilen zu lang werden, Abstände auseinanderdriften oder Elemente verloren wirken.
4. Setzen Sie den ersten Hauptbreakpoint knapp unter diese Breite und ändern Sie das Layout.
5. Ziehen Sie weiter und suchen Sie die nächste Bruchstelle.
6. Lösen Sie kleine Probleme in der Komponente, statt einen neuen Hauptbreakpoint anzulegen.
7. Geben Sie dem Inhalt schließlich auf den breitesten Bildschirmen eine maximale Breite.

Wiederholen Sie diesen Rundgang für jede Seitenvorlage. Die Startseite wirkt vielleicht einwandfrei, während ein Blogartikel oder ein Kontaktformular bei einer anderen Breite bricht. Sammeln Sie die gefundenen Breakpoints in einer einfachen Tabelle. Dann wissen Sie später noch, warum jede Regel existiert.

Wie beeinflusst die Zeilenlänge die Wahl eines Breakpoints?

Lesbarkeit ist eines der verlässlichsten Signale für Breakpoints. Wächst der Bildschirm, wächst auch die Textspalte, und die Zeilen werden länger. Bei sehr langen Zeilen verliert das Auge beim Sprung vom Zeilenende zum nächsten Zeilenanfang leicht den Halt. Deshalb ist die Zeilenlänge auf textlastigen Seiten der natürlichste Auslöser.

Der Leitfaden von web.dev empfiehlt, einen Breakpoint zu erwägen, sobald Zeilen etwa zehn Wörter überschreiten. Das ist keine feste Grenze; sie hängt von Schriftart, Größe und Zeilenabstand ab. Trotzdem eignet sie sich gut als schnelle Kontrolle.

In der Praxis haben Sie drei Möglichkeiten. Erstens geben Sie der Textspalte eine maximale Breite. Zweitens erhöhen Sie die Schriftgröße auf großen Bildschirmen leicht. Drittens ergänzen Sie neben dem Text eine zweite Spalte, etwa ein Inhaltsverzeichnis. Welche Lösung passt, hängt vom Zweck der Seite ab.

Ihre Schriftwahl beeinflusst all diese Entscheidungen. Eine schmale Schrift bringt mehr Wörter in dieselbe Breite. Ausführlich erklären wir das in unserem Leitfaden Web Typografie: die passende Schrift wählen. Planen Sie Schrift und Layout gemeinsam, sparen Sie sich daher spätere Nacharbeit.

Pixel oder em: Welche Einheit eignet sich für Breakpoints?

Sie können Breakpoints in Pixeln oder in relativen Einheiten wie em angeben. Beides funktioniert also in Browsern. Der Unterschied zeigt sich, wenn Nutzer die Standardschriftgröße im Browser erhöhen.

Ein Wert in em hängt von der Standardschriftgröße ab. Vergrößert jemand die Schrift, wechselt die Seite also früher zum schmalen Layout. Dadurch bleiben Spalten auch bei großer Schrift luftig. Ein Pixelwert bleibt dagegen unabhängig von der Schriftgröße.

Egal, wofür Sie sich entscheiden: Konsequenz zählt am meisten. Mischen Sie Pixel und em im selben Projekt, sorgt das bei der Wartung für Verwirrung. Unser Team legt die Hauptwerte einmal als Variablen im Designsystem an, und jede Komponente nutzt diese Variablen.

Noch ein Hinweis: Ein Pixel in einer Media Query ist kein physisches Gerätepixel. Es ist vielmehr ein CSS Pixel, denn der Browser rechnet in eigenen Einheiten. Auf Bildschirmen mit hoher Pixeldichte entspricht ein CSS Pixel mehreren physischen Pixeln. Folglich hilft Ihnen die Auflösung aus dem Datenblatt eines Smartphones bei dieser Entscheidung kaum.

Wann sind Container Queries besser als Media Queries?

Media Queries prüfen den Viewport des Browsers. Container Queries prüfen dagegen die Größe des Elements, das eine Komponente umgibt. Die MDN Dokumentation zu CSS Container Queries erklärt, dass sich eine Komponente so an ihren Platz anpasst, ohne das Seitenlayout zu kennen.

Ein Beispielszenario: Sie nutzen dieselbe Produktkarte in einer schmalen Seitenleiste und in einer breiten Hauptspalte. Eine Media Query sieht an beiden Stellen dieselbe Viewportbreite. Deshalb gerät die Karte in der Seitenleiste ins Gedränge. Eine Container Query wählt das Layout hingegen nach dem Platz, den die Karte tatsächlich hat.

Sollten Sie Media Queries also aufgeben? Nein. Das Grundgerüst der Seite, also Spaltenzahl und Navigation, steuern Sie mit Media Queries weiterhin am einfachsten. Container Queries empfehlen wir für Komponenten, die Sie an verschiedenen Stellen wiederverwenden.

Zudem muss sich der Container erst ausdrücklich als solcher anmelden. Für Browser ohne Unterstützung schlägt MDN Ausweichlösungen vor, etwa ein ähnliches Layout mit Grid oder Flexbox und eine einspaltige Media Query für kleine Viewports. Prüfen Sie die aktuelle Browserunterstützung vor dem Einsatz in der offiziellen Dokumentation.

Wie sollten Navigation, Tabellen und Formulare auf kleinen Bildschirmen funktionieren?

Navigation, Datentabellen und Formulare machen im Plan meist die meisten Schwierigkeiten. Jedes Element braucht eine eigene Entscheidung. Denn eines funktioniert bei einer Breite einwandfrei, bei der ein anderes bereits überläuft.

• Navigation: Wechseln Sie zum kompakten Menü, sobald die horizontalen Einträge nicht mehr passen. Anzahl und Länge der Einträge bestimmen diese Schwelle.
• Datentabellen: Blenden Sie keine Spalten aus. Lassen Sie die Tabelle stattdessen in ihrem eigenen Bereich horizontal scrollen oder wandeln Sie Zeilen in Karten um.
• Formulare: Ordnen Sie Felder in einer Spalte an, setzen Sie Beschriftungen über die Felder und halten Sie Schaltflächen groß genug für den Daumen.
• Bildergalerien: Ergänzen Sie mit wachsender Breite Spalten, behalten Sie aber das Seitenverhältnis der Bilder bei.

Tippflächen verdienen zudem besondere Aufmerksamkeit. Unser Leitfaden zur Daumenzone im mobilen Design zeigt, welche Bereiche der Daumen leicht erreicht. Das hilft konkret bei der Platzierung von Schaltflächen.

Noch eine Warnung: Inhalte auf kleinen Bildschirmen zu entfernen, wirkt verlockend. Allerdings erinnert der Leitfaden von web.dev daran, dass die Bildschirmgröße nicht vorhersagt, was Nutzer sehen möchten. Ändern Sie daher lieber die Reihenfolge oder nutzen Sie Akkordeons und Tabs.

Warum sind 320 CSS Pixel für die Barrierefreiheit wichtig?

Das Erfolgskriterium 1.4.10 Reflow der WCAG gehört zur Stufe AA. Es verlangt, dass vertikal scrollende Inhalte bei einer Breite von 320 CSS Pixeln funktionieren. Dabei dürfen weder Informationen noch Funktionen verloren gehen, und Scrollen in zwei Richtungen darf nicht nötig sein.

Laut W3C entspricht diese Breite einem Viewport von 1280 CSS Pixeln bei 400 Prozent Zoom. Das Kriterium betrifft also nicht nur kleine Smartphones, sondern auch Menschen, die am Desktop stark vergrößern. Für horizontal scrollende Inhalte dient eine Höhe von 256 CSS Pixeln als Bezug.

Damit erhält Ihr Plan eine klare Untergrenze. Testen Sie die schmalste Version Ihrer Seite bei dieser Breite. Text darf nicht überlaufen, Schaltflächen müssen sichtbar bleiben, und eine horizontale Scrollleiste darf nicht erscheinen. Ausnahmen gelten für Inhalte mit zweidimensionalem Layout, etwa Karten, Videos oder Datentabellen.

Den größeren Zusammenhang erklären wir in unserem Artikel zur barrierefreien Website nach WCAG. Laufen Planung und Barrierefreiheitstest zusammen, vermeiden Sie somit große Korrekturen nach dem Start.

Beeinflussen Breakpoints die Suchmaschinenoptimierung?

Breakpoints sind zunächst kein direktes Rankingsignal. Trotzdem wirken sie indirekt. Google nutzt die mobile Version einer Website für Indexierung und Ranking. Eine Seite, die mobil bricht, Inhalte versteckt oder sich schwer bedienen lässt, kann deshalb die Sichtbarkeit in der Suche schwächen.

Der Leitfaden von Google Search Central zur Mobile First Indexierung nennt Responsive Webdesign das am einfachsten umzusetzende und zu pflegende Muster. Zudem soll die mobile Version denselben Hauptinhalt tragen wie die Desktopversion. Tabs und Akkordeons sind in Ordnung, solange der Inhalt gleichwertig bleibt.

Für Ihre Planung heißt das: Verstecken Sie auf kleinen Bildschirmen keine Überschriften, keine strukturierten Daten und keinen Haupttext. Meiden Sie außerdem Muster, die Hauptinhalte erst nach einem Klick oder Wischen laden. Denn laut Leitfaden löst Google solche Aktionen nicht aus.

Auch Layoutverschiebungen und schwere Bilder beeinflussen Messwerte der Nutzererfahrung. Diese Messwerte erklären wir im Artikel Core Web Vitals erklärt. Geben Sie Bildmaße für jede Breite vorab an, reduzieren Sie Verschiebungen beim Laden.

Wie dokumentieren Sie Breakpoints in der Designdatei?

Lebt der Plan nur im Code, driften Design und Entwicklung auseinander. Deshalb dokumentiert unser Team die Schwellen auch in der Designdatei. Für jeden Hauptbreakpoint legen wir einen eigenen Rahmen an und notieren, wie sich das Layout zwischen ihnen bewegt.

Konkret dokumentieren Sie am einfachsten mit einer kleinen Tabelle. Sie nennt jede Schwelle, die betroffenen Komponenten und den Grund. Eine Notiz wie „Kartenraster wechselt auf zwei Spalten, weil Titel dreizeilig umbrachen“ erklärt die Entscheidung auch nach sechs Monaten noch.

Funktionen für automatisches Layout im Designwerkzeug helfen ebenfalls. Ziehen Sie einen Rahmen breiter, sehen Sie das Verhalten einer Komponente, bevor jemand Code schreibt. Diesen Ablauf beschreiben wir im Leitfaden Webdesign mit Figma Schritt für Schritt.

Teilen Sie außerdem zu Projektbeginn alle Daten über die Geräte Ihrer Zielgruppe. Haben Sie Analysedaten, nehmen Sie die häufigsten Breiten in Ihre Testliste auf. Setzen Sie die Schwellen dennoch dort, wo der Inhalt es verlangt. Wie Sie ein solches Briefing aufbauen, zeigt unser Artikel Webdesign Briefing erstellen.

Wie testen Sie Breakpoints richtig?

Am Anfang stehen die Entwicklertools des Browsers. Der Leitfaden von web.dev beschreibt, wie Sie in den Chrome DevTools den Gerätemodus einschalten und die Anzeige der Media Queries aktivieren. Diese Ansicht zeigt Ihre Schwellen als farbige Balken über der Seite. Ein Klick auf einen Balken zeigt dann die Vorschau dieser Breite.

Voreinstellungen für Geräte allein reichen allerdings nicht. Ziehen Sie das Fenster von Hand durch alle Breiten. Achten Sie besonders auf Breiten zwischen zwei Schwellen, denn dort verstecken sich Probleme oft. Zoomen Sie außerdem auf 200 und 400 Prozent und prüfen Sie den Umbruch.

Tests auf echten Geräten sind ebenfalls unverzichtbar. Eine Simulation bildet Berührung, die Verkleinerung durch eine offene Bildschirmtastatur und reale Netzgeschwindigkeit nicht vollständig ab. Probieren Sie daher die Kernabläufe auf einigen Smartphones und Tablets aus: Menü öffnen, Formular ausfüllen, Tabelle scrollen.

Für eine schnelle erste Prüfung eignet sich unser Tool zum Test der Mobilfreundlichkeit. Ausführlichere Methoden finden Sie im Artikel Mobilfreundlichkeit testen.

Wie berücksichtigen Sie Querformat und Bildschirmhöhe?

Pläne für Breakpoints konzentrieren sich oft nur auf die Breite. Dreht jemand sein Smartphone, erhält er allerdings einen breiten, aber sehr niedrigen Bildschirm. Dann können eine fixierte Kopfleiste, ein großes Titelbild und ein Cookiebanner gemeinsam fast den ganzen Viewport bedecken.

Deshalb empfehlen wir, neben der Breite auch die Höhe zu bedenken. Media Queries prüfen nicht nur die Breite, sondern auch Höhe und Ausrichtung. Zum Beispiel können Sie auf niedrigen Bildschirmen die fixierte Kopfleiste verkleinern oder die Höhe des Titelbereichs begrenzen. Warum dieser erste Bildschirm so wichtig ist, erklärt unser Artikel Was ist Above the Fold.

Zudem nutzt das Reflow Kriterium der WCAG eine Höhe von 256 CSS Pixeln als Bezug für horizontal scrollende Inhalte. Dieser Wert erinnert daran, dass Inhalte auch auf niedrigen Bildschirmen nutzbar bleiben müssen. Ein Formular bei offener Bildschirmtastatur auszufüllen, erzeugt eine ähnliche Lage.

Ein Beispielszenario: In einem Buchungsformular öffnet sich beim Tippen die Tastatur, und die sichtbare Fläche halbiert sich. Belegen eine fixierte Schaltfläche unten und eine fixierte Kopfleiste den Rest, sieht die Person ihr Eingabefeld nicht mehr. Vereinfachen Sie daher fixierte Elemente auf niedrigen Bildschirmen und testen Sie das Formular auf einem echten Gerät mit offener Tastatur.

Bei Tablets gilt ebenso Ähnliches. Dasselbe Tablet zeigt im Hochformat vielleicht mittlere Regeln und im Querformat breite Regeln. Nehmen Sie also beide Ausrichtungen in Ihre Testliste auf und prüfen Sie, ob das Layout ohne Sprünge wechselt.

Welche Fehler passieren bei Breakpoints am häufigsten?

Die Fehler, die wir in Projekten sehen, lassen sich meist in wenige Gruppen ordnen. Kennen Sie diese, erkennen Sie Probleme schon während der Gestaltung.

• Breakpoints für bestimmte Smartphonemodelle wählen und die Breiten dazwischen nie testen.
• Zu viele Hauptbreakpoints anlegen und dann bei jeder Änderung Dutzende Regeln anpassen.
• Inhalte auf kleinen Bildschirmen komplett ausblenden und mobile Nutzer mit Lücken zurücklassen.
• Bildmaße weglassen, sodass sich das Layout beim Laden verschiebt.
• Auf großen Bildschirmen keine maximale Breite setzen, sodass Zeilen unlesbar lang laufen.
• Smartphones im Querformat und gezoomte Desktopfenster nie ausprobieren.
• Die Menüschwelle nicht erneut prüfen, nachdem neue Menüeinträge hinzukommen.

Achten Sie deshalb besonders auf den letzten Punkt. Jeder neue Menüeintrag verändert die Breite, die das Menü braucht. Daher sollten Sie die Schwelle der Navigation bei jeder Inhaltsänderung prüfen. Gleiches gilt für Sprachversionen; deutsche Begriffe sind zum Beispiel oft länger als englische.

Beispielszenario: Breakpoints für eine Dienstleistungswebsite

Das Beispiel in diesem Abschnitt ist frei erfunden und veranschaulicht nur die Methode. Stellen Sie sich die fünfseitige Website eines Architekturbüros vor. Sie hat eine Startseite, Leistungen, eine Projektgalerie, einen Blog und eine Kontaktseite.

Zunächst gestaltet das Team die schmale Version. Jede Seite hat eine Spalte, und das Menü liegt hinter einer kompakten Schaltfläche. Danach zieht das Team das Fenster breiter. Wirken die Leistungskarten einspaltig zu breit und leer, setzt es den ersten Hauptbreakpoint und ordnet die Karten in zwei Spalten.

Beim weiteren Verbreitern findet das Team eine Breite, bei der alle Menüeinträge horizontal passen. Dort greift der zweite Hauptbreakpoint und bringt das horizontale Menü. Gleichzeitig wechselt dann die Galerie auf drei Spalten. Im Blog gibt das Team der Textspalte eine maximale Breite, damit die Zeilen lesbar bleiben.

Schließlich ergänzt das Team zwei kleine Anpassungen. Die Schaltfläche im Kontaktformular wächst bei mittlerer Breite etwas. Außerdem nutzen Projekttitel auf sehr breiten Bildschirmen eine größere Schrift. Zwei Hauptschwellen und einige Anpassungen in Komponenten genügen für eine fünfseitige Website oft.

Checkliste für Breakpoints vor dem Livegang

Haken Sie daher vor dem Start jeden Punkt ab. Diese Liste ist eine vereinfachte Fassung der Prüfungen, die unser Team vor der Übergabe durchgeht.

• Das Meta Tag für den Viewport ist vorhanden und setzt die Breite auf die Gerätebreite.
• Die Basisstile zielen auf schmale Bildschirme, Regeln für breite Bildschirme folgen danach.
• Eine Tabelle hält fest, warum jeder Hauptbreakpoint existiert.
• Die Seite lässt sich bei 320 CSS Pixeln ohne horizontales Scrollen lesen.
• Inhalte und Funktionen überstehen 200 und 400 Prozent Zoom.
• Sie haben die Breiten zwischen den Schwellen von Hand durchgezogen.
• Navigation, Tabellen und Formulare bleiben auf kleinen Bildschirmen bedienbar.
• Bilder haben feste Maße, und Sie sehen keine Layoutverschiebung.
• Die mobile Version enthält denselben Hauptinhalt, dieselben Überschriften und dieselben strukturierten Daten wie der Desktop.
• Sie haben ein Smartphone im Querformat und mindestens ein Tablet auf echter Hardware getestet.

Lautet jede Antwort ja, steht Ihr Plan auf einem soliden Fundament. Lautet eine Antwort nein, beheben Sie diesen Punkt zuerst. Schon ein kleiner Überlauf kann das Vertrauen mobiler Besucher erschüttern.

Wer sollte die Breakpoints für Ihre Website planen?

Bauen Sie eine kleine Website mit einem fertigen Theme, genügt es oft, dessen Schwellen mit der beschriebenen Methode zu testen. Bei individuellem Design, mehrsprachigen Inhalten oder komplexen Komponenten gehört der Plan allerdings an den Anfang. Sonst stapeln sich die Korrekturen nach dem Livegang.

Wir, Talha Aslan und Team, planen Breakpoints in jedem Webprojekt gemeinsam mit Design, Inhalt und Tests. Möchten Sie Ihre Website vom schmalen Bildschirm aus gestalten und in jeder Breite testen lassen, finden Sie den Umfang auf unserer Seite zum Webdesign.

Bricht Ihre aktuelle Website mobil? Gehen Sie zunächst die Checkliste aus diesem Artikel durch. Wirken die Probleme strukturell, schildern Sie uns Ihr Projekt und fordern Sie ein Angebot für Webdesign an. Im Angebot nennen wir klar, welche Vorlagen wir überarbeiten und was der Testumfang umfasst.