Wie kann das sein? Nun, jeder Versandhändler verliert pro 15 Mio € Umsatz 1 Mio €, wenn sein Shop 1 Sek. länger lädt. Studien zu diesem Thema zeigen:
1 Sek Ladezeit = bis zu 7% weniger Kaufabschlüsse
Obwohl dieses Thema eigentlich nichts neues ist, ein Rundumblick zeigt: Da liegt noch viel im Argen. Dabei geht es ganz einfach. In dieser Artikelserie werde ich auf die einzelnen Optimierungshebel im Detail eingehen und zeigen, wie leicht sich die Ladezeit verbessern lässt. Übrigens hat die Ladezeit nicht nur Einfluss auf Conversion Rate sondern auch auf das Suchmaschinen-Ranking.
Was hat sich in den letzten Jahren zum Thema Performance Optimierung geändert?
Auf den ersten Blick, nicht viel. Zumindest was die Techniken angeht, um mehr Geschwindigkeit aus den Frontends der Shops und Websites heraus zu holen. Zwei Dinge haben sich allerdings in der Zwischenzeit sehr wohl geändert:
1.) Die Browser können mehr
Es gibt einerseits weniger “alte” Browser welche technologiebedingte Engpässe haben. Andererseits können die aktuellen Browser deutlich mehr (z. B. HTML5, CSS3), sind per se schneller (Parallelisierung) und brauchen daher weniger “Kniffe”.
2.) Es gibt mehr (unterschiedliche) Endgeräte
Durch mobile Endgeräte und Tablets, hat sich hier – und wird sich sehr wahrscheinlich in Zukunft – die Anzahl der Plattformen erhöht. Demnach spielen unterschiedliche Auflösungen mit erhöhtem Pixel-Verhältnis (Stichwort: Retina-Display), Fähigkeiten der Plattformen, Geräte- und Empfangsabhängige Geschwindigkeit (z. B. GPRS vs. LTE) eine Rolle.
Kommt uns die erste Veränderung bei der Performance Optimierung noch entgegen, stellt die zweite allerdings eine Herausforderung dar.
Mit Blick auf diese Veränderungen: Wie sollte eine Performance Optimierung 2013, gerade in Puncto Responsive Websites, ausschauen?
Hebel Nr. 1: Reduktion
An dieser Vorgehensweise hat sich in den letzten Jahren nicht viel geändert. Auch wenn die aktuellen Browser deutlich mehr Dateien (sog. Assets) parallel laden können, ist weniger Datenvolumen besser. Obwohl dies zumindest bei Desktop oder mobilen Endgeräten über HSPA oder LTE nicht besonders auffällt.
Aber gerade mit Blick auf langsame Internetverbindungen spielt die Anzahl, Größe und Art der zu ladenden Dateien eine Rolle. Hier entsteht durch die verschiedenen Endgeräte und empfangsbedingten Bandbreiten eine Kluft. Auf der einen Seite sind in Urbanen Gebieten die Geschwindigkeiten über VDSL, Kabel oder LTE jenseits der 50 MBit/s (51.200 Kbit/s), auf der anderen Seite bestehen gerade auf eher ländlichen Gebieten gerade mal mit ISDN, DSL Lite, GPRS oder Edge Bandbreiten um die 300 Kbit/s.
Hier sind 7 konkrete Tipps um mit Reduktion die Performance dramatisch zu verbessern:
1. Weniger Dateien ausliefern
Zu viele Dateien – Mehrere CSS-, JavaScript- und Grafikdateien
Es sollten stets möglichst wenige Dateien ausgeliefert werden, also das CSS und JavaScript in so wenig Dateien wie möglich zusammengefasst werden. Der Code sollte sauber sein, Redundanzen sind zu vermeiden. Sowohl CSS als auch JavaScript sollte stets in externen Dateien zusammengefasst werden (nicht im Quellcode der Seite), damit diese im Cache (Zwischenspeicher des Browsers) abgelegt und nur einmalig geladen werden müssen.
Tipp:Die meisten Shop-, CMS- oder Blogg-Systeme bieten Plugins oder Module, um die Dateien automatisiert zusammenzufassen. In der Regel geht dies direkt mit einer Minimierung einher (dazu im nächsten Artikel mehr). Ist kein Plugin vorhanden, so kann dies auch manuell erfolgen. Dabei ist zu beachten, dass das CSS möglichst im <head> der Seite, das JavaScript möglichst vor dem schließenden </body>-Tag einzufügen ist. Jeweils in einer einzigen Datei. Sofern das JavaScript die Aufgabe hat, Inhalte zu liefern oder zu manipulieren (z. B. Testing), sollte das betreffende Script und ggf. die Bibliothek(en) ausgelagert und im <head> geladen werden.
2. CSS verwenden
Beispiel für einen mit CSS3 erzeugten Button (Links CSS3, Mitte Grafik, Rechts IE < 9)
Was Grafikdateien betrifft, insbesondere Layoutgrafiken: Hier sollte soweit es geht auf CSS3 zurückgegriffen werden. Die meisten Designfeatures wie runde Ecken, Schatten, Verläufe usw. lassen sich alle über CSS generieren. Hier rendert der Browser das Layout deutlich schneller als die dazu benötigten Grafiken geladen werden können. Außerdem werden diese Inhalte auch auf hochauflösenden Displays (z. B. Retinas) scharf und unverpixelt dargestellt (Vektorbasierte Ausgabe).
Der Kompromiss an dieser Stelle:Ältere Browser wie beispielsweise Internet Explorer < 9 stellen diese Features nicht dar. Hier kann, sofern ein 100% identisches Look and Feel gewünscht ist, als Fallback auf Grafiken für die älteren Geräte zurückgegriffen werden. Ob der Aufwand tatsächlich notwendig ist, entscheidet ein Blick in die Webanalyse und letztlich die Unternehmenspolitik.
Tipp:Ist man in CSS3 noch nicht besonders fit, bieten sich CSS3-Generatoren wie css3generator.com oder ColorZilla Gradient an.
3. Klassische Sprite
Was die Anzahl Layoutgrafiken angeht, die sich nicht generieren lassen. Hier gab es bisher die Wunderwaffe Sprite. Diese etwas unzeitgemäße Vorgehensweise, noch aus der frühen Computerspiel-Entwicklung stammend, fasst mehrere Grafiken in einer (oder wenigen) Datei(en) zusammen. Somit wird für mehrere Elemente eine Grafik geladen und der sichtbare Bereich dieser Grafik je nach Bedarf verschoben (sog. Clipping). Hier am Beispiel der Sprite.
Der Vorteil:
Nur eine Datei muss geladen werden. Auch diese lässt sich sehr gut im Cache ablegen und muss daher nur einmal geladen werden.
Diese Vorgehensweise ist etwas unzeitgemäß, weil sich diese Grafiken nicht (ohne Verluste) skalieren lassen und daher für das immer breiter werdende Spektrum an verschiedenen Endgeräten, Auflösungen und Geschwindigkeiten zu starr ist.
Um also für verschiedene Geräte und Auflösungen stets Sprites in der richtigen Auflösung anbieten zu können, würde es unterschiedliche Sprites benötigen. Der Aufwand hierfür ist recht hoch, zumal es nicht nur mehrere Sprites sondern auch CSS-Anpassungen mit sich bringen würde.
Tipp:Sprites lassen sich manuell mit einem Grafikprogramm zusammenstellen, wobei allerdings auch das entsprechende Positionieren im CSS manuell erfolgen muss. Einfacher geht es mit Generatoren wie beispielsweise dem von Toptal.
4. Vektorbasierte Grafiken
Bei der Verwendung von (pixelbasierten) Sprites besteht auf den Punkt gebracht also ein Nachteil: Sie sind nicht variabel genug. Die Lösung besteht also hier in vektorbasierten Grafiken. Selbst ältere Internet Explorer Modelle sind bereits dazu in der Lage, SVG (Scalable Vector Graphics) zu interpretieren. Anstatt also das Endprodukt, eine Pixelgrafik zu laden, lassen wir den Browser die Grafik selbst rendern.
Der Vorteil:
Die Grafiken sind meistens deutlich kleiner, weil nur auf mathematischen Formeln basierend und praktisch unendlich skalierbar.
Auf Sprites zu verzichten und stattdessen jetzt SVG-Grafiken zu laden, ist allerdings nicht der Weisheit letzter Schluss. Wir wären wieder am Anfang, bloß mit kleineren, skaliebaren aber zu vielen Grafiken angekommen.
Tipp:
Eine SVG-Grafik lässt sich in der Regel direkt über das Vektorgrafikprogramm exportieren.
5. Kombination Sprite + Vektor
Somit besteht die Musterlösung in der Kombination aus Sprites und vektorbasierten Grafiken. Ein Weg ist die pixelbasierten Sprites einfach durch vektorbasierte auszutauschen.
Tipp:Die bereits vorhandene Sprite in ein Vektor-Grafikprogramm importieren, und die Grafiken als Vektoren über die Positionen der Pixelgrafiken legen (die Pixelgrafik anschließend löschen). Damit spart man die Anpassung im CSS. Dort ist lediglich für die unterschiedlichen Endgeräte der Zoom-Faktor (respektive Scaling) je nach Endgerät und / oder Auflösung anzupassen und der Pfad zur Pixel-Sprite durch das SVG-Pendant auszutauschen.
6. Inline-Images mit CSS-Data
Ein anderer Weg ist auf die Datei(en) als solche ganz zu verzichten. Alle aktuellen Browser bieten die Möglichkeit, mit Inline-Images – über das CSS-Data-Attribut – direkt im CSS zu generieren. Der Browser erhält somit die Vektordaten (Base64 encodiertes XML) und rendert die Grafik selbst anstatt diese zu laden.
Der Vorteil:
Es müssen keine zusätzlichen Dateien geladen werden. Die Grafiken werden schon mit dem CSS ausgeliefert, welches gleichermaßen im Cache liegt bzw. liegen sollte (dazu mehr im nächsten Artikel).
Der Nachteil:
Die Darstellung der Inhalte hängt von der Interpretations-Leistung des Browsers ab. Das CSS wird durch die Base64-Rohdaten größer. Hier liegt das Dateigrößen-Verhältnis etwas höher. Also der Quellcode der SVG-Grafik im CSS, erhöht die Größe der Datei etwas mehr, als die SVG-Grafik als “echte” Datei groß wäre.
Aktuelle Browser und die Prozessorleistung (CPU) sowohl der Desktop als auch mobilen Endgeräte lässt durchaus zu, die Grafiken direkt im CSS zu generieren. Einige Geräte weiten diese Berechnungen bereits auf den Grafikprozessor (GPU) aus, so dass die Interpretation noch schneller und unabhängig von der Systemlast abläuft. Außerdem lässt sich das CSS sehr gut minimieren bzw. komprimieren (dazu mehr im nächsten Artikel).
Selbst mit den CSS generierten Grafiken lassen sich übrigens Sprites bilden. Auch wenn die Grafiken in einer CSS Datei erzeugt werden, hat das Zusammenfassen in einer “Inline CSS Sprite” durchaus Vorteile. Der Browser muss das XML beispielsweise nur einmalig interpretieren, die generierte Grafik kann von da an im Zwischenspeicher behalten werden und muss nicht “erst bei Bedarf” immer wieder neu erzeugt werden.
Tipp:Um eine Inline-Grafik zu erzeugen, sind folgende 3 Schritte notwendig:
- SVG-Grafik mit einem Texteditor öffnen. XML-Code markieren und in die Zwischenablage kopieren.
- XML-Code z. B. über das WebToolkit in Base64 encodieren
- Im CSS Data Attribut wie folgt aufbauen: background: url(“data:image/svg+xml;base64,svgxmlcode“);(svgxmlcode steht für unter 2. erzeugten Code)
7. WebFonts
Neben den SVG-Grafiken ist eine weitere Möglichkeit für “skalierbare Inhalte in nur einer Datei”, die Verwendung von Grafik-WebFonts wie beispielsweise FontAwesome. Ähnlich wie eine SVG-Sprite beinhaltet das WebFont die Grafiken auf Vektorbasis, muss bloß einmal geladen werden und steht von da an immer zur Verfügung.
Der Nachteil:
Gegebenenfalls werden nur wenige der enthaltenen Grafiken benötigt, der Rest ist sozusagen Datenmüll.
Tipp:
Es gibt aber auch WebFont Generatoren, die es ermöglichen solche WebFonts gezielt zu erzeugen (beispielsweise FontSquirrel).
Fazit
Schon der erste Hebel aus der Artikelserie zeigt, dass sich zwar an der Vorgehensweise in den letzten Jahren nicht viel geändert hat, aber im Detail einige Dinge anders angegangen werden sollten. Gerade die heterogene Plattform-Landschaft erfordert mehr Fingerspitzengefühl.
Um 2013 mit Blick auf die Zukunft mehr Performance durch Hebel Nr. 1: Reduktion zu erreichen, hier noch mal eine Zusammenfassung der Maßnahmen:
- CSS und JavaScript in so wenig Dateien wie möglich zusammenfassen, extern und möglichst nicht im HTML-Quellcode
- Der Code sollte sauber sein (kein unnötiger Code)
- Redundanzen sind zu vermeiden (auch hier kein unnötiger Code)
- Layout sollte mit CSS generiert werden (auf Grafiken soweit es geht verzichten)
- Vektorbasierte Sprites für Grafiken verwenden
- Noch besser: Inline Grafiken im CSS als vektorisierte Sprite erzeugen und auf Grafikdateien (für Layout) gänzlich verzichten
3 Kommentare
Thorsten Barth,
Ich kann noch ergänzen, dass oft serverseitige Generierungszeiten noch Potenziale bieten, und dass sich in vielen Websites eine große Anzahl von JavaScript-Bibliotheken (z.B. Frameworks) angesammelt hat, die teilweise durch Refactoring überflüssig gemacht werden könnten. In einer Plattform, die Geld verdient, sollte immer auch in einen schlanken, übersichtlichen, schnellen Code investiert werden (z.B. nachd den Grundsätzen von eXtreme Programming oder Clean Code Developers)
Kay Steeger,
Ein sehr guter Artikel. Gerade bei den Ladezeiten einer umsatzgenerierenden Website wird die Ladezeit sehr oft vernachlässigt. Dabei kennt doch fast jeder Web-Nutzer lange Ladezeiten und damit oftmals verbunden das Gefühl, dass es nervt und man lieber auf einen Mitbewerber ausweicht, wo das Klicken aunf Kaufen Spaß macht. Zeit ist Geld und Warten nervt nunmal.
Diese Serie beginnt sehr erfolgsversprechend. Ich bin schon auf die nächsten Artikel gespannt.
Viele Grüße, Kay Steeger
Alexander Gasser,
Sehr toller, wenn auch etwas technischer Artikel zum Thema Webseitenoptimierung. Wer heute eine schnellladende Seite haben möchte, muss sich also anstrengen- vielen Dank für die hervorragenden Tipps.
Beste Grüße, Alexander