Kurz zusammengefasst:
- Ladezeit ist ein Conversion-Faktor, aber kein Wachstumsprogramm. Wer den Page Speed optimiert, holt Reibung aus dem Kaufprozess. Umsatzsprünge entstehen trotzdem meist über Angebot, Struktur und Kommunikation.
- Mobile entscheidet. In vielen unserer Projekte liegt der mobile Traffic-Anteil bei über 90 %. Wenn du Performance nur am Desktop prüfst, misst du an der Realität deiner Käufer vorbei.
- Die Bremse ist selten Shopify selbst. Die größten Probleme entstehen durch Drittanbieter-Apps, veralteten Custom-Code und Page-Builder-Erweiterungen.
- Score-Jagd ist Zeitverschwendung. Ein besserer Wert in PageSpeed Insights ist kein Ziel. Das Ziel ist eine schnellere gefühlte Nutzung auf den Seiten, die deinen Umsatz tragen.
- Performance und Testing schließen sich nicht aus. Wir laden Testvarianten möglichst direkt im Shop, um Flicker-Effekte und zusätzliche Ladezeit zu vermeiden.
Warum Ladezeit direkt auf deinen Umsatz durchschlägt
Ich werde selten gefragt, ob Ladezeit wichtig ist. Fast jeder Shopbetreiber weiß, dass sie eine Rolle spielt. Die spannendere Frage ist eine andere: Wie viel Umsatz kostet dich eine langsame Seite wirklich, und wo genau entsteht der Schaden?
Meine Antwort nach über 1.000 A/B-Tests: Der Schaden entsteht fast nie dort, wo ihn die meisten vermuten. Nicht in einem abstrakten Google-Ranking-Faktor, sondern im Kopf des Nutzers, der gerade auf einer Produktseite steht und sich unbewusst fragt, ob sich das Warten lohnt.
Kaufentscheidungen im E-Commerce sind selten rein rational. Menschen entscheiden heuristisch, emotional und kontextabhängig. Eine langsame Seite sendet ein klares Signal: Anstrengung. Und Anstrengung ist im Onlineshop teuer, weil die Alternative immer nur einen Zurück-Button entfernt ist.
Dazu kommt der Effekt auf deine Akquisitionskosten. Du bezahlst für jeden Klick, unabhängig davon, ob die Seite in 1,4 oder in 5,8 Sekunden nutzbar ist. Jede Sekunde, in der Nutzer abspringen, bevor sie dein Angebot überhaupt gesehen haben, ist bezahlter Traffic ohne Chance auf Conversion.
Was Page Speed wirklich misst: Core Web Vitals ohne Buzzwords
Wenn Leute von Page Speed sprechen, meinen sie meistens eine einzige Zahl aus einem Google-Tool. Sinnvoller ist es, drei Dimensionen zu trennen: Wie schnell sehe ich etwas, wie schnell kann ich etwas tun, und wie stabil bleibt die Seite dabei.
Genau das beschreiben die Core Web Vitals:
| Metrik | Was sie misst | Guter Wert | Was der Nutzer spürt |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Wann das größte sichtbare Element geladen ist | unter 2,5 Sek. | Ich sehe das Produkt |
| INP (Interaction to Next Paint) | Wie schnell die Seite auf Eingaben reagiert | unter 200 ms | Der Button tut endlich was |
| CLS (Cumulative Layout Shift) | Wie stark Inhalte während des Ladens springen | unter 0,1 | Ich habe daneben getippt |
Aus meiner Sicht ist CLS der am stärksten unterschätzte Wert im E-Commerce. Springende Layouts sind nicht nur unangenehm – sie führen zu Fehlklicks. Wer auf einer Produktseite versehentlich die falsche Variante auswählt, weil das Bild nachgeladen hat, hat ein reales Conversion-Problem, das in keinem Score sichtbar wird.
Labordaten und Felddaten sind nicht dasselbe
PageSpeed Insights zeigt zwei völlig unterschiedliche Datentypen an. Das verwechseln selbst erfahrene Shopbetreiber regelmäßig.
| Labordaten (Lighthouse) | Felddaten (CrUX) |
|---|---|
| Simulierter Testlauf auf einem definierten Gerät | Echte Messwerte echter Nutzer der letzten 28 Tage |
| Gut für Debugging und Vorher-Nachher-Vergleiche | Gut für die Frage, ob du wirklich ein Problem hast |
| Schwankt stark, oft mehrere Punkte pro Messung | Träge, reagiert erst Wochen nach einer Änderung |
| Sagt nichts über deine tatsächliche Nutzerbasis | Bildet Endgeräte, Netz und Standort deiner Käufer ab |
Für Entscheidungen nutze ich Felddaten. Ein Laborwert ist ein Werkzeug für Entwickler, keine Geschäftsgrundlage. Wenn du wissen willst, ob dein Shop ein Ladezeitproblem hat, schau dir an, was echte Nutzer erleben – segmentiert nach Gerät und Seitentyp.
Mobile First: Warum dein Handy-Nutzer die härteste Prüfung ist
Mobile-Optimierung hat in meiner Arbeit einen sehr hohen Stellenwert. In vielen Projekten liegt der mobile Traffic-Anteil bei über 90 %. Selbst bei höherpreisigen Produkten ist Mobile in der Regel mindestens gleichwertig zum Desktop. Wer die mobile Nutzererfahrung nicht optimiert, verschenkt heute einen Großteil seines Potenzials.
Erstens: Dein Testgerät ist nicht dein Nutzergerät. Ein aktuelles Smartphone im WLAN sagt dir wenig darüber, wie sich dein Shop auf einem drei Jahre alten Android-Gerät im mobilen Netz anfühlt. Genau dort kaufen aber viele deiner Kunden.
Zweitens: Mobile Nutzer kommen häufiger aus Social-Kanälen und damit aus einem In-App-Browser. Instagram und TikTok öffnen Links in ihrer eigenen Browserumgebung, die zusätzliche Ressourcen lädt und teilweise anders rendert. Wenn ein Großteil deines bezahlten Traffics über diesen Weg kommt, ist das dein realer Startpunkt – nicht Chrome auf dem Desktop.
Drittens: Auf einem kleinen Display ist Layout-Stabilität kritischer. Was am Desktop ein leichtes Ruckeln ist, wird mobil zum Fehlklick.
Die häufigsten Page-Speed-Bremsen in Shopify-Shops
Ich halte Shopify aktuell für das beste E-Commerce-System am Markt. Der Checkout ist stark optimiert, die Infrastruktur ist stabil, und die Theme-Architektur ist grundsätzlich performant. Die größten technischen Probleme entstehen deshalb selten durch Shopify selbst, sondern durch individuelle Anpassungen.
Das ist eine wichtige Unterscheidung. Wenn dein Shop langsam ist, liegt das mit hoher Wahrscheinlichkeit an Entscheidungen, die im Laufe der letzten zwei Jahre getroffen wurden – nicht an der Plattform.
| Bremse | Warum sie bremst | Impact | Aufwand |
|---|---|---|---|
| Zu viele Drittanbieter-Apps | Jede App lädt eigenes JavaScript und CSS, oft auf allen Seiten | Hoch | Mittel |
| Page-Builder-Apps | Erzeugen aufgeblähtes Markup und zusätzliche Render-Schritte | Sehr hoch | Hoch |
| Unkomprimierte Bilder | Große Dateien blockieren den Largest Contentful Paint | Hoch | Niedrig |
| Veralteter Custom-Code | Über Jahre gewachsene Anpassungen ohne Aufräumen | Mittel bis hoch | Hoch |
| Externe Schriften | Zusätzliche Verbindungen und verzögerte Textdarstellung | Mittel | Niedrig |
| Zu viele Tracking-Skripte | Jedes Pixel kostet Rechenzeit im Browser | Mittel | Niedrig |
| Slider und Videos above the fold | Verzögern genau das Element, auf das der Nutzer wartet | Mittel | Mittel |
Apps: Der am meisten unterschätzte Bremsklotz
Wenn ich einen einzigen Hebel nennen müsste, mit dem die meisten Shopify-Shops ihre Ladezeit spürbar verbessern könnten, wäre es der ehrliche Blick in die App-Liste.
Page-Speed-Probleme durch zu viele Apps sind ein sehr häufiges Thema. Vor allem von Drittanbieter-Page-Builder-Apps bin ich kein Freund, weil sie den Page Speed stark negativ beeinflussen können. Sie versprechen Flexibilität ohne Entwicklung und erzeugen dafür Markup, das kein Entwickler so schreiben würde.
Das Problem ist selten die einzelne App, sondern die Summe. Jede wurde irgendwann für ein Feature installiert, oft von einem anderen Dienstleister. Und fast keine wird wieder entfernt, wenn sie nicht mehr gebraucht wird.
So machst du den App-Kassensturz
- Liste alle installierten Apps auf und notiere zu jeder, welchen messbaren Geschäftsnutzen sie hat. Nicht welchen sie haben sollte, sondern welchen sie nachweisbar hat.
- Markiere alles ohne klare Antwort. Aus meiner Erfahrung sind das in gewachsenen Shops schnell 30 bis 40 % der Apps.
- Prüfe Überschneidungen. Zwei Review-Apps, drei Popup-Tools und zwei Analytics-Erweiterungen mit identischem Zweck sind keine Seltenheit.
- Deinstallieren reicht nicht. Viele Apps hinterlassen Code-Fragmente im Theme. Ohne saubere Entfernung bleibt die Ladelast bestehen, obwohl die App weg ist.
- Miss danach erneut – und zwar über Felddaten, nicht über einen einzelnen Lighthouse-Lauf.
Shopify Page Speed optimieren: So gehen wir konkret vor
Der häufigste Fehler bei der Optimierung ist fehlende Priorisierung. Viele Shops arbeiten Maßnahmen ohne klare Strategie ab und investieren Zeit in Dinge mit geringem Impact, während größere Potenziale ungenutzt bleiben. Bei Page Speed passiert das besonders oft, weil Tools eine lange Liste an Empfehlungen ausspucken und alles gleich wichtig aussieht.
Deshalb arbeiten wir auch hier mit einem Scoring-Ansatz: Jede Maßnahme wird nach erwartetem Impact, Reichweite, Aufwand und Problemdruck bewertet. Erst dann wird umgesetzt.
Schritt 1: Miss dort, wo dein Geld verdient wird
Nicht die Startseite entscheidet, sondern die Seiten mit dem meisten Umsatzanteil. In den meisten Shops sind das Produktdetailseiten und der Warenkorb. Prüfe diese Seitentypen einzeln, mobil, mit Felddaten.
Schritt 2: Verbinde Ladezeit mit Verhalten
Ein Speed-Report allein sagt dir nicht, ob Nutzer wegen der Ladezeit abspringen. Wir kombinieren dafür Google Analytics 4 mit Microsoft Clarity und Hotjar. Session Recordings zeigen sehr deutlich, wenn Nutzer mehrfach auf einen Button tippen, weil nichts passiert. Über den Google Tag Manager lassen sich zusätzlich Events tracken, die standardmäßig nicht in Analytics vorhanden sind – etwa die Interaktion mit einem Element, das erst spät geladen wird.
Schritt 3: Nimm die günstigen Punkte zuerst mit
Bilder komprimieren und in modernen Formaten ausliefern, Lazy Loading für alles unterhalb des sichtbaren Bereichs, feste Dimensionen für Bildcontainer gegen Layout-Sprünge, nicht kritische Skripte verzögert laden. Das sind Maßnahmen mit hohem Verhältnis von Wirkung zu Aufwand.
Schritt 4: Räum den Code auf
Danach kommt der aufwendigere Teil: ungenutztes CSS und JavaScript entfernen, alte App-Fragmente aus dem Theme löschen, Custom-Code konsolidieren. Das ist Entwicklungsarbeit, keine Klickarbeit. Sie zahlt sich aber dauerhaft aus, weil sie die Basis für alle künftigen Änderungen sauber hält.
Schritt 5: Behandle Performance als laufende Aufgabe
Ein Shop wird nicht einmal schnell gemacht. Jede neue App, jede Kampagnenseite, jedes zusätzliche Pixel verschiebt die Basis wieder. Performance gehört deshalb in einen festen Rhythmus – nicht in ein einmaliges Projekt.
Rechenbeispiel: Was eine Sekunde tatsächlich wert ist
Ich rechne mit Kunden ungern in Prozentversprechen. Deshalb hier ein Beispiel, mit dem du dein eigenes Potenzial abschätzen kannst.
Ausgangslage
120.000 Sessions pro Monat
Conversion Rate: 1,8 %
Average Order Value: 68 EUR
Monatsumsatz: rund 146.880 EUR
Szenario: +0,2 Prozentpunkte CR durch bessere Ladezeit
Neue Conversion Rate: 2,0 %
Neuer Monatsumsatz: 163.200 EUR
Zusätzlicher Umsatz pro Monat: +16.320 EUR
Zusätzlicher Umsatz pro Jahr: +195.840 EUR
Diese 0,2 Prozentpunkte sind keine Garantie und kein Benchmark. Sie sind eine Rechengröße, um die Diskussion vom Score weg und auf den Geschäftswert zu lenken.
Ein Punkt, der dabei oft untergeht: Ich optimiere nicht auf die Conversion Rate allein, sondern auf den Average Revenue per User. Diese Kennzahl kombiniert Conversion Rate und Warenkorbwert und zeigt direkt, wie viel Umsatz pro Nutzer entsteht. Bei Löwenkind lag die Conversion Rate zu Beginn zwischen drei und vier Prozent. Im Verlauf der Zusammenarbeit haben wir sie auf konstant sechs bis sieben Prozent gebracht und den ARPU nachweislich um über 92 % gesteigert. Technik war dabei ein Baustein – aber nicht der Kern.
Page Speed und A/B-Testing: Wie du testest, ohne den Shop zu bremsen
Hier kommen wir an einen Punkt, an dem ich eine klare Meinung habe: Performance darf beim Testing niemals leiden.
Der klassische Fehler ist, zu viel Code über das A/B-Testing-Tool zu laden. Das kann die Ladezeit negativ beeinflussen oder zu Flicker-Effekten führen, bei denen Nutzer kurz die Originalversion sehen, bevor die Variante geladen wird. Das verschlechtert nicht nur die Nutzererfahrung – es verfälscht auch die Testergebnisse. Wenn Variante B systematisch später erscheint als Variante A, misst du nicht deine Hypothese, sondern deine Implementierung.
Deshalb setzen wir Varianten technisch so um, dass möglichst viel Code direkt im Shop geladen wird und nicht über ein externes Tool. Zusätzlich vermeiden wir unnötige Drittanbieter-Apps und setzen auf optimierte Implementierungen. Mit diesem Setup haben wir seit Jahren sehr stabile Ausspielungen ohne relevante Performance-Probleme.
Kann man Ladezeit selbst A/B-testen?
Direkt und sauber: nur eingeschränkt. Ein echter Ladezeit-Test müsste zwei technisch identische Varianten gegeneinander stellen, die sich ausschließlich in der Performance unterscheiden. In der Praxis ist das aufwendig und die Effekte sind oft kleiner als das statistische Rauschen bei üblichen Traffic-Mengen.
Realistischer ist ein Vorher-Nachher-Vergleich über Felddaten, kombiniert mit Verhaltensmetriken. Ich stecke Testkapazität lieber in Fragen, bei denen die Antwort wirklich offen ist.
Wann Page Speed nicht dein Problem ist
Wenn dein Shop in unter zwei Sekunden lädt und deine Conversion Rate trotzdem bei 0,8 % liegt, ist Ladezeit nicht dein Engpass. Dann fehlt etwas Grundlegenderes: Product-Market-Fit, Vertrauen, Orientierung, ein überzeugendes Angebot oder schlicht die richtige Zielgruppe.
Meine ehrliche Einordnung, wann sich Aufwand in Page Speed lohnt:
| Page Speed hat Priorität, wenn … | Page Speed hat keine Priorität, wenn … |
|---|---|
| Deine mobilen LCP-Werte in Felddaten liegen deutlich über 3 Sekunden | Du bereits stabil unter 2,5 Sekunden bist und den Score von 82 auf 90 heben willst |
| Du sichtbare Layout-Sprünge auf Produktseiten hast | Deine Layout-Stabilität bereits gut ist |
| Dein Shop über 15 aktive Apps hat, ohne dass jede einen Zweck erfüllt | Dein App-Stack schlank und bewusst gewählt ist |
| Du bezahlten Social-Traffic auf langsame Landingpages schickst | Dein größtes Problem in der Kommunikation deines Angebots liegt |
| Session Recordings mehrfache Klicks auf nicht reagierende Elemente zeigen | Nutzer den Kaufprozess technisch problemlos durchlaufen, aber trotzdem abbrechen |
Ich halte es außerdem für falsch, einen perfekten Score zum Ziel zu erklären. Der Aufwand steigt bei hohen Werten überproportional, während der Nutzen für den Kunden gegen null geht. Niemand kauft, weil dein Lighthouse-Wert bei 97 statt bei 88 liegt.
Was ich stattdessen empfehle
Bring die Ladezeit auf ein solides Niveau, sorge dafür, dass sie dort bleibt, und investiere die restliche Energie in strukturiertes Testing. Sinnvoll wird A/B-Testing aus meiner Erfahrung ab etwa 500 bis 1.000 Bestellungen pro Monat, vorausgesetzt der Product-Market-Fit stimmt. Darunter zählen Angebot, Traffic-Aufbau und bewährte Grundlagen mehr.
Häufig gestellte Fragen
Als Orientierung gilt ein Largest Contentful Paint unter 2,5 Sekunden auf mobilen Geräten, gemessen an echten Nutzerdaten. Wichtiger als der exakte Wert ist die Konsistenz uber deine umsatzstarksten Seitentypen hinweg. Ein schneller Startseiten-Wert nutzt wenig, wenn die Produktseite vier Sekunden braucht.
Nutze PageSpeed Insights fur eine erste Einschatzung, achte dabei aber auf die Felddaten und nicht nur auf den Score. Zusatzlich lohnt sich ein Blick in die Search Console unter Core Web Vitals sowie in Session Recordings, um zu sehen, wie sich Verzogerungen im echten Verhalten auswirken.
Aus meiner Erfahrung sind Page-Builder-Apps die grossten Bremsen, weil sie zusatzliches Markup und Render-Schritte erzeugen. Danach folgen Popup- und Review-Tools, die auf allen Seiten laden, auch dort, wo sie gar nicht gebraucht werden. Entscheidend ist immer die Summe, nicht die einzelne App.
Nein. Ladezeit ist ein Hygienefaktor: Sie kann Conversions kosten, wenn sie schlecht ist, aber sie erzeugt keine Nachfrage, wenn Angebot oder Kommunikation nicht uberzeugen. In unseren Projekten kommen die grosseren Uplifts fast immer aus Struktur, Psychologie und Angebotsdarstellung.
Core Web Vitals sind ein Ranking-Signal, aber ein vergleichsweise schwaches im Vergleich zu Relevanz und Inhaltsqualitat. Der wirtschaftlich relevantere Effekt liegt in der Nutzererfahrung und damit direkt in der Conversion, nicht in der Position im Suchergebnis.
Bildoptimierung ist in den meisten Shops die Massnahme mit dem besten Verhaltnis von Wirkung zu Aufwand, weil das grosste sichtbare Element auf Produktseiten fast immer ein Bild ist. Moderne Formate, passende Grossen und Lazy Loading unterhalb des sichtbaren Bereichs sind der Standard, den ich erwarte.
Sie mussen es nicht. Wenn zu viel Code uber ein externes Testing-Tool geladen wird, entstehen zusatzliche Ladezeit und Flicker-Effekte. Wir setzen Varianten deshalb moglichst direkt im Shop um, sodass Performance und Testing sich nicht gegenseitig ausschliessen.
Beim Flicker sieht der Nutzer kurz die Originalversion, bevor die Testvariante erscheint. Das stort nicht nur die Wahrnehmung, es verzerrt auch die Ergebnisse, weil die Varianten unterschiedlich schnell sichtbar werden. Damit misst du am Ende deine Implementierung statt deiner Hypothese.
Ja, weil die technischen Massnahmen unabhangig vom Traffic wirken und der Aufwand uberschaubar ist. Klassisches A/B-Testing halte ich bei sehr wenigen Conversions dagegen noch nicht fur sinnvoll, weil die statistische Aussagekraft fehlt. In dieser Phase zahlen Product-Market-Fit und solide Grundlagen mehr.
Ein Theme-Wechsel ist selten die erste Antwort. Prufe zuerst Apps, Bilder und gewachsenen Custom-Code, denn dort liegt meistens die Ursache. Ein Wechsel oder Redesign wird eher dann sinnvoll, wenn zusatzlich strukturelle UX-Probleme oder sehr niedrige Conversion Rates bestehen.
Dein Shop lädt langsam und du weißt nicht, wo die Bremse liegt?
Wir analysieren deinen Shopify Page Speed, identifizieren die relevanten Bremsen und zeigen dir, welche Maßnahmen wirklich auf deinen Umsatz einzahlen.
Erstgespräch sichern
Chris Dengler
Gründer, Convertlab
Über den Autor: Chris Dengler
Chris hat in 4 Jahren mehr als 1.000 A/B-Tests durchgeführt und dabei Shopify-Shops zu durchschnittlich 34 % mehr Umsatz verholfen.