Die Theorie der responsiven Webseiten

Inhaltsverzeichnis

Eine Webseite ist responsiv, wenn sie ihre Darstellung unterschiedlichen Geräten anpassen kann. Allerdings gehört mehr dazu, als ein paar Änderungen am CSS vorzunehmen. Themen wie "Mobile first" sind in aller Munde und bei Weitem nicht nur eine technische Herausforderung.

Statistiken belegen den eindeutigen Trend der steigenden Zahlen mobiler Internet-Surfer. Um Mobil- und Desktopgeräte gleichmäßig gut bedienen zu können, kann responsives Webdesign (RWD) einen perfekten Kompromiss zwischen technischem Aufwand und Nutzen bieten. Eines der zentralen Merkmale von RWD ist das der gleichbleibenden HTML-Ausgabe auf jedem Gerät, denn es handelt sich im Prinzip immer um dieselbe Webseite. Wie sie dargestellt wird, kann jedes Gerät selbst entscheiden, indem es Elemente wie Container oder Menüs den Gegebenheiten entsprechend anpasst.

Ein Smartphone-Bildschirm bietet längst nicht so viel Platz wie der eines großen Desktop-PCs, was ein Umdenken bei vielen Designern erfordert. Ein mittlerweile weit verbreiteter Ansatz, das Problem zu lösen, ist "Mobile first". Dabei berücksichtigen die Verantwortlichen zuerst, wie sich die Webseite auf den kleineren Geräten verhalten soll, was darzustellen ist und wie der Besucher letztlich durch die Seite navigieren soll. Erst danach optimieren sie die mobile Webseite Schritt für Schritt für die größeren Brüder.

Dieses sogenannte "Progressive Enhancement"-Verfahren kommt bei der Entwicklung sehr häufig zum Einsatz, denn es bringt einige Vorteile mit sich:

• Durch den eingeschränkten Platz (in der Regel bietet ein Smartphone nur etwa 20 Prozent der verfügbaren Fläche eines Desktops), sind die Designer gezwungen, sich auf das Wichtigste zu konzentrieren. Auch auf den kleinsten Geräten sollen die Kerninformationen der Webseite zur Verfügung stehen und vor allem einfach zu finden sein.
• Durch den progressiven Enhancement-Prozess lässt sich sicherstellen, dass Informationen häppchenweise dazukommen und keine unnötige Informationsflut entsteht.
• Es ist einfacher, der Webseite Details hinzuzufügen, als welche zu entfernen. Hat sie einen komplexen Aufbau, gestaltet es sich vergleichsweise schwierig, Elemente zu entfernen, ohne den Desktop leer wirken zu lassen. Elemente zu verstecken, also auf display:none zu setzen, ist zwar einfach, widerspricht allerdings dem Prinzip.

Einmal angenommen, es käme folgende Media Query zum Einsatz, um bei geringen Auflösungen die Inhalte einer Seite untereinander darzustellen:

/* Desktop first - nicht empfohlen! */
.spalte {
    float: left;
    width: 50%;
}

@media all and (max-width: 500px) {
    .spalte {
        float: none;
        width: auto;
    }
}

Der Code hat gleich mehrere Nachteile, denn zum einen ignoriert er die älteren mobilen Browser, die keine Media Queries unterstützen, und zum anderen kann er durch viele Redundanzen schnell komplex werden. Eine elegantere und sauberere Lösung wäre es, von einer mobilen Version auszugehen und für größere Auflösungen Anpassungen vorzunehmen:

@media all and (min-width: 500px) {
    .spalte {
        float: left;
        width: 50%;
    }
}

Dieser Ansatz ist viel kürzer und bleibt beim Hinzufügen weiterer Auflösungen und Erweiterungen vergleichsweise überschaubar.

Unterschiedliche Darstellungen realisieren

Die in CSS3 eingeführten Media Queries bieten eine Vielfalt an Möglichkeiten, Regeln für unterschiedliche Auflösungen zu erstellen. Sie lassen sich sowohl innerhalb der einzelnen Stylesheet-Dateien als auch beim Einbinden dieser einsetzen:

