Der Stand der Shopify-Performance in 2026

Die wichtigsten Erkenntnisse

• Core Web Vitals sind ein offizieller Google-Ranking-Faktor, und seit März 2024 hat INP FID als Metrik für die Reaktionsfähigkeit abgelöst. “Gut” bedeutet LCP unter 2,5s, INP unter 200ms und CLS unter 0,1.¹²
• Speed ist ein Conversion-Hebel, nicht nur ein SEO-Thema. Ein Geschwindigkeitsgewinn von 0,1 Sekunden auf Mobilgeräten steigerte in der Studie von Deloitte und Google die Conversion-Rates im Einzelhandel um 8,4 % und den durchschnittlichen Bestellwert um 9,2 %.³
• Das Web besteht alle drei Core Web Vitals nur bei 43 % der mobilen Seitenaufrufe. INP ist die am schwersten zu erreichende Metrik und genau da spüren App-lastige Shopify-Stores den meisten Druck.⁴
• Die größte Bremse für einen Shopify-Store ist selten die Plattform. Es sind aufeinandergestapeltes App-JavaScript, Third-Party-Widgets, schwere Hero-Medien und Layouts, die sich verschieben, wenn späte Skripte nachgeladen werden.
• Nativer Theme-Code vermeidet die App-Runtime-Kosten bei jedem Besuch. In unseren eigenen Tests liefen Drag-and-Drop-Builder 22-37 % langsamer als Varianten mit nativem Code.

Alle paar Monate schickt mir ein Händler einen PageSpeed-Score, meistens einen roten, und stellt dieselbe Frage: Liegt das an Shopify, an meinem Theme oder an den zwölf Apps, die ich letztes Jahr installiert habe? Dieser Artikel ist mein Versuch einer ehrlichen, fundierten Antwort auf die grundlegendere Version dieser Frage. Wo steht die Shopify-Performance im Jahr 2026 wirklich, was sind die echten Shopify Performance-Benchmarks, und was zieht die meisten Stores nach unten?

Die Kurzversion: Das Fundament der Plattform ist solide und wird immer besser, die Messlatte hat sich verschoben, und fast alle Performance-Probleme in realen Stores stammen von den Dingen, die Händler obendrauf packen.

---

Warum du uns vertrauen kannst

Über 15 Jahre Entwicklererfahrung und vier Jahre im Shopify-Ökosystem. Wir haben die Core Web Vitals bei über 500 Shopify-Stores gemessen und Themes speziell umgebaut, um durch Apps verlorene Geschwindigkeit zurückzugewinnen. Außerdem bauen wir Fudge, einen KI-Store-Editor, der Seiten direkt als nativen Code in dein Theme schreibt, anstatt sie durch eine App-Runtime zu rendern. Diese Designentscheidung ist direkt aus diesem Performance-Problem heraus entstanden, daher weisen wir gleich vorab auf unsere Befangenheit hin, wo sie eine Rolle spielt.

---

Warum die Store-Performance 2026 noch wichtiger ist

Zwei Faktoren machen Speed in diesem Jahr zu einem vorrangigen Thema und nicht nur zu einem technischen Nice-to-have.

Core Web Vitals sind ein Ranking-Faktor, und die Metriken haben sich geändert

Google nutzt Core Web Vitals als Teil seiner Ranking-Systeme für die Page Experience.² Das ist schon eine Weile so. Was sich erst kürzlich geändert hat, ist das Set der Metriken selbst.

Im März 2024 hat Interaction to Next Paint (INP) den First Input Delay (FID) als Core Web Vital zur Messung der Reaktionsfähigkeit abgelöst.¹ FID hat nur die Verzögerung bei der ersten Interaktion eines Nutzers gemessen. INP misst die Latenz von Interaktionen während des gesamten Besuchs und erfasst somit schwerfällige Klicks, laggy Menüs und langsame Add-to-Cart-Aktionen, die FID noch stillschweigend ignoriert hat. Es ist eine härtere Messlatte, aber auch eine ehrlichere.

Die drei Schwellenwerte für ein „gutes“ Erlebnis, gemessen am 75. Perzentil echter Seitenaufrufe, lauten:

• LCP (Largest Contentful Paint): 2,5s oder darunter - wie schnell der Hauptinhalt geladen (gepaintet) wird
• INP (Interaction to Next Paint): 200ms oder darunter - wie flüssig die Seite auf Eingaben reagiert
• CLS (Cumulative Layout Shift): 0,1 oder darunter - wie sehr das Layout beim Laden hin- und herspringt²

