Grundsätzlich gibt es serverseitige und clientseitige Ansätze, um mobile Seiten möglichst schnell bereitzustellen. Aber während es durchaus einige Sonderfaktoren gibt, die auf der Serverseite speziell für mobile Sites relevant sind (z. B. schnellere oder langsamere Mobilweichen; dynamisch erzeugte optimierte Fassungen von Ressourcen vs. statische Versionen etc.), ist ein schneller Server mehr oder weniger gleichermaßen für mobile Sites wie deren großen Pendants wichtig. Anders ausgedrückt: Eine serverseitige Performanceoptimierung muss mit wenigen Ausnahmen nicht unbedingt mobile Zugriffe im Fokus haben, um auch dort zu helfen. Viel wesentlicher ist aber die Tatsache, dass in der technischen „Komposition“ der mobilen Website i. d. R. sehr viel mehr Potential zur Optimierung steckt, welches mit Eigenheiten von Mobilgeräten, mobilen Browsern und der mobilen Internetverbindung zusammenhängt.

Daher soll hier besonders auf die technischen Besonderheiten eingegangen werden, die vor allem im Zusammenhang mit mobilen Browsern und den Eigenheiten einer mobilen Internetverbindung bestehen. Welche Faktoren sind zu beachten und was kann getan werden, um hier möglichst große Zeitfresser zu eliminieren?

Die kurze Antwort darauf ist sehr einfach: Gezielte Reduktion in allen Belangen lautet die Zauberformel. Denn viele Dinge, die bei einer DSL-Verbindung auf dem Notebook und Desktop nur eine geringe Rolle spielen, können auf dem mobil verbundenen Smartphone und Tablet echte Spielverderber sein. „Reduktion in allen Belangen“ bedeutet daher:

• Weniger Requests. Wer die Anzahl der Requests deutlich minimieren kann, hat dem größten Feind mobiler Performance einen harten Schlag versetzt. Denn Latenz ist meistens der größte Zeitfresser. Und da die übermäßig hohe Latenz bei nicht parallelisierbaren Requests in Summe in die Ladezeit eingeht, ist z. B. durch Zusammenfassung von mehreren Scriptdateien, CSS-Dateien und vor allem auch den meistens eingesetzten vielen kleinen Bildern in wenige CSS-Sprites gerade auf Mobilgeräten eine Menge herauszuholen.
• Weniger Domains. Während auf dem Desktop die Parallelisierung von Downloads verschiedener Ressourcen über CDNs eine prima Idee ist, um schnellere Seiten auszuliefern, kann (nicht: muss) diese Idee nach hinten losgehen, wenn es um mobile Sites geht. Das ist zwar streng genommen ein Unteraspekt von „Weniger Requests“, aber auch die Anzahl der beteiligten Domains können wegen des trägen Verbindungsaufbaus und der damit einhergehenden besonders hohen Latenz für den ersten Zugriff der mobilen Site mehr Schaden als Nutzen bringen. Hier hilft im Zweifelsfall nur die Messung verschiedener Varianten, wenn die Minimierung der Anzahl der Ressourcen abgeschlossen ist und man verschiedene Verteilungsszenarien durchspielen und messen kann.
• Weniger Bytes. Die Optimierung von Scripts, CSS und dem Seitenquellcode durch Filter oder in Form physikalisch bereits von formatierenden Leerzeichen und Umbrüchen befreiter Inhalte macht sich durch die mobil auch deutlich schlechteren Durchsatzraten deutlich bemerkbar. Je Verbindung mag das mal mehr mal weniger Gewicht haben… da aber mobil immer deutlich langsamere Übertragung als per DSL & Co. zu erwarten ist, sind minimierte Dateien, optimierte (und für die mobile Site passend skalierte) Grafiken (z. B. via „Responsive Images“) für schnelle Darstellung unabdingbar. Auch der vollständige Verzicht auf Grafik zu Gunsten von CSS3 für Farbverläufe, Schatten usw. ist dank der auf Mobilgeräten voraussetzbaren modernen Browsern mit der Fähigkeit zum Umgang mit CSS3 eine relativ sichere Option. Da ohnehin eine simplere Darstellung auf dem Smartphone erforderlich ist und „bildschirmfüllende“ Teaser hier das Ziel verfehlen, ist „weniger“ gleich mehrfach „mehr“.
• Weniger Content. Unabhängig davon, dass das ein ganz anderes Thema ist und mobile Websites nicht nur aus technischen idealerweise nicht den gleichen Umfang wie die komplette Desktop-Browser-Version haben sollte (und das auch nicht muss), ist weniger Content auch weniger zu laden.
• Weniger Scripts (und einfacheres CSS). Nicht nur aus nacheliegenden Gründen der Verkleinerung der zu übertragenden Datenmenge, sondern als Konzession an die normalerweise der dem Desktop nach wie vor unterlegenen mobilen Hardware (CPU, Speicher, Rechenleistung) ist JavaScript einfach langsamer und benötigen viele durch CSS-Anweisungen erforderliche „Reflows“ im Browser mehr Zeit. Die direkte Auslieferung einer optimierten CSS-Fassung für Mobilgeräte ist und ein Minimum an Script (vor allem, wenn dadurch der DOM manipuliert wird, was wiederum jeweils einen Neuaufbau im Browser erfordert) sind daher aus mehr als nur einem Grund wünschenswert.

