13. Dezember 2013
Legales Doping für Responsive Websites.
Immer wieder treffe ich auf Websites, deren Layout sich zwar flexibel an die Grösse des Endgeräts anpasst, die aber in Sachen Ladezeiten ganz und gar nicht für mobile Geräte optimiert wurden. Mit ein paar Tricks lässt sich die Performance einer Website deutlich steigern. Denn erst eine Website, die via Mobilnetz schnell lädt, ist wirklich «responsive».
Fünf Real World Beispiele von (responsive) Startseiten von Schweizer Web- und Grafikagenturen:
- 60 Requests, 7.6 MB, 11.5 Sekunden Ladezeit via 3G Netz
- 67 Requests, 2.5 MB, 8.9 Sekunden Ladezeit via 3G Netz
- 70 Requests, 3.1 MB, 9.5 Sekunden Ladezeit via 3G Netz
- 144 Requests, 3,8 MB, 11.5 Sekunden Ladezeit via 3G Netz
- 168 Requests, 22.9 MB, 1.4 Minuten Ladezeit via 3G Netz
Bei allen Beispielen sind die Ladezeiten doch sehr hoch und nicht wirklich mobile-friendly.
Im Netz finden sich zahlreiche Artikel, wie man die Performance einer Website optimieren kann. Da die Wichtigkeit der Ladezeit-Optimierung nicht oft genug wiederholt werden kann, mache ich es auch nochmals:
Dateigrössen reduzieren
Klingt banal, ist es auch und wird trotzdem zu wenig konsequent gemacht.
- gzip via .htaccess auf dem Server aktivieren. Dann werden HTML, CSS und JavaScript komprimiert über die Leitung und den Äther geschickt. Es wirkt Wunder. Siehe HTML5 Boilerplate .htacces, ab Zeile 467
- JavaScript und CSS via Minification komprimieren. Dem Browser ist es egal wie schön CSS und JavaScript geschrieben sind. Mit Minification werden alle Leerschläge, Zeilenumbrüche und auch Kommentare entfernt und somit wird die Datei leichter. Manuell via Browser oder via Text-Editor-Plugin (Sublime, Brackets / Edge Code und sogar Dreamweaver...)
Und wer SASS oder LESS nutzt, kann die Komprimierung im generierten CSS-File sowieso aktivieren (z.B. via CodeKit oder Grunt für alle, die das Terminal lieben). - Das Gewicht von Grafiken und Bildern lässt sich mit Tools wie ImageOptim spielend leicht reduzieren. Ein absolutes Muss. Ein aus Photoshop exportiertes PNG wird so schnell mal 60% leichter.
Anzahl Datei-Requests tief halten
Jede Netzwerkanfrage benötigt für DNS-Anfrage und die Anfrage beim Server Zeit, darum sollten die Anzahl an Datei-Requests tief gehalten werden.
- Nur laden, was wirklich nötig ist zum ersten: Müssen es wirklich 10 Bilder sein oder reichen auch 9?
- Nur laden, was wirklich nötig ist zum zweiten: Inhalte auf kleinen Bildschirmen nicht via display: none; ausblenden, sondern nur für grosse Screens laden. MatchMedia (z.B. mit Hilfe des Enquire Scripts) oder Serverside-Detection (z.B. via MobileDetect) nutzen.
- JavaScript und CSS-Dateien in möglichst wenigen Dateien zusammenfassen. Mit der Pluginbasierten Architektur ist insbesondere WordPress in diesem Bereich ein Sünder.
- Layout-Grafiken in einem Sprite zusammenfassen. Mehr dazu in einem älteren, aber noch immer hochaktuellen Artikel auf CSS Tricks.
JavaScript ans Ende des HTML Dokuments
JavaScript im Head blockiert das Laden und Rendering der nachfolgenden Inhalte. Darum nur JavaScript, das zwingend in den Head muss, auch im Head platzieren. Die Feature-Detection-Library Modernizr ist so ein Kandidat.
Cache
Extrem nützlich ist es zu definieren, wie lange Dateien im Browsercache gespeichert werden sollen. Damit erreicht man, dass Dateien beim Laden einer zweiten Seite aus dem Cache und nicht vom Server geladen werden. Dies wird ebenfalls via .htaccess definiert.
HTML5Boilerplate .htaccess, ab Zeile 537
Speedtests nutzen
Sehr hilfreich sind Speedtests. Ich nutze vor allem Google PageSpeed Insights und Y-Slow. Beide Services analysieren Websites und geben Tipps, wo und wie man eine Website optimieren kann.
Auch Millisekunden haben einen Effekt
Und für diejenigen, die auch gegenüber den Business-Leuten Argumente benötigen:
Bereits im Jahre 2006 veröffentlichte Amazon eine Studie (Powerpoint-Datei), dass für jede Erhöhung der Ladezeit um 100ms die Verkäufe um 1% zurückgingen.
Auch Google hatte 2010 in einem Blogpost angekündigt, dass sie die Ladezeiten einer Website in ihren Suchresultaten berücksichtigen würden. Noch ist aber nicht wirklich bekannt, ob dies bereits zum tragen kommt und wie gross der Effekt ist / sein wird.
Dranbleiben
Ich bin noch keiner Website begegnet, die bei einem Speed-Test das Punktemaximum erreicht hat. Auch Google selbst kommt im eigenen Speed-Test noch nicht auf 100 Punkte.
Da immer mehr Personen mit ihren Mobile-Devices surfen, wird Doping für Websites immer wichtiger. Die Performance einer Website sollte in jedem Projekt die nötige Aufmerksamkeit erhalten und alle Beteiligten (Designer, Entwickler und auch die Auftraggeber selbst) sollten die Ladezeiten einer Website als essentiell betrachten.
Längst nicht immer habe ich in der Vergangenheit bei meinen Projekten das Optimum herausgeholt. Bei aktuellen Projekten versuche ich aber die beschriebenen Dopingmittel einzusetzen. Und ich empfehle es allen gleich zu tun, damit das Web schneller wird.
Links
Wer sich für das Thema «Website Doping» interessiert, findet nachfolgend noch ein paar Links, die das Thema noch etwas vertiefter behandeln.
- Brad Frost: «Performance as Design»
- CSS Wizardry: «Front-end performance for web designers and front-end developers»
- Smashing Magazine: «Build fast loading mobile websites»
- Smashing Magazine: «Perfomance Optimization for Websites»
- A List Apart: «Improving UX Through Front-End Performance»