Shopify Page Builder Speed Test: Methodik & RUM Best Practices

Wichtigste Erkenntnisse

• In unserer Analyse von über 500 Shopify-Shops waren Seiten, die von Apps gerenderte Page Builder nutzen, durchweg langsamer als vergleichbare Seiten, die mit nativem Theme-Code erstellt wurden. Der Unterschied ist struktureller Natur, keine Konfigurationsfrage.
• Ein häufiger Fehler, den Shops bei Geschwindigkeitstests machen, ist das Vertrauen auf einen einzigen Lighthouse-Durchlauf. Lighthouse ist ein einzelner Seitenaufruf in einer synthetischen Umgebung; echte Nutzer besuchen deine Seite mit verschiedenen Netzwerken, Geräten und Unterseiten.
• Nutze Real-User Monitoring (RUM) im 75. Perzentil, um zu messen, was deine Kunden tatsächlich erleben. Das ist auch das, was Google für das Ranking verwendet.
• Synthetische Tests (Lighthouse, WebPageTest) eignen sich gut als relativer Vergleich zwischen Tools. Sie sind kein verlässliches Maß für deine Live-UX.

Die schnellsten Shopify Page Builder sind diejenigen, die nativen Theme-Code ausgeben, weil sie der Seite keine Builder-Runtime hinzufügen; alle von Apps gerenderten Builder kosten bei jedem Besuch Leistung durch ihre App-Runtime. In unserer Analyse von über 500 Shopify-Shops waren Seiten, die von Apps gerenderte Page Builder nutzen, durchweg langsamer als vergleichbare Seiten mit nativem Theme-Code. Ein Page Builder, der deinen Shop verlangsamt, kostet dich gleichzeitig Conversions, Ad-ROAS und SEO-Rankings. Dieser Guide erklärt, was die Verlangsamung wirklich verursacht, wie du sie ehrlich mit echten Nutzerdaten misst und enthält ein Template, das du kopieren kannst, um jedes Tool selbst zu testen.

Warum du uns vertrauen kannst

Wir haben über 15 Jahre Entwicklungserfahrung und arbeiten seit mehr als vier Jahren im Shopify-Ökosystem. Wir haben die Performance von über 500 Shopify-Shops gemessen, die Fudge und andere Tools nutzen, und haben Themes speziell neu aufgebaut, um durch Apps verlorene Geschwindigkeit zurückzugewinnen. Wir entwickeln auch Fudge, den KI-Operator für Shopify-Shops, mit einer Bewertung von 4.9 im Shopify App Store. Sein Page Builder schreibt Seiten direkt in dein Theme, anstatt eine Runtime hinzuzufügen – eine Designentscheidung, die genau durch dieses Problem motiviert 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 gerendert wird. Dieses Stylesheet muss heruntergeladen und geparst werden, bevor der Browser mit dem Rendering (Painting) beginnt. In langsamen Netzwerken trägt dies maßgeblich zu einem schlechten LCP bei.

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 der Kunde die Seite besucht, rendert der Server sie genau wie jede andere Shopify-Seite. Kein App-SDK, keine Builder-Runtime, 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 deinem Entwickler handgeschriebene Seite. Der Lighthouse-Score wird durch dein Theme, deine Bilder und deine anderen Apps begrenzt – nicht durch Fudge. Auf Wunsch kann Fudge auch einen Speed-Audit für den Rest des Shops durchführen und die Fixes in deinem Theme entwerfen, damit du sie genehmigen kannst.

Das ist der strukturelle Vorteil dieser Kategorie. Es liegt nicht daran, 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 einen einzigen Lighthouse-Audit durch und berichten den Score. Das reicht nicht. Die Zahl, die du aus einem Lighthouse-Durchlauf erhältst, ist nicht das, was deine Kunden erleben – und es ist nicht das, was Google nutzt, um deinen Shop zu ranken.

Die folgenden Techniken sind nach ihrer Nützlichkeit geordnet, um die tatsächlichen Auswirkungen der Geschwindigkeit auf UX, SEO-Traffic und Conversions zu bewerten.

