Auf dem Smartphone laden Seiten über schwankende Mobilfunkverbindungen und mit schwächeren Prozessoren als am Rechner. Wer die mobile Ladezeit verbessern will, sollte deshalb wissen, welche Teile des Ladevorgangs auf dem Smartphone die meiste Zeit kosten. Google nennt als Zielwerte einen Largest Contentful Paint (LCP) innerhalb von 2,5 Sekunden und einen Interaction to Next Paint (INP) unter 200 Millisekunden [1]. Gemessen wird beim 75. Perzentil aller Seitenaufrufe, getrennt nach Mobilgeräten und Desktop [2]. Dieser Ratgeber ordnet die Maßnahmen danach, an welcher Stelle des Ladevorgangs sie ansetzen. Wie Sie die mobilen Werte messen und Felddaten von Labortests unterscheiden, erklärt der Ratgeber Core Web Vitals auf Mobilgeräten.
Wo die Zeit verloren geht
Das Team von web.dev zerlegt den LCP in vier Teilzeiten: die Zeit bis zum ersten Byte der Serverantwort, die Verzögerung, bis das Hauptbild zu laden beginnt, die Ladedauer des Bildes selbst und die Verzögerung, bis es dargestellt wird [3]. Als grobe Richtlinie für eine gut optimierte Seite nennt web.dev etwa 40 Prozent für die Serverantwort, etwa 40 Prozent für das Laden der Ressource und jeweils unter 10 Prozent für die beiden Verzögerungen [3]. Die beiden Verzögerungen sollten möglichst nahe bei null liegen.
Für die Praxis heißt das: Bevor Sie Bilder komprimieren, lohnt der Blick, welcher Teil bei Ihrer Seite aus dem Rahmen fällt. web.dev schreibt selbst, dass die reine Ladedauer der Ressource bei den meisten Websites nicht der wesentliche Engpass ist, und rät, die Daten echter Besucher heranzuziehen [3].
| Teilzeit | Typische Ursache auf dem Smartphone | Ansatz |
|---|---|---|
| Serverantwort | kein Seitencache, Weiterleitungsketten, langsamer Verbindungsaufbau | Caching, Weiterleitungen kürzen |
| Verzögerung bis zum Laden | Hauptbild erst über CSS oder Skript gefunden, Lazy Loading | Bild im HTML, hohe Priorität |
| Ladedauer | zu große Bilddatei, Webschrift als größtes Element | passende Größe, Kompression, Formate |
| Verzögerung bis zur Anzeige | blockierende Stylesheets und Skripte | Skripte verschieben, CSS verschlanken |
Die Serverantwort beschleunigen
Die Zeit bis zum ersten Byte, kurz TTFB, setzt sich aus Weiterleitungen, dem Start eines Service Workers, der DNS-Abfrage, dem Verbindungs- und TLS-Aufbau und der eigentlichen Antwort des Servers zusammen [4]. Als groben Richtwert nennt web.dev eine TTFB von 0,8 Sekunden oder weniger, mehr als 1,8 Sekunden gelten als schlecht [4]. Die TTFB ist selbst kein Core-Web-Vitals-Wert, sie ist aber die erste der vier Teilzeiten des LCP [3, 4].
Auf dem Smartphone fällt jeder zusätzliche Verbindungsaufbau stärker ins Gewicht. Prüfen Sie deshalb zuerst Weiterleitungsketten, etwa von http auf https und von ohne auf mit www, die bei Aufrufen aus Suchergebnissen oder Werbelinks vor der eigentlichen Seite stehen. Danach kommt der Seitencache: Ein Content-Management-System, das jede Seite bei jedem Aufruf neu aus der Datenbank baut, antwortet langsamer als eines, das fertige Seiten ausliefert. Bei Besuchern aus vielen Regionen verkürzt ein Content Delivery Network den Weg zur Ressource [3].
Noch eine Frage offen?
In der gratis Sprechstunde beantworten wir Fragen zu SEO live, jeden ersten Samstag im Monat um 18 Uhr. Oder Sie rufen einfach an.
Das Hauptbild früh laden
Auf vielen Mobilseiten ist das größte sichtbare Element ein Bild: das Titelbild eines Artikels, das Produktfoto oder eine große Fläche im Kopfbereich. Drei Regeln aus der Anleitung von web.dev wirken hier am stärksten [3]:
- Das Bild steht als img-Element im HTML, damit der Browser es sofort findet. Ein Hintergrundbild aus dem Stylesheet oder ein Bild, das erst ein Skript einfügt, entdeckt der Browser später.
- Das Hauptbild wird nie mit Lazy Loading geladen. Ein loading="lazy" am LCP-Bild verzögert seinen Start immer.
- Das Attribut fetchpriority="high" am Hauptbild teilt dem Browser mit, dass es Vorrang hat. Mehr als ein oder zwei Bilder sollten diese Priorität nicht bekommen, sonst verliert sie ihre Wirkung.
Lazy Loading bleibt für alle Bilder weiter unten auf der Seite sinnvoll. Wie Sie es richtig einsetzen, steht im Ratgeber Lazy Loading richtig einsetzen.
Bilder und Schriften verkleinern
Das LCP-Element ist laut web.dev entweder ein Bild oder Text in einer Webschrift, und für beide gibt es eigene Wege zur kleineren Datei: passende Bildgröße, moderne Bildformate, Kompression und kleinere Schriftdateien [3]. Auf dem Smartphone fällt die Bildgröße besonders ins Gewicht, weil die Bildschirme schmal sind. Ein Titelbild in 2.400 Pixeln Breite für einen Bildschirm, der 400 CSS-Pixel breit ist, überträgt ein Vielfaches der nötigen Daten. Mit srcset und sizes wählt der Browser selbst die passende Datei. Die Technik beschreibt der Ratgeber Responsive Bilder mit srcset.
Bei Schriften hilft es, nur die Schnitte zu laden, die die Seite wirklich nutzt. Jede zusätzliche Stärke und jede Kursive ist eine eigene Datei, die vor der Textdarstellung geladen werden kann.
Schnelles Laden nützt wenig, wenn die Seite dabei springt. Auf dem schmalen Bildschirm schieben nachladende Bilder den Text besonders weit nach unten, und Besucher tippen dann daneben. web.dev rät, für Bilder und Videos immer die Attribute width und height anzugeben oder den Platz mit der CSS-Eigenschaft aspect-ratio zu reservieren, damit der Browser die Fläche schon vor dem Laden freihält [7]. Das verbessert den dritten Core-Web-Vitals-Wert, den Cumulative Layout Shift.
JavaScript zähmen
Für die Reaktion auf Eingaben zählt vor allem der Hauptthread des Browsers. Er kann jeweils nur eine Aufgabe abarbeiten, und jede Aufgabe über 50 Millisekunden gilt als lange Aufgabe, während der der Browser Eingaben blockiert [5]. Auf einem Smartphone mit langsamerem Prozessor dauern dieselben Skripte länger als am Rechner. Ein Menü, das am Rechner sofort aufgeht, reagiert mobil dann spürbar träge.
Drei Ansätze helfen. Erstens Skripte entfernen, die keine Aufgabe mehr haben, etwa alte Tracking-Codes, nicht genutzte Slider oder doppelt eingebundene Bibliotheken. Zweitens Skripte, die nicht für den ersten Bildschirm gebraucht werden, mit defer oder später laden. Drittens lange Aufgaben in kleinere Stücke teilen, damit der Browser zwischendurch auf Eingaben reagieren kann [5]. Gerade Drittanbieter-Skripte für Chats, Werbung oder Einbettungen sind nach unserer Erfahrung häufig die größten Posten.
Die Reihenfolge in der Praxis
Für eine typische Unternehmenswebsite empfehlen wir diese Reihenfolge, weil die ersten Schritte wenig Aufwand machen und die meisten Seiten auf einmal betreffen:
- Weiterleitungsketten auflösen und den Seitencache prüfen.
- Das Hauptbild jeder Vorlage ohne Lazy Loading und mit fetchpriority="high" ausliefern.
- Bildgrößen mit srcset an die Bildschirmbreite anpassen.
- Ungenutzte Skripte und Schriftschnitte entfernen, übrige Skripte verschieben.
- Lange Aufgaben im verbleibenden JavaScript aufteilen.
Danach messen Sie erneut. PageSpeed Insights zeigt die Felddaten echter Besucher aus dem Chrome User Experience Report über einen Zeitraum von 28 Tagen [6]. Eine Änderung ist dort also erst nach etwa vier Wochen vollständig zu sehen, im Labortest dagegen sofort. Für den schnellen Labortest zwischendurch eignet sich auch unser kostenloses Werkzeug PageSpeed.de, das Lighthouse für Mobil oder Desktop ausführt und dazu den Server prüft. Wie Ladezeit, Inhalt und Bedienung im Mobile SEO zusammenhängen, zeigt der Überblick Mobile SEO Grundlagen. Wer die Arbeit abgeben möchte, findet sie auf der Seite Core Web Vitals verbessern.
Sie wissen nicht, welche Teilzeit bei Ihrer Seite das Problem ist? Bringen Sie eine Adresse und einen Bericht aus PageSpeed Insights in die gratis Sprechstunde, dann sehen wir uns die Aufschlüsselung gemeinsam an.
- Organisation Core Web Vitals und Google-Suchergebnisse. Google Search Central. Stand 18.12.2025. abgerufen am 31.10.2026
- Organisation Web Vitals (Philip Walton). web.dev (Google). Stand 31.10.2024. abgerufen am 31.10.2026
- Organisation Largest Contentful Paint optimieren. web.dev (Google). Stand 31.03.2025. abgerufen am 31.10.2026
- Organisation Zeit bis zum ersten Byte (TTFB). web.dev (Google). Stand 21.01.2025. abgerufen am 31.10.2026
- Organisation Lange Aufgaben optimieren. web.dev (Google). Stand 19.12.2024. abgerufen am 31.10.2026
- Organisation Über PageSpeed Insights. Google for Developers. Stand 25.07.2025. abgerufen am 31.10.2026
- Organisation Cumulative Layout Shift optimieren. web.dev (Google). Stand 07.02.2025. abgerufen am 31.10.2026
Häufige Fragen
Welche Ladezeit ist auf dem Smartphone gut?
Google nennt für den Largest Contentful Paint einen Zielwert innerhalb von 2,5 Sekunden und für INP unter 200 Millisekunden. Gemessen wird beim 75. Perzentil aller Aufrufe, getrennt für Mobilgeräte und Desktop.
Darf ich das Titelbild mit Lazy Loading laden?
Nein. web.dev schreibt, dass das LCP-Bild nie mit Lazy Loading geladen werden soll, weil das seinen Start immer verzögert. Lazy Loading gehört an Bilder weiter unten auf der Seite.
Was bringt fetchpriority="high"?
Das Attribut sagt dem Browser, dass ein Bild wichtiger ist als andere. Setzen Sie es am Hauptbild der Seite und an höchstens ein oder zwei Bildern, sonst verliert die Angabe ihre Wirkung.
Ist die Serverantwortzeit ein Core-Web-Vitals-Wert?
Nein, die TTFB gehört nicht zu den Core Web Vitals. Sie ist aber Teil des LCP. web.dev nennt 0,8 Sekunden oder weniger als groben Richtwert.
Wann sehe ich die Wirkung meiner Änderungen?
In Labortests sofort. Die Felddaten echter Besucher in PageSpeed Insights umfassen einen Zeitraum von 28 Tagen, deshalb lohnt ein Vergleich nach etwa vier Wochen.
Noch eine Frage offen?
In der gratis Sprechstunde beantworten wir Fragen zu SEO live, jeden ersten Samstag im Monat um 18 Uhr. Oder Sie rufen einfach an.
Zuletzt geprüft am 03.11.2026, nächste Prüfung spätestens im November 2027. Haben Sie einen Fehler entdeckt? Schreiben Sie uns.
