Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Erfolgreiche Websites sind schnelle Websites

Web-Performance für Mobilgeräte

Erfolgreiche Websites sind schnelle Websites

Schlechte Web-Performance bremst die Internetnutzung mit Mobilgeräten. Was sind die Ursachen für langsame Webseiten und wie können wir sie optimieren?

Die Mobile-Computing-Revolution

In der Geschichte der Menschheit waren globale Umwälzungen selten als solche wahrnehmbar. Ob es sich um das Weltklima, gesellschaftliche Machtverhältnisse oder ökonomisch-technische Prozesse handelt: Aus der Froschperspektive gesehen besteht eine große Umwälzung stets nur aus kleinen Schritten. Das führt dazu, dass sie unterschätzt oder gar geleugnet wird.

Eben so verhält es sich bei der Mobile-Computing-Revolution, die uns erfasst hat. Es ist nicht der Fall, dass keine Desktop-PCs und mobile Workstations mehr verkauft und genutzt werden. Im Gegenteil, sie entwickeln sich weiter und bleiben leistungsfähige Werkzeuge mit vielfältigen, kreativen Anwendungsmöglichkeiten. Doch der Markt der Mobilgeräte, insbesondere der Smartphones, wächst weiterhin, während der PC-Markt schrumpft.

Der Umstieg von Desktop- auf Mobilgeräte betrifft vor allem bereits digitalisierte Industrieländer. Der mobile Internet-Traffic übertrifft dort nach und nach den Traffic von Desktop-Rechnern. In vielen anderen Ländern erlangen Menschen mit Mobilgeräten erstmals regelmäßigen Zugang zum Internet. Für sie sind Smartphones die erste und einzige Art, das Web zu nutzen. Man spricht von »the next billion«, der nächsten Milliarde Menschen, die mit Smartphones online gehen.

Während in Mitteleuropa und Nordamerika Oberklasse-Geräte die Berichterstattung dominieren, so liegt das Gros der verkauften Smartphones in der Unter- und Mittelklasse. Die Preise sind derart gefallen, dass der durchschnittliche Verkaufspreis zwischen 100 und 200 Euro liegt. Das sorgt dafür, dass Smartphones für immer mehr Menschen in Entwicklungs- und Schwellenländern erschwinglich werden. Ein Beispiel dafür ist Nigeria, das Finanz- und Technologiezentrum Westafrikas.

Die große Krise: Mobile Website-Performance

»We’re really in the midst of a crisis and collectively, we don’t understand how bad that crisis is. If we did, we would have already modulated our behavior. … Unless we change the way we’re working, the web won’t work for the next billion users.«

Die Websites, die wir derzeit bauen, berücksichtigen die Anforderungen von Mobilgeräten nicht. Die Zufriedenheit der Nutzer leidet insbesondere unter der schlechten Lade-Performance.

Mobile Seiten sind laut dem HTTP Archive im Median 1,5 MB groß. 25% der untersuchten Seiten sind größer als 2,9 MB, 10% sogar größer als 5,5 MB. Laut Google-Untersuchungen dauert es durchschnittlich 22 Sekunden, bis eine mobile Seite vollständig geladen ist. Bei 70% der untersuchten Seiten dauerte es 7 Sekunden, bis die ersten Inhalte zu sehen waren.

Gleichzeitig springen 53% der Besucher einer mobilen Seite ab, wenn diese länger als 3 Sekunden lädt. Schon länger ist der Zusammenhang zwischen Konversion und Performance bekannt. Der Umstieg auf Mobilgeräte verschärft die Situation: Eine Performance, die auf Desktop-Rechnern noch zu verschmerzen ist, ist auf Mobilgeräten katastrophal und schreckt Nutzer ab.

Die Technik der Mobilgeräte

Um zu verstehen, woher Performance-Probleme auf Mobilgeräten rühren, müssen wir verstehen, was Smartphones von Desktop-Rechnern unterscheidet.

Zunächst einmal sind Smartphones batteriebetrieben und müssen sparsam mit Energie umgehen. Hard- und Software sind daraufhin optimiert, möglichst effizient die verfügbare elektrische Energie einzusetzen. Insbesondere betrifft das Prozessor, Bildschirm und Funkübertragung (Mobilfunk, Wi-Fi, Bluetooth etc.).