1. Real-User-Daten (RUM) – was wir und Google nutzen

Der zuverlässigste Weg, die Shopify-Geschwindigkeit zu messen, sind die von echten Kunden gesammelten Daten. Genau das nutzt Google über die Core Web Vitals für seine Ranking-Systeme. RUM-Daten erfassen die störenden Faktoren, die synthetische Tests nicht abbilden können: unterschiedliche Netzwerkgeschwindigkeiten, Bildschirmgrößen, Gerätefähigkeiten, geografische Regionen und den tatsächlichen Mix an Seiten, die Kunden besuchen.

Da die Erfahrung eines einzelnen Nutzers zu fehleranfällig ist, um daraus Schlüsse zu ziehen, werden die Daten aggregiert. Wir – und auch Google – bevorzugen das 75. Perzentil (P75) jedes Core Web Vitals. Ein LCP von 4,5s beim P75 bedeutet also, dass 75 % deiner Nutzer diesen LCP oder einen besseren erleben. Das P75 ist das richtige Perzentil, weil es die Erfahrung der großen Mehrheit der Nutzer erfasst und gleichzeitig extreme Ausreißer abschwächt (ein Kunde mit einer 2G-Verbindung im Tunnel definiert nicht die UX deines Shops).

Wenn deine P75-Metrik gut ist, weißt du, dass die meisten Nutzer eine gute Erfahrung haben.

Wo du diese Daten findest:

• Dein eigenes RUM-Skript – zum Beispiel Googles web-vitals-Bibliothek, die das P75 nach Template und Gerät meldet
• Chrome User Experience Report (CrUX) – Googles öffentlicher RUM-Datensatz, der der Echtzeit um ca. 28 Tage hinterherhinkt
• Google Search Console – Core Web Vitals-Bericht, gespeist von CrUX

Wenn du heute eine Geschwindigkeitsänderung vornimmst, zeigt dein eigenes RUM-Skript dies an, sobald neuer Traffic ankommt; in CrUX und der Search Console erscheint es innerhalb von 28 Tagen.

2. Synthetisches Testing (Lighthouse, WebPageTest)

Synthetisches Testen bedeutet, eine Seite durch eine kontrollierte Umgebung laufen zu lassen, die einen Nutzer simuliert. Der Lighthouse-Audit in PageSpeed Insights ist das bekannteste Beispiel. Er ist nützlich, weicht aber immer von echten Nutzerdaten ab. Führe mal einen Lighthouse-Audit für Amazon, eBay oder Walmart durch und vergleiche das mit ihren CrUX-Zahlen – die Lücke ist riesig.

Drei Dinge, die du beim Lesen synthetischer Ergebnisse beachten solltest:

Synthetisch ist ein Seitenaufruf, RUM sind tausende. Ein einziger Lighthouse-Durchlauf kann um mehr als 30 % vom Median dreier Durchläufe abweichen. Nimm immer den Median aus mindestens drei Durchläufen, bei gleichen Netzwerkbedingungen und zur gleichen Tageszeit.

