Key takeaways
- Across 500+ Shopify stores we have analysed, sites using drag-and-drop page builders were 22–37% slower than equivalent sites using native-theme-code builders. The gap is structural, not configuration.
- The single biggest mistake stores make when testing speed is trusting a single Lighthouse run. Lighthouse is one page load in a synthetic environment; real users hit your site with different networks, devices, and pages.
- Use real-user monitoring (RUM) at the 75th percentile to measure what customers actually feel. That is also what Google uses for ranking.
- Synthetic testing (Lighthouse, WebPageTest) is fine as a relative comparison between tools. It is not a reliable measure of your live UX.
The fastest Shopify page builders are the ones that output native theme code, because they add no runtime JavaScript to the page; drag-and-drop builders all carry a measurable speed tax from their per-visit app runtime — 22–37% on average across the 500+ Shopify stores we have analysed. A page builder that slows your store down costs you conversions, ad ROAS, and SEO rankings simultaneously. This guide explains what actually causes the slowdown, how to measure it honestly with real-user data, and a template you can copy-paste to test each tool yourself.
Why you can trust us
Over 15 years of dev experience and four years inside the Shopify ecosystem. We have measured performance across 500+ Shopify stores running Fudge and other tools, and have rebuilt themes specifically to recover speed lost to apps. We also build Fudge, which writes pages directly into your theme rather than adding a runtime — a design choice driven by exactly this issue.
What actually slows a Shopify store when you install a page builder
There are four contributors. They compound.
1. The builder’s runtime JavaScript
Most drag-and-drop builders inject a JavaScript bundle on every visit to a page they render. That bundle handles layout hydration, lazy-loaded blocks, animations, and the editor preview link. It runs even when the customer is just browsing.
The weight varies. Some tools have pared their runtime down. Others ship 200KB+ of JavaScript that the customer parses before the page is interactive. The difference shows up in Total Blocking Time and Largest Contentful Paint.
2. Render-blocking CSS injected into the head
Page builders frequently inject a stylesheet into the document head before the page renders. That stylesheet has to download and parse before the browser starts painting. On slow networks this is the single biggest contributor to a slow LCP.
3. Large hero images served without modern formats
Not the builder’s fault per se — but page-builder templates often default to oversized hero images. The customer downloads a 1.5MB hero on a mobile connection. Fix this by using WebP/AVIF, correct sizes, and proper loading attributes.
4. Stacked apps each adding their own footprint
A page-builder app + a reviews app + a chat widget + an upsell app adds up to 1-2MB of JavaScript before the page does anything useful. The page builder is rarely the only culprit, but it’s usually one of the heaviest. Audit everything.
What “no runtime” means in practice
A page builder that outputs native theme code writes Liquid + CSS + HTML into your theme files and adds nothing else. When the customer visits, the server renders the page exactly like any other Shopify page. No app SDK, no extra JavaScript, no runtime layout.
Fudge works this way: you describe the page, Fudge writes it into your theme, and the published page has the same JavaScript footprint as a page your developer hand-coded. The Lighthouse score is bounded by your theme, your images, and your other apps — not by Fudge.
This is the structural advantage of the category. It’s not that AI builders are inherently faster; it’s that builders writing native code don’t add a runtime to slow them down.
How to measure Shopify speed honestly
Most “speed test” articles run a single Lighthouse audit and call the result. That is wrong. The number you get from one Lighthouse run is not what your customers experience — and it is not what Google uses to rank your store.
The techniques below are listed in order of usefulness for actually assessing speed’s impact on UX, SEO traffic, and conversions.
1. Real-user data (RUM) — what we and Google use
The most reliable way to measure Shopify speed is the data collected from real customers. This is what Google uses in its ranking systems via Core Web Vitals. RUM data captures the confounding factors that synthetic tests cannot: different network speeds, screen sizes, device capabilities, geographic regions, and the actual mix of pages customers visit.
Because a single user’s experience is too noisy to draw conclusions from, you aggregate. We — and Google — prefer the 75th percentile (P75) of every Core Web Vital. So an LCP of 4.5s at P75 means 75% of your users experience that LCP or better. P75 is the right percentile because it captures the experience of the vast majority of users while mitigating extreme outliers (a customer on a 2G connection in a tunnel doesn’t define your store’s UX).
If your P75 metric is good, you know most users have a good experience. On Shopify stores running Fudge, P75 Core Web Vitals pass for over 80% of users.
Where to find this data:
- Fudge dashboards — real-time P75 metrics across 100% of page loads, broken down by template and device
- Chrome User Experience Report (CrUX) — Google’s public RUM dataset, lags real-time by ~28 days
- Google Search Console — Core Web Vitals report, fed from CrUX
If you make a speed change today, you’ll see it in your Fudge dashboard immediately; it appears in CrUX and Search Console within 28 days.
2. Synthetic testing (Lighthouse, WebPageTest)
Synthetic testing means running a page through a controlled environment that simulates a user. The Lighthouse audit in PageSpeed Insights is the most common example. It is useful, but always differs from real-user data. Run a Lighthouse audit on Amazon, eBay, or Walmart and compare to their CrUX numbers — the gap is large.
Three things to remember when reading synthetic results:
Synthetic is one page load, RUM is thousands. A single Lighthouse run can be 30%+ off the median of three runs. Always take the median of at least three runs, on the same network conditions, on the same time of day.
Total Blocking Time can mislead. Tools that defer non-critical scripts to load after the main content (which is the right pattern for UX) often score a higher TBT in Lighthouse than tools that block on those scripts. The Lighthouse number can go up while the actual UX improves. Cross-check with RUM before reacting to a TBT regression.
LCP measurement caveats. Lighthouse and WebPageTest measure the largest paint of the entire page load. Google’s RUM measurement uses the largest paint before the user interacts with the page. On a product page, that often means the product image — but WebPageTest will sometimes measure how long it takes for an exit-intent popup to render. Configure your synthetic tool to stop measuring at first interaction, or you will overstate the problem.
When forced to choose a synthetic tool, WebPageTest is the gold standard in the web-performance community because it lets you finely tune the environment to match a P75 user (network throttling, device emulation, geographic location). We use it ourselves when comparing the experience of a site with and without Fudge before real-user data is available.
3. The order of operations
- Connect a RUM tool (Fudge dashboard, web-vitals library, or pull from CrUX)
- Establish a 28-day P75 baseline across your top templates and device classes
- Make one change
- Watch P75 in RUM. Use Lighthouse only for relative comparison between configurations, never as the source of truth
If you don’t have RUM yet, start there. Synthetic comparisons without RUM context are guesses.
A copy-paste speed test template
Use this when you need to compare page builders on a development store before committing. Pair the synthetic median with at least a week of RUM data once you go live.
| Builder | Baseline LCP | Builder Page LCP | Δ LCP | INP | CLS | JS Added | Survives Uninstall? | Notes |
|---|---|---|---|---|---|---|---|---|
| Fudge | Yes | Native theme code; no runtime | ||||||
| PageFly | No | App-rendered runtime | ||||||
| GemPages | No | App-rendered runtime | ||||||
| Shogun | No | App-rendered runtime | ||||||
| Replo | No | App-rendered runtime |
How to fill it in:
- Install a fresh Shopify Dawn theme on a development store. Run Lighthouse Mobile 3× on the homepage; record the median LCP as your baseline.
- Install one builder. Publish a representative page (hero, three image+text blocks, testimonial slider, FAQ, CTA). Run Lighthouse Mobile 3×; record the median.
- The Δ LCP is your synthetic estimate of that builder’s cost. Note: this is one page load. Confirm with RUM after a week of live traffic.
- Uninstall the builder fully — including any theme.liquid script tags it left behind — before testing the next.
- Use Chrome DevTools → Coverage tab to count “JS Added” (unused vs total) for each builder.
The “Survives Uninstall” column is the bit no Lighthouse run can show you. Test it: build a page, uninstall the app, see what’s left. Native-theme-code output stays; app-rendered output reverts to a placeholder.
What “good” looks like
Target numbers for a Shopify page on mobile, measured at P75:
- LCP (Largest Contentful Paint): under 2.5s
- INP (Interaction to Next Paint): under 200ms
- CLS (Cumulative Layout Shift): under 0.1
- Total page weight: under 1.5MB (excluding video)
These aren’t aspirational — they are Google’s Core Web Vitals thresholds, measured at the 75th percentile of page loads across mobile and desktop (web.dev, 2024). Google has confirmed Core Web Vitals are used by its ranking systems — a page that misses them isn’t competitive in search.
The easiest way to hit them consistently across every page you publish is to use a builder that adds no runtime — which today means an AI builder that writes native theme code rather than a drag-and-drop app rendering pages through its own runtime. The 22–37% gap we see between drag-and-drop and native-code builders across 500+ Shopify stores isn’t a configuration problem; it’s the architecture.
Categories that have a structural disadvantage on speed
Without naming specific tools:
- App-rendered pages with iframe embeds. The iframe alone costs you LCP and complicates CLS.
- Builders that inject a global stylesheet sitewide, not just on builder-rendered pages. Every page in the store pays the cost, even the ones the builder didn’t touch.
- Builders with heavy animation runtimes. Smooth scroll, parallax, and entrance animations cost INP.
- Builders that lazy-load layout (not just images). Layout that depends on JavaScript before paint hurts LCP and CLS together.
Tools that ship lean runtimes can still be acceptable — the cost is real but bounded. Tools that ship heavy runtimes plus heavy templates plus iframes compound the cost.
For the wider comparison, see our best Shopify page builders ranking and our what is a Shopify page builder explainer.
A short note on hosting and CDN
Shopify hosts every store on its own CDN with edge caching built in. Page-builder slowness is rarely a hosting problem — it’s almost always a payload problem. Improving images, removing unused JavaScript, and consolidating apps fixes more than any hosting change.
Where the category is going
Acknowledging the bias up front — we built Fudge, which writes pages directly into your theme rather than rendering them through an app runtime. We chose that design because the speed tax of the runtime model isn’t a fixable bug; it’s the architecture. Drag-and-drop tools can pare their runtimes down, but they can’t ship zero. AI builders that output native theme code can.
For most stores in 2026 — especially those running paid traffic where every 100ms of LCP costs ROAS — the question stops being “which page builder is fastest” and starts being “which category has no structural ceiling on speed.” That’s a different choice than the one the category was framed around a year ago.
FAQ
Which Shopify page builder is the fastest?
The fastest are the ones that output native theme code with no runtime, because their pages render with no app-imposed overhead. Across 500+ Shopify stores we have analysed, sites using drag-and-drop builders averaged 22–37% slower than sites using native-theme-code builders. Verify with your own RUM data once you go live; Lighthouse alone is not enough.
Should I trust a single Lighthouse run?
No. Lighthouse is one page load in a controlled environment; real users hit your site under thousands of different conditions. Use the median of three Lighthouse runs as a relative comparison between configurations, then validate with at least a week of real-user data at the 75th percentile.
What is RUM and why does it matter?
Real User Monitoring is data collected from your actual customers’ browsers, aggregated to the 75th percentile. It is what Google uses for ranking via Core Web Vitals. Synthetic tools (Lighthouse, WebPageTest) approximate what one user might experience; RUM tells you what most customers actually feel.
Will a page builder hurt my Shopify SEO?
It can, if it adds enough JavaScript to push your P75 LCP and INP outside Core Web Vitals thresholds. Pages that fail Core Web Vitals are competitively disadvantaged in search. Test on mobile RUM, not desktop Lighthouse.
Does Shopify’s built-in CDN make page-builder speed irrelevant?
No. The CDN delivers files fast, but the customer’s browser still has to parse and execute every JavaScript bundle the builder loads. Heavy runtime = slow page, no matter how fast the CDN is.
How do I test a page builder without installing it on my live store?
Use a development store. Install Shopify Theme Dawn, install the builder, publish a representative page, run Lighthouse 3× on mobile, take the median. Uninstall before testing the next. Once a builder is on your live store for a week, the RUM data is the source of truth — synthetic was just the screening pass.
Should I uninstall page-builder apps I’m not using to recover speed?
Yes — and check the theme for leftover snippets after uninstalling. Some builders leave script tags or CSS imports in theme.liquid even after the app is gone. Search your theme for the builder’s domain or asset names.
