Das Wichtigste in Kürze
- Bei der Analyse von über 500 Shopify-Stores haben wir festgestellt, dass Websites mit Drag-and-Drop Page Buildern 22–37 % langsamer waren als vergleichbare Seiten mit Native-Theme-Code Buildern. Dieser Unterschied ist strukturell bedingt und kein bloßes Konfigurationsproblem.
- Der größte Fehler, den Store-Betreiber bei Speed-Tests machen, ist das Vertrauen auf einen einzigen Lighthouse-Lauf. Lighthouse ist ein einziger Page Load in einer synthetischen Umgebung; echte Nutzer greifen über verschiedene Netzwerke, Geräte und Seiten auf deinen Store zu.
- Nutze Real User Monitoring (RUM) beim 75. Perzentil, um zu messen, was deine Kunden tatsächlich erleben. Genau das nutzt auch Google für das Ranking.
- Synthetic Testing (Lighthouse, WebPageTest) ist in Ordnung für einen relativen Vergleich zwischen Tools. Es ist jedoch kein verlässlicher Maßstab für deine Live-UX.
Die schnellsten Shopify Page Builder sind die, die Native Theme Code ausgeben, da sie der Seite kein Runtime-JavaScript hinzufügen. Drag-and-drop Builder bringen alle eine messbare „Speed-Steuer“ durch ihre App-Runtime pro Besuch mit sich – im Schnitt 22–37 % bei den über +500 von uns analysierten Shopify Stores. Ein Page Builder, der deinen Store ausbremst, kostet dich gleichzeitig Conversions, Ad-ROAS und SEO-Rankings. Dieser Guide erklärt dir, was den Slowdown eigentlich verursacht, wie du ihn ehrlich anhand von Real-User-Daten messen kannst, und bietet dir ein Template zum unkomplizierten Copy-Paste, 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 User simuliert. Das Lighthouse-Audit in den PageSpeed Insights ist das bekannteste Beispiel. Es ist nützlich, weicht aber immer von den Real-User-Daten ab. Mach mal ein Lighthouse-Audit für Amazon, eBay oder Walmart und vergleiche es mit ihren CrUX-Zahlen – die Kluft ist gewaltig.
Drei Dinge, an die du denken solltest, wenn du synthetische Ergebnisse liest:
Synthetisch bedeutet ein Page-Load, RUM bedeutet Tausende. Ein einzelner Lighthouse-Durchlauf kann mehr als 30 % vom Median aus drei Durchläufen abweichen. Nimm immer den Median von mindestens drei Durchläufen unter denselben Netzwerkbedingungen und zur selben Tageszeit.
Die Total Blocking Time (TBT) kann in die Irre führen. Tools, die unkritische Skripte aufschieben, damit sie nach dem Hauptinhalt geladen werden (was das richtige Muster für gute UX ist), erzielen in Lighthouse oft eine höhere TBT als Tools, die bei diesen Skripten blockieren. Die Lighthouse-Zahl kann steigen, während sich die tatsächliche UX verbessert. Gleiche die Daten mit RUM ab, bevor du auf eine TBT-Verschlechterung reagierst.
Einschränkungen bei der LCP-Messung. Lighthouse und WebPageTest messen den Largest Contentful Paint des gesamten Page-Loads. Googles RUM-Messung verwendet den Largest Paint, bevor der User mit der Seite interagiert. Auf einer Produktseite ist das oft das Produktbild – WebPageTest misst jedoch 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 bewertest du das Problem über.
Wenn man sich für ein synthetisches Tool entscheiden muss, ist WebPageTest der Goldstandard in der Web-Performance-Community, da man die Umgebung fein abstimmen kann, um einem P75-Nutzer zu entsprechen (Netzwerk-Drosselung, Geräte-Emulation, geografischer Standort). Wir nutzen es selbst, wenn wir die UX einer Website mit und ohne Fudge vergleichen, bevor Real-User-Daten 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 dieses Template, wenn du Page Builder auf einem Development-Store vergleichen musst, bevor du dich festlegst. Kombiniere den synthetischen Median mit mindestens einer Woche RUM-Daten, sobald du live gehst.
| Builder | Baseline LCP | Builder Page LCP | Δ LCP | INP | CLS | JS Added | Ü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 es aus:
- Installiere ein frisches Shopify Dawn-Theme in einem Development-Store. Lass Lighthouse Mobile dreimal 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 dreimal laufen; notiere den Median.
- Das Δ LCP ist deine synthetische Schätzung der “Kosten” dieses Builders. Hinweis: Dies ist ein einziger Page-Load. Bestätige den Wert nach einer Woche mit echtem Live-Traffic über RUM.
- Deinstalliere den Builder vollständig – einschließlich aller
theme.liquidScript-Tags, die er hinterlassen hat –, bevor du den nächsten testest. - Nutze die Chrome DevTools → Tab “Coverage”, um das hinzugefügte JavaScript („JS Added“, ungenutzt vs. gesamt) für jeden Builder zu zählen.
Die Spalte „Überlebt Deinstallation“ ist der Teil, den dir kein Lighthouse-Durchlauf zeigen kann. Teste es: Baue eine Seite, deinstalliere die App und schau, was übrig bleibt. Der Output von nativem Theme-Code bleibt erhalten; der per App gerenderte Output fällt auf einen Platzhalter zurück.
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
Die schnellsten sind solche, die Native Theme Code ohne Runtime ausgeben, weil ihre Seiten ohne App-Overhead gerendert werden. Bei über 500 von uns analysierten Shopify-Stores waren Webseiten mit Drag-and-Drop Buildern durchschnittlich 22–37 % langsamer als Seiten mit Native-Theme-Code Buildern. Überprüfe das nach dem Live-Gang mit deinen eigenen RUM-Daten; Lighthouse allein reicht nicht aus.
Nein. Lighthouse ist ein Page Load in einer kontrollierten Umgebung; echte Nutzer rufen deine Seite unter tausenden verschiedenen Bedingungen auf. Nutze den Median aus drei Lighthouse-Runs als relativen Vergleich zwischen Konfigurationen und validiere ihn dann mit Echtzeit-Nutzerdaten (RUM) von mindestens einer Woche beim 75. Perzentil.
Real User Monitoring (RUM) sind Daten, die aus den Browsern deiner tatsächlichen Kunden gesammelt und auf das 75. Perzentil aggregiert werden. Das ist genau das, was Google über die Core Web Vitals für das Ranking nutzt. Synthetische Tools (Lighthouse, WebPageTest) schätzen lediglich die Erfahrung eines einzelnen Nutzers ab; RUM verrät dir, wie die meisten Nutzer die Seite tatsächlich erleben.
Das kann passieren, wenn so viel JavaScript hinzukommt, dass dein P75 LCP und INP die Grenzwerte der Core Web Vitals sprengen. Seiten, die bei den Core Web Vitals durchfallen, haben einen Wettbewerbsnachteil in der Suche. Teste immer anhand von Mobile-RUM und nicht mit Desktop-Lighthouse.
Nein. Das CDN liefert Dateien zwar schnell aus, aber der Browser des Kunden muss trotzdem jedes JavaScript-Bundle parsen und ausführen, das der Builder lädt. Große Runtime = langsame Seite, egal wie schnell das CDN ist.
Nutze einen Development-Store. Installiere das Shopify-Theme Dawn, installiere den Builder, veröffentliche eine repräsentative Seite, lasse Lighthouse 3× auf Mobile durchlaufen und nimm den Median. Deinstalliere die App wieder, bevor du die nächste testest. Sobald ein Builder eine Woche lang im Live-Store aktiv ist, bilden die RUM-Daten die absolute Wahrheit – die synthetischen Tests waren nur die Vorprüfung.
Ja – und prüfe das Theme nach der Deinstallation auf übriggebliebene Snippets. Einige Builder hinterlassen Script-Tags oder CSS-Importe in der theme.liquid, auch wenn die App bereits weg ist. Durchsuche dein Theme nach der Domain oder den Asset-Namen des Builders.