<link rel="stylesheet" type="text/css" href="desktop.css" 
media="screen and (min-width: 768px)" />

Layout

Die wohl am häufigsten verwendete Regel ist die der min- und max-width/height-Angaben. Letztere bestimmen, ab welcher Breite oder Höhe von Browser und Gerät eine CSS-Klasse anzuwenden ist. Es gibt eine Hand voll relativ häufig verwendeter Größen (Breakpoints), die im Internet kursieren. Sie reichen von 320 Pixel für ein Smartphone im Hochformat über 768 Pixel für Tablets und 1024 beziehungsweise 1200 Pixel für Desktops. Natürlich lassen sich noch weitere finden, aber sie stellen in gewisser Hinsicht Richtlinien dar, an die sich viele Webentwickler halten. Es ist ungewiss, wie genau sich die Geräte in Zukunft ändern, aber eines ist sicher: Sie werden, dem 5-Inch-Trend der aktuellen Smartphones folgend, größer und werden vor allem mit einer höheren Pixeldichte ausgestattet sein. Das soll heißen, dass immer mehr Details auf kleinstem Raum Platz finden müssen.

Daraus folgt, dass nicht nur für kleine Geräte zu optimieren ist, sondern auch beispielsweise Bilder für hochauflösende Bildschirme zur Verfügung zu stellen sind. Auch auf Bildschirmen jenseits von FullHD (1920x1080 Pixel) kann eine Webseite schnell einer Miniaturausgabe gleichen.

Relative Größen nutzen

Schritt eins für responsive Webseiten lautet: Abschied von festen Größenangaben nehmen. Pixelangaben sind statisch und helfen bei RWD nicht viel. Jeder Webentwickler hat irgendwann einmal von em gehört, auch wenn diese Angabe oft missverstanden wird. Dabei ist die Formel für die Berechnung ganz einfach:

Ziel / Kontext = Ergebnis

Unter der Annahme, dass der Body einer HTML-Seite eine Schriftgröße von 12 Pixeln hat, sollte das primäre Header-, sprich das H1-Element, 18 Pixel groß sein. Mit den Angaben lässt sich die Formel wie folgt nutzen:

18 (Ziel: H1) / 12 (Kontext: Body) = 1.5em

h1: {
    font-size: 1.5em;
}

Berechnet man die Schriftgröße immer anhand des Eltern-Elements, kann das bei komplexen Webseiten zu unerwünschten Nebeneffekten führen. In CSS3 wurde daher eine etwas veränderte Version eingeführt:rem (Root em). Im Gegensatz zu den bekannten em verhalten sie sich nicht relativ zum Eltern-Element, sondern zum Viewport der Seite. Davon profitieren vor allem tief verschachtelte Elemente. Mittlerweile gibt es eine breite Unterstützung von Seiten der Browser und alternative Lösungen. Vor allem, wenn CSS-Präprozessoren wie LESS zum Einsatz kommen, lässt sich auf der Serverseite die Größe berechnen und in Pixeln kompilieren.

Für Layouts gibt es mittlerweile ähnliche Ansätze, zum Beispiel die Angaben viewport-percentage-length. Sie verhalten sich, wie der Name schon sagt, relativ zum Viewport der Seite. Das heißt, dass 1 vw bei einer Viewport-Breite von 480px gleich 4,8 Pixeln ist. Dasselbe gilt für die Höhe mit vh, während sich vmin und vmax dazu verwenden lassen, um die größere oder kleinere Angabe der Breite oder Höhe zu finden. Vor allem bei Containern, die 100 Prozent der Höhe haben sollen, sind solche Angaben willkommen: Im Moment kann man so einen Fall nur unter Berücksichtigung aller Parent-Elemente ermitteln, was letztlich fast immer einen JavaScript-Hack nötig macht.

Arbeitserleichterung und Aufbau

