Responsive allein reicht nicht mehr, moderne Webseiten müssen auch schnell laden. Wir zeigen, wie wir…
Responsive Performance
Seitdem Ethan Marcotte mit seinem Artikel auf A List Apart 2010 den Begriff “Responsive Design” in die Welt gerufen hat, hat sich in diesem Bereich einiges getan. Ein spezielles Problem von vielen Websites scheint dabei die responsive Performance zu sein: Seitengrößen von mehreren Megabytes sind auf mobilen Devices keine Seltenheit, ebenso wie Ladezeiten von 10 Sekunden und mehr auf 3G.
In diesem Artikel geben wir einen Abriss über die Entwicklung und den aktuellen Stand der Diskussion um Maßnahmen zur Performanceoptimierung, zusammen mit unseren eigenen Erfahrungen, die wir mit diesem Thema bei unseren Responsive-Projekten gemacht haben.
Dieser Beitrag gliedert sich in folgende Abschnitte:
- Welche Bedeutung hat Antwortzeit auf die Mensch-Maschine-Kommunikation aus kognitiver Sicht? Eine Verortung des Themas in der menschlichen Wahrnehmung.
- Danach betrachten wir im Überblick den Verlauf, den die Diskussion in verschiedenen Blog-Artikeln seit 2011 genommen hat.
- In unseren ausführlichen Referenzen findet ihr die von uns zitierten Artikel, Verweise auf Bücher und Tools zusammengefasst.
Die Bedeutung von Performance für die Interaktion aus kognitiver Sicht
Miller hat in seinem Paper bereits 1968 die Bedeutung von Antwortzeiten für die Mensch-Maschine-Kommunikation herausgestrichen und spricht von einer “almost magical boundary” von zwei Sekunden Antwortzeit in der zwischenmenschlichen Kommunikation. Alles, was darüber liegt, sorgt laut Miller für Irritation und Diskontinuität im Antwortfluss; am effizientesten sei eine Antwortzeit von 0.5 Sekunden.
Führen Menschen eine Serie von Aktionen aus, um ein bestimmtes Ziel zu erreichen, steigern Verzögerungen die Fehlerrate, etwa beim Suchen eines Namens in einer Liste. Die Limitation dafür ist das menschliche Kurzzeitgedächtnis, das nur eine begrenzte Kapazität hat, Informationen zu speichern. Das Limit scheint laut Miller hier auch etwa bei zwei Sekunden zu liegen.
Er argumentiert weiter, dass längere Antwortzeiten nur auf einen psychologischen “Abschluss”, wie er es nennt, folgen soll. Ein solcher Abschluss wäre z.B. das Finden des Namens in der Liste.
Sicherlich muss man diese Erkenntnisse im Lichte der damaligen Technologie sehen, aber als Startpunkt für die Diskussion über den Einfluss von Zeit auf die Mensch-Computer-Interaktion sind sie allemal nützlich. Susanne Bodker fügt in ihrem Buch “Through the Interface” Millers Erkenntnisse in ein Framework menschlicher Aktivität ein und ergänzt, dass es schwierig ist, ohne weitere empirische Untersuchung allgemein gültige Regeln für akzeptable Antwortzeiten zu finden, wie Miller das getan hat. Außerdem spielt die Expertise der Nutzer eine große Rolle, welchen Einfluss die Antwortzeiten eines Systems auf das Nutzerverhalten haben.
Trotzdem haben sich hier Faustregeln durchgesetzt, wie zum Beispiel von Cooper und Nielsen. Sie
leiten von Millers Arbeit eine ganz ähnliche Kategorisierung von Antwortzeit-Limits ab:
- (bis zu) 0.1 Sekunden: wird vom User als “sofort” wahrgenommen
- bis zu 1 Sekunde: die Verzögerung wird wahrgenommen, die gedanklichen Prozesse jedoch nicht unterbrochen.
- bis zu 10 Sekunden: das obere Limit, um die Aufmerksamkeit der User auf dem Dialog zu halten, obwohl die Gedanken sehr wahrscheinlich beginnen abzuschweifen. Wird als langsam wahrgenommen.
- Darüber: man verliert die Aufmerksamkeit, die Gedankenprozesse werden unterbrochen. User werden vermutlich andere Prozesse starten.
Man kann also zu Recht sagen, dass die Antwortzeit einen wesentlichen Teil der User Experience, der “Benutzererfahrung” beim Interagieren mit dem System ausmacht.
Responsive Performance: Ein Überblick
Luke Wroblewski schlägt in seinem Blogbeitrag vom September 2011 vor, responsive Design um serverseitige Komponenten zu erweitern, um nur das auszuliefern, was der Client tatsächlich braucht. So können mobile-optimierte Teile gezielt ausgeliefert werden, und andere Komponenten für die Desktop-Variante.
2011 “Performance is a critical component in your user’s experience.”
Guy Podjarny identifiziert in seinem Buchbeitrag vom Juli 2012 auf seinem Blog drei Hauptgründe für die schlechte Performance von responsive Websites: “download and hide”, “download and shrink” und “excess DOM”. Seine Erkenntnisse basieren auf einer Testreihe, in der die Performance von 471 Webseiten in allen Ausprägungen analysiert hat. Als Lösung schlägt er vor, responsive Images zu verwenden, dem “mobile first”-Ansatz zu folgen, und die Performancegewinne auch zu überprüfen.
2012 “On average, 80% of the end-user response time is spent on the front end.”
In seinem Slide-Set vom Dezember 2012 beschreibt Chris Coyier allgemeine Techniken zum Verbessern der Performance. Er betont hier die 80:20-Regel und rät, sich auf die “low hanging fruits” zu fokussieren. Als Maßnahmen nennt er hier Kompression, den Einsatz von Cache, Bildoptimierung und die Kombination von CSS und JS.
2013 “Knowing a few things about how browsers work can really allow us to manipulate it further and make our front-ends even faster.”
Im darauffolgenden Jänner erklärt Harry Roberts in seinem Artikel die Gründe, warum Webseiten schlecht performen. Er geht insbesondere auf das Blocking-Verhalten der Browser-Engines ein, und beschreibt, wie Webseiten so aufgebaut werden können, dass sie den Seitenaufbau so wenig wie möglich blockieren. Weiters erklärt er, wie die Anzahl der DNS-Lookups und HTTP-Requests minimiert werden können, da sie eine weitere Quelle für Verzögerungen sind.
Wie man CSS aus diesem “kritischen Pfad” entfernen kann, führt Stoyan Stefanov in seinem Artikel “CSS and the critical path” vom Juni 2012 weiter aus.
Auf perf.tooling.today gibt es eine umfangreiche Sammlung von node.js-Modulen und grunt-Tasks, unter anderem auch solche, die das kritische CSS identifizieren und herauslösen helfen.
2013 “We’re seeing some fruit of our performance preaching labor, but the vast majority of RWD sites still don’t devote enough attention (or time) to performance.”
Guy Podjarny wiederholte ein Jahr nach dem ersten Durchlauf den Performance-Test für Responsive Websites. In seinem Artikel vom März 2013 beschreibt er die Ergebnisse und stellt fest, dass die durchschnittliche Seitengröße über alle Devices angewachsen war, und dass Maßnahmen zur Performance-Optimierung vermehrt eingesetzt wurden. Doppelt so viele Webseiten lieferten deutlich kleinere Versionen an die kleinste Device-Größe aus wie im Jahr davor. Ein Großteil der Seiten (ca. 70%) lieferten 2013 jedoch immer noch in etwa dieselbe Anzahl an Bytes an die kleinste Device-Größe aus wie an Desktop-Seiten. Dieser Wert sank aber deutlich im Vergleich zum Vorjahr, wo er noch etwa 85% betrug.
2013 “Treat Performance As Design”
Im Juli 2013 folgte Brad Frost mit seinem Artikel und nahm darin Bezug auf die Testreihen von Guy Podjarny. Frost empfiehlt, Performance als Designkomponente zu betrachten, da Performance Teil der User Experience bzw. von Usability ist. Diese Erkenntnis besteht schon seit langem, siehe unter anderem in diesem Beitrag Jakob Nielsen, der Antwortzeiten definiert, die auf seinen empirischen Testdaten basieren und auf Web- und Desktop-Applikationen gleichermaßen anwendbar sind.
Weiters empfiehlt Frost, ein Performance-Budget mit konkreten Zielen zu definieren, Conditional Loading einzusetzen, oft unter realen Bedingungen zu testen, und ebenfalls nach “low hanging fruit” Ausschau zu halten.
2014 “Users want something fast and easy to use. They don’t usually resize the browser, and they don’t even understand what ‘responsive’ means.”
In seinem Artikel schreibt Firtman, dass responsive Webdesign oft als einzige Strategie betrachtet wird und andere Möglichkeiten außer acht gelassen werden. Er plädiert dafür, dass nicht allein die Screen-Größe als Kriterium herangezogen wird, sondern dass man eher auf Feature-Detection setzen sollte, um das passende UI anzubieten. Bei allgemeinen Empfehlungen zur Performance-Optimierung erwähnt er auch die Optimierung für “above-the-fold-content”.
Er interpretiert den Begriff “Responsive” dahingehend, dass es nicht immer die beste Lösung sein muss, dasselbe HTML an unterschiedliche Device-Gruppen auszuliefern, und innerhalb der Gruppen mit responsive-Techniken auf verschiedene Szenarien zu reagieren.
Er argumentiert für einen neuen Architektur-Layer in großen Projekten, um die Vorteile von Server-Erweiterungen nutzen zu können, und schlägt node.js als optimalen Kandidaten vor.
2014 “A more useful benchmark for evaluating page speed from the user’s perspective is the time it takes for a page to become usable.”
Jehl betont die Wichtigkeit der subjektiv wahrgenommenen Performance in seinem Artikel vom Juli 2014. Er schlägt ebenfalls vor, den kritischen Pfad zu optimieren, und die Website so bald als möglich benutzbar zu machen. Als weitere Maßnahmen erwähnt er asynchrone Scripts, um das Blocking-Verhalten von JavaScript zu optimieren, und alles, was zum initialen Rendern gebraucht wird, in den ersten Request in einer Größe von 14KB zu verpacken.
Eine ausführliche und sehr nützliche Ressource sind die PageSpeed Insight Rules auf dem Google Developer Network (seit 2012, wird ständig aktualisiert). Hier werden im Detail die Analyseregeln des Insight-Tools erklärt, das Webseiten auf ihr Performanceverhalten hin analysiert.
Einen guten Überblick gibt auch Ilya Grigorik in seinem Artikel “Optimizing Performance” vom Mai 2014 auf dem Google Developer Network. Er gliedert den Beitrag in zwei Bereiche, “critical rendering path”, und “optimizing content efficiency”. Besonders die Abschnitte über die Hintergründe des Seitenaufbaus und zu Bildoptimierung sind uns hier aufgefallen.
Das Internet-Urgestein Yahoo bietet auf seinem Developer Network seit 2007 die “Best Practices for Speeding Up your Website” an. Die Seiten werden ebenfalls ständig aktualisiert. Interessant, dass sich viele Tipps zur Performance-Optimierung seit damals nicht wesentlich verändert haben: Yahoo empfiehlt schon damals, die Anzahl der HTTP-Requests zu reduzieren, Skripte ans Ende der Seite zu verschieben, die Anzahl der DNS-Lookups zu reduzieren, und andere mehr. In der heutigen Ausprägung der Seite ist die Anzahl der Empfehlungen allerdings von 13 auf 35 in sieben verschiedenen Kategorien angestiegen.
Referenzen, Tools, Ressourcen zum Weiterlesen
Kognitive Grundlagen
Response time in man-computer conversational transactions, Robert B. Miller, Fall Joint Computer Conference, 1968
Response Time: the 3 important limits, Jakob Nielsen, January 1993
Through the Interface: A Human Activity Approach to User Interface Design, Susanne Bodker, 1991
About Face 3: The Essentials of Interaction Design, Alan Cooper, 2007
Blogbeiträge und Artikel
RESS: Responsive Design and Server Side Components Luke Wroblewski, September 2011
Performance implications of responsive design Guy Podjarny, July 2012
Real World RWD Performance Guy Podjarny, March 2013
Let’s Do A Bunch of Simple Stuff to Make Websites Faster Chris Coyier, December 2012
Front-end performance for web designers and front-end developers Harry Roberts, January 2013
Prioritizing Performance in Responsive Design Brad Frost, July 2013
RWD should not be your only strategy Maximiliano Firtman, July 2014
Google Developers: Optimising Performance Ilya Grigorik, May 2014
How we make RWD sites load fast as heck Scott Jehl, July 2014
Google & Yahoo!
Google Developers: PageSpeed Insights Rules Updated 2015
YAHOO Developer Network: Best Practices for Speeding up Your Web Site Updated 2015
Bücher
High Performance Responsive Design: Building Faster Sites Across Devices By Tom Barker, O’Reilly Media, November 2014
Responsible Responsive Design by Scott Jehl, A Book Apart, November 2014
6 Web Performance Books That Every Developer Should Read, Performance Calendar
Tools
YSlow
imageoptim.com
mediaqueri.es
perf.tooling.today
Performance-Messung
Akamai Mobitest
WebPageTest (Desktop)
Schöner Artikel der vielleicht einen leichten Denkstoß dahin gibt, nicht unbedingt seine Website mit 20 Megapixel Grafiken voll zu ballern. Reaktionszeiten sind auch – trotz immer höheren Übertragungsbandbreiten enorm wichtig und sollte auf keinen Fall vernachlässigt werden.
Das finden wir auch — ein gutes Benutzererlebnis setzt auch gute Performance voraus. Niemand wartet länger als ein paar Sekunden auf eine Seite, schon gar nicht auf mobilen Endgeräten!
Guter Artikel. Finde auch, dass die Performance zu oft vernachlässigt wird, auch weil die Sensibiltät für dieses Thema fehlt und entsprechende Optimierung oft ein “Geschenk des Hauses” sein muss wenn man sie in der Entwicklung berücksichtigen will :/ Aber da muss man einfach dran bleiben, es kann nur besser werden!
Danke, Emanuel! Spätestens dann, wenn man zeigen kann, dass sich Performance-Optimierung direkt im User-Verhalten auswirkt, ist es wohl jedem klar, dass sich damit durchaus auch Geld machen lässt. Performance ist eben ein fixer Teil von Benutzbarkeit und User Experience.