In den vorangegangenen Artikeln habe ich die drei Module der Responsive Design Technik erklärt, den Fluid Grid, die Media Queries und das Thema Fluid Images. In der Praxis ist der richtige Umgang mit den Modulen nicht immer ganz einfach. Es gibt ein paar kritische Punkte, mit denen man sich auseinandersetzen sollte.
Wer mit dem Smartphone eine Website aufruft, befindet sich in einer anderen Situation als jemand, der vor einem Desktop Rechner sitzt. Da ist einmal die Verbindungsgeschwindigkeit. Zwischen einer schnellen DSL-Anbindung und einem Funknetzwerk liegen Welten. Das heißt, beim Smartphone zählt jedes Byte, beim Desktop-Rechner in einer DSL-Umgebung sind Ladezeiten kein Thema mehr.
Mit dem Smartphone sucht man zudem nach anderen Informationen als vom Desktop-Rechner aus. Am Schreibtisch hat man die Muße, auch mal einen längeren Texte zu lesen. Hier werden auch die meisten Käufe in Online-Shops abgeschlossen. Am Smartphone kauft man seltener ein, man sucht statt dessen nach ganz bestimmten Informationen. Und möchte schnell zum Punkt kommen.
Die Grundidee hinter Responsive Design ist es, für jede Bildschirmgröße ein passendes Design zu liefern. Auf dem Smartphone-Screen werden nur noch die wichtigsten Elemente der Website gezeigt, Überflüssiges wird weggelassen. Also entwickelt man zuerst die Desktop-Version und speckt das Layout dann Schritt für Schritt ab, bis man beim Smartphone angekommen ist.
Das Problem mit den Ladezeiten
Die Kritik an der Responsive Design Methode setzt meistens bei den Ladezeiten an. Entwickelt man eine Website nämlich „von oben nach unten“, läuft man geradewegs in ein Problem. Denn jedes Element, das man per Media Queries bzw. der CSS-Anweisung display:none ausblendet, wird nach wie vor im Hintergrund geladen.
Das führt zu der Situation, das ausgerechnet das schwächste Gerät in der Nahrungskette, das Smartphone, einen Haufen unbrauchbarer Daten im Hintergrund laden muss.
Für die Bilddaten gibt es Workarounds, die dafür sorgen, dass die Bilder in unterschiedlichen Größen vorgehalten werden können. Wie das geht, habe ich im vierten Teil dieser Artikelserie erklärt.
Aber auch Javascripts kosten auf die Ladezeit. Bei der Entwicklung von Themes sollte man darauf achten, dass nicht jedes Script auf jeder Seite zu jeder Zeit geladen wird. Das ist zwar einfach (alle Scripts in werden in den head-Bereich gepackt), aber die Performance geht in die Knie. Nicht nur die auf dem Smartphone.
Die Lösung: Mobile First
Die Antwort ist so genial wie einfach: Man fängt einfach am anderen Ende an.
Statt die Website von der Desktop-Version abwärts kleinzuschrumpfen, beginnt man mit der mobilen Version. Die Media Queries rufen dann alle weiteren Geräte von hier aus auf. Das hat den Vorteil, dass auch Smartphones, die Media Queries noch nicht unterstützen, die mobile Version darstellen können.
Kein Stylesheet ist das erste Stylesheet (Bryan Rieger)
Man braucht dann zwar Extra-Stylesheets für ältere Desktop-Browser, die Media Queries nicht lesen können. Aber um die kommt man so oder so nicht herum.
Lieber eine Mobile App?
Oft hört man das Argument, das eine Mobile App die bessere Lösung sei. Aber es kommt darauf an, wie die Website aufgebaut ist und was sie leisten soll.
Die typische Website eines mittelständischen Unternehmens, ein Blog, das Portfolio eines Freiberuflers sind perfekte Kandidaten für ein Responsive Design. Die Website ist damit gut gerüstet für die Nutzung mit mobilen Geräten.
Für einen Shop, ein Buchungsportal oder für den Auftritt eines Großunternehmens sind die Bedingungen anders. Hier kommt es darauf an, die spezifischen Möglichkeiten der Smartphones auszunutzen und da ist es mit einer reinen oft Layout-Anpassung nicht getan.
Was sind Eure Erfahrungen? Habt Ihr schon Responsive-Design Projekte realisiert? Auf welche Probleme seid Ihr gestoßen?