Vom Tabellenlayout über RWD (Responsive Web Design) zu AWD (Adaptive Web Design)

Hinweis:
Dieser Artikel ist älter als 18 Monate / wurde seit 18 Monaten nicht aktualisiert. Dies kann (muss aber nicht) dazu führen, dass der Artikel, und / oder darin beschriebene Techniken, nicht mehr aktuell sind. Bitte berücksichtigen Sie diesen Hinweis bei der Lektüre.

tl;dr: Responsives Web Design (RWD) alleine reicht in Zeiten der mobilen Internet-Nutzung nicht aus.

Geschichtliches gefällig?

Mein erster Kontakt mit dem Internet erfolgte per 56-kbit/s-Telefonmodem (oder war es gar noch ein Akustikkoppler?). Das muss so um das Jahr 1995 gewesen sein. Die heutigen Digital Natives können sich vermutlich nicht vorstellen, was 56 kbit/s bedeutet (oder etwa doch? Wozu gibt es schließlich Mobilfunk und Edge?). Eine Webseite, die nur Text beinhaltete, baute sich zeilenweise im Verlauf von Minuten auf. Grafik auf Webseiten war zwar damals technisch schon möglich, aber Grafiken, die keinen Inhalt transportierten, also Schmuckgrafiken, zu verwenden, verbot sich unter solchen Umständen.

Gut, ganz so aussichtslos war die Situation auch damals nicht. Wenig später konnte ich an einem Pilotprojekt "Internet via TV-Kabel" teilnehmen. Wow! Der Speed war vergleichbar mit DSL, das Internet machte Spaß!

