Mobile-First Shopify-Speed: Optimierung für 3G und langsame Geräte

Wichtigste Erkenntnisse

• Shopify Mobile Speed (mobile Ladegeschwindigkeit) ist ein anderes Problem als auf dem Desktop. Smartphones haben langsamere CPUs und nutzen variable Netzwerke, und auf Mobilgeräten finden die meisten Storefront-Besuche und Conversions statt.
• Google bewertet drei Core Web Vitals auf Mobilgeräten: LCP, CLS und INP. Sie werden anhand von echten Felddaten (Field Data) im 75. Perzentil gemessen und für Mobile separat ausgewiesen.
• Die Taktiken, die wirklich etwas bringen, sind Responsive Images aus dem Shopify-CDN, Lazy-Loading von Medien Below-the-Fold, das Zurückstellen (Deferring) von nicht-kritischem JavaScript und das Reduzieren von App-Skripten.
• App-Bloat ist der größte Killer für die mobile Geschwindigkeit. Jede Widget-App injiziert ihr eigenes JavaScript auf jeder Seite, und das muss auch auf dem Smartphone ausgeführt werden.
• Fudge schreibt schlanken, nativen Theme-Code, anstatt eine weitere Widget-App hinzuzufügen, sodass ein Feature ohne die Skript-Steuer (Script Tax) ausgeliefert wird, die eine App bei jedem Seitenaufruf erhebt.

Die Shopify Mobile Speed in den Griff zu bekommen, ist nicht dieselbe Aufgabe wie die Optimierung für den Desktop. Eine Seite, die sich auf einem Laptop mit Glasfaserverbindung sofort aufbaut, kann auf einem Mittelklasse-Smartphone in einem lückenhaften Mobilfunknetz ewig brauchen. Und da der meiste Shopify-Traffic und die meisten Shopify-Checkouts auf Smartphones stattfinden, ist die mobile Version diejenige, die tatsächlich über deinen Umsatz entscheidet.

Dieser Leitfaden behandelt, warum Mobile schwieriger ist, welche Core Web Vitals Google bewertet, die konkreten Taktiken, die mobile Page-Speed-Probleme reduzieren, und wie du testen kannst, wie deine langsamsten Kunden den Shop erleben.

Warum du uns vertrauen kannst

Jacques hat über 15 Jahre Entwicklererfahrung und hat an der Storefront-Performance von hunderten Shopify-Shops gearbeitet. Wir entwickeln Fudge, einen KI-Storefront-Editor mit einer 5,0-Bewertung im Shopify App Store. Wir arbeiten also genau an der Theme-Ebene, auf der die mobile Geschwindigkeit stattfindet, und sehen, was ein aufgeblähter App-Stack mit einem Smartphone anstellt.

Warum mobile Geschwindigkeit ein anderes Problem ist als Desktop

Das gleiche Theme läuft auf beiden, aber die Bedingungen sind nicht gleich.

Smartphones haben langsamere CPUs. Ein Mittelklasse-Android-Gerät parst und führt JavaScript viel langsamer aus als ein Desktop-Rechner. Skriptlastige Seiten, die sich auf einem Laptop flüssig anfühlen, können auf einem Smartphone ins Stocken geraten, weil das Handy länger im Main Thread damit verbringt, denselben Code auszuführen.

Mobilfunknetze sind variabel. Ein Käufer könnte zu Hause im schnellen 5G sein und zehn Minuten später im Zug im langsamen 3G. Jeder zusätzliche Request und jedes überdimensionierte Bild kostet bei einer langsamen Verbindung mit hoher Latenz mehr Zeit.

Mobile bringt das Geld. Bei den meisten Shopify-Shops macht Mobile den Großteil der Sitzungen (Sessions) und Bestellungen aus. Das macht den mobilen Render Path zu dem, auf den du deine Bemühungen zuerst konzentrieren solltest.

Das Ziel ist also kein guter Desktop-Score. Es ist eine Seite, die auf einem günstigen Smartphone und einer langsamen Verbindung schnell bleibt, denn das beschreibt einen großen Teil der echten Kunden.

Core Web Vitals auf Mobilgeräten: die Metriken, die Google bewertet

Googles Page-Experience-Signale basieren auf den Core Web Vitals. Es gibt drei davon, und INP wurde 2024 zu einem stabilen Core Web Vital und ersetzte den First Input Delay.¹

Die Schwellenwerte sind auf Mobile und Desktop gleich, aber die Zahlen, die du erreichst, sind es nicht. Auf einem Smartphone treibt ein großes Hero-Image den LCP in die Höhe, und schwere Skripte verschlechtern den INP, da der Main Thread beschäftigt bleibt.

Warum die Felddaten mobil-gewichtet sind

Google bewertet die Core Web Vitals anhand von echten Felddaten (Field Data) und nicht anhand eines einzelnen Labortests. Diese Daten stammen aus dem Chrome User Experience Report und werden im 75. Perzentil der Besuche ausgewertet. Ein Shop besteht also nur, wenn drei Viertel der tatsächlichen Sessions den Schwellenwert erreichen.¹

