Der mobile Performance-Unterschied.

Dieselbe Seite läuft auf Mobilgeräten deutlich langsamer als am Desktop, und der Grund ist nicht das Netz, sondern die Prozessorleistung.

Performance-Tests geschehen meist auf der eigenen Maschine der Entwicklung, und diese Maschine steht am besten Ende der Geräteverteilung echter Nutzer. Das Ergebnis: ein systematisch optimistisches Bild und ein Labor-Score, der ständig von den Felddaten abweicht.

Der Unterschied zeigt sich am stärksten beim JavaScript. Die Ladezeit eines Skripts hängt am Netz, und mobile Netze sind manchmal schneller als Desktop-Leitungen; aber Parsen, Kompilieren und Ausführen dieses Skripts hängen am Prozessor — und ein Mittelklasse-Telefon liegt um ein Mehrfaches hinter einem Laptop.

Gleiche Bytes, verschiedene Kosten

Diese Asymmetrie erklärt auch, warum bytebasierte Budgets nicht genügen. Ein Bild von hundert Kilobyte trägt auf jedem Gerät ungefähr dieselben Kosten — es wird geladen und dekodiert. Ein Skript von hundert Kilobyte erzeugt je Gerät um ein Mehrfaches verschiedene Kosten.

Die praktische Folge: Der Fokus der mobilen Performance-Arbeit gehört auf das JavaScript, nicht auf die Bilder. Bilder zu verkleinern bringt auf jedem Gerät ähnliche Gewinne; Skripte zu verkleinern bringt auf schwachen Geräten überproportionale.

Die zweite Folge betrifft die Wahl des Testgeräts: Auf dem neuesten Telefon zu testen unterscheidet sich kaum vom Test auf dem neuesten Laptop. Der aussagekräftige Test geschieht auf einem Gerät der Mittel- oder Unterklasse — oder wird mit der CPU-Drosselung der Browserwerkzeuge simuliert.

1. Vierfache Drosselung — eine Simulation nahe der Mittelklasse.
2. Sechsfache Drosselung — Unterklasse. Googles eigener Mobiltest liegt in dieser Gegend.
3. Die Netzdrosselung ist getrennt — zusammen mit der CPU-Drosselung zu verwenden; die zwei fangen Verschiedenes.
4. Ein echtes Gerät — die Simulation ersetzt es nicht; mindestens einmal auf einem echten Telefon testen.
5. Felddaten — der letzte Schiedsrichter. Die Simulation ist eine Schätzung, die Felddaten sind eine Messung.

Sichtfenster und Layout

Es gibt einen zweiten mobilen Unterschied, und er wird übersehen: Derselbe Inhalt erzeugt auf schmalem Bildschirm eine viel längere Seite. Das ändert die Zahl der Elemente im sichtbaren Bereich — und kann damit ändern, welches Element das LCP-Element ist.

Wo am Desktop das Hero-Bild das LCP-Element ist, kann es auf Mobil ein Überschriftentext sein. Die zwei verlangen völlig verschiedene Behandlungen — das eine Bildoptimierung, das andere Schriftladeverhalten. Das LCP-Element muss deshalb je Umbruch eigens bestimmt werden.

Dieselbe Trennung gilt für Touch-Ziele und Layoutverschiebung: Ein am mobilen Umbruch verengtes Raster kann am Desktop einwandfreie Ziele unter die Schwelle drücken, und später kommender Inhalt erzeugt auf schmalem Bildschirm eine größere Verschiebung.

Auf dieser Website misst die Prüfsuite den mobilen Umbruch als eigenen Block: Bei 390 Pixel Breite werden Seitenfluss, Touch-Ziele, Textbeschnitt und die Maße der Beitragsseite einzeln geprüft. Die Annahme, die Desktop-Messung decke Mobil ab, wird nie gemacht.

Nichts am Desktop Gemessenes sagt etwas über Mobil; die zwei werden getrennt gemessen.

Die Netzvariabilität

