Berichte und Recherche zu Shopify und E-Commerce
Händler gehen davon aus, dass langsame Storefronts neue Einstellungen brauchen, die man aktiviert, doch der Theme-Code zeigt das umgekehrte Problem: Funktionen, die nie als Schalter angelegt wurden. Die Lösung besteht also darin, ein Theme zu wählen, dessen Core Web Vitals im Ausgangszustand schon unter echtem Traffic standhalten.
Die meisten Händler gehen mit der Annahme in BFCM, dass die Lösung für eine langsame Storefront irgendwo in einem Einstellungsbereich liegt, ein Schalter für Animationen, ein Schalter für das, was vor dem Öffnen des Cart-Drawers läuft, irgendetwas, das sie im Theme-Editor abschalten und dann vergessen können. Diesen Schalter gibt es meistens nicht. Das Wort mag in den Theme-Dateien auftauchen, aber es steht in einem Lizenzhinweis oder einer JavaScript-Funktion, nicht in einem Schema-Block mit Label und Wertebereich. Den Unterschied zwischen einer echten Einstellung und einem zufälligen Wortfund zu kennen, ist die eigentliche BFCM-Vorbereitung, und sie ist kleiner und weniger flexibel, als die meisten Checklisten zur Sale-Vorbereitung nahelegen.
Dawn, Shopifys Referenz-Theme, enthält zum Commit vom 2026-08-10 das Wort “off” in 78 seiner 351 Dateien. Das klingt nach vielen Schaltern. Ist es nicht. Zu diesen 78 Dateien gehören LICENSE.md und README.md, also reiner Rechtstext, in dem das Wort zufällig vorkommt, dazu assets/animations.js und assets/base.css, also Implementierungsdateien, keine Einstellungsdateien. Es gibt in Dawns Settings-Schema keinen eigenen Bereich rund um eine An/Aus-Steuerung für Animationen, den ein Händler finden und anklicken könnte. Wer vor einer Traffic-Spitze weniger Bewegung auf einer Produktseite will, öffnet animations.js und bearbeitet Funktionslogik, und das ist eine Entwickleraufgabe, keine Händleraufgabe.
Dasselbe Muster gilt für “before”. Das Wort erscheint in 30 von Dawns 351 Dateien, konzentriert in assets/base.css, assets/cart-disclosure-tooltip.js, assets/cart.js und assets/component-article-card.css. Auch hier handelt es sich um Style- und Verhaltenscode, nicht um eine benannte Einstellung. Ein Händler, der im Theme-Editor nach etwas namens “before checkout” oder “before add to cart” sucht, wird kein passendes Steuerelement finden, denn das Vorkommen des Wortes in der Codebasis ist ein Zufall der Implementierung, kein dokumentiertes Feature.
Horizon, das neuere Shopify-Theme, zeigt das Wort “off” in 138 seiner 484 Dateien und “before” in 77 von 484, beides in absoluten Zahlen mehr als bei Dawn. Die Dateien sind außerdem stärker auf den Warenkorb ausgerichtet: assets/anchored-popover.js, assets/cart-discount.js, assets/cart-drawer.js und assets/cart-icon.js enthalten alle “before”. Das sagt Ihnen, dass Horizons Warenkorb-Interaktionen mehr bedingte Logik enthalten als die von Dawn, vermutlich weil Horizon von Haus aus mehr Warenkorb-Funktionen unterstützt. Es sagt Ihnen nicht, dass es einen Einstellungsschalter gibt, mit dem Händler dieses Verhalten ohne Eingriff in den Code ändern können. Zum Commit 8b42ace vom 2026-08-31 existiert auch in Horizons Schema für keines der beiden Wörter ein eigener Einstellungsbereich.
Die ehrliche Lesart beider Codebasen lautet: “vor BFCM etwas abschalten” ist weder bei Dawn noch bei Horizon eine Aktion im Theme-Editor. Es ist eine Code-Änderung, und wenn Ihr Shop das nicht intern leisten kann, existiert die Einstellung für Sie faktisch nicht.
Da keines der beiden Flaggschiff-Themes von Shopify den granularen Performance-Schalter bereitstellt, nach dem Händler suchen, ist der nützlichere Hebel vor einer traffic-starken Phase schlicht die Wahl eines Themes, dessen Ausgangswerte bereits stark sind. Über den gesamten Markt hinweg, gemessen anhand von CrUX-Felddaten für Juli 2026, besteht das Median-Theme alle Core Web Vitals bei 85.5% der Mobile-Besuche und 86.2% der Desktop-Besuche. Doch dieser Median verdeckt eine große Streuung.
| Gerät | Themes mit ausreichender Datenbasis | Mediane Bestehensquote | Bester Wert am Markt | Schlechtester Wert am Markt |
|---|---|---|---|---|
| Mobile | 247 | 85.5% | 98.6% | 46.1% |
| Desktop | 199 | 86.2% | 99.2% | 30.3% |
Ein Theme, das auf Mobile nahe bei 46.1% liegt, fällt bei den Core Web Vitals für mehr als die Hälfte seiner echten Besucher durch, und kein Animationsschalter und keine Cart-Drawer-Anpassung schließt eine Lücke dieser Größe. Das sind Felddaten von tatsächlichen Shoppern und kein synthetischer Labordurchlauf, sie spiegeln also echte Geräte, echte Netze und echtes Seitengewicht bei normalem Traffic wider, bevor eine BFCM-Spitze die Sache verschlimmert.
Die Anforderungen des Shopify Theme Store setzen einen minimalen durchschnittlichen Lighthouse-Performance-Score von 60 über die Produkt-, Kategorie- und Startseiten eines Themes voraus, jeweils für Desktop und Mobile, dazu einen Mindestwert von 90 bei der Barrierefreiheit für dieselben Seiten und Geräte. Ein Theme muss also lediglich einen Score von 60 überschreiten, um überhaupt gelistet zu werden. Vergleicht man das mit den realen medianen Bestehensquoten am Markt von 85.5% auf Mobile und 86.2% auf Desktop, wird klar, dass die Store-Freigabe eine Untergrenze ist und kein Beleg für BFCM-Tauglichkeit. Zwei Themes können beide die Theme-Store-Prüfung bestehen und sich in der tatsächlichen Besuchererfahrung um zig Punkte unterscheiden.
Preise und Bewertungen klären das ebenfalls nicht. Der mediane Theme-Preis am Markt liegt bei $300, in einer Spanne von $100 bis $500, und die durchschnittliche Bewertung bei 4.53 von 5 über 308 Themes, mit einem Median von 23 Bewertungen pro Theme. Keine dieser Zahlen korreliert direkt mit der Core-Web-Vitals-Bestehensquote, da Bewertungen vor allem die Zufriedenheit mit Design und Support erfassen. Die Themes von UTD erscheinen in dieser allgemeinen Marktübersicht neben allen anderen, und Händler, die Optionen vergleichen, sehen die vollständige Liste unter themes.shopify.com/themes?q=utd, auch wenn die hier vorliegenden Fakten UTD bei keiner spezifischen Geschwindigkeitskennzahl vorn zeigen.
Wählen Sie ein Theme nach seiner gemessenen Core-Web-Vitals-Bestehensquote für das Gerät, das Ihr Traffic tatsächlich nutzt, denn diese Zahl und nicht eine versteckte Einstellung entscheidet darüber, ob Ihr Shop unter BFCM-Last standhält. Wenn der Code eines Themes keinen eigenen Schalter für das enthält, was Sie deaktivieren wollen, planen Sie Budget für einen Entwickler ein, der die Datei direkt bearbeitet, statt nach einer Einstellung zu suchen, die nie gebaut wurde.
Im Code von Dawn gibt es zum Commit 258f00f vom 2026-08-10 keinen eigenen Einstellungsbereich für Animationen. Das Wort 'off' erscheint in 78 seiner 351 Dateien, aber diese Treffer verteilen sich auf LICENSE.md, README.md, assets/animations.js und assets/base.css, nicht auf einen Schema-Block, den ein Händler im Theme-Editor umschalten könnte. Wer bestimmte Bewegungseffekte deaktivieren will, bearbeitet assets/animations.js direkt und klickt keinen Schalter.
Das Wort 'before' erscheint in 77 von Horizons 484 Dateien gegenüber 30 von Dawns 351 Dateien, und in Horizon stehen diese Vorkommen in assets/anchored-popover.js, assets/cart-discount.js, assets/cart-drawer.js und assets/cart-icon.js, also durchweg in warenkorbbezogenem JavaScript. Keines der beiden Themes stellt das als benannte Einstellung bereit, nach der Händler in settings_schema.json suchen könnten. Der Unterschied in der Dateianzahl spiegelt mehr Code für Warenkorb-Interaktionen in Horizon wider, nicht mehr Kontrolle für Händler.
Über 247 Themes mit ausreichender Mobile-Datenbasis liegt der Median-Anteil der Besuche, die alle Core Web Vitals bestehen, bei 85.5%, wobei das beste Theme am Markt 98.6% erreicht und das schlechteste 46.1%. Auf dem Desktop liegt der Median über 199 Themes mit ausreichender Datenbasis bei 86.2%, der beste Wert bei 99.2% und der schlechteste bei 30.3%. Alles, was auf dem Gerätetyp, über den Ihr Shop tatsächlich Traffic bekommt, deutlich unter dem Median liegt, ist bei einer Lastspitze ein echtes Risiko, denn diese Daten stammen aus tatsächlichen Besucher-Sessions in CrUX für Juli 2026 und nicht aus einem Labortest.
Die Prüfung zu bestehen heißt, dass das Theme bei der Lighthouse-Performance mindestens 60 über Produkt-, Kategorie- und Startseiten hinweg erreicht hat, jeweils für Desktop und Mobile, zusätzlich mindestens 90 bei der Barrierefreiheit für dieselben Seiten und Geräte. Das ist eine Untergrenze, kein Zielwert, und es ist ein Laborwert und keine Messung echter Besucher. Die reale mediane Bestehensquote am Markt von 85.5% auf Mobile und 86.2% auf Desktop ist eine deutlich höhere Hürde als das Lighthouse-Minimum von 60 Punkten, die Freigabe im Store allein sagt also sehr wenig über BFCM-Tauglichkeit aus.
Die durchschnittliche Bewertung am Markt liegt bei 4.53 von 5 über 308 Themes, bei einem Median von 23 Bewertungen pro Theme, und diese Bewertung misst die Zufriedenheit der Käufer mit Design und Support, nicht die Seitengeschwindigkeit unter Last. Die Core-Web-Vitals-Bestehensquoten, separat über 247 Themes mit Mobile-Daten und 199 Themes mit Desktop-Daten gemessen, sagen Ihnen, wie das Theme für echte Shopper abschneidet. Ein Theme kann eine hohe Bewertung haben und trotzdem nahe der Mobile-Untergrenze von 46.1% liegen, prüfen Sie also beide Zahlen, nicht nur eine.