Diese Felddaten werden für Mobile und Desktop separat ausgewiesen. In Kombination mit Mobile-First-Indexing, bei dem Google vorwiegend die mobile Version einer Seite für Indexierung und Ranking nutzt, ist die praktische Schlussfolgerung simpel: Deine Mobile Experience ist diejenige, die wirklich ins Gewicht fällt.

Für den breiteren Kontext dazu, wo Shopify-Shops tatsächlich stehen, sieh dir unseren Report zum Stand der Shopify-Performance an.

Wie du die mobile Geschwindigkeit in Shopify verbesserst

Die Erfolge konzentrieren sich auf wenige Bereiche: Bilder, Skripte und Layout-Stabilität. Hier lohnt es sich, Arbeit reinzustecken.

Liefere Responsive Images über das Shopify-CDN aus

Bilder sind in der Regel das Schwerste auf einer Produkt- oder Kategorie-Seite, und Smartphones brauchen keine Dateien in Desktop-Größe.

Das Bild-CDN von Shopify kann die Größe eines Bildes on-the-fly anpassen. Der image_url-Liquid-Filter liefert eine CDN-URL in genau der Breite, die du anfragst, und das CDN stellt automatisch ein modernes Format wie WebP oder AVIF bereit, wenn der Browser es unterstützt.²

Kombiniere das mit srcset und sizes, damit der Browser eine an das Gerät angepasste Datei herunterlädt. Mit Breiten-Deskriptoren im srcset und einem sizes-Hint wählt der Browser die kleinste Quelle, die noch scharf aussieht. Das erspart einem Smartphone, ein 2000px-Bild in einen 400px-Slot zu laden.³

Der größte Einzelgewinn beim LCP auf Mobilgeräten ist normalerweise das Verkleinern des Hero-Images. Für eine vollständige Anleitung siehe Bilder in Shopify komprimieren.

Lazy-Loading für Medien Below-the-Fold

Alles Below-the-Fold (im nicht sofort sichtbaren Bereich) kann warten. Das native loading="lazy"-Attribut bei einem <img> sagt dem Browser, dass er das Bild zurückstellen soll, bis es sich dem Viewport nähert. Das reduziert die Anzahl der konkurrierenden Requests beim ersten Laden.⁴

Nutze es für Bilder und Iframes weiter unten auf der Seite: Lifestyle-Bilder, Bewertungssektionen, Footer-Logos, eingebettete Videos. Verwende Lazy-Loading nicht für das LCP-Element selbst, denn wenn du dein Hero-Image aufschiebst, wird der LCP schlechter, nicht besser.

Details dazu, auch zum Umgang mit eingebetteten Videos, findest du unter Lazy Loading für Bilder in Shopify.

Nicht-kritisches JavaScript zurückstellen (defer)

JavaScript ist das, was dem INP auf Mobilgeräten am meisten schadet, da die langsamere CPU des Handys länger für die Ausführung braucht und der Main Thread blockiert bleibt.

Alles, was nicht für den First Paint benötigt wird, sollte ihn nicht blockieren. Füge Skripten ein defer hinzu, damit sie laden, ohne das Rendering aufzuhalten, und lade nicht essenzielle Widgets erst, wenn die Seite interaktiv ist, anstatt im <head>.

Render-blocking Scripts (Rendering-blockierende Skripte) verdienen einen eigenen Durchlauf. Siehe Wie man Render-blocking Scripts in Shopify behebt für die Details.

App-Skripte reduzieren

Das ist der Punkt, den die meisten Shops unterschätzen. Fast jede Widget-App injiziert ihr eigenes JavaScript in deine Storefront, und dieses Skript läuft auf dem Smartphone auf jeder einzelnen Seite. Ein Stack aus einem Dutzend Apps kann eine Payload erzeugen, die durch kein noch so gutes Bild-Tuning ausgeglichen werden kann.

Überprüfe, was jede App tatsächlich kostet. Entferne Apps, die du nicht mehr nutzt. Und für Features, die du direkt im Theme bauen kannst, solltest du nativen Code einem weiteren Script-Tag vorziehen. Mehr dazu im Abschnitt unten.

Critical CSS hinzufügen und font-display setzen

Zwei kleinere Optimierungen, die beim First Paint helfen:

• Critical CSS. Binde die Styles, die für das Rendering des oberen Teils der Seite (Above-the-Fold) benötigt werden, inline ein. So kann der Browser die Seite schon mal aufbauen, bevor er das komplette Stylesheet abruft.
• font-display: swap. Lass Text sofort in einer Fallback-Schriftart rendern, während die eigentliche Web-Font lädt, anstatt eine leere Fläche zu hinterlassen. Das verhindert unsichtbaren Text bei langsamen Verbindungen.

Layout-Shift durch Banner und Hero-Sections stoppen

Der CLS ist oft der am einfachsten zu behebende Vital-Wert, da die Ursachen strukturell sind. Layout-Sprünge entstehen durch Elemente, die spät laden und den Inhalt nach unten drücken: eine Announcement-Bar, ein Hero-Image ohne reservierten Platz, ein Cookie-Banner oder ein spät injiziertes App-Widget.

