Wichtigste Erkenntnisse
- Bei über 500 von uns analysierten Shopify-Stores waren Websites mit Drag-and-Drop Page Buildern 22–37 % langsamer als vergleichbare Websites, die mit nativem Theme-Code gebaut wurden. Die Lücke ist strukturell, nicht konfigurationsbedingt.
- Der größte Fehler, den Shop-Betreiber beim Testen der Geschwindigkeit machen, ist das blinde Vertrauen in einen einzigen Lighthouse-Lauf. Lighthouse ist ein einziger Seitenaufruf in einer synthetischen Umgebung; echte Nutzer greifen mit unterschiedlichen Netzwerken, Geräten und Seiten auf deine Website zu.
- Nutze Real User Monitoring (RUM) am 75. Perzentil, um zu messen, was deine Kunden tatsächlich erleben. Das ist auch das, was Google für das Ranking heranzieht.
- Synthetisches Testing (Lighthouse, WebPageTest) ist für den relativen Vergleich zwischen Tools in Ordnung. Es ist aber kein verlässliches Maß für deine Live-UX.
Die schnellsten Shopify Page Builder sind diejenigen, die nativen Theme-Code ausgeben, da sie der Seite kein Runtime-JavaScript hinzufügen. Drag-and-Drop-Builder bringen alle eine messbare Geschwindigkeitssteuer durch ihre App-Runtime pro Besuch mit sich – im Durchschnitt 22–37 % bei den über 500 von uns analysierten Shopify-Stores. Ein Page Builder, der deinen Shop verlangsamt, kostet dich gleichzeitig Conversions, Ad-ROAS und SEO-Rankings. Dieser Guide erklärt, was die Verlangsamung tatsächlich verursacht, wie du sie mit echten Nutzerdaten verlässlich messen kannst, und bietet dir ein Template zum Kopieren, mit dem du jedes Tool selbst testen kannst.
Warum du uns vertrauen kannst
Über 15 Jahre Entwicklererfahrung und vier Jahre im Shopify-Ökosystem. Wir haben die Performance von über 500 Shopify-Stores mit Fudge und anderen Tools gemessen und Themes speziell umgebaut, um die durch Apps verlorene Geschwindigkeit zurückzugewinnen. Wir entwickeln auch Fudge, das Seiten direkt in dein Theme schreibt, anstatt eine Runtime hinzuzufügen – eine Designentscheidung, die genau aufgrund dieses Problems getroffen wurde.
Was einen Shopify-Store wirklich verlangsamt, wenn du einen Page Builder installierst
Es gibt vier Faktoren. Sie verstärken sich gegenseitig.
1. Das Runtime-JavaScript des Builders
Die meisten Drag-and-Drop Builder injizieren bei jedem Besuch einer von ihnen gerenderten Seite ein JavaScript-Bundle. Dieses Bundle kümmert sich um Layout-Hydration, Lazy-Loading von Blöcken, Animationen und den Editor-Vorschaulink. Es läuft selbst dann, wenn der Kunde nur durch den Store browsed.
Das Gewicht variiert. Manche Tools haben ihre Runtime extrem entschlackt. Andere liefern 200KB+ an JavaScript aus, das der Kunde parsen muss, bevor die Seite interaktiv wird. Der Unterschied zeigt sich deutlich bei der Total Blocking Time und beim Largest Contentful Paint.
2. Render-blocking CSS, das in den Head injiziert wird
Page Builder fügen oft ein Stylesheet in den Document Head ein, bevor die Seite rendert. Dieses Stylesheet muss erst heruntergeladen und geparst werden, bevor der Browser mit dem Painting beginnt. In langsamen Netzwerken ist das die Hauptursache für einen langsamen LCP.
3. Große Hero-Images ohne moderne Formate
Nicht per se die Schuld des Builders – aber Page Builder-Templates verwenden oft standardmäßig viel zu große Hero-Images. Der Kunde lädt über eine mobile Verbindung ein 1,5 MB großes Hero-Image herunter. Du kannst das beheben, indem du WebP/AVIF, die richtigen Bildgrößen und korrekte loading-Attribute verwendest.
4. Gestapelte Apps hinterlassen alle ihren eigenen Footprint
Eine Page-Builder-App + eine Reviews-App + ein Chat-Widget + eine Upsell-App summieren sich schnell auf 1-2 MB JavaScript, bevor die Seite überhaupt etwas Nützliches tut. Der Page Builder ist selten der einzige Schuldige, aber er ist meistens einer der schwersten. Auditiere alles.
Was „keine Runtime“ in der Praxis bedeutet
Ein Page Builder, der nativen Theme-Code ausgibt, schreibt Liquid + CSS + HTML in deine Theme-Dateien und fügt sonst nichts hinzu. Wenn ein Kunde die Seite aufruft, rendert der Server sie genau wie jede andere Shopify-Seite. Kein App-SDK, kein zusätzliches JavaScript, kein Runtime-Layout.
Fudge funktioniert genau so: Du beschreibst die Seite, Fudge schreibt sie in dein Theme, und die veröffentlichte Seite hat denselben JavaScript-Footprint wie eine von einem Entwickler handcodierte Seite. Der Lighthouse-Score wird durch dein Theme, deine Bilder und deine anderen Apps begrenzt – nicht durch Fudge.
Das ist der strukturelle Vorteil dieser Kategorie. Es ist nicht so, dass KI-Builder von Natur aus schneller sind; es liegt daran, dass Builder, die nativen Code schreiben, keine Runtime hinzufügen, die sie verlangsamt.
Wie man die Shopify-Geschwindigkeit wirklich reell misst
Die meisten „Speed Test“-Artikel führen ein einziges Lighthouse-Audit durch und verlassen sich auf das Ergebnis. Das ist falsch. Die Zahl, die du aus einem einzigen Lighthouse-Durchlauf erhältst, spiegelt nicht das Erlebnis deiner Kunden wider – und es ist nicht das, was Google für das Ranking deines Stores nutzt.
Die folgenden Methoden sind nach ihrer Nützlichkeit geordnet, um die tatsächlichen Auswirkungen der Geschwindigkeit auf UX, SEO-Traffic und Conversions zu beurteilen.
1. Real-User-Daten (RUM) – was wir und Google nutzen
Der zuverlässigste Weg, die Geschwindigkeit von Shopify zu messen, sind die Daten von echten Kunden. Das ist das, was Google über die Core Web Vitals in seinen Ranking-Systemen nutzt. RUM-Daten erfassen die variablen Faktoren, die synthetische Tests nicht berücksichtigen können: unterschiedliche Netzwerkgeschwindigkeiten, Bildschirmgrößen, Geräteleistungen, geografische Regionen und den tatsächlichen Mix der von den Kunden besuchten Seiten.
Da die Erfahrung eines einzigen Users zu starke Schwankungen aufweist, um daraus Schlüsse zu ziehen, aggregiert man die Daten. Wir – und Google – bevorzugen das 75. Perzentil (P75) jedes Core Web Vitals. Ein LCP von 4,5s beim P75 bedeutet also, dass 75 % deiner Kunden diesen LCP-Wert oder einen besseren erleben. P75 ist das richtige Perzentil, weil es die Erfahrung der großen Mehrheit der User erfasst und gleichzeitig extreme Ausreißer abmildert (ein Kunde mit einer 2G-Verbindung in einem Tunnel definiert nicht die UX deines Stores).
Wenn deine P75-Metrik gut ist, weißt du, dass die meisten User ein gutes Erlebnis haben. In Shopify-Stores, die Fudge nutzen, bestehen die P75 Core Web Vitals für über 80 % der User.
Wo du diese Daten findest:
- Fudge-Dashboards – P75-Metriken in Echtzeit für 100 % der Page-Loads, aufgeschlüsselt nach Template und Gerät
- Chrome User Experience Report (CrUX) – Googles öffentlicher RUM-Datensatz, hinkt der Echtzeit um ca. 28 Tage hinterher
- Google Search Console – Core Web Vitals-Bericht, gespeist von CrUX
Wenn du heute eine Geschwindigkeitsänderung vornimmst, siehst du sie sofort in deinem Fudge-Dashboard; in CrUX und der Search Console taucht sie innerhalb von 28 Tagen auf.
2. Synthetisches Testing (Lighthouse, WebPageTest)
Synthetisches Testing bedeutet, dass eine Seite durch eine kontrollierte Umgebung läuft, die einen Nutzer simuliert. Der Lighthouse-Audit in PageSpeed Insights ist das bekannteste Beispiel dafür. Das ist nützlich, weicht aber immer von echten Nutzerdaten ab. Mach mal einen Lighthouse-Audit für Amazon, eBay oder Walmart und vergleiche ihn mit ihren CrUX-Zahlen – der Unterschied ist riesig.
Drei Dinge, die du dir bei synthetischen Ergebnissen merken solltest:
Synthetisch ist ein Seitenaufruf, RUM sind Tausende. Ein einzelner Lighthouse-Durchlauf kann über 30 % vom Median aus drei Tests abweichen. Nimm immer den Median von mindestens drei Durchläufen unter denselben Netzwerkbedingungen und zur selben Tageszeit.
Total Blocking Time (TBT) kann irreführend sein. Tools, die nicht-kritische Skripte aufschieben, damit sie nach dem Hauptinhalt laden (was für die UX das richtige Muster ist), erzielen in Lighthouse oft einen höheren TBT-Wert als Tools, die bei diesen Skripten blockieren. Der Lighthouse-Wert kann steigen, während sich die eigentliche UX verbessert. Überprüfe das mit RUM gegen, bevor du auf eine TBT-Verschlechterung reagierst.
Tücken bei der LCP-Messung. Lighthouse und WebPageTest messen den größten Paint des gesamten Ladevorgangs. Googles RUM-Messung berücksichtigt den größten Paint, bevor der Nutzer mit der Seite interagiert. Auf einer Produktseite ist das oft das Produktbild – aber WebPageTest misst manchmal, wie lange es dauert, bis ein Exit-Intent-Popup gerendert wird. Konfiguriere dein synthetisches Tool so, dass es bei der ersten Interaktion aufhört zu messen, sonst schätzt du das Problem falsch ein.
Wenn man sich für ein synthetisches Tool entscheiden muss, ist WebPageTest der Goldstandard in der Web-Performance-Community, da man die Umgebung dort extrem genau auf einen P75-Nutzer abstimmen kann (Netzwerk-Drosselung, Geräte-Emulation, geografischer Standort). Wir nutzen es selbst, wenn wir das Erlebnis einer Seite mit und ohne Fudge vergleichen, bevor echte Nutzerdaten vorliegen.
3. Die richtige Reihenfolge (Order of Operations)
- Verknüpfe ein RUM-Tool (Fudge-Dashboard, web-vitals Library oder Daten aus CrUX abrufen)
- Erstelle eine 28-tägige P75-Baseline über deine wichtigsten Templates und Geräteklassen hinweg
- Nimm eine Änderung vor
- Beobachte den P75 in RUM. Nutze Lighthouse nur für den relativen Vergleich zwischen Konfigurationen, niemals als die absolute Wahrheit (Source of Truth)
Wenn du noch kein RUM hast, fang dort an. Synthetische Vergleiche ohne RUM-Kontext sind reines Raten.
Ein Copy-Paste Speed Test Template
Nutze das hier, wenn du Page Builder auf einem Development Store vergleichen musst, bevor du dich entscheidest. Paare den synthetischen Median mit mindestens einer Woche RUM-Daten, sobald du live gehst.
| Builder | Baseline-LCP | Builder-Seite LCP | Δ LCP | INP | CLS | Hinzugefügtes JS | Überlebt Deinstallation? | Notizen |
|---|---|---|---|---|---|---|---|---|
| Fudge | Ja | Nativer Theme-Code; keine Runtime | ||||||
| PageFly | Nein | App-gerenderte Runtime | ||||||
| GemPages | Nein | App-gerenderte Runtime | ||||||
| Shogun | Nein | App-gerenderte Runtime | ||||||
| Replo | Nein | App-gerenderte Runtime |
So füllst du sie aus:
- Installiere ein frisches Shopify Dawn Theme auf einem Development Store. Lass Lighthouse Mobile 3× auf der Startseite laufen; notiere den Median-LCP als deine Baseline.
- Installiere einen Builder. Veröffentliche eine repräsentative Seite (Hero, drei Bild+Text-Blöcke, Testimonial-Slider, FAQ, CTA). Lass Lighthouse Mobile 3× laufen; notiere den Median.
- Der Δ LCP ist deine synthetische Schätzung der Kosten für diesen Builder. Hinweis: Das ist ein Seitenaufruf. Bestätige das nach einer Woche Live-Traffic mit RUM.
- Deinstalliere den Builder vollständig – inklusive aller
theme.liquidScript-Tags, die er hinterlassen hat –, bevor du den nächsten testest. - Nutze den “Coverage”-Tab in den Chrome DevTools, um das “Hinzugefügte JS” (ungenutzt vs. gesamt) für jeden Builder zu ermitteln.
Die Spalte „Überlebt Deinstallation?“ ist genau das, was dir kein Lighthouse-Lauf zeigen kann. Teste es: Baue eine Seite, deinstalliere die App und schau, was übrig bleibt. Nativer Theme-Code bleibt bestehen; App-gerenderter Output wird zu einem Platzhalter.
Wie „gut“ aussieht
Zielwerte für eine Shopify-Seite auf Mobile, gemessen beim P75:
- LCP (Largest Contentful Paint): unter 2,5s
- INP (Interaction to Next Paint): unter 200ms
- CLS (Cumulative Layout Shift): unter 0,1
- Gesamtes Page-Weight: unter 1,5 MB (ohne Video)
Das sind keine bloßen Wunschziele – es sind die Core Web Vitals-Grenzwerte von Google, gemessen am 75. Perzentil der Page-Loads über Mobile und Desktop hinweg (web.dev, 2024). Google hat bestätigt, dass Core Web Vitals in seinen Ranking-Systemen verwendet werden – eine Seite, die sie verfehlt, ist in der Suche nicht wettbewerbsfähig.
Der einfachste Weg, diese Werte auf jeder veröffentlichten Seite konstant zu erreichen, ist die Nutzung eines Builders, der keine Runtime hinzufügt – was heutzutage einen KI-Builder bedeutet, der nativen Theme-Code schreibt, anstatt einer Drag-and-Drop App, die Seiten durch ihre eigene Runtime rendert. Der Unterschied von 22–37 %, den wir bei über 500 Shopify-Stores zwischen Drag-and-Drop Buildern und Native-Code Buildern sehen, ist kein Konfigurationsproblem; es ist die Architektur.
Kategorien mit einem strukturellen Nachteil in Sachen Speed
Ohne bestimmte Tools zu nennen:
- App-gerenderte Seiten mit iFrame-Embeds. Allein der iFrame kostet dich LCP und verkompliziert den CLS.
- Builder, die ein globales Stylesheet auf der gesamten Website einbinden, nicht nur auf den vom Builder gerenderten Seiten. Jede Seite im Store zahlt den Preis, selbst die, die der Builder gar nicht berührt hat.
- Builder mit schweren Animations-Runtimes. Smooth Scroll, Parallax und Entrance-Animationen kosten INP.
- Builder, die Layouts (nicht nur Bilder) per Lazy-Load laden. Ein Layout, das vor dem Paint auf JavaScript angewiesen ist, schadet LCP und CLS gleichzeitig.
Tools mit schlanken Runtimes können dennoch akzeptabel sein – der Preis ist real, aber überschaubar. Tools, die dicke Runtimes plus schwere Templates plus iFrames mitbringen, summieren die Kosten auf.
Für einen umfassenderen Vergleich siehe unser Ranking der besten Shopify Page Builder und unsere Erklärung, was ein Shopify Page Builder ist.
Eine kurze Anmerkung zu Hosting und CDN
Shopify hostet jeden Store auf seinem eigenen CDN mit integriertem Edge Caching. Die Langsamkeit eines Page Builders ist selten ein Hosting-Problem – es ist fast immer ein Payload-Problem (zu große Dateigrößen). Bilder zu optimieren, ungenutztes JavaScript zu entfernen und Apps zu konsolidieren, bringt mehr als jeder Wechsel des Hostings.
Wohin sich die Kategorie entwickelt
Wir geben unsere Voreingenommenheit von vornherein zu – wir haben Fudge entwickelt, das Seiten direkt in dein Theme schreibt, anstatt sie über eine App-Runtime zu rendern. Wir haben uns für dieses Design entschieden, weil die Geschwindigkeitseinbuße des Runtime-Modells kein behebbarer Bug ist; es ist die Architektur. Drag-and-Drop Tools können ihre Runtimes zwar reduzieren, aber sie können sie nicht auf null bringen. KI-Builder, die nativen Theme-Code ausgeben, können das.
Für die meisten Stores im Jahr 2026 – besonders solche mit Paid Traffic, bei denen jede LCP-Verzögerung von 100ms ROAS kostet – lautet die Frage nicht mehr „welcher Page Builder ist der schnellste“, sondern „welche Kategorie hat keine strukturelle Obergrenze in punkto Speed“. Das ist eine andere Entscheidung als noch vor einem Jahr in dieser Kategorie üblich war.
FAQ
Am schnellsten sind diejenigen, die nativen Theme-Code ohne Runtime ausgeben, da ihre Seiten ohne App-bedingten Overhead gerendert werden. Bei über 500 von uns analysierten Shopify-Stores waren Websites mit Drag-and-Drop Buildern durchschnittlich 22–37 % langsamer als Websites mit nativem Theme-Code. Überprüfe das mit deinen eigenen RUM-Daten, sobald du live gehst; Lighthouse allein reicht nicht aus.
Nein. Lighthouse ist ein Seitenaufruf in einer kontrollierten Umgebung; echte Nutzer greifen unter Tausenden verschiedener Bedingungen auf deine Website zu. Nutze den Median aus drei Lighthouse-Tests als relativen Vergleich zwischen Konfigurationen und validiere ihn dann mit mindestens einer Woche echter Nutzerdaten am 75. Perzentil.
Real User Monitoring (RUM) sind Daten, die in den Browsern deiner tatsächlichen Kunden gesammelt und auf das 75. Perzentil aggregiert werden. Das ist das, was Google über die Core Web Vitals für das Ranking nutzt. Synthetische Tools (Lighthouse, WebPageTest) schätzen ungefähr ab, was ein Nutzer erleben könnte; RUM sagt dir, was die meisten Kunden tatsächlich erleben.
Das kann passieren, wenn er so viel JavaScript hinzufügt, dass dein P75-LCP und -INP die Grenzwerte der Core Web Vitals überschreiten. Seiten, die bei den Core Web Vitals durchfallen, haben in der Suche einen Wettbewerbsnachteil. Teste mit Mobile-RUM, nicht mit Desktop-Lighthouse.
Nein. Das CDN liefert Dateien schnell aus, aber der Browser des Kunden muss dennoch jedes JavaScript-Bundle parsen und ausführen, das der Builder lädt. Schwere Runtime = langsame Seite, ganz egal wie schnell das CDN ist.
Nutze einen Development Store. Installiere das Shopify Theme Dawn, installiere den Builder, veröffentliche eine repräsentative Seite, lass Lighthouse 3× auf Mobile laufen und nimm den Median. Deinstalliere die App, bevor du die nächste testest. Wenn ein Builder eine Woche lang in deinem Live Store ist, sind die RUM-Daten die absolute Wahrheit – der synthetische Test war nur der erste Filter.
Ja – und überprüfe das Theme nach dem Deinstallieren auf übrig gebliebene Snippets. Manche Builder hinterlassen Script-Tags oder CSS-Importe in der theme.liquid, selbst wenn die App gelöscht wurde. Durchsuche dein Theme nach der Domain oder den Asset-Namen des Builders.
