Mobile Performance optimieren: schnell auf jedem Smartphone
Google bewertet Ihre Website anhand der mobilen Version, und die meisten Besucher sehen sie ohnehin zuerst auf dem Handy. Wir messen Mobile-First auf realistischen Geräten und beseitigen genau die Bremsen, die nur unterwegs auftreten.
60%+
der Seitenaufrufe in Deutschland mobil (Statcounter, 2024)
< 2,5 s
Ziel-LCP auf dem Smartphone
< 200 ms
Ziel-INP bei Touch-Eingaben
50+
optimierte Projekte
Viele Websites wirken schnell — solange man sie am Schreibtisch öffnet. Auf einem Mittelklasse-Smartphone im Mobilfunknetz sieht dieselbe Seite oft ganz anders aus: Der Hauptinhalt erscheint spät, Tippen fühlt sich zäh an, und beim Nachladen springt das Layout. Genau diese Lücke schließt Mobile-Performance-Optimierung. Wir messen Ihre Seiten unter realistischen mobilen Bedingungen, ordnen die Werte in die Core Web Vitals ein und beseitigen die Bremsen, die nur mobil sichtbar werden. Das ergänzt unsere Frontend-Optimierung um die Perspektive, die für Ranking und Umsatz entscheidend ist.
Mobile Messung: dieselbe Seite auf dem Gerät Ihrer Besucher
Mobile Performance · Festpreis-Einstieg
- Messung auf realistischem Gerät statt nur im Desktop-Browser
- Mobile Feld- und Labordaten im direkten Vergleich
- Full-Performance-Audit ab 1.490 € netto
- Core-Web-Vitals-Monitoring ab 59 € pro Monat netto
Der Performance-Quick-Check misst eine Schlüsselvorlage Mobile-First und liefert die wirksamsten Sofortmaßnahmen. Für mehrere Vorlagen empfehlen wir den Full-Performance-Audit ab 1.490 € netto; laufende Überwachung als Core-Web-Vitals-Monitoring ab 59 € pro Monat netto. Alle Preise und Pakete auf der Seite Preise. Die Erstanalyse Ihrer mobilen Ladezeit ist kostenlos.
Warum Mobilgeräte den Maßstab setzen
Über 60 Prozent aller Seitenaufrufe in Deutschland erfolgen über mobile Endgeräte (Statcounter, 2024). Google hat daraus die Konsequenz gezogen und indexiert Websites seit der Umstellung auf Mobile-First Indexing anhand ihrer mobilen Version. Was bedeutet das praktisch? Die Werte, die über Ihre Sichtbarkeit entscheiden, stammen nicht von einem leistungsstarken Rechner mit Glasfaseranschluss, sondern von einem Smartphone in einem durchschnittlichen Mobilfunknetz. Eine Seite, die im Desktop-Browser in einer Sekunde steht, kann mobil trotzdem in den roten Bereich fallen.
Der Unterschied hat zwei Ursachen. Erstens die Rechenleistung: Ein Mittelklasse-Smartphone braucht für dieselbe JavaScript-Menge ein Vielfaches der Zeit eines Desktop-Prozessors (Projekterfahrung). Zweitens das Netz: Mobilfunk bringt höhere Latenz, schwankende Bandbreite und Verbindungswechsel mit sich. Beides trifft ausgerechnet die Phase, in der die Seite sichtbar werden soll. Deshalb genügt es nicht, eine Website „auch mobil“ zu prüfen — die mobile Messung muss der Ausgangspunkt sein. Wie wir dabei vorgehen, beschreibt unsere Seite zur technischen Analyse im Detail.
Die typischen Mobil-Bremsen
Mobile Performance-Probleme wiederholen sich. In den meisten Projekten stoßen wir auf dieselben sechs Muster — sie erklären in der Praxis den größten Teil der Differenz zwischen Desktop- und Mobilwerten (Projekterfahrung).
JavaScript, das der Prozessor nicht schafft
Bundles, die auf dem Desktop kaum auffallen, blockieren auf dem Smartphone den Hauptthread für Hunderte Millisekunden. Wir teilen den Code auf, verschieben Nicht-Kritisches und brechen lange Aufgaben in kleine Stücke.
Bilder in Desktop-Größe
Ein Hero-Bild mit 2400 Pixeln Breite landet ungefragt auf einem 390 Pixel breiten Display. Mit responsiven Bildgrößen, moderner Kompression und passenden Formaten sinkt das übertragene Gewicht deutlich.
Drittanbieter-Skripte
Chat-Widgets, Karten, Einbettungen und Consent-Tools kosten mobil überproportional viel Zeit. Wir inventarisieren jedes Skript, laden es verzögert oder ersetzen es durch eine leichte Vorschau.
Schriften, die den Text verzögern
Werden Webfonts render-blockierend geladen, bleibt der Text unsichtbar oder springt beim Tausch. Self-Hosting, Subsetting und eine passende Anzeige-Strategie beseitigen beide Effekte.
Layout, das nachträglich springt
Banner, Einwilligungsdialoge und nachgeladene Werbeplätze schieben den Inhalt nach unten. Feste Platzhalter und reservierte Flächen halten das Layout auf kleinen Displays stabil.
Langsame erste Antwort
Auf dem Handy summieren sich Verbindungsaufbau und Serverdenkzeit besonders spürbar. Eine gezielte TTFB-Optimierung verkürzt die Zeit bis zum ersten Byte und wirkt auf jede weitere Metrik.
Core Web Vitals auf Mobilgeräten
Die drei Core Web Vitals gelten mobil wie am Desktop, aber die Ausgangslage ist eine andere. Google bewertet die Werte im Feld am 75. Perzentil über 28 Tage — es zählt also nicht der beste Messwert, sondern das Erlebnis der langsameren drei Viertel Ihrer Besucher. Die folgende Übersicht zeigt, worauf wir mobil besonders achten.
| Metrik | Was mobil anders ist | Unser Ansatz |
|---|---|---|
| LCP · Largest Contentful Paint | Hero-Bild und Schrift konkurrieren mit langsamer Verbindung | Priorisiertes Laden des Hauptbildes, moderne Formate, kein Render-Blocker davor |
| INP · Interaction to Next Paint | Touch-Eingaben treffen auf einen ausgelasteten Hauptthread | Lange Aufgaben aufbrechen, Event-Handler entschlacken, Arbeit verschieben |
| CLS · Cumulative Layout Shift | Schmale Displays reagieren empfindlicher auf nachgeladene Elemente | Feste Abmessungen, reservierte Flächen, stabile Einbettungen |
| TTFB · Time to First Byte | Höhere Latenz verstärkt jede Serververzögerung | Caching-Schichten, kurze Serverdenkzeit, frühzeitige Verbindungen |
| Seitengewicht | Datenvolumen und Akku sind reale Kosten für Ihre Besucher | Weniger Bytes statt nur andere Reihenfolge |
| Feld gegen Labor | Labordaten zeigen mobil oft ein zu freundliches Bild | Labormessung plus reale Nutzerdaten aus dem Chrome User Experience Report |
Dasselbe Skript, ganz andere Rechenzeit
Der entscheidende Unterschied zwischen Desktop und Mobil ist nicht die Bildschirmgröße, sondern die verfügbare Rechenzeit. Ein Skript, das auf einem Bürorechner in wenigen Millisekunden ausgewertet ist, beschäftigt ein Einstiegsgerät spürbar länger. Wir messen deshalb nicht nur, wie viel geladen wird, sondern wie lange das Gerät braucht, um es zu verarbeiten — und reduzieren gezielt die Arbeit, nicht nur die Dateigröße.
- Code-Splitting statt eines großen Bundles
- Nicht-kritische Skripte erst nach der ersten Darstellung
- Lange Aufgaben aufbrechen, damit Eingaben durchkommen
Der Daumen ist ungeduldig: INP im Blick
Auf dem Smartphone ist jede Interaktion eine Berührung: Menü öffnen, Filter setzen, in den Warenkorb legen. Interaction to Next Paint misst, wie lange es dauert, bis der Bildschirm darauf sichtbar reagiert. Bleibt der Hauptthread mit Skriptarbeit beschäftigt, wirkt die Seite hängend, obwohl sie längst geladen ist. Wir jagen genau diese Verzögerungen — sie kosten Vertrauen und Abschlüsse.
- Menüs, Filter und Warenkorb-Aktionen einzeln vermessen
- Event-Handler entschlacken und Arbeit auslagern
- Ergebnis im Feld prüfen, nicht nur im Labor
Wie schnell ist Ihre Seite auf dem Handy?
Wir messen Ihre wichtigsten Vorlagen Mobile-First, ordnen die Core Web Vitals ein und zeigen Ihnen die größten mobilen Bremsen — unverbindlich und kostenlos.
Mobile-First messen: Labor und Feld zusammen
Eine einzelne Messung sagt wenig. Labordaten sind reproduzierbar, aber künstlich; Felddaten spiegeln die Realität, reagieren jedoch träge auf Änderungen. Wir kombinieren beides und arbeiten in vier Schritten, die sich in jedem Projekt bewährt haben.
Geräte- und Netzprofil festlegen
Zuerst klären wir, mit welchen Geräten und Verbindungen Ihre Besucher tatsächlich kommen. Aus dieser Verteilung leiten wir das Messprofil ab: Rechenleistung, Bandbreite und Latenz werden entsprechend gedrosselt, damit die Messung Ihr Publikum abbildet und nicht unser Testgerät.
Mobile Labormessung je Vorlage
Jede relevante Seitenvorlage wird mehrfach gemessen und der Median gebildet. So fallen Ausreißer durch Netzschwankungen heraus. Wir dokumentieren nicht nur die Kennzahlen, sondern auch die Ursachen: welche Ressource blockiert, welche Aufgabe den Hauptthread belegt, welches Element den Layout-Sprung auslöst.
Felddaten gegenprüfen
Reale Nutzerdaten aus dem Chrome User Experience Report zeigen, wie Ihre Seite bei den langsameren drei Vierteln der Besucher ankommt. Weichen Labor und Feld stark voneinander ab, ist das selbst ein Befund — meist steckt eine bestimmte Gerätegruppe oder Region dahinter.
Maßnahmen priorisieren und umsetzen
Aus beiden Datenquellen entsteht ein Maßnahmenplan, sortiert nach erwarteter Wirkung und Aufwand. Die Umsetzung läuft in der Testumgebung, jede Änderung wird vorher und nachher mobil gemessen. Am Ende steht ein Vorher-Nachher-Vergleich, der die Wirkung belegt.
Touch-Eingaben, Menüs und Reaktionszeit
Mobil ist nahezu jede Interaktion eine Berührung, und der Nutzer hält das Gerät in der Hand — Verzögerungen fallen deshalb stärker auf als mit Maus und Tastatur. Interaction to Next Paint bewertet die langsamste relevante Interaktion einer Sitzung. Es genügt also nicht, dass die Startseite schnell erscheint; auch das Öffnen des Menüs, das Setzen eines Filters und das Absenden eines Formulars müssen zügig reagieren. Typische Verursacher sind:
- Große Event-Handler, die bei jedem Tippen umfangreiche Arbeit anstoßen
- Nachladende Skripte, die währenddessen den Hauptthread belegen
- Animationen, die Layout und Neuberechnung erzwingen statt nur zu verschieben
- Filter- und Suchfunktionen, die bei jeder Eingabe die gesamte Liste neu aufbauen
- Consent- und Tracking-Skripte, die beim ersten Klick nachträglich starten
- Zu große DOM-Bäume, bei denen jede Änderung teuer wird
Wie sich diese Effekte messen und beheben lassen, beschreiben wir ausführlich im Beitrag INP optimieren. Ergänzend lohnt der Blick in unseren Artikel zu Mobile Performance, der die wichtigsten Hebel für Smartphones zusammenfasst.
Netz, Latenz und der Weg zum ersten Byte
Mobilfunk unterscheidet sich vom Festnetz vor allem in der Latenz. Jede zusätzliche Verbindung, jede Weiterleitung und jede Anfrage an eine fremde Domain kostet unterwegs mehr Zeit als am Schreibtisch. Deshalb wirken mobil Maßnahmen besonders stark, die die Anzahl der Runden zwischen Gerät und Server verringern: moderne Protokolle, frühzeitiger Verbindungsaufbau zu wirklich benötigten Domains, konsequente Kompression und ein Cache, der Wiederkehrer ohne erneute Serveranfrage bedient.
Zugleich bleibt die Serverdenkzeit wichtig: Ist die erste Antwort langsam, verschiebt sich alles Nachfolgende. Unsere Server-Optimierung und die passenden Caching-Strategien setzen genau hier an. Auf schmalen Verbindungen zahlt sich außerdem jede eingesparte Datei aus — Hintergründe dazu finden Sie in unserem Beitrag zu TTFB und Server-Antwortzeit.
Praxistipp: Erst messen, dann drosseln
Bilder, Schriften und Layout auf kleinen Displays
Bilder machen häufig den größten Anteil am Seitengewicht aus (HTTP Archive Web Almanac). Mobil wirkt das doppelt: Die Datenmenge muss über eine langsamere Verbindung, und das Gerät muss sie anschließend dekodieren. Drei Bereiche bringen hier den größten Gewinn.
Responsive Bilder statt einer Größe für alle
Jedes Bild wird in mehreren Auflösungen bereitgestellt, das Gerät wählt die passende. Zusammen mit modernen Formaten sinkt das übertragene Gewicht deutlich, ohne dass die Darstellung leidet. Details dazu auf unserer Seite zur Bilder-Optimierung.
Schriften ohne Nachladeruck
Selbst gehostete Schriften, auf die benötigten Zeichen reduziert und mit einer passenden Anzeige-Strategie eingebunden, verhindern unsichtbaren Text und den späteren Tausch. Auf kleinen Displays ist dieser Sprung besonders auffällig.
Reservierte Flächen für alles Nachgeladene
Banner, Einwilligungsdialoge, Bewertungssterne und Karten brauchen von Anfang an ihren Platz. Wo die Fläche vorab feststeht, kann das Layout beim Nachladen nicht mehr springen — CLS bleibt stabil.
Typische mobile Optimierungsverläufe
Anonymisierte Projektbeispiele (Projekterfahrung), illustrativ. Ergebnisse hängen von Ausgangslage, Plattform und Umfang ab.
Mobile Performance und Ihr System
Mobile Optimierung ist plattformübergreifend gedacht: Die Messmethode und die Hebel bleiben gleich, unabhängig davon, ob Ihre Seite auf einem Content-Management-System, einem Shopsystem oder einer eigenen Anwendung läuft. Die konkrete Umsetzung unterscheidet sich allerdings je nach Technik. Für WordPress-Installationen beschreibt unsere Seite zur WordPress-Performance die systemspezifischen Schritte von Caching bis Plugin-Audit. Für Shops auf Shopware finden Sie die Details unter Shopware-Performance, für Online-Shops allgemein unter PageSpeed im E-Commerce.
Diese Seite beantwortet die Frage „Wie wird meine Website auf dem Smartphone schnell?“ — die Systemseiten beantworten „Wie setze ich das in meiner Plattform um?“. Beide greifen ineinander: Ohne mobile Messung fehlt der Maßstab, ohne systemspezifische Umsetzung bleibt der Maßnahmenplan Theorie. Welche Kombination für Sie sinnvoll ist, klären wir in der kostenlosen Erstanalyse; die zugehörigen Pakete und Preise finden Sie auf der Seite Preise.
Mobile Performance in Kürze
- Google bewertet die mobile Version — die mobile Messung ist der Maßstab, nicht der Desktop-Eindruck
- Rechenleistung und Netzlatenz sind die beiden Ursachen für die Desktop-Mobil-Lücke
- LCP, INP und CLS brauchen mobil eigene Maßnahmen, nicht nur eine Wiederholung der Desktop-Arbeit
- Labordaten und Felddaten zusammen ergeben ein belastbares Bild
- Einstieg über den Performance-Quick-Check ab 349 € netto, Erstanalyse kostenlos