Nicht alle Faktoren sind auf allen mobilen Plattformen gleich stark an der Ladezeit beteiligt. Da man aber keine Site nur für das iPad2, iPhone3 oder Android 2.3 – Tablets oder einzelne Smartphones optimiert, bleibt daraus nur ein Schluss: Man muss sich allen Faktoren widmen, wenn man im Gesamtdurchschnitt auf allen beteiligten / relevanten Geräten möglichst schnelle Seiten ausliefern will.

Ansatzpunkte zur Optimierung

Oben bereits angesprochen wurden für folgenden Punkte:

• Optimierte Grafiken,
• Mimimierung von Scripts, CSS und HTML;
• Zusammenfassen von Dateien,
• CSS-Sprites und
• CSS3 statt Grafik

Davon kann man nun aber – um die Verwirrung perfekt zu machen – teilweise wieder einen Schritt zurück machen und so z. B.für einzelne Ressourcen, die umfangreich und für eine grundsätzlich komplette und funktionierende „erstaufgebaute“ Seite nicht wesentlich sind, eine Auslagerung in Betracht zu ziehen. Denn wenn diese asynchron nachgeladen werden können, ist hierdurch sowohl eine initial schnellere Seite zu realisieren als auch so die Gefahr eines möglichen Stillstands beim Seitenaufbau durch übermäßigen Paketverlust zu minimieren. Bei stark ausgelasteten Mobilfunkzellen in Ballungsgebieten / zu Spitzenzeiten ist dieses Gefahr leider nicht nur theoretischer Natur. Also: Gezielte Parallelisierung von Ressourcenzugriffen ist ganz und gar nicht schlecht für mobile Seiten (siehe auch „HTTP Pipelining„). Denn je früher eine „erste Version“ der Seite dargestellt werden kann, desto besser ist die gefühlte Performance für den mobilen Besucher.

Ein ähnlicher Ansatz: Bilder nur laden, wenn benötigt. Bei langen Seiten können weiter unten platzierte Bilder erst dann nachgeladen werden, wenn diese in den Sichtbereich des Viewports gescrollt werden. Spart ggf. Requests und Bytes. Oder nach Erreichen des „onload“-Events der Seite in der ersten Fassung ohne zusätzliche Grafiken. Spart nichts, stellt aber schneller eine Seite im Browser bereit.

Nicht auf den Cache verlassen: Bei aller Minimierung darf nicht vergessen werden, dass der Cache (sowohl flüchtiger als auch persistenter Speicher) bei Mobilgeräten kleiner als auf dem Desktop ist. Oder im schlimmsten Fall auch gar nicht vorhanden. Sicherheit, dass alle Ressourcen beim nächsten Laden einer weiteren Seite also aus dem Cache kommen können, ist je nach Umfang der Ressourcen, Anzahl offener Tabs im Browser etc. nicht gegeben. „CSS-Riesensprites“, die 10 Varianten aller Headergrafikvarianten enthalten, sind also aus Mobilsicht genau so „am falschen Platz optimiert“ wie 100 Symbole, von denen auf 80% der Seiten nur 20 Stück benötigt werden. Sinnvolle Aufteilung in mehrere Dateien ist also durchaus angesagt. Für kleinere Ressourcen wie Scripts und CSS kann als Ersatz der persistente Speicher von „HTML5 localStorage“ verwendet werden, auf dessen Existenz man sich glücklicherweise bei den modernen mobilen Browsern verlassen kann. Für viele Bilder sind die dazu i. d. R. verfügbaren 5 MB allerdings selten eine brauchbare Lösung.

Auch hier gilt: Messen heißt wissen!

Verschiedene Varianten testen, besten Kompromiss für alle wichtigen Geräte – iPhone, iPad, Android Tablets und Smartphones – durch messen ermitteln. Dazu dienen idealerweise echte Geräte, auf denen die Messungen z. B. mit PCApPerf durchgeführt werden können. Ersatzweise kann auch ein Webdienst wie blaze.io eingesetzt werden, um sich schrittweise der besten Lösung zu nähern. Welche Geräte heute schon besonders wichtig sind, zeigt ggf. die eigene Webanalyse. Aber Vorsicht: Nur weil ein bestimmtes, ansatzweise prominentes Gerät durch die Zahlen aus der eigenen Webanalyse nicht relevant erscheint, muss das nicht bedeuten, dass das in Zukunft so bleibt. Sich hier am lokalen Marktdurchschnitt zu orientieren und den Fokus primär auf iOS-Geräte und wenige ausgesuchte Androids, speziell Smartphones, zu richten, kann eigentlich kaum falsch sein.

Wer sich konkret an die Arbeit machen möchte, findet eine hilfreiche Zusammenfassung vieler Faktoren und Optimierungsmöglichkeiten bei Youtube in einem (nicht mehr ganz neuen)  Google TechTalk von Guy Podjarny (englisch, ca. 1 Stunde Laufzeit).