Die gängigen Prozessoren der ARM-Architektur haben mehrere Kerne, zum Teil unterschiedlich getaktet zwischen 1 und 2 GHz. Sie liefern nur einen Bruchteil der Leistung eines Desktop-Prozessors und können nur kurzfristig Leistung geben. Bei längerer Nutzung werden sie heruntergetaktet, um Energie zu sparen und Überhitzung zu vermeiden.

Neben der eingeschränkten Rechenleistung ist die Internetverbindung der wichtigste Flaschenhals für die Web-Performance. Hier soll es vor allem um GSM-basierten mobilen Internetzugang gehen.

Mobile Internetverbindungen sind bekanntlich langsamer als Kabelverbindungen. Was heißt das konkret? Der Datendurchsatz ist abhängig vom Verbindungstyp (GPRS, EDGE, UMTS/HSPA, LTE usw.) und der tatsächlichen Funkverbindung zur Mobilfunk-Basisstation. Die maximale Download- und Upload-Rate wird z.B. in Kilobits oder Megabits pro Sekunde gemessen.

Ebenso wichtig ist die Latenz der Internetverbindung. Das ist die Laufzeit eines Signals vom Mobilgerät zum Webserver. Läuft das Signal hin und zurück, spricht man von der Round Trip Time. Bei gut angebundenen Kabelverbindungen und Webservern beträgt die Round Trip Time gerade einmal 25-35 Millisekunden. Bei Mobilverbindungen zum gleichen Server kann sie zwischen 50 Millisekunden und einer Sekunde liegen, je nach Funkverbindung.

Der Datendurchsatz bestimmt zum Beispiel, wie lange der HTML-Code einer Webseite übertragen wird. Die Latenz sorgt dafür, dass der Aufbau jeder HTTP-Verbindung zwischen Mobilgerät und Webserver ein vielfaches der Round Trip Time dauert.

Das wichtigste Merkmal von Mobilverbindungen ist das begrenzte Datenvolumen. Jedes übertragene Byte kostet den Nutzer nicht nur Zeit, sondern bares Geld. Je nach Land und Tarif kostet die Übertragung einer durchschnittlichen Webseite zwischen einem US-Cent und 43 US-Cent (kaufkraftbereinigt). Übliche Datentarife in Deutschland beinhalten einige hundert Megabyte oder, wenn Nutzer zuzahlen, wenige Gigabyte monatliches Datenvolumen bei voller Geschwindigkeit.

Die größten Probleme der mobilen Web-Performance

Es gibt verschiedene Kennzahlen, um mobile Performance zu messen und zu verbessern. Sehen wir uns die wichtigsten Metriken an, um die Ursachen langsamer Seiten zu identifizieren.

1. Ladeverhalten

Das Ladeverhalten beschreibt den Aufbau der Webseite und die erste Interaktion des Nutzers mit der Seite.

  • Wie lange dauert es, bis der erste Inhalt zu sehen ist? (Time to first meaningful paint)
  • Wie lange dauert es, bis die Seite bedient werden kann? (Time to interactive)
  • Hängt die Seite beim Lesen und Bedienen? Werden Inhalte nachgeladen? Springen Inhalte herum? (Time to consistently interactive)

Bevor der Browser eine Seite erstmals rendert, muss ein Teil des HTML-Codes und alle im head verlinkten Stylesheets heruntergeladen und verarbeitet werden. Weitere externe HTTP-Ressourcen können das Rendern blockieren. Wird zum Beispiel ein JavaScript im head mit <script src="…"></script> eingebunden, so verzögert das Herunterladen und Ausführen des Scripts das erste Rendern.

Dieser Ablauf wird als Critical Render Path bezeichnet. Langsame Webseiten laden viele Daten, die das erste Rendern blockieren. Die Optimierung besteht darin, unwichtige Inhalte aus dem Critical Render Path zu entfernen und sie gegebenenfalls später zu laden. JavaScripte etwa können asynchron, nicht-blockierend geladen werden.

Ein frühes erstes Rendern sorgt dafür, dass Nutzer sich schnell zurechtfinden und erste Inhalte lesen können. Danach möchten sie mit der Seite interagieren, ohne unterbrochen zu werden. Das umfasst Scrolling, das Aktivieren von Buttons und Links, Gesten usw.