Vor allem zu Projektbeginn sollten Entwickler überlegen, ob für Aufgaben wie die Unterteilung in ein Box-Modell (um beispielsweise Elemente auf kleinen Geräten untereinander darzustellen), ein Framework geeignet ist. Mittlerweile ist die Auswahl groß und reicht von kleinen Frameworks, die sich auf die Funktion beschränken, CSS-Klassen für ein Grid-Layout bereitzustellen, bis hin zu kompletten Baukästen wie Twitter-Bootstrap. Vorteile der Frameworks liegen unter anderem in der verbesserten Browserkompatibilität, den Lösungen zu allgemeinen CSS-Problemen und der Hilfe, die sie durch standarisierte Klassen bei der Entwicklung im Team bieten.

Da gerade bei responsiven Webseiten die Performance eine große Rolle spielt, kann es auf lange Sicht kontraproduktiv sein, unüberlegt ein "All-inclusive"-Framework einzusetzen. Komplette Frameworks locken mit vielen nützlichen und zeitsparenden Features und erleichtern das Erstellen von Prototypen erheblich. Genau dafür sind sie besonders zu empfehlen. In allen anderen Fällen versucht man jedoch in der Regel, jedes überflüssige Kilobyte einzusparen, sodass Frameworks schnell die erste Adresse zum Reduzieren der Datenmenge sind. Vor dem Einbau sollte daher jeder Entwickler gut überlegen, welche Features er letztlich verwenden möchte, um die Charakteristiken der einzelnen optimal ausnutzen zu können und keine unnötige Last zu erzeugen.

Die oben angesprochenen Grid-Systeme unterteilen das Layout in mehrere Zeilen und Spalten. Das im Twitter-Bootstrap integrierte Grid etwa stellt zwölf Spalten dar, wie es in vielen weiteren Frameworks der Fall ist. Sie lassen sich mit CSS-Klassen (col-md-1 bis col-md-12, md steht für Medium Device) auf Elemente anwenden und wie folgt definieren:

<div class="row">
  <div class="col-md-6">6 Spalten</div>
  <div class="col-md-6">6 Spalten</div>
</div>
<div class="row">
  <div class="col-md-2">2 Spalten</div>
  <div class="col-md-10">10 Spalten</div>
</div>

Das Umsetzen des Verhaltens der Spalten auf unterschiedlichen Geräten ist nun Aufgabe des Frameworks. So sorgt es etwa dafür, dass Spalten, die auf einem Desktop nebeneinander angezeigt werden, sich auf kleinen Devices untereinander schieben. Über das Hinzufügen von CSS-Klassen lässt sich das noch etwas feiner steuern: Mit dem Klassen-Präfix .col-xs (xs steht für Extra Small Devices mit Auflösungen unter 768px) kann man etwa erreichen, dass die Klassen nur für die angegebenen Auflösungen zum Einsatz kommen.

Performance

Fallstricke in Sachen Performance

Eine mobile Seite muss schnell sein, ganz egal wie viele Informationen sie auf dem Desktop anzuzeigen hat. Da die HTML-Datei für alle Geräte gleich ist, ist zu überlegen, was sofort geladen wird und was sich gegebenenfalls nachladen lässt. Vor allem bei mobilen Geräten kann die Größe einer Webseite ein Problem darstellen, wenn man davon ausgeht, dass 2013 die durchschnittliche Größe bei 1,5 MByte lag.

Aber nicht nur die Größe, sondern auch die Anzahl der Anfragen, die für Bilder, Script- und Style-Dateien sowie andere Ressourcen im Hintergrund anfallen, kann von Bedeutung sein. Immerhin leiden vor allem die Besucher mit einer mobilen Verbindung unter hohen Latenzzeiten. Zwar kann der LTE-Standard letztere reduzieren, zur Grundlage darf man ihn trotzdem nicht nehmen. Folgende Optimierungen sollten in der Trickkiste eines jeden Webentwicklers liegen:

