Der Stand der Shopify-Performance in 2026

Das Wichtigste in Kürze

• Core Web Vitals sind ein offizieller Google Ranking-Faktor, und seit März 2024 hat INP den FID als Metrik für die Reaktionsfähigkeit abgelöst. “Gut” bedeutet ein LCP unter 2,5s, INP unter 200ms und CLS unter 0,1.¹²
• Geschwindigkeit ist ein Conversion-Hebel, nicht nur ein SEO-Faktor. Eine Verbesserung der mobilen Ladezeit um 0,1s steigerte in einer Studie von Deloitte und Google die Conversion-Raten im Einzelhandel um 8,4 % und den durchschnittlichen Bestellwert um 9,2 %.³
• Nur 48 % der Websites bestehen alle drei Core Web Vitals auf Mobilgeräten (Web Almanac 2025). LCP ist die Metrik, an der die meisten Websites scheitern; INP ist der Punkt, an dem Shopify-Stores mit vielen Apps am stärksten zu kämpfen haben.⁴
• Der größte Bremsklotz für einen Shopify-Store ist selten die Plattform selbst. Es ist angehäuftes App-JavaScript, Third-Party-Widgets, große Hero-Medien und Layouts, die sich verschieben, wenn späte Skripte geladen werden.
• Nativer Theme-Code spart dir die Performance-Kosten, die bei jedem Besuch durch App-Runtimes entstehen. In unserer Analyse von über 500 Shopify-Stores waren Websites, die mit App-gerenderten Page Buildern erstellt wurden, durchweg langsamer als vergleichbare Websites, die mit nativem Theme-Code gebaut wurden.

Shopify-Performance 2026, kurz gesagt: Das Fundament der Plattform ist solide und wird immer besser, die Messlatte hat sich verschoben, und fast alle Performance-Probleme in echten Stores entstehen durch das, was Händler obendrauf packen.

Alle paar Monate schickt mir ein Händler einen PageSpeed-Score, meistens einen roten, und stellt mir dieselbe Frage: Liegt das an Shopify, an meinem Theme oder an den zwölf Apps, die ich letztes Jahr installiert habe? Unten findest du belegte Shopify Performance-Benchmarks und die Faktoren, die die meisten Stores ausbremsen.

Warum du uns vertrauen kannst

Ich habe über 15 Jahre Entwicklererfahrung und wir arbeiten seit mehr als vier Jahren im Shopify-Ökosystem. Wir haben die Core Web Vitals bei über 500 Shopify-Stores gemessen und Themes speziell umgebaut, um die durch Apps verlorene Geschwindigkeit wiederherzustellen. Außerdem entwickeln wir Fudge, den KI-Operator für Shopify-Stores, mit einer Bewertung von 4.9 im Shopify App Store. Sein Store-Editor und Page Builder schreiben Änderungen und Seiten direkt als nativen Code in dein Theme, anstatt sie über eine App-Runtime zu rendern. Diese Designentscheidung ist direkt aus diesem Performance-Problem entstanden, daher werden wir ehrlich darauf hinweisen, falls wir voreingenommen sind.

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 Wahrheit. Die andere Hälfte ist, dass schnellere Stores mehr verkaufen.

Die am häufigsten zitierte kontrollierte Studie dazu ist der „Milliseconds Make Millions“-Bericht von Deloitte und Google, bei dem 37 Marken-Websites in mehr als 30 Millionen Sitzungen gemessen wurden. Eine Verbesserung der mobilen Ladezeit um 0,1 Sekunden steigerte die Conversion-Rate im Einzelhandel um 8,4 % und den durchschnittlichen Bestellwert um 9,2 %.³ Das ist eine Zehntelsekunde, die für einen fast zweistelligen Umsatzzuwachs sorgt. Unser Mobile-First Shopify Speed Guide erklärt, wie man dieses Potenzial bei 3G-Verbindungen und Low-End-Geräten ausschöpft, wo die Gewinne am größten sind.

Um die Dimensionen beim Checkout einzuordnen: Laut einer von Shopify in Auftrag gegebenen Studie liegt die Conversion-Rate des eigenen Checkouts um bis zu 36 % höher – und im Durchschnitt um 15 % höher – als bei der Konkurrenz.⁵ Die Plattform hat bei den Teilen, die sie kontrolliert, wirklich gute Arbeit geleistet. Das Storefront vor diesem Checkout ist jedoch der Bereich, in dem die meisten Händler noch Geld liegen lassen.

Für ein detailliertes Bild nach Kategorien, wo die Conversion steht, siehe unsere Shopify Conversion-Rate-Benchmarks.

Die Core Web Vitals Grenzwerte und wie das Web abschneidet

Bevor wir uns Shopify im Detail ansehen, ist es hilfreich zu wissen, was im restlichen Web als “normal” gilt, denn Shopify-Stores werden nach demselben Maßstab bewertet.