Nach dem ersten Rendern ist der Browser oft damit beschäftigt, weitere Inhalte zu laden und zu verarbeiten, die nicht unbedingt den sichtbaren Seitenausschnitt betreffen. Darunter fallen Bilder, asynchrone JavaScripte und Drittinhalte wie Werbeanzeigen, Media-Player, Sharing-Buttons und Tracker.

Netzwerkverkehr und Datenverarbeitung belasten den Prozessor und sorgen mitunter dafür, dass der Haupt-Thread des Browsers vollständig ausgelastet ist. Der Browser friert dadurch ein und kann Eingaben nicht mehr oder nur mit Verzögerung abarbeiten.

Die Optimierung des Ladeverhaltens stellt sicher, dass eine Seite schnell erscheint und nach dem ersten Rendern dauerhaft bedienbar bleibt. Der Schlüssel dazu ist das kontrollierte Nachladen von Inhalten, wenn sie benötigt werden (Lazy Loading). Lang laufende JavaScripte müssen reduziert oder optimiert werden. Es sollten nur ausgewählte, als performant bekannte Drittinhalte eingebunden werden.

2. Übertragene Datenmenge

Erstrebenswert ist, dass eine Seite nach ein paar Sekunden erscheint und nach weiteren Sekunden voll bedienbar ist. Angesichts der Latenz und des Durchsatzes von Mobilverbindungen kann eine Seite in diesen paar Sekunden nur wenige hunderte Kilobyte laden.

Neben dem Ladeverhalten in den kritischen ersten Sekunden ist wichtig, wie viel Daten insgesamt übertragen worden sind, wenn die Webseite vollständig geladen ist. Meist haben HTML- und CSS-Code nur einen kleinen Anteil an der übertragenen Datenmenge. Schuld an schwergewichtigen Seiten sind zumeist nicht-optimierte Pixelgrafiken, zahlreiche Webfonts und riesige JavaScripte. Ein zwei Megabyte großes Bild etwa verzögert zwar nicht das Rendern von Textinhalten, aber dessen Übertragung kostet den Nutzer mitunter einige Cent.

Besonders Pixelgrafiken haben großes Einsparpotenzial. Sie müssen reduziert und für Mobilgeräte optimiert werden. Dies ist ein Thema für sich und kann hier nur zusammengefasst werden: Nutze das picture-Element oder das srcset-Attribut, um verschiedene, auf die Viewport-Größe abgestimmte Grafiken zu laden. Dabei spielen das richtige Grafikformat und die Komprimierung eine Rolle. Mittlerweile gibt es hilfreiche Richtlinien, Tools und Dienste.

3. Verhalten von JavaScripten

Visualisierung der Anteile verschiedener Kategorien an der Prozessor-Auslastung auf einer beispielhaften Webseite. 59,1% der Zeit wurde JavaScript ausgeführt.
Die Ausführung von JavaScript beschäftigt den Prozessor am meisten

Beim Untersuchen der Performance auf einem echten Mobilgerät fällt schnell auf, dass der Browser einen Großteil der Zeit mit der Ausführung von JavaScript beschäftigt ist. Das liegt daran, dass ein Mobilgerät zwischen 2-mal und 20-mal so lange wie ein Desktop-Rechner braucht, um den JavaScript-Code zu entpacken, zu parsen, zu kompilieren und schließlich auszuführen.

Bei einem Test läuft ein 214-KB-Script auf einem Desktop-Rechner zwischen 150 und 200 Millisekunden und auf einem älteren Mobilgerät zwischen 3,0 und 3,8 Sekunden. Bei der Ausführung löst es mehrere zeitaufwändige Reflows aus, die den Browser dazu zwingen, das Seitenlayout neu zu berechnen.

Während dieser Ausführung ist der Haupt-Thread des Browsers wie gesagt blockiert. Die Seite kann nicht oder nur ruckelig bedient werden. Oder der Nutzer schaut dem JavaScript zu, wie es nach und nach die Seite umbaut.

Visualisierung der Anteile verschiedener Formate an der Gesamtgröße einer beispielhaften Webseite. JavaScript nimmt mit 52,5% ein.
Auf manchen Seiten entfallen mehr als 50% der übertragenen Daten auf JavaScript