• Bilder sollten angepasst sein, denn in den meisten Fällen entpuppen sich die geladenen Grafiken als Performancekiller. Notfalls lässt sich auch eine serverseitige Lösung (Adaptive Images) verwenden, um entsprechende Elemente in einer optimalen Größe auszuliefern. Bei hohen Auflösungen und einer hohen Pixeldichte ist es von Vorteil, die Bilder mit der großen Auflösung nachzuladen.
• Anfragen reduzieren: Wie bereits angedeutet, lädt jedes Gerät alle Ressourcen. Vor allem bei CSS- und JavaScript-Dateien gibt es diesbezüglich einige Stellschrauben. Zum Beispiel helfen CSS-Frameworks wie Compass beim Erstellen eines verständlichen Markup und der Strukturierung großer Projekte. Für JavaScripts helfen Tools wie UglifyJs, den Code minifiziert und optimiert auszuliefern. Wenn klar ist, wie sich der Besucher auf der Webseite bewegt, sollten zudem gewisse Ressourcen vorgeladen werden (pre-fetching).
• Nur laden, was geladen werden muss (conditional loading): Mobile Geräte zeigen dem Besucher viel weniger Bereiche an, als auf der Seite tatsächlich vorhanden sind. Ein klassisches Beispiel dafür sind die Social-Media-Plug-ins von Facebook, Twitter und Google+. Sie laden mehrere JavaScript-, CSS- und Bilddateien und sind in ihrer Summe mehrere Hundert Kilobytes groß, was dem Vielfachen eines großen Frameworks wie Bootstrap entspricht. Das soll nicht heißen, dass man sie auf den mobilen Geräten gar nicht anzeigen soll. Allerdings kann die Anwendung sie etwas später laden, zum Beispiel wenn der Besucher die Plug-ins am Ende der Seite tatsächlich sieht. Vorsicht ist bei dieser Technik im Zusammenhang mit SEO-relevanten Themen geboten, denn die Suchmaschinen berücksichtigen kein Nachladen über JavaScript.

APIs und Browserfeatures gezielt nutzen

"Was ist der Unterschied zwischen einem Desktop-PC und einem Smartphone?". Die meisten werden eine solche Frage mit der Aussage beantworten, dass ein Smartphone kleiner und dazu durch Berührung mit dem Finger kontrollierbar ist. Irrelevant ob diese Antwort aussagekräftig ist, technisch gesehen kann es genau umgekehrt ein Problem sein, denn auf dem Smartphone gibt es keinen Mauszeiger. Die Einschränkung betrifft zum Beispiel die CSS-Klasse :hover, denn es gibt bei mobilen Kleingeräten kein Äquivalent zum entsprechenden Mausverhalten. In Zukunft soll es allerdings eine Media Query pointer geben, die auf die Genauigkeit des jeweiligen Gerätes reagieren soll. Ist der Besucher der Webseite mit einer Maus oder einem Stylus unterwegs, wird die Regel mit "fine" angewendet. Ungenaue Eingaben, wie die Finger-Berührungen auf einem Smartphone-Display, sollte das Angebot als "coarse" erkennen und entsprechend reagieren.

Jedem, der sich über die manchmal viel zu kleinen Buttons auf Webseiten geärgert hat, kann folgende Media Query vielleicht helfen:

@media (pointer:coarse) {
    button {
        min-width: 40px;
        min-height: 30px;
    }
}

Auch für JavaScript soll es bald einen Standard für die Touch-Interaktion geben. Dazu arbeitet die W3C Working Group an einer Spezifikation, die Ereignisse wie touchstart, touchend oder touchmove definiert. Während die Anzahl der Browser, in denen sich Letztere nutzen lassen, noch recht überschaubar ist, können alternative Frameworks wie Hammer.js bei der Umsetzung helfen und bei Nichtunterstützung einen Fallback bieten.

Ein weiterer interessanter Ansatz ist der der Network Information API, um die Geschwindigkeit der Verbindung zu messen. Ein derartiger Standard könnte für Entwickler und damit verbunden für die Performance einen großen Vorteil bringen.

Fazit

Vor- und Nachteile auf einen Blick

Vorteile:

