Shopify Page Builder Speed Test: Methodik & RUM Best Practices

Wichtigste Erkenntnisse

• Bei über 500 analysierten Shopify-Stores waren Seiten, die Drag-and-Drop Page Builder nutzen, 22–37 % langsamer als vergleichbare Seiten mit nativen Theme-Code-Buildern. Der Unterschied ist strukturell bedingt, nicht konfigurationsbedingt.
• Der größte Fehler, den Stores beim Speed-Testing machen, ist, sich auf einen einzigen Lighthouse-Durchlauf zu verlassen. Lighthouse misst einen einzelnen Page-Load in einer synthetischen Umgebung; echte User besuchen deine Seite über verschiedene Netzwerke, Geräte und Seiten.
• Nutze Real-User Monitoring (RUM) auf dem 75. Perzentil, um zu messen, was deine Kunden tatsächlich erleben. Das ist auch der Wert, den Google fürs Ranking nutzt.
• Synthetisches Testing (Lighthouse, WebPageTest) ist für einen 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. Alle Drag-and-Drop Builder bringen eine messbare Geschwindigkeitsbremse 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 Store verlangsamt, kostet dich gleichzeitig Conversions, Ad-ROAS und SEO-Rankings. Dieser Guide erklärt, was die Verlangsamung wirklich verursacht, wie du sie fair anhand echter User-Daten messen kannst, und enthält ein Template, das du per Copy-Paste nutzen kannst, um jedes Tool selbst zu testen.

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)

1. Verknüpfe ein RUM-Tool (Fudge-Dashboard, web-vitals Library oder Daten aus CrUX abrufen)
2. Erstelle eine 28-tägige P75-Baseline über deine wichtigsten Templates und Geräteklassen hinweg
3. Nimm eine Änderung vor
4. 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.

So füllst du es aus:

1. 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.
2. 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.
3. 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.
4. Deinstalliere den Builder vollständig – einschließlich aller theme.liquid Script-Tags, die er hinterlassen hat –, bevor du den nächsten testest.
5. 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

Welcher Shopify Page Builder ist der schnellste?

Die schnellsten sind diejenigen, die nativen Theme-Code ohne Runtime ausgeben, da ihre Seiten ohne App-bedingten Overhead gerendert werden. Bei über 500 analysierten Shopify-Stores waren Websites mit Drag-and-Drop Buildern im Durchschnitt 22–37 % langsamer als Websites mit Native-Theme-Code Buildern. Überprüfe dies mit deinen eigenen RUM-Daten, sobald du live gehst; Lighthouse allein reicht nicht aus.

Sollte ich einem einzigen Lighthouse-Durchlauf vertrauen?

Nein. Lighthouse ist ein einziger Page-Load in einer kontrollierten Umgebung; echte User rufen deine Seite unter tausenden verschiedenen Bedingungen auf. Nutze den Median von drei Lighthouse-Durchläufen als relativen Vergleich zwischen Konfigurationen und validiere ihn dann mit mindestens einer Woche Real-User-Daten im 75. Perzentil.

Was ist RUM und warum ist es wichtig?

Real User Monitoring (RUM) sind Daten, die von den Browsern deiner tatsächlichen Kunden gesammelt und auf das 75. Perzentil aggregiert werden. Genau diese Daten nutzt Google für das Ranking über die Core Web Vitals. Synthetische Tools (Lighthouse, WebPageTest) schätzen ab, was ein User theoretisch erleben könnte; RUM sagt dir, was die meisten Kunden tatsächlich erleben.

Schadet ein Page Builder meiner Shopify-SEO?

Das kann er, wenn er so viel JavaScript hinzufügt, dass dein P75-LCP und -INP außerhalb der Core Web Vitals-Grenzwerte liegen. Seiten, die die Core Web Vitals nicht erfüllen, sind in der Suche wettbewerblich benachteiligt. Teste Mobile RUM, nicht Desktop Lighthouse.

Macht das in Shopify integrierte CDN die Geschwindigkeit von Page Buildern irrelevant?

Nein. Das CDN liefert Dateien zwar schnell aus, aber der Browser des Kunden muss dennoch jedes serverseitig geladene JavaScript-Bundle des Builders parsen und ausführen. Eine dicke Runtime = langsame Seite, egal wie schnell das CDN ist.

Wie teste ich einen Page Builder, ohne ihn in meinem Live-Store zu installieren?

Nutze einen Development-Store. Installiere das Shopify Theme Dawn, installiere den Builder, veröffentliche eine repräsentative Seite, lasse Lighthouse dreimal auf Mobile laufen und nimm den Median. Deinstalliere ihn, bevor du den nächsten testest. Sobald ein Builder eine Woche lang in deinem Live-Store aktiv ist, sind die RUM-Daten die absolute Wahrheit (Source of Truth) – der synthetische Test war nur der erste Filter.

Sollte ich Page Builder-Apps, die ich nicht verwende, deinstallieren, um Speed zurückzugewinnen?

Ja – und überprüfe dein Theme nach der Deinstallation auf übrig gebliebene Code-Snippets. Einige Builder hinterlassen sogar nach dem Entfernen der App noch Script-Tags oder CSS-Importe in der theme.liquid. Durchsuche dein Theme nach der Domain des Builders oder den Namen der Assets.