Der Prozessorunterschied ist der größte Faktor, aber nicht der einzige; auch die Variabilität mobiler Netze ist eine Entwurfsbeschränkung. Anders als eine feste Leitung ändert die mobile Verbindung Geschwindigkeit und Latenz, während der Nutzer sich bewegt — und reißt in manchen Momenten ganz ab.

Das verlangt Widerstandsfähigkeit. Eine gescheiterte Anfrage ist keine Ausnahme, sondern ein erwarteter Zustand, und was die Oberfläche dann tut, muss entworfen sein. Ein still scheiterndes Formular kostet den Nutzer seine Daten.

Auf dieser Website ist das Kontaktformular nach diesem Prinzip gebaut: Antwortet der Server nicht, übergibt der Ablauf an einen E-Mail-Link. Der Kanal schließt sich in keinem Fall vollständig, und die Prüfsuite misst dieses Rückfallverhalten eigens.

1. Langsame Verbindung — der Inhalt soll schrittweise kommen; ein Skelett zeigen, keinen leeren Bildschirm.
2. Abreißende Verbindung — scheitert eine Anfrage, muss der Nutzer erfahren, was geschah.
3. Gedeckelter Datentarif — wird die Datensparpräferenz gemeldet, sollen schwere Ressourcen nicht laden.
4. Hohe Latenz — die Anfragenzahl soll sinken; jeder Umlauf ist teuer.
5. Der Rückfallweg — kritische Abläufe dürfen nicht an einer einzigen Technologie hängen.

Der letzte Punkt ist ein Architekturprinzip und reicht über Mobil hinaus: Ein Ablauf, der der einzige Konversionspfad ist, darf nicht davon abhängen, dass eine einzige Technologie funktioniert. Das ist so sehr Verlässlichkeit wie Performance — und beide zeigen hier auf dieselbe Lösung.

Eine praktische Checkliste

Übersetzt man diese Seite in einen Prüfschritt, ist für die mobile Performance Folgendes zu prüfen. Die Liste bleibt kurz, denn lange Listen werden nicht abgeschritten; sechs Punkte passen in eine Sitzung.

1. Lief der Test mit gedrosseltem Prozessor?
2. Wurde mindestens einmal auf einem echten Mittelklasse-Gerät probiert?
3. Ist das LCP-Element auf Mobil ein anderes — es muss getrennt vom Desktop bestimmt werden.
4. Liegen die Touch-Ziele am mobilen Umbruch über der Schwelle?
5. Was tut die Oberfläche beim Netzabriss?
6. Wurden die Felddaten für Mobil und Desktop getrennt gelesen?

Der dritte Punkt wird am meisten übersehen: Wo am Desktop das Hero-Bild das LCP-Element ist, kann es auf Mobil ein Überschriftentext sein — und die zwei verlangen völlig verschiedene Behandlungen.

Nichts am Desktop Gemessenes sagt etwas über Mobil.

Ein Prioritätsrahmen zum Schluss: Auf den meisten Websites kommt mehr als die Hälfte des Verkehrs von Mobil, und die Performance-Arbeit geschieht weiter Desktop-first. Diese verkehrte Priorität heißt, dass die Probleme, die die meisten Nutzer betreffen, zuletzt behandelt werden.

Die Korrektur ist ein Gewohnheitswechsel: mit der Messung bei Mobil beginnen, das Testgerät aus der Mittelklasse wählen und die Felddaten am mobilen Umbruch lesen. Keines der drei kostet extra — sie ändern nur, welche Zahl zuerst angesehen wird. Und auf dieser Website misst die Suite den mobilen Umbruch als eigenen Block; die Annahme, die Desktop-Messung decke Mobil ab, wird nie gemacht.

Eine Messerinnerung zum Schluss: Mobile Felddaten fallen meist deutlich schlechter aus als Desktop, und das ist normal. Das Problem ist nicht, diesen Unterschied zu sehen und zu sagen „auf Mobil gibt es viel zu verbessern“ — das Problem ist, die zwei Datensätze zu verschmelzen, auf den Durchschnitt zu schauen und den Unterschied nie zu sehen. Zwei getrennt gelesene Zahlen geben eine Diagnose; eine verschmolzene Zahl gibt nur ein Gefühl.