Der HTTP Archive Web Almanac, der Millionen echter Websites analysiert, hat herausgefunden, dass im Juli 2025 nur 48 % der Websites alle drei Core Web Vitals auf Mobilgeräten bestanden haben, im Vergleich zu 36 % zwei Jahre zuvor.⁴ Hier ist die Aufschlüsselung nach Metriken:

Zwei Dinge fallen auf.

Erstens: Der Wechsel zu INP hat die Messlatte höher gelegt. Der Almanac 2024 zeigte, dass 48 % der mobilen Websites das komplette Set unter der alten FID-Metrik bestanden hätten, aber unter INP bestanden nur 43 %.⁶ Das Web ist nicht langsamer geworden. Das Lineal ist nur ehrlicher geworden.

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

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

Wo Shopify-Stores eigentlich stehen

Shopify liegt bei der Metrik, die die Plattform am direktesten kontrolliert, über dem E-Commerce-Durchschnitt. Die E-Commerce-Analyse des Web Almanac stellt fest, dass Shopify seit 2022 konstant gute LCP-Bestehensquoten aufweist – eine Gruppe, die sich die Plattform mit nur einer Handvoll anderer teilt.⁷ Das ist kein Zufall. Jeder Shopify-Store läuft über dasselbe CDN, dasselbe Edge-Caching und dasselbe serverseitig gerenderte Liquid. Die First-Paint-Grundlagen sind also von Haus aus so stark, wie es eine selbst gehostete Plattform einfach nicht garantieren kann.

Wo Shopify-Stores Probleme haben, ist genau da, wo der Rest des interaktiven Webs auch kämpft: beim INP. Und hier ist die Ursache fast nie die Plattform. Es ist das clientseitige JavaScript, das Händler oben draufpacken.

Ein kurzer Hinweis zur Ehrlichkeit der Zahlen: Öffentliche aggregierte Daten zum “Anteil der Shopify-Stores, die alle drei Core Web Vitals bestehen” variieren stark je nach Quelle und Messzeitraum. Daher werde ich hier keine einzelne Headline-Zahl zitieren, als wäre sie in Stein gemeißelt. Die belastbaren, belegten Fakten sind diese: Das LCP auf Plattformebene von Shopify ist durchweg gut,⁷ die webweite Bestehensquote für alle drei Metriken liegt mobil bei 48 %⁴ und INP ist die Metrik, die am meisten unter Druck steht. Der Rest des Scores deines Stores wird davon bestimmt, was du als Händler hinzufügst.

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 das große Ganze, zeichnet sich ein klares Muster ab. Fast jeder der oben genannten Bremsklötze ist eine Variante desselben Problems: Code, der bei jedem Besuch auf dem Gerät des Käufers ausgeführt wird, um ein Feature bereitzustellen, das auch einmalig auf dem Server hätte gerendert werden können.

Das ist das strukturelle Problem bei Modellen, die stark auf Apps setzen. Eine App, die einen Teil deiner Seite über eine eigene Runtime rendert, muss diese Runtime laden, damit der Käufer das Ergebnis sieht. Ein Page Builder, der Seiten über ein App-SDK rendert, fügt sein Bundle zu jeder Seite hinzu, die er anfasst. Der Store zahlt für den Komfort des Editors bei jedem Besuch einen Performance-Preis.

Nativer Theme-Code kennt dieses Problem nicht. Wenn eine Seite als Liquid, CSS und HTML direkt ins Theme geschrieben wird, rendert der Server sie genau wie jede andere Shopify-Seite. Es muss kein App-SDK heruntergeladen werden, kein Runtime-Layout muss hydriert werden und es gibt keine Builder-Runtime, die mit dem Main-Thread konkurriert.

Unser Shopify Page Builder Speed Test zeigt dir, wie du diesen Unterschied in deinem eigenen Store messen kannst. Die Lücke ist architektonischer Natur, kein Konfigurationsfehler, den du einfach wegoptimieren kannst. Eine Runtime kann zwar verschlankt werden, aber sie kann eben nicht null Bytes groß sein.

Genau an diesem Punkt setzt Fudge an und das ist der Grund, warum wir es so gebaut haben. Du beschreibst die Seite, Fudge entwirft sie in deinem Theme als nativen Code, und die veröffentlichte Seite hat denselben JavaScript-Fußabdruck wie eine, die dein Entwickler von Hand codiert hat. Das Lighthouse-Limit wird durch dein Theme, deine Bilder und deine anderen Apps vorgegeben, nicht durch den Builder. Fudge kann außerdem jederzeit einen Speed-Audit durchführen, den Code finden, den deinstallierte Apps in deinem Theme hinterlassen haben, und einen Entwurf zum Aufräumen erstellen, den du nur noch absegnen musst.

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