Das sind die offiziellen Google-Grenzwerte. Eine Seite, die sie verfehlt, fliegt nicht direkt aus der Suche, hat aber einen Wettbewerbsnachteil gegenüber Stores, die sie erreichen.

Speed bringt Conversions, und damit bares Geld

Das Ranking-Argument ist nur die halbe Miete. Die andere Hälfte ist, dass schnellere Stores einfach mehr verkaufen.

Die am häufigsten zitierte kontrollierte Studie hierzu ist der Report „Milliseconds Make Millions“ von Deloitte und Google, bei dem 37 Marken-Websites mit mehr als 30 Millionen Sitzungen analysiert wurden. Eine Verbesserung der Ladezeit auf Mobilgeräten um 0,1 Sekunden steigerte die Conversion-Rates im Einzelhandel um 8,4 % und den durchschnittlichen Bestellwert um 9,2 %.³ Hier sorgt eine Zehntelsekunde für einen fast zweistelligen Umsatzunterschied.

Um ein Gefühl für die Größenordnung beim Checkout zu bekommen: Shopifys eigene in Auftrag gegebene Forschung besagt, dass der Checkout eine bis zu 36 % höhere Conversion-Rate aufweist – im Schnitt 15 % höher – als Konkurrenz-Checkouts.⁵ Die Plattform hat bei den Teilen, die sie kontrolliert, wirklich gute Arbeit geleistet. Das Storefront vor diesem Checkout ist jedoch der Ort, wo die meisten Händler immer noch Geld auf der Strecke lassen.

Wie die Conversion-Rates in den einzelnen Kategorien im Detail aussehen, erfährst du in unseren Shopify Conversion-Rate Benchmarks.

---

Die Core Web Vitals Grenzwerte und wie das Web abschneidet

Bevor wir uns speziell Shopify ansehen, hilft es zu wissen, wie “normal” im gesamten Web aussieht, denn Shopify-Stores werden nach denselben Maßstäben bewertet.

Der HTTP Archive Web Almanac, der Millionen echter Websites analysiert, stellte fest, dass 2024 nur 43 % der Websites auf Mobilgeräten alle drei Core Web Vitals bestanden haben.⁴ Hier ist die Aufschlüsselung nach Metriken:

Core Web Vital	Grenzwert für “Gut” (P75)	Erfolgsquote mobil, alle Websites (2024)
LCP	2,5 s oder weniger	59 %4
INP	200 ms oder weniger	74 %4
CLS	0,1 oder weniger	79 %4
Alle drei	n/a	43 %4

Zwei Dinge fallen auf.

Erstens: Der Wechsel zu INP hat die Messlatte höher gelegt. Unter der alten FID-Metrik hätten 2024 noch 48 % der mobilen Websites alle Anforderungen erfüllt. Mit INP fiel dieser Wert auf 43 %.⁴ Das Web ist nicht langsamer geworden. Der Maßstab ist nur ehrlicher geworden.

Zweitens: INP verbessert sich schnell, bleibt aber der Schwachpunkt für interaktive Websites. Die INP-Erfolgsquoten auf Mobilgeräten stiegen von 55 % (2022) über 64 % (2023) auf 74 % im Jahr 2024.⁴ Die Lücke zwischen Desktop und Mobile ist immer noch groß, und INP ist genau die Metrik, die durch viel JavaScript leidet. Jedes Skript, das der Browser parsen und ausführen muss, konkurriert mit dem Main Thread, der auf Taps und Klicks reagiert.

Behalte diesen Gedanken im Hinterkopf, denn beim Thema JavaScript wird es für Shopify spannend.

---

Wo Shopify-Stores eigentlich stehen

Shopify liegt in der Metrik, die die Plattform am direktesten kontrolliert, über dem E-Commerce-Durchschnitt. Die E-Commerce-Analyse des Web Almanacs merkt an, dass Shopify seit 2022 konstant gute LCP-Bestehensraten aufweist, eine Gruppe, die sie sich nur mit einer Handvoll Plattformen teilt.⁶ Das ist kein Zufall. Jeder Shopify-Store läuft über dasselbe CDN, dasselbe Edge-Caching und dasselbe Server-Side-Rendered Liquid, wodurch die First-Paint-Basis von Haus aus stark ist – auf eine Weise, die selbst-gehostete Plattformen so kaum garantieren können.

Wo Shopify-Stores Schwierigkeiten haben, ist an derselben Stelle wie der Rest des interaktiven Webs: INP. Und hier ist fast nie die Plattform schuld. Es ist das Client-Side JavaScript, das Händler obendrauf packen.