Reserviere Platz für alles, was nach dem First Paint geladen wird. Gib Bildern explizite width- und height-Attribute, damit der Browser den Platz reserviert, bevor die Datei ankommt, und vermeide es, Banner über Content einzufügen, der bereits gerendert wurde.

Wie man mit 3G und auf langsamen Geräten testet

Du kannst die mobile Ladegeschwindigkeit nicht von deinem eigenen Smartphone im Büro-WLAN aus beurteilen. Du musst die Bedingungen simulieren, mit denen deine langsamsten Kunden konfrontiert sind.

Führe Lighthouse im Mobile-Modus aus. In den Chrome DevTools nutzt das Lighthouse-Panel standardmäßig ein simuliertes Mittelklasse-Smartphone mit gedrosselter CPU und Netzwerk. Das kommt der mobilen Realität viel näher als ein Desktop-Test.

Drossle das Netzwerk. Setze das Throttling im Network-Tab der DevTools auf ein langsames Profil wie “Slow 3G” und lade die Seite neu. Das deckt die Requests auf, die bei einer Verbindung mit hoher Latenz schmerzen und bei einer schnellen Verbindung nicht auffallen.

Drossle die CPU. Wende im Performance-Tab ein 4x- oder 6x-CPU-Slowdown an, um ein Low-End-Smartphone zu emulieren. Schweres JavaScript, das auf deinem Rechner augenblicklich ausgeführt wird, zeigt hier seine wahren Kosten – genau das misst der INP.

Prüfe auch die Felddaten. Labortests decken vieles auf, aber Google bewertet anhand von Felddaten (Field Data). Behalte den Core-Web-Vitals-Bericht in der Google Search Console im Auge, der nach Mobile und Desktop segmentiert ist. So kannst du bestätigen, dass auch echte Besucher die Tests bestehen und nicht nur deine Laborläufe.

Teste nach jeder größeren Änderung, besonders nach der Installation einer App. Eine App, die im Admin-Bereich harmlos aussieht, kann jeder Seite echtes Gewicht hinzufügen.

App-Bloat ist der wahre Killer der mobilen Geschwindigkeit

Wenn du eine einzige Sache behebst, dann diese. Bilder und CSS sind wichtig, aber die größte und häufigste Bremse für die mobile Shopify-Geschwindigkeit ist der App-Stack.

Das Muster wiederholt sich quer durch alle Shops. Jede App, die ein sichtbares Feature hinzufügt (eine Sticky-Bar, ein Bewertungs-Widget, ein Upsell-Popup, ein Währungs-Selector), bringt normalerweise ihr eigenes JavaScript mit, und dieses Skript lädt auf dem Smartphone auf jeder relevanten Seite. Einzeln betrachtet wirkt jedes klein. Zusammen blockieren sie den Main Thread, verzögern die Interaktivität und blähen den INP auf.

Die schlimmsten Übeltäter verursachen außerdem Layout-Shifts, weil sie ihr UI injizieren, nachdem die Seite bereits gerendert wurde. Dadurch wird der Inhalt verschoben und der CLS leidet.

Die Lösung besteht nicht darin, das einfach als Preis für Features hinzunehmen. Viele dieser Funktionen benötigen nur eine kleine Menge an Theme-Code. Wenn du sie nativ baust, anstatt eine weitere App hinzuzufügen, wird das Feature ohne die Skript-Steuer pro Seite ausgeliefert. Wenn dein Shop bereits langsam ist, setze genau dort an, bevor du etwas Neues hinzufügst: Wie du ein Shopify-Theme schneller machst führt dich durch das Audit.

Wie Fudge ins Spiel kommt

Der übliche Weg, ein Storefront-Feature hinzuzufügen, ist die Installation einer App. Aber jede App, die du installierst, bedeutet mehr JavaScript auf jeder Seite, was sich am stärksten auf Mobilgeräten bemerkbar macht.

Fudge geht den anderen Weg. Es ist ein KI-Storefront-Editor, der nativen Theme-Code schreibt. Du beschreibst, was du willst, und die KI schreibt das Liquid, CSS und JavaScript direkt in dein Theme.

Da der Output nativ ist, bringt ein Feature, das du mit Fudge baust, kein Drittanbieter-Widget oder ein zusätzliches App-Skript mit, das auf jeder Seite geladen werden muss. Das ist der Unterschied, der sich in deinen mobilen Core Web Vitals zeigt: weniger Render-blocking Scripts, weniger Arbeit für den Main Thread und kein spät injiziertes Widget, das Layout-Shifts verursacht.

Und da es sich um Theme-Code handelt, überlebt er auch eine Deinstallation. Alles, was du mit dem Shopify-Store-Editor baust, bleibt in deinem Theme, auch wenn du kündigst – im Gegensatz zu einem von einer App gerenderten Element, das in dem Moment verschwindet, in dem du die App entfernst.

FAQ