Mobile Performance: Shops auf Smartphones beschleunigen
Ein Shop, der am Entwickler-Laptop in unter einer Sekunde steht, kann auf dem Smartphone eines Kunden trotzdem zäh wirken. Der Grund liegt nicht in einem schlechten Code, sondern in zwei Welten, die selten zusammenfallen: ein leistungsfähiger Desktop mit Glasfaser auf der einen Seite, ein Mittelklasse-Telefon im Mobilfunknetz auf der anderen. Genau diese Luecke macht die Zahlen sichtbar: Laut Web Almanac bestehen nur 48 Prozent (Web Almanac, 2025) der Origins auf dem Smartphone alle drei Core Web Vitals, am Desktop sind es 56 Prozent (Web Almanac, 2025). Das ist umso bedeutsamer, als rund 57 Prozent (Statista, 2024) des weltweiten E-Commerce-Umsatzes auf Mobilgeräten entstehen. Und die Geduld ist knapp: 53 Prozent (Google, 2018) der mobilen Besuche werden abgebrochen, wenn das Laden länger als drei Sekunden dauert. Dieser Beitrag zeigt, warum Mobile-Performance eigenen Regeln folgt -- gedrosselte CPU, langsameres Netz, kleiner Viewport, Touch-Eingaben -- und mit welchen Hebeln Sie Ihre mobilen Core Web Vitals gezielt verbessern.
Das Wichtigste in Kürze
- Was am Desktop schnell ist, ist mobil nicht automatisch schnell -- schwächere CPU, höhere Netzlatenz, kleiner Viewport und Touch verschieben alle drei Core Web Vitals.
- LCP ist mobil der schwierigste Vital, weil das größte sichtbare Element meist ein Bild ist, das über ein langsameres Netz reist.
- Responsiv ausgelieferte Bilder mit srcset und sizes plus fetchpriority für das LCP-Bild sind die wirksamsten Hebel gegen lange Ladezeiten auf dem Smartphone.
- INP leidet mobil unter langem JavaScript, das den schwächeren Hauptthread blockiert -- großzügige Tippziele gehören genauso dazu wie schlanker Code.
- Mobile ist der Hauptkanal, nicht der Sonderfall: Wer jede Änderung unter gedrosselten Bedingungen misst und Mobil-Felddaten getrennt liest, holt die Conversion zurück.
Warum mobile Performance ihren eigenen Regeln folgt
Der häufigste Trugschluss in der Performance-Optimierung lautet: Was am Desktop schnell ist, ist auch mobil schnell. Tatsächlich treffen auf dem Smartphone mehrere Engpässe gleichzeitig zusammen, die der Desktop nicht kennt. Ein Mittelklasse-Telefon hat eine deutlich schwächere CPU, arbeitet oft im Mobilfunknetz mit höherer Grundlatenz und stellt den Inhalt auf einem kleinen Bildschirm dar, der mit den Fingern bedient wird. Jeder dieser Faktoren verschiebt das Verhalten genau jener Metriken, an denen Google die Nutzererfahrung misst.
Die Folge ist eine messbare Kluft zwischen den Geräteklassen. Besonders deutlich zeigt sie sich bei der Reaktionsfreudigkeit: Während am Desktop 97 Prozent (Web Almanac, 2024) der Seiten einen guten INP-Wert erreichen, fällt der mobile Anteil spürbar ab. Diese Diskrepanz entsteht nicht durch andere Nutzer, sondern durch andere Hardware -- dieselbe JavaScript-Last blockiert einen schwachen Mobilprozessor viel länger als einen Desktop-Kern. Eine fundierte Performance-Analyse trennt deshalb stets Mobil- und Desktop-Felddaten, statt einen gemittelten Wert zu betrachten.
Die drei Core Web Vitals -- kurz erklaert
Gedrosselte CPU und langsames Netz: so wird mobil gemessen
Wer mobile Performance ernsthaft testen will, darf nicht den eigenen Highend-Rechner als Maßstab nehmen. Die Mobil-Prüfung in Lighthouse simuliert bewusst ein realistisches Gerät: Standardmäßig wird die CPU um den Faktor 4x (Google Lighthouse) verlangsamt, um einen Mittelklasse-Prozessor nachzubilden. Hinzu kommt die Netzwerk-Drosselung auf das Profil Slow 4G, das laut Lighthouse-Dokumentation etwa die unteren 25 Prozent (Google Lighthouse) der 4G-Verbindungen abbildet. Erst unter diesen Bedingungen werden Engpässe sichtbar, die auf schneller Hardware vollkommen verborgen bleiben.
Diese Drosselung ist kein kuenstliches Schikanieren, sondern eine Annäherung an die Realität vieler Nutzer. In zahlreichen Maerkten dominiert weiterhin das 4G-Netz, und nicht jeder besitzt das aktuellste Spitzenmodell. Wichtig ist die Unterscheidung zweier Datenquellen: Synthetische Labortests wie Lighthouse erzeugen reproduzierbare Bedingungen, während Felddaten aus echten Sitzungen (CrUX) die tatsächliche Geräte- und Netzvielfalt abbilden. Erfahrungsgemäß (Projekterfahrung) deckt erst die Kombination beider Quellen die wahren mobilen Schwachstellen auf -- der Labortest findet Regressionen, das Feld zeigt die reale Verteilung.
Schwaechere CPU
Ein Mittelklasse-Telefon verarbeitet JavaScript um ein Vielfaches langsamer als ein Desktop. Lighthouse bildet das mit einer 4x-CPU-Drosselung nach -- lange Skripte blockieren den Hauptthread dort spürbar länger.
Höhere Netzlatenz
Mobilfunkverbindungen haben höhere Grundlatenzen und schwanken stark. Jeder zusaetzliche Round-Trip für DNS, Verbindung oder Ressourcen kostet mobil mehr Zeit als im Festnetz.
Kleiner Viewport
Auf einem schmalen Bildschirm ist der sichtbare Bereich klein. Welche Inhalte oberhalb der Falz liegen und welche Bildgröße wirklich gebraucht wird, unterscheidet sich grundlegend vom breiten Desktop-Layout.
LCP auf dem Smartphone: der häufigste Engpass
Unter den drei Vitals ist der Largest Contentful Paint mobil der schwierigste. Nur 62 Prozent (Web Almanac, 2025) der mobilen Seiten bestehen den LCP-Schwellenwert, während INP mit 77 Prozent (Web Almanac, 2025) und CLS mit 81 Prozent (Web Almanac, 2025) deutlich besser dastehen. LCP ist damit der primaere Flaschenhals -- und der hängt mobil besonders stark an Bildern, denn das größte sichtbare Element ist sehr oft ein Bild oder eine Hero-Grafik.
Hier liegt ein klassischer Mobilfehler: Dem Smartphone wird dieselbe große Bilddatei ausgeliefert wie dem Desktop. Ein Bild, das im breiten Layout 1.200 Pixel breit angezeigt wird, braucht auf einem schmalen Telefon vielleicht nur 400 Pixel -- liefert man trotzdem die große Datei, wandern unnoetige Bytes über das langsamere Mobilnetz. Laut web.dev gibt der sizes-Attributwert dem Browser die voraussichtliche Anzeigebreite vor, sodass dieser bereits die kleinstmögliche Datei wählt, bevor das Layout berechnet ist. In Kombination mit srcset bedient ein einziges Markup so jede Bildschirmgröße passend.
<!-- Mobil bekommt eine kleine Datei, Desktop eine große -->
<img
src="produkt-800.webp"
srcset="produkt-400.webp 400w,
produkt-800.webp 800w,
produkt-1200.webp 1200w"
sizes="(max-width: 600px) 90vw, 600px"
width="1200" height="800"
fetchpriority="high" alt="Produktansicht">Zwei Details auf dieser Markup-Ebene wirken stark. Erstens beschleunigt fetchpriority="high" das LCP-Bild, indem der Browser es früh anfordert, statt es hinter anderen Ressourcen einzureihen. Zweitens verhindern feste width- und height-Angaben, dass das Bild beim Laden noch Platz reserviert und Inhalte verschiebt -- das schuetzt direkt den CLS. Wer Bilder zusaetzlich in moderne Formate überführt, spart erneut Gewicht; wie das gelingt, vertieft unser Beitrag zur Bildoptimierung mit WebP und AVIF, die gerade mobil überproportional wirkt.
Der Viewport-Meta-Tag ist Pflicht
INP und Touch: wenn das Antippen hängt
Interaction to Next Paint misst, wie schnell die Seite sichtbar auf eine Eingabe reagiert -- mobil ist das meist eine Touch-Geste. Genau hier schlaegt die schwächere CPU am haertesten durch. Wenn beim Antippen eines Buttons ein langes JavaScript laeuft, blockiert es den Hauptthread, und die Seite reagiert erst verzögert. Auf dem Desktop verarbeitet ein schneller Kern dasselbe Skript in Bruchteilen, mobil zieht es sich. Das erklaert, warum der Desktop bei INP 97 Prozent (Web Almanac, 2024) gute Werte erreicht, das Smartphone aber deutlich darunter bleibt.
Verschärft wird das durch die schiere Menge an JavaScript, die mobil ausgeliefert wird. Der Web Almanac misst eine mediane JavaScript-Last von rund 615 KB (Web Almanac, 2025) auf Mobilgeräten -- mit steigender Tendenz, und ein großer Teil davon stammt aus Drittanbieter-Skripten wie Analyse-, Test-, Chat- und Tag-Manager-Werkzeugen. Jedes dieser Skripte konkurriert um denselben Hauptthread, der mobil ohnehin knapp ist. Wie sich solche externen Skripte gezielt reduzieren lassen, behandelt unser Beitrag zum Entschlacken von Third-Party-Scripts.
- Lange Aufgaben aufteilen, damit der Hauptthread regelmäßig für Eingaben frei wird
- Nicht dringende Arbeit verschieben, bis die Interaktion sichtbar quittiert ist
- Touch-Ziele mindestens rund 44 mal 44 CSS-Pixel groß und mit genug Abstand gestalten
- Event-Handler schlank halten und teure Berechnungen aus dem kritischen Pfad nehmen
- Drittanbieter-Skripte verzögert oder bedingt laden statt blockierend im Head
- Bei jedem Release die mobilen INP-Felddaten beobachten, nicht nur Laborwerte
Ein oft übersehener Aspekt ist die Gestaltung der Tippziele selbst. Liegen Buttons zu eng beieinander oder sind sie zu klein, verfehlt der Finger das Ziel, und der Nutzer tippt mehrfach -- was sich wie eine langsame Seite anfühlt, obwohl es ein Layout-Problem ist. Eine großzügige Gestaltung der Tippflächen gehoert deshalb genauso zur mobilen Performance wie schlanker Code. Wie sich JavaScript gezielt entlasten lässt, vertieft unser Beitrag zum INP optimieren.
CLS: Layout-Stabilität auf dem kleinen Schirm
Cumulative Layout Shift beschreibt, wie stark sich Inhalte beim Laden noch verschieben. Mobil ist dieses Problem besonders ärgerlich: Auf dem schmalen Bildschirm springt der Inhalt sichtbar, wenn ein nachgeladenes Bild, ein Werbeblock oder eine spät geladene Schrift den Text nach unten drueckt -- und der Nutzer tippt im falschen Moment auf das falsche Element. Mit 81 Prozent (Web Almanac, 2025) bestandener Seiten ist CLS mobil zwar der stärkste der drei Vitals, doch die verbleibenden Fälle sind oft frustrierende Fehlklicks.
Die Gegenmittel sind konkret. Bildern und Medien-Containern feste Dimensionen oder ein aspect-ratio mitgeben, damit der Browser den Platz von Anfang an reserviert. Schriften so laden, dass kein abrupter Wechsel die Zeilen verschiebt -- wie das gelingt, zeigt unser Beitrag zur Web-Font-Performance. Und dynamisch eingefuegte Elemente wie Banner möglichst nicht oberhalb bereits sichtbaren Inhalts platzieren, sondern Platz vorhalten. Auf dem kleinen Viewport fällt jede dieser Verschiebungen stärker ins Gewicht als auf dem weiten Desktop.
| Faktor | Desktop | Mobil | Mobile Konsequenz |
|---|---|---|---|
| CPU-Leistung | stark | gedrosselt (Lighthouse 4x) | JavaScript blockiert länger, INP leidet |
| Netzwerk | meist Festnetz | Mobilfunk, höhere Latenz | jeder Round-Trip kostet mehr Zeit |
| Viewport | breit | schmal | kleinere Bilder noetig, andere Falz |
| Eingabe | Maus, praezise | Touch, ungenauer | große Tippziele und Abstaende noetig |
| LCP-Bestehensquote | höher | 62 Prozent (Web Almanac) | Bilder sind der Hauptengpass |
Mobile-First messen statt mobil hinterherzubessern
Der wirksamste Ansatz ist, Mobile von Anfang an zum Maßstab zu machen, statt am Ende für das Smartphone nachzubessern. Das bedeutet, jede Aenderung unter gedrosselten Bedingungen zu prüfen und die Felddaten getrennt nach Gerätetyp zu lesen. Da der mobile Anteil am Umsatz mit rund 57 Prozent (Statista, 2024) überwiegt, ist die mobile Erfahrung nicht ein Sonderfall, sondern der Normalfall -- und entsprechend sollte sie priorisiert werden.
Wir kombinieren in der Praxis synthetische Lighthouse-Laeufe mit echtem Real User Monitoring, um Labor und Feld zusammenzubringen. Der Labortest mit 4x-CPU und Slow-4G-Profil deckt Regressionen reproduzierbar auf, bevor sie live gehen; die Felddaten zeigen, wie sich die Aenderung über die reale Geräte- und Netzvielfalt verteilt. Diese doppelte Sicht ist Teil unserer Performance-Leistungen, die Mobil und Desktop bewusst getrennt betrachten.
Mobile Performance scheitert selten am Code an sich, sondern an der Annahme, der eigene schnelle Rechner sei der Maßstab. Wer jede Aenderung unter gedrosselter CPU und im langsamen Netz prüft, sieht die Engpässe, bevor die Kunden sie spüren.
Mobile-Performance ist zudem kein isoliertes Thema, sondern hängt eng mit Server- und Datenseite zusammen. Eine langsame Datenbankabfrage verzögert die erste Antwort genauso mobil wie am Desktop -- nur fällt die Verzögerung auf dem Smartphone stärker ins Gewicht. Wie sich die serverseitige Antwortzeit verbessern lässt, zeigt unser Beitrag zur Datenbank-Query-Optimierung für Shop-Performance. Und welche Ressourcen der Browser vorab anfordern sollte, damit das kritische Mobil-Bild früh laedt, vertieft unser Beitrag zu Resource Hints mit Preload und Prefetch.
Der Kern in einem Satz
Der Aufwand lohnt sich doppelt. Bessere mobile Core Web Vitals stärken die organische Sichtbarkeit, weil Google die mobile Erfahrung bewertet, und sie senken zugleich die Absprungrate dort, wo der Umsatz tatsächlich entsteht. Da 53 Prozent (Google, 2018) der mobilen Besuche bei mehr als drei Sekunden Ladezeit abbrechen, ist jede eingesparte Hundertstelsekunde auf dem Smartphone unmittelbar geschaeftsrelevant -- der Hebel, den eine spezialisierte Core-Web-Vitals-Optimierung gerade für den mobilen Hauptkanal konsequent bedient.