Eine kurze Bemerkung zur Ehrlichkeit der Zahlen: Öffentliche aggregierte Zahlen zum „Anteil von Shopify-Stores, die alle drei Core Web Vitals bestehen“ variieren je nach Quelle und Messzeitraum stark. Daher werde ich keine einzelne Headline-Prozentzahl zitieren, als wäre dies unumstößlich. Dies sind die belegbaren Fakten: Shopifys LCP auf Plattform-Ebene ist konstant gut,⁶ die webweite Quote für das Bestehen aller drei Werte liegt auf Mobilgeräten bei 43 %,⁴ und INP ist die Metrik mit dem größten Verbesserungsbedarf. Der restliche Teil des Scores eines Stores wird vor allem dadurch bestimmt, was der Händler noch alles hinzufügt.

---

Die größten Performance-Bremsen bei Shopify

Bei allen Stores, die wir geprüft haben, tauchen immer und immer wieder dieselben Übeltäter auf. Keiner davon ist Shopify selbst. Und sie summieren sich alle auf.

JavaScript-Bloat durch Apps

Das ist der mit Abstand größte Faktor. Die mediane mobile Webseite lädt bereits rund 570 KB JavaScript.⁷ Auf einem Shopify-Store, der ein normales App-Setup hat, schießt diese Zahl schnell in die Höhe, da die meisten Apps bei jedem Seitenaufruf ihr eigenes Skript-Bundle laden – egal, ob der Kunde die Funktion nutzt oder nicht.

Eine Review-App, eine Upsell-App, ein Currency-Switcher, ein Chat-Widget und ein Page-Builder können jeweils Dutzende bis Hunderte Kilobytes hinzufügen. Der Browser muss alles herunterladen, parsen und ausführen, und genau diese Ausführung drückt den INP über die 200-ms-Grenze. Ein Feature wird vielleicht nur von 2 % der Besucher genutzt. Aber die Runtime-Kosten bezahlen 100 % der Nutzer.

Third-Party Widgets

Ähnlich, aber unterschiedlich: Skripte, die von Drittanbieter-Domains geladen werden. Reviews, Social-Proof-Popups, Live-Chats, zusätzliche Analytics-Tools und eingebettete Videoplayer erfordern meist vor dem Rendern einen Aufruf an einen externen Server. Jeder Aufruf bedeutet einen DNS-Lookup, eine neue Verbindung und eine Payload, die du nicht kontrollierst. Wenn dieser Third-Party-Anbieter einen lahmen Tag hat, hat auch dein LCP einen lahmen Tag.

Unoptimierte Bilder und Hero-Medien

Produkt- und Lifestyle-Bilder sind meist die größten Dateien, und das Hero-Bild ist oft das LCP-Element. Ein einziges unkomprimiertes 1,5 MB Hero-Bild über eine mobile Datenverbindung kann das 2,5s-LCP-Budget bereits ganz alleine sprengen. Die Lösungen sind unscheinbar, aber wirkungsvoll: WebP- oder AVIF-Bilder ausliefern, Bilder passend zum Gerät skalieren und alles, was Below the fold ist (also nicht direkt sichtbar), per Lazy Loading verzögert laden. Unser Guide zum Thema Lazy Loading von Bildern auf Shopify zeigt dir, wie das funktioniert, ohne das LCP-Element Above the fold kaputtzumachen.

Theme-Bloat und render-blockierende Skripte

Themes sammeln im Laufe der Zeit unnötiges Gewicht an. Code von längst gelöschten Features, Anpassungen mehrerer Entwickler-Generationen und Skripte, die einfach in <head> gepackt werden und das erste Rendern blockieren. Ein render-blockierendes Skript zwingt den Browser, den Aufbau der Seite zu stoppen, bis es heruntergeladen und ausgeführt ist. Das Verschieben unkritischer Skripte (Defer) und das Aufräumen alten Codes sind oft die Aufgaben mit dem besten Kosten-Nutzen-Faktor bei einem älteren Store. Schau dir unseren Guide How to speed up a Shopify theme für die genauen Hebel an.

Layout Shifts durch spät ladende Elemente

CLS ist die Metrik, die die meisten Stores bestehen, aber die Fehlschläge sind vermeidbar und störend. Ein Banner, das den Content beim Laden nach unten drückt, ein Bild ohne Größenangaben, ein Font-Swap, der den Text neu umbricht, oder eine Cookie-Leiste, die erst nach dem Paint auftaucht – all das verschiebt die Seite direkt unter dem Daumen der Kunden. Platz für später ladende Elemente zu reservieren, behebt fast all diese Probleme. Den kompletten Diagnose-Workflow und die Lösung für jede Ursache findest du in unserem Guide zu Cumulative Layout Shift auf Shopify.