• Vor allem bei der Wartung und Instandhaltung einer Webseite bietet RWD einen großen Vorteil, da nur eine Codebase zu pflegen ist.
• Zukünftige Design oder Feature Updates sind nur einmal zu erledigen.
• Die Releasezyklen werden durch die eben genannten Vorteile verkürzt.
• Es gibt nur eine URL-Struktur (getrennte Webseiten nutzen zum Beispiel eine http://mobile./-Subdomain).
• Auch die Suchmaschinenoptimierung kann profitieren, da es keine mehrfach auf der Seite vorhandenen Inhalte gibt.
• Durch die im Artikel beschriebenen Ansätze von Content und Mobile first sind Designer gezwungen, von Anfang an für mobile Geräte zu entwickeln. Davon können auch Desktops etwa in puncto Performance profitieren.
• Das Progressive-Enhancement-Prinzip stellt sicher, dass die wichtigsten Informationen des Webangebots dem Besucher – egal auf welchem Gerät – immer angezeigt werden.
• Webseiten sollten ihren Nutzern auf jedem Gerät gleiche Erfahrung bieten, was bei einer für sich stehenden mobilen Seite nur selten der Fall ist.
• Designer und Entwickler können die Vorteile der neuen Technologien nutzen (zum Beispiel Standortbestimmung oder andere Sensoren des Mobilgerätes).

Nachteile:

• RWD ist nur eine Anpassung des Designs, denn es gibt nur eine HTML-Ausgabe. Das bedeutet, dass alle Ressourcen auch auf die kleinsten Geräte zuübertragen sind. Hierfür gibt es mittlerweile Ansätze (RESS: Responsive Design + Server Side Components), die durch Mithilfe des Browsers (user-agent) nur bestimmte Elemente rendern, allerdings widerspricht das dem allgemeinen responsiven Trend.
• CSS kann keine Geräte unterscheiden, es gibt also keinen Unterschied zwischen einem Desktop oder beispielsweise einem 55-Zoll-Fernseher.
• Es sind mehr Performance-Optimierungen vorzunehmen.
• Bei der Entwicklung von Seiten und Erweiterungen sind die unterschiedlichen Endgeräte zu bedenken, was zu Mehraufwand führen kann.
• Der Content ist technisch gesehen auf jedem Gerät gleich.

Bevor mit der Konzeption einer responsiven Webseite begonnen wird, ist zu überlegen, ob zuvor nicht andere, wichtigere Teile zu optimieren sind und ob das Team dem technischen Aufwand gewachsen ist. Auch sind die Einschränkungen im Design nicht zu vernachlässigen und es kann manchmal sehr schwer sein, lange Inhalte so aufzubereiten, dass sie sich auch auf kleinen Geräten gut anzeigen lassen. Ist man sich dieser Einschränkungen bewusst, steht einem RWD nichts im Wege.

Fazit

Responsive Webdesign ist nicht nur eine technische Herausforderung, sondern viel mehr eine Entscheidung und ein Prozess, der von allen Entwicklern und Designern zu verinnerlichen ist. Vor allem durch Ansätze wie "Mobile first" lässt sich eine bessere Benutzerfreundlichkeit erlangen und die Webseite gewinnt an Zukunftssicherheit, egal welche Auflösungen sich auf Herstellerseite durchsetzen. Natürlich ist selbst mit den teils sehr hilfreichen Media Queries nicht alles möglich, aber dennoch stellen sie einen großen Schritt nach vorn dar und vor allem einen Kompromiss zwischen Aufwand und Nutzen.

Das im Artikel Behandelte kratzt das Thema eigentlich nur an der Oberfläche an, denn es gehört noch weit mehr zur Entwicklung einer responsiven Webanwendung: Was passiert mit den Navigationen oder mit den Form-Elementen auf den mobilen Geräten? Welche Box-Modelle gibt es? Wie lassen sich Bilder für kleine und sehr große Geräte optimieren? Diese und weitere Informationen folgen im nächsten Teil, der die Praxis des RWD beschreibt.

Roberto Bez
ist passionierter Webentwickler und begeistert von neuen Technologien, die er versucht, in die tägliche Anwendungsentwicklung miteinzubringen. (jul)