Die meisten Shopify-Speed-Ratschläge optimieren eine Zahl, die niemand sehen kann, der bei dir kauft. Sie sagen dir, komprimiere Bilder, aktiviere Lazy Loading, bring den Score ins Grüne, und nichts davon ist falsch. Es überspringt nur die Frage, die zuerst zählt: welcher Teil der Langsamkeit kostet dich tatsächlich Bestellungen?
Das hier ist die Sicht eines Conversion-Praktikers auf diese Frage, kein Performance-Engineering-Guide. Shopifys eigene Entwicklerdokumentation deckt die Engineering-Seite bereits ab und besser, als ich es könnte. Was sie nicht abdeckt: warum Speed-Projekte in Stores weiter scheitern, die die Komprimierung längst gemacht haben.
Die Messungen, die zählen, und die eine, die täuscht
Die drei Core Web Vitals und ihre Schwellenwerte für "gut", aus Googles eigener Dokumentation:
| Metrik | Gut | Was der Käufer erlebt |
|---|---|---|
| Largest Contentful Paint | innerhalb 2,5s | wie lange, bis das Wesentliche erscheint |
| Interaction to Next Paint | 200ms oder weniger | ob Taps sich sofort anfühlen |
| Cumulative Layout Shift | 0,1 oder weniger | ob die Seite unter dem Daumen springt |
Eine Korrektheits-Anmerkung, weil viele Shopify-Speed-Inhalte hier veraltet sind: Interaction to Next Paint hat First Input Delay ersetzt und wurde 2024 ein stabiler Core Web Vital. Wenn ein Guide dir noch sagt, du sollst FID optimieren, wurde er zwei Jahre nicht aktualisiert, was dir etwas über den Rest seiner Ratschläge sagt.
Jetzt die Metrik, die täuscht. Ein Lighthouse-Score ist ein Labortest auf einem simulierten Gerät, und er lässt sich bewegen, ohne dass ein Käufer etwas davon spürt. Google bewertet Felddaten echter Besucher. Ein Store kann also in Lighthouse von 42 auf 78 gehen, nichts ausliefern, was ein Kunde bemerken würde, und ein erfolgreiches Speed-Projekt melden. Ich habe dieses Ergebnis mehr als einmal als Erfolg verkauft gesehen.
Optimiere das, worauf ein Käufer wartet. Dann prüfe, ob die Conversion sich bewegt hat, nicht der Score.
Warum Speed-Arbeit scheitert: sie beginnt zu spät
Der häufigste Fehler, den ich über Shopify-Projekte hinweg sehe, ist keine fehlende Technik. Es ist die Reihenfolge. Speed wird als Politur behandelt, die nach dem fertigen Design aufgetragen wird.
Wenn ein Build die Phase "jetzt optimieren wir Performance" erreicht, sind die teuren Entscheidungen längst gefallen. Ein Hero über den ganzen Viewport. Illustrationen als Raster exportiert statt als SVG. Ein Autoplay-Video über der Falz. Ein Scroll, der weiss aufblitzt, weil nichts Platz reserviert. Vier Apps, die je ein Skript injizieren. An diesem Punkt bleiben nur Komprimierung und Lazy Loading, und deshalb enden so viele Speed-Projekte mit einer leicht schnelleren Version einer Seite, die vom Design her strukturell schwer war.
Konkrete Dinge, die ich in dieser Phase immer wieder finde, grob nach Häufigkeit:
- Hohe Time to First Byte, die dem Redesign vorausgeht. Niemand prüft sie, bevor darauf neu gebaut wird. Das ist ein Entwickler-Problem, nicht meines, und es muss vor der Design-Arbeit gefunden werden, nicht danach.
- Raster-Illustrationen, wo ein SVG genügt. Linien-Grafiken und Icons als PNG exportiert, oft in 2x, oft mehrere hundert Kilobyte für etwas, das als Vektor wenige Kilobyte wäre.
- Ruckelnder Scroll, der weiss aufblitzt. Inhalte, die ihren Platz nicht reservieren. Ein Cumulative-Layout-Shift-Problem und ausserdem einfach unangenehm, und genau das kostet dich.
- Autoplay-Video über der Falz. Was zu einem verwandten Argument führt.
Das Video-Argument, das eigentlich nicht um Speed geht
Ich argumentiere meist gegen ein Produktseiten-Video und für einen statischen Screenshot, und Seitengewicht ist erst der dritte Grund.
Die ersten zwei: ein Video wirft Fragen auf, die der Käufer klären muss, bevor er Nutzen daraus zieht. Wie lang ist das? Muss ich pausieren, um Details zu lesen? Ein statisches, annotiertes Bild der Sache liefert dieselbe Information in der Zeit eines Blicks. Und ein Video, das angesehen werden muss, konkurriert mit der Kaufentscheidung, statt sie zu stützen.
Und ja, es kostet Ladezeit. Aber wenn dein einziges Argument gegen das Video das Seitengewicht ist, verlierst du diese Diskussion gegen einen Kunden, dem das Markengefühl wichtig ist, und zu Recht. Das stärkere Argument ist, dass es seine Aufgabe schlechter erfüllt.
Der schwere Hero ist ein Hierarchie-Problem im Speed-Kostüm
Besonders auf Collection-Seiten ist das grösste Einzelelement oft ein dekorativer Hero, und der Instinkt sagt: komprimieren.
Die bessere Frage ist, warum er da ist. Der Sinn einer Collection-Seite ist, Besucher so schnell wie möglich zu den Produkten zu bringen. Ein überdimensionierter Hero über einem Produktgrid ist im Grunde Rauschen: er drückt das Einzige, wofür die Seite existiert, unter die Falz und kostet dich gleichzeitig deinen Largest Contentful Paint.
Dieses Bild zu komprimieren gibt dir eine schnelle Version einer Seite, die die Produkte weiterhin verzögert. Es zu entfernen löst beide Probleme auf einmal, und das ist die allgemeine Form der wertvollsten Speed-Arbeit: der Fix ist häufig Löschen, nicht Optimieren. Es ist auch der Grund, warum diese Arbeit zu dem gehört, der die Seitenhierarchie verantwortet, nicht zu dem, der die Build-Pipeline verantwortet.
Zwei verwandte Fallen auf derselben Fläche:
- Suchmaschinen-Copy, die den Weg zum Produkt blockiert auf Collection-Seiten. Sie muss nicht weg, aber sie kann ausfaden oder in ein Accordion, damit sie crawlbar bleibt, ohne den Klick zu verzögern.
- Whitespace, der sich wie das Seitenende liest. Überhaupt kein Speed-Problem, aber es erzeugt dasselbe Geschäftsergebnis wie eine langsame Seite: Leute erreichen die Produkte nicht.
Apps: prüfe, was sie einbringen, bevor du ihre Grösse prüfst
Die meisten Shopify-Apps laden Skripte auf jeder Seite, ob die Seite das Feature nutzt oder nicht. Der übliche Rat ist, die unnötigen zu entfernen, was richtig und unzureichend ist.
Das teurere Muster ist Überlappung: mehrere Apps für dieselbe Aufgabe, also mehrere Skripte für ein Feature. Ich habe Stores geöffnet, die gleichzeitig mehrere Bundle-Apps laufen liessen, und die ehrliche Beschreibung ist, dass es ein bisschen ein Chaos ist: widersprüchliches Cart-Verhalten, doppelte Skripte, und niemand kann sagen, welche davon den Umsatz erzeugt.
Prüfe Apps also zuerst danach, was jede einbringt, dann danach, was sie an Gewicht kostet. Eine App mit echter Attach-Rate ist ihr Skript wert. Drei Apps, die ein Feature untereinander aufteilen, sind es nicht.
Was nicht mein Job ist, und was du damit machst
Direkt zum Scope, weil hier viele Speed-Ratschläge sich überverkaufen.
Wenn deine Time to First Byte schlecht ist, das Liquid deines Themes teure Arbeit in Loops macht, du Server-Rendering-Entscheidungen brauchst oder dein App-Stack auf Code-Ebene entwirrt werden muss, ist das ein Entwickler-Job. Ich sage dir das, statt vorzugeben, ein Design-Durchgang würde es lösen, und es lohnt sich, das zu wissen, bevor du jemanden beauftragst: das sind zwei verschiedene Engagements.
Woran ich arbeite, ist der Teil, der das Gewicht erzeugt hat: was auf die Seite kam, in welcher Reihenfolge, und ob das, worauf dein Largest Contentful Paint wartet, ein Produkt oder eine Dekoration ist.
Wie du es sequenzierst, wenn du jetzt anfängst
- Hol Felddaten vor Meinungen. Core Web Vitals echter Besucher, nicht ein Lighthouse-Lauf auf deinem Laptop im Büro-WLAN.
- Finde heraus, was dein Largest-Contentful-Paint-Element wirklich ist. In vielen Shopify-Stores ist es ein dekoratives Bild. Diese einzige Tatsache stellt das Projekt meist neu auf.
- Frage, was jedes schwere Element einbringt. Löschen, dann komprimieren. In dieser Reihenfolge, denn etwas zu komprimieren, das nicht existieren sollte, ist verschwendete Arbeit.
- Prüfe Time to First Byte separat und gib sie an einen Entwickler, wenn sie schlecht ist. Designe nicht auf einem langsamen Server.
- Miss Conversion, nicht Score. Über ein vorab festgelegtes Zeitfenster, an der Metrik, die zur Änderung passt.
Zu Schritt fünf gilt dieselbe Einschränkung wie überall: ein aussagekräftiger A/B-Test braucht rund 200 bis 250 Conversions und etwa 5.000 Sessions pro Variante. Die meisten Stores mit $50k bis $1m im Monat können eine Speed-Änderung so nicht isolieren, also misst du ein klares Vorher-Nachher und sagst laut, dass du genau das tust.
Eine Anmerkung zu den Statistiken, die du zitiert sehen wirst
Jeder Speed-Artikel zitiert eine Zahl, die Millisekunden mit Umsatz verbindet. Ich habe absichtlich keine zitiert, denn als ich nach Primärquellen für die berühmten suchte, führten die meisten zu Hersteller-Blogposts, Beratungs-Marketing oder zueinander.
Verifizierbar sind Googles veröffentlichte Schwellenwerte oben und der schlichte Mechanismus: ein Mensch, der auf eine Seite wartet, auf die er nicht warten wollte, geht mit höherer Wahrscheinlichkeit. Das genügt, um die Arbeit zu rechtfertigen. Du brauchst keine geliehene Statistik ohne Quelle, und eine zu zitieren kostet dich Glaubwürdigkeit bei genau dem technischen Käufer, der nachschaut.
Weiterlesen: Der komplette Shopify CRO Leitfaden · Shopify Checkout-Optimierung · Conversion-Rate-Optimierung Audit
Wenn du wissen willst, ob deine Langsamkeit ein Design-Problem oder ein Entwickler-Problem ist, bevor du jemanden dafür bezahlst, buche ein kostenloses 30-Minuten-Gespräch. Ich sage dir, welches von beiden es ist, auch dann, wenn die Antwort lautet, dass du einen Entwickler brauchst und nicht mich.