---

Das App-Gewicht-Problem: Nativer Code vs. gestapelte Widgets

Betrachtet man die Problembereiche von weitem, zeigt sich ein klares Muster. Nahezu jede Bremse von oben ist eine Variante derselben Sache: Code, der bei jedem einzelnen Besuch auf dem Gerät des Käufers ausgeführt wird, für Funktionen, die auch einfach serverseitig hätten gerendert werden können.

Das ist ein strukturelles Problem extrem App-lastiger Setups. Eine App, die deinen Shop über eine eigene Laufzeitumgebung rendert, muss diese Laufzeit auch immer laden, damit der Käufer das Ergebnis sieht. Ein Page-Builder, der Seiten durch ein App-SDK baut, schleppt sein Bundle auf jede Seite mit, die er berührt. Der Shop zahlt bei jedem einzelnen Besuch quasi eine “Steuer” für die Bequemlichkeit des Editors.

Nativer Theme-Code hat diese Steuer nicht. Wenn eine Seite direkt in Liquid, CSS und HTML ins Theme geschrieben wird, rendert der Server sie genau wie jede andere Shopify-Seite auch. Kein runtergeladenes App-SDK, keine Layoutanpassungen zur Laufzeit, kein Extragewicht beim JavaScript-Main-Thread.

Wir haben in unserem Shopify Page Builder Speed Test Zahlen sprechen lassen. Bei der Analyse von über 500 Shopify-Stores liefen Seiten, die mit Drag-and-Drop-Buildern erstellt wurden, 22-37 % langsamer als Varianten mit nativem Code. Das Problem liegt in der Architektur, es ist kein Einstellungsfehler, den man mal eben fixen könnte. Eine Runtime lässt sich zwar verschlanken, sie kann aber niemals bei null Byte liegen.

Das ist die Lücke, in die Fudge springt, und der Grund, warum wir es so gebaut haben. Du gestaltest die Seite, Fudge schreibt sie in nativem Code direkt ins Theme, und die fertige Seite hat exakt denselben kleinen JavaScript-Footprint wie eine handgeschriebene vom Entwickler. Das Lighthouse-Limit wird dann nur noch von deinem Theme, deinen Bildern und deinen anderen Apps vorgegeben und nicht von dem Builder.

---

Wie “gut” aussieht und wie du dorthin kommst

Konkrete Ziele für eine Shopify-Seite auf Mobile, gemessen am 75. Perzentil realer Nutzer:

• LCP unter 2,5s - das Hero-Bild oder die Überschrift laden schnell
• INP unter 200ms - Klicks, Menüs und der Add-to-Cart fühlen sich sofort an
• CLS unter 0,1 - nichts springt beim Nachladen auf der Seite herum
• Das gesamte Seitengewicht unter 1,5 MB, Video ausgeschlossen

Der Weg, dieses Niveau beständig zu halten, ist unspektakulärer als die meisten Shops vermuten. In etwa in dieser Reihenfolge bringen sie den besten ROI:

1. App-Stack aufräumen. Deinstalliere alles, was nur von wenigen Nutzern wirklich verwendet wird, und checke das Theme auf verbliebene Skript-Tags nach der Deinstallation (in der Regel der größte einzelne Gewinn).
2. Hero-Medien fixen. Moderne Formate, richtige Bildgrößen und geeignete Loading-Attribute helfen oft Wunder. Günstig in der Behebung und hat massiven Einfluss auf die LCP-Werte.
3. Unkritisches JavaScript per Defer laden und render-blockierende Skripte aus dem <head> werfen.
4. Platz reservieren für Banner, Bilder und eingebettete Widgets, um Layout Shifts (CLS) im Keim zu ersticken.
5. Verwende echte User-Daten statt eines einzigen Lighthouse-Runs. Ein synthetischer Test kann locker um 30 % abweichen. Nutze als Maßstab stattdessen reale 75. Perzentil-Daten aus dem Chrome User Experience Report (CrUX) oder aus der Google Search Console und betrachte Lighthouse eher als Screening-Tool auf der eigenen Maschine.

Und wie du siehst: Das meiste davon war Subtraktion und keine Addition. Die schnellsten Stores sind nicht die mit den meister Performance-Apps. Es sind die, die am wenigsten Ballast mitschleppen.