Total Blocking Time kann irreführend sein. Tools, die nicht-kritische Skripte verzögern, sodass sie nach dem Hauptinhalt geladen werden (was das richtige Muster für 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. Überprüfe das immer mit RUM, bevor du auf eine Verschlechterung der TBT reagierst.

Vorbehalte bei der LCP-Messung. Lighthouse und WebPageTest messen den Largest Paint des gesamten Ladevorgangs. Googles RUM-Messung nutzt den Largest Paint, bevor der Nutzer 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 übertreibst du das Problem.

Wenn du dich für ein synthetisches Tool entscheiden musst, ist WebPageTest der Goldstandard in der Web-Performance-Community, da du die Umgebung genau an einen P75-Nutzer anpassen kannst (Network Throttling, Device Emulation, geografischer Standort). Wir nutzen es selbst, wenn wir die Erfahrung einer Website mit und ohne Fudge vergleichen, bevor echte Nutzerdaten verfügbar sind.

3. Die richtige Reihenfolge (Order of Operations)

1. Verbinde ein RUM-Tool (die web-vitals Library, einen RUM-Dienst oder zieh die Daten aus dem CrUX)
2. Erstelle eine 28-Tage P75-Baseline über deine wichtigsten Templates und Geräteklassen hinweg
3. Mach genau eine Änderung
4. Beobachte das P75 im RUM. Nutze Lighthouse nur als relativen Vergleich zwischen Setups, niemals als die absolute Wahrheit

Wenn du noch kein RUM nutzt, fang dort an. Synthetische Vergleiche ohne RUM-Kontext sind reines Raten.

Ein Copy-Paste Speed Test Template

Nutze dies, wenn du Page Builder in einem Development Store vergleichen musst, bevor du dich festlegst. Kombiniere den synthetischen Median mit mindestens einer Woche RUM-Daten, sobald du live gehst.

So füllst du es aus:

1. Installiere eine frische Kopie von Horizon (oder Dawn) in einem Development Store. Lass Lighthouse Mobile 3× über die Startseite laufen; notiere den LCP-Median als deine Baseline.
2. 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.
3. Das Δ LCP ist deine synthetische Schätzung für die Kosten dieses Builders. Hinweis: Das ist nur ein Seitenaufruf. Bestätige dies mit RUM-Daten nach einer Woche Live-Traffic.
4. Deinstalliere den Builder vollständig – inklusive aller theme.liquid Script-Tags, die er hinterlassen hat –, bevor du den nächsten testest.
5. Nutze den Chrome DevTools → Coverage-Tab, um „JS hinzugefügt“ (ungenutzt vs. gesamt) für jeden Builder zu zählen.

Die Spalte „Nach Deinstallation bearbeitbar?“ ist der Teil, den dir kein Lighthouse-Lauf zeigen kann. Teste es: Baue eine Seite, deinstalliere die App und schau, was übrig bleibt. Nativer Theme-Code bleibt erhalten und lässt sich weiter bearbeiten; App-gerenderter Output geht kaputt oder friert ein.

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
• Gesamte Seitengröße: unter 1,5 MB (ohne Video)

Die ersten drei sind Googles Core Web Vitals-Schwellenwerte, gemessen am 75. Perzentil der Seitenaufrufe über Mobile und Desktop hinweg (web.dev, 2024); der Wert zur Seitengröße ist unsere eigene Richtlinie. Google hat bestätigt, dass Core Web Vitals von seinen Ranking-Systemen verwendet werden, und das Verfehlen dieser Werte kann dich im Vergleich zu ansonsten ähnlichen Seiten Rankings kosten.

Der einfachste Weg, diese Ziele konstant auf jeder Seite zu erreichen, die du veröffentlichst, ist die Nutzung eines Builders, der keine Runtime hinzufügt. Das bedeutet heute ein Builder, der nativen Theme-Code schreibt, statt eine App, die Seiten über ihre eigene Runtime rendert. Der Unterschied zwischen App-gerenderten und Native-Code-Buildern 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

Um unsere Befangenheit zu wiederholen: Wir haben Fudge entwickelt, das Seiten direkt in dein Theme schreibt, anstatt sie durch eine App-Runtime zu rendern. Wir haben dieses Design gewählt, weil die Geschwindigkeits-Steuer des Runtime-Modells kein behebbarer Bug ist; es ist die Architektur. App-gerenderte Tools können ihre Runtimes reduzieren, aber sie können sie nicht auf null bringen. Builder, die nativen Theme-Code ausgeben, können das.

Für die meisten Shops im Jahr 2026 – besonders für diejenigen, die mit bezahltem Traffic (Paid Traffic) arbeiten, bei dem jede 100ms LCP dich ROAS kosten – lautet die Frage nicht mehr „Welcher Page Builder ist der schnellste“, sondern „Welche Kategorie hat kein strukturelles Limit bei der Geschwindigkeit“. Das ist eine andere Entscheidung als die, um die sich die Kategorie noch vor einem Jahr drehte.

FAQ