Das Medium Internet hat mich schnell gefesselt. Und bald wollte ich wissen, wie man so eine Webseite selbst erstellt. Nach kurzer Recherche — nein, nicht via Google; Google gab es 1995 noch gar nicht! AltaVista war angesagt — fand ich ein Programm namens FrontPage auf meiner Festplatte. Damit konnte man tatsächlich eine Webseite erstellen. Mir fiel allerdings auf, dass Änderungen an fertigen Seiten das Layout immer mehr zerschossen. Ich wollte der Ursache auf den Grund gehen. Bald entdeckte ich, dass Webseiten auch nur Textdateien sind. Halt mit einigen speziellen "Befehlen" angereichert. (Ja, ich weiß, HTML kennt keine Befehle; sei's drum.) Diese "Befehle" haben meine Neugier geweckt. Und tatsächlich, FrontPage war gar nicht nötig, um Webseiten zu erstellen. Ein beliebiger Texteditor, und das Wissen um einige wenige "Befehle" genügen.

Ich lernte HTML.

Natürlich sollten auch meine mit dem Texteditor erstellten Seiten ein ansprechendes Layout aufweisen. Das Mittel der Wahl war damals — bei FrontPage konnte ich das ja abgucken — Layouten mittels Tabellen. Dieses sogenannte Tabellenlayout war vom Printlayout inspiriert. Jedes Element wurde pixelgenau platziert. Ein wichtiges Hilfsmittel dazu war auch das sogenannte Null-Gif. Eine transparente Grafik von 1 x 1 Pixel Größe.

Diskussionen um Webdesign drehten sich damals vorwiegend um die Frage, ob man (noch) für 800 x 600 oder bereits für 1024 x 768 Monitore produziert.

Dass Layout für feste Seitenabmessungen aus der Print-Welt stammt, und dem Web nicht angemessen ist, und Tabellenlayout einen Mißbrauch darstellt (Tabellen dienen der übersichtlichen Darstellung von Daten!), ahnte ich, als ich erstmals von CSS hörte.

CSS

trennt das Layout vom Inhalt. Meine Probleme mit ständig zerschossenem (Tabellen-)Layout hatten ein Ende. Erst Jahre später entdeckte ich, dass es so etwas wie Barrierefreiheit auch für Webseiten gibt. Und wie elegant die Trennung von Layout und Inhalt mittels CSS Barrierefreiheit unterstützt. (Dass zu barrierefreien Webseiten mehr als das gehört, ist nicht Thema dieses Artikels.)

CSS ermöglicht beispielsweise Angaben, um die Lesbarkeit von Texten zu optimieren: Vorder- und Hintergrundfarben, Schriftarten und -größe, aber auch Zeilenabstände und sogar minimale und maximale Zeilenlänge konnten vorgegeben werden. Mit CSS hielt Flexibilität Einzug. Prozentuale Größenangaben, oder CSS-Angaben wie min-width und max-width, machten Schluss mit der fruchtlosen Diskussion um Monitorgrößen. Das Design konnte sich der jeweiligen Monitorgröße (genauer: Viewportgröße) anpassen.

Damit, und mit weiteren, fortgeschrittenen CSS-Techniken, z. b. float und position kann man schon recht flexibel layouten, und eine große Bandbreite von Monitorgrößen abdecken.

Mobile Nutzung auf dem Vormarsch.
Hier: webdesign.weisshart.de.
Desktop: 67,6 %
Mobile: 25,7 %
Tablet: 6,7 %

Erst mit der Verbreitung von Smartphones stieß man mit reinen CSS-Techniken wieder an eine Grenze. Die kleinen Monitore von Smartphones erzwingen ein neues Denken über die "richtige" Anordnung von Seitenelementen. Aus mehrspaltigem Layout muss unterhalb einer minimalen Monitorgröße ein einspaltiges Layout werden. Seitenelemente wie Header, Navigation, oder Footer, die auf größeren Monitoren gerne auch feste (fixed) Positionen einnehmen, dürfen das auf Smartphones natürlich keinesfalls, weil fixierte Elemente keinen Platz für die eigentlichen Inhalte mehr freilassen würden. Bilder müssen eventuell durch Ausschnitte der Originalbilder ersetzt werden, weil der Inhalt des Originalbildes auf dem kleinen Monitor anders nicht mehr erkennbar wäre. Der Einsatz von Schmuckgrafiken muss eventuell reduziert, Schriften vielleicht größer dargestellt werden.

RWD

Diese oben genannten grundsätzlichen Anforderungen an das RWD (Responsive Web Design) können mittels Media Queries umgesetzt werden, die es seit CSS3 gibt. CSS3, und damit Media Queries, werden von allen modernen Browsern unterstützt. Media Queries erfordern kein Browser Sniffing und keine Browserweichen, sondern werden als Bereiche innerhalb ein und derselben CSS-Datei definiert. Entscheidend ist dabei das Konzept der Breakpoints. Breakpoints entscheiden, unter- bzw. oberhalb welcher Monitorabmessungen bestimmte CSS Regeln gelten. Häufig wird auch JavaScript zur Unterstützung von RWD eingesetzt. Beispielsweise, um Navigationsmenüs je nach Monitorgröße unterschiedlich darzustellen, oder gar erst nach einem Mausklick zu öffnen.

RWD sorgt also dafür, dass Webseiten auf allen Monitoren ansprechend angezeigt und vernünftig benutzt werden können, von winzigen Smartphones, bis zu riesigen Desktop-Monitoren.

RWD ist heute weitestgehend Stand der Technik, und wird auf zahlreichen Websites eingesetzt. Leider jedoch "vergessen" die meisten Webworker einen wichtigen Aspekt: Die Beschränkung der verfügbaren Bandbreite und des Transfervolumens im mobilen Bereich. Seiten mit 1 bis 2 MB "Gewicht" sind heute leider üblich, 3 und sogar 6 MB nicht selten. Wenn ich mit meinem Smartphone kein LTE oder wenigstens 3G habe, sind solche Seiten eine Zumutung, egal wie "schön" das (responsive) Design ist. Und selbst wenn LTE bzw. 3G verfügbar ist, bezeichne ich solche Seiten als rücksichtslos. Mein mobiles Datenvolumen wird mit mehreren MB belastet, obwohl RWD viele Inhalte "unsichtbar" oder unbenutzbar, und damit unnütz und überflüssig gemacht hat.

Man muss sich also Gedanken machen, was auf den kleinen Smartphone-Monitoren angezeigt, was weggelassen werden kann oder muss. Auch der lange Zeit verpönte Begriff "above the fold" gewinnt eine ganz neue Bedeutung. Was muss, was muss nicht auf den kleinen Monitoren ohne Scrollen sofort sichtbar sein? Siehe dazu auch LazyLoad weiter unten.

Vielleicht macht es Sinn, das Konzept an einem Beispiel zu erläutern:

Der Header mit dem Namen der Webpräsenz ist mit einer Slideshow aus 4 zufällig ausgewählten Bildern hinterlegt.
Das Navigationsmenü wird komplett angezeigt.
Das Bild mit der Ansicht des Objekts ist ebenfalls als Slideshow (3 wechselnde Bilder) ausgeführt.

Die beiden Slideshows wurden durch entsprechend kleine, statische Bilder ersetzt.
Das Menü wurde als Klappmenü ("Hamburger Menü") ausgeführt.
Auf der Desktop-Ansicht ausgeblendet, für Smartphones jedoch an prominenter Stelle: Die Anschrift, sowie 4 Buttons, die eine ggf. auf dem Smartphone installierte Navigationsapp aufrufen.

Jenseits von RWD

Was für Monitorgrößen gilt — es gibt nichts, was es nicht gibt — gilt auch für Bandbreite und Datenvolumen. Von GSM / Edge (maximal 384 kbit/s, häufig jedoch deutlich darunter, je nach aktueller Auslastung des Netzes) bis VDSL mit 50 MB/s und mehr kann die verfügbare Bandbreite betragen. Dazu kommt, je nach Mobilfunk-Datentarif eine Begrenzung des monatlichen Datenvolumens. 200 oder 500 MB pro Monat sind übliche Werte. Sparsamer Umgang mit der Dateigröße von Webseiten ist also unumgänglich, wenn RWD Sinn machen und nicht nur eine "Schönwetterveranstaltung" für Smartphones im (heimischen?) WLAN sein soll.

AWD = RWD + Conditional Loading

Um den mobilen Geräten wirklich nur das auszuliefern, was sie auch benötigen / anzeigen, sind weitere Techniken erforderlich, die ich unter dem Begriff AWD (Adaptive Web Design) zusammenfassen möchte. (Der Begriff AWD ist leider nicht etabliert, und wird sehr kontrovers definiert. Am ehesten noch würde ich folgende Definition teilen: www.sitepoint.com)

Zuerst und vor allem gilt dies für Bilder. Keinesfalls dürfen Bilder einfach vom Browser oder mittels CSS auf das passende (kleine) Anzeigeformat heruntergerechnet werden. Vielmehr muss Sorge getragen werden, dass die Bilder bereits in der passenden Größe (und damit Dateigröße) vom Server geliefert werden.

Eine vielleicht sogar seitenfüllende Slideshow etwa, die auf dem Smartphone (zurecht) nicht angezeigt wird (per Media Queries), darf gar nicht erst übertragen werden. Das gilt für die einzelnen Bilder, aber eventuell auch für das einige hundert kB schwere Script, das die Slideshow erzeugt. Glücklicherweise ist so etwas durch Abfrage des User Agents recht zuverlässig realisierbar: detectmobilebrowsers.com liefert fertige Scripts zur Abfrage des User Agents.

Anmerkung:

Ja, ich weiß, die Abfrage des User Agents ist unzuverlässig, weil der User Agent eventuell nicht übertragen wird, oder manupuliert werden kann. Beides ist im Falle von Smartphones allerdings recht unwahrscheinlich.
Zum anderen: Die Logik des Conditional Loading auf Basis des User Angents muss immer so angelegt werden, dass alle Inhalte angezeigt werden, falls der User Agent nicht erkannt wird.

Elemente von Webseiten, und was ist für AWD im Einzelnen zu beachten:

• Text:
  bricht der Browser um. Es ist also kein zusätzlicher Aufwand bei der Erstellung der Seiten erforderlich.
  Auf kleinen Monitoren macht darüber hinaus Silbentrennung Sinn, um keinen Platz am Ende der — ohnehin kurzen — Zeilen zu verschenken. Obwohl hyphens (automatische Silbentrennung) derzeit nur in einigen Browsern, und nur mit Vendor-Prefix funktioniert.
• Schriften:
  Embedded Fonts sind in der Regel 20 bis 40 kB schwer. Mit Media Queries kann man diese Fonts für kleine Monitore durch Systemschriftarten ersetzten, und einige kB einsparen.
  iosfonts.com zeigt, welche Systemschriften auf iOS verfügbar sind.
• Bilder:
  • Einfachster Fall, nur relativ kleine Grafiken: Abmessungen nicht im HTML hart kodieren, sondern per CSS mit max-width:100% o.Ä. auszeichnen. Damit laufen Bilder jedenfalls nicht aus dem Viewport.
  • Es gibt Techniken, um die Abmessungen von Bildern mehr oder weniger automatisch zu skalieren.
    • Adaptive Images
    • <picture>
  • Lightbox und ähnliche Techniken:
    Alle Techniken basieren darauf, erst einmal eine kleine Grafik (Thumbnail / Vorschau) anzuzeigen, und setzen auf diese Vorschau einen Link auf eine große Grafik. Die Anzeige dieser großen Grafik macht auf Smartphones natürlich keinen Sinn. Also darf man auch den Link nicht setzen, um ein versehentliches Laden der großen Grafik zu vermeiden. Realisierbar ist dies leider nur mit zwei Code-Alternativen, die abhängig vom abgefragten User-Agent ausgeliefert werden. Sinnvoll ist darüber hinaus, auch das für die Lightbox erforderliche JavaScript gar nicht erst auszuliefern, wenn es ohnehin nicht benötigt wird.
  • Gleiches gilt für Slideshows, Rotation von Hintergrundgrafiken und ähnliches. Es muss vermieden werden, dass nicht angezeigte Elemente heruntergeladen werden.
  • LazyLoad: wenn viele Bilder auf einer Seite gezeigt werden, z. B. Fotogalerien oder Shops. LazyLoad reduziert zwar nicht das Datenvolumen insgesamt, lädt aber Bilder dynamisch erst dann, wenn sie gebraucht werden, also (durch Scrollen) in den Viewport kommen.
• Listen sollten für RWD kein größeres Problem darstellen.
• Formulare:
  Formulare dürften im mobilen Web zu den am häufigsten vorkommenden Elementen gehören. Es muss ja nicht gleich der große Webshop sein. Auch ein simples Kontaktformular muss auf allen Geräten zuverlässig funktionieren.
  Im einfachsten Fall genügt es, Formularelemente mittels CSS max-width entsprechend auszuzeichen, um sicher zu stellen, dass das Formular auch auf Smartphones komfortabel ausgefüllt werden kann. Vor allem komplexere Formulare mit vielen Elementen müssen aber mittels Media Queries an kleine Monitore angepasst werden.
• Tabellen - eine Herausforderung für RWD.
• Videos: für kleine Monitore muss eine eigene Version mit entsprechend kleinen Abmessungen und geringer Dateigröße erstellt werden, damit auch im Mobilfunknetz Streaming möglich wird. Die Entscheidung über die Auswahl des "passenden" Videos erfolgt wieder per Abfrage des User Agents.

Das Ergebnis von AWD in der Praxis:

webpagetest.org ist ein geniales Online-Tool, um das "Gewicht" von Webseiten zu analysieren und zu optimieren.
Beispiel: Diese Seite "wiegt" auf dem Desktop 241 kB, auf dem Smartphone nur noch 121 kB

Ja, ich weiß, von 241 kB auf 121 kB klingt nicht berauschend. Ich bin aber überzeugt, dass bei konsequenter Anwendung der beschriebenen Techniken sich eine Seite von 1 oder 2 MB Gewicht auf wenige hundert kB "eindampfen" lässt. Und das hat dann schon einen spürbaren Effekt, wenn man mobil surft.

Weiterführender Lesestoff

• PC Magazin: Mehr Performance fürs Responsive Webdesign
• Chris Heilmann: Conditional loading of resources with mediaqueries
• Nett: Teste selbst, ob deine Website mobile-friendly ist. (by Google). Die Dateigröße wird bei diesem Test leider nicht bewertet!?

Artikeltexte und Code-Snippets: Creative Commons CC BY-SA 4.0
Medien (Bilder, Videos, Audios) sind evtl. urheberrechtlich geschützt.

1. Fabian schrieb am Dienstag, 25.11.14 18:49 Uhr:

   habe auch schon mal den Ausdruck RESS (Responsive Webdesign with Server Side components) gelesen für die hier beschriebene Vorgehensweise.

2. Fritz schrieb am Freitag, 06.03.15 15:46 Uhr:

   @Peter

   Interessant ist insbesondere die Tatsache, dass Patrick Lobacher zwar über Responsive Web Design schwafelt, aber die eigene Unternehmenswebsite www.pluswerk.ag wird mit 1,5 MB sowohl an Desktops als auch an Smartphones ausgeliefert.
   Einer mehr in der Sammlung, der mit Schlagworten seine Produkte verkauft, aber nicht wirklich verstanden hat, wofür RWD.
   

3. Peter schrieb am Freitag, 06.03.15 16:26 Uhr:

   @Fritz
   Vielen Dank für die Analyse. Ich denke die Seite wird zum nächsten Relaunch entsprechend ausgestattet werden.
   Was sagen Sie denn zu unserer Seite http://www.andersundsehr.com mit RWD? Diese gehört zur Pluswerk AG.