---

Ausblick: Wie sich die Shopify-Performance weiterentwickeln wird

Hier ein paar Dinge, auf die ich für das nächste Jahr wetten würde.

Die Performance-Basis wird immer besser, während der Absturz durch den App-Layer eher weiter driftet. Shopifys Verbesserungen auf Server-Seite und beim CDN machen die Basics super stark. Da die Plattform immer besser wird, wächst zudem auch logischerweise der Einfluss, den zusätzliches Third-Party JavaScript ausmacht. Der Gap zwischen einem aufgeräumten Store und einem vollgepackten wird sichtbarer.

INP bleibt die Metrik, die gute von den durchschnittlichen Stores spaltet. LCP und CLS werden zunehmend durch Standards und gute Themes gelöst. INP hängt aber direkt davon ab, wie viel JavaScript auf dem Main Thread ausgeführt wird, und das ist einzig die Entscheidung des jeweiligen Händlers. Die Stores, die die Installation jeder neuen App als Performance-Entscheidung betrachten, werden denen davonlaufen, die das nicht tun.

Der Output von nativem Code wird zur Standarderwartung beim Storefront-Editing. Bei Stores, die bezahlten Traffic schalten (wo laut Deloitte-Logik jede verschenkte 100ms auch ROAS einbüßt)³, wird die Frage schnell nicht mehr sein: „Welcher Editor ist am einfachsten?“, sondern „Welcher Editor fügt der Seite nichts Unnötiges hinzu?“. Das ist ein völlig anderer Ansatz als der, mit dem die Branche in der Vergangenheit vermarktet wurde.

Das Fazit für 2026 lautet: Shopify bietet eine schnelle Basis, und die meisten Stores verspielen diesen Vorsprung durch Gewicht, das sie gar nicht mitschleppen müssten. Die gute Nachricht: Das ist das am einfachsten lösbare Problem in Sachen E-Commerce-Performance, denn fast alles davon liegt allein in deiner Hand.

---

FAQ

Footnotes

1. web.dev, “Interaction to Next Paint becomes a Core Web Vital on March 12” - INP hat am 12. März 2024 First Input Delay (FID) als Core Web Vital ersetzt. https://web.dev/blog/inp-cwv-march-12 ↩ ↩²

2. Google Search Central, “Understanding page experience in Google Search results” und web.dev, “Web Vitals” - Core Web Vitals werden von Googles Ranking-Systemen verwendet; gute Grenzwerte (am 75. Perzentil) sind LCP unter 2,5 s, INP unter 200 ms, CLS unter 0,1. https://developers.google.com/search/docs/appearance/page-experience und https://web.dev/articles/vitals ↩ ↩² ↩³

3. Deloitte und Google, “Milliseconds Make Millions” (2020) - eine Verbesserung der mobilen Ladezeit um 0,1 s steigerte die Conversion Rates im Einzelhandel um 8,4 % und den durchschnittlichen Bestellwert um 9,2 % (über 37 Marken und mehr als 30 Mio. Sitzungen). https://www.deloitte.com/ie/en/services/consulting/research/milliseconds-make-millions.html ↩ ↩² ↩³

4. HTTP Archive, Kapitel “Performance”, Web Almanac 2024 - 43 % der mobilen Websites haben alle drei Core Web Vitals bestanden (48 % nach der alten FID-Metrik); die mobilen Erfolgsquoten lagen bei LCP 59 %, INP 74 %, CLS 79 %; der mobile INP verbesserte sich von 55 % (2022) über 64 % (2023) auf 74 % (2024). https://almanac.httparchive.org/en/2024/performance ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹

5. Shopify, “Shopify Checkout is the best-converting in the world. Here’s why.” - Laut einer Studie einer großen Unternehmensberatung konvertiert der Shopify-Checkout bis zu 36 % besser und im Durchschnitt 15 % besser als Konkurrenz-Checkouts. https://www.shopify.com/enterprise/blog/shopify-checkout ↩

6. HTTP Archive, Kapitel “Ecommerce”, Web Almanac 2024 - Shopify hat seit 2022 im Gegensatz zu Plattformen wie WooCommerce konstant gute LCP-Erfolgsquoten beibehalten. https://almanac.httparchive.org/en/2024/ecommerce ↩ ↩²

7. HTTP Archive, Kapitel “Page Weight”, Web Almanac 2024 - die durchschnittliche mobile Seite (Median) fragt rund 570 KB JavaScript ab. https://almanac.httparchive.org/en/2024/page-weight ↩