Heutzutage ist zu viel und falsch eingesetztes JavaScript eine der Hauptursachen für schlechte Performance auf Mobilgeräten. Dabei handelt es sich um Scripte der Seite selbst oder um Scripte von Dritten. Das Aufkommen komplexer JavaScript-Frameworks wie Angular, React und Vue hat dazu geführt, dass noch mehr JavaScript an den Browser ausgeliefert wird und der Dokumentinhalt erst clientseitig erzeugt wird. Laut HTTP Archive lädt eine mobile Seite im Median 19 Scripte mit einer Gesamtgröße von 334 KB.

Das derzeitige JavaScript-Ökosystem ist nicht auf die Mobile-Computing-Revolution vorbereitet. Die JavaScripte im Web müssen insgesamt reduziert werden und die verbleibenden klüger eingesetzt werden, um den Anforderungen der mobilen Internetnutzung gerecht zu werden.

Schnelle mobile Websites nach Plan

Die Optimierung der Performance einer Website darf keine nachträgliche Idee sein. Es ist nahezu unmöglich, eine fertige langsame Website nachträglich schnell zu machen. Die Bedeutung der Performance muss allen Beteiligten schon in der Planungsphase bewusst sein: Der Erfolg der Website hängt auch von der Performance ab.

Dazu hat es sich als hilfreich erwiesen, ein Performance-Budget aufzustellen. Genauso wie eine Website ein begrenztes finanzielles und zeitliches Budget hat, sollte die Ladedauer ebenfalls begrenzt sein. Das Budget definiert Grenzwerte, die nicht über- bzw. unterschritten werden dürfen. Ein Beispiel:

  • Das Referenzgerät ist ein Mittelklasse-Smartphone mit 3G-Verbindung (1.6 Mbits Download, 300ms Round Trip Time).
  • Stabiler Chrome-Browser auf Android bzw. Safari auf iOS.
  • Nach maximal 3 Sekunden wird der erste Inhalt gerendert (time to first meaningful paint).
  • Nach maximal 5 Sekunden ist die Seite bedienbar (time to interactive).
  • Nach maximal 6 Sekunden ist die Seite durchgängig ohne Unterbrechungen bedienbar (time to consistently interactive).
  • Die übertragene Datenmenge beim load-Ereignis beträgt maximal 1,2 MB.

Alle Beteiligten – Kunden, Projektleitung, Frontend- und Backend-Entwicklung – sollten sich vorab auf ein Performance-Budget einigen und dessen Einhaltung überprüfen. Im Verlauf des Projekts werden einzelne Features geschätzt: Welche Auswirkung auf die Performance haben sie? Sobald das Budget aufgebraucht ist, können weitere Features nur hinzugefügt werden, wenn bestehende entfernt oder optimiert werden. Damit wird das Hinzufügen weiterer, ungeplanter Features (Feature Creep) erschwert.

Mobile First: Jetzt erst recht

Schon 2011 veröffentlichte Luke Wroblewski das einflussreiche Buch »Mobile First«. Wroblewski forderte, dass sich Produktstrategie und Design auf die Bedürfnis von Mobilnutzern ausrichten. Ihm war klar, dass die Gestaltung für Mobilgeräte auch Beschränkungen mit sich bringt. Doch er sah die Übersichtlichkeit und den notwendigen Fokus eher als Vorteil.

Die Ausrichtung auf mobile Performance hilft, die Ziele einer Website klar zu definieren sowie Inhalte und Funktionen zu priorisieren: Was möchte eine Nutzerin erreichen? Welche Aufgabe möchte ein Nutzer erledigen? Was soll die Website demnach leisten? In welcher Ladezeit und mit wie viel übertragenen Daten? Welche Inhalte und Funktionen müssen schnell laden, welche können später geladen werden?

Web-Performance ist kein technisches Randthema für Frontend- und Backend-Developer, sondern ein fundamentaler Aspekt jeder zukunftsfähigen Website mit einem herausragenden Nutzererlebnis.

Links

Kommentare

Matthias Apsel
am 14.01.2018 - 10:00

Im SELFHTML-Forum hat sich eine Diskussion dazu entwickelt: https://forum.selfhtml.org/m1711637

Permanenter Link

Neuen Kommentar schreiben

Bitte beachtet unsere Hausregeln fürs Kommentieren. Die Kommentare werden nach sechs Wochen geschlossen.