If your Shopify store feels slower after you started using a page builder, you’re not imagining it. Most visual page builders don’t generate plain theme code — they render pages through a runtime, which means shipping JavaScript to the browser on every page that builder touches, whether the shopper’s device needs it or not. This post walks through why that happens, what it typically costs in Lighthouse score and conversion, how to measure it on your own store, and what migrating away from a runtime builder actually looks like.
Runtime rendering vs native Liquid, explained simply
Shopify’s Online Store 2.0 architecture is built around Liquid sections — reusable blocks of server-rendered template code that Shopify compiles into the HTML your theme serves directly. When a page is built this way, the browser gets HTML and CSS from Shopify’s own servers, styled by your theme, with no additional framework required to assemble the layout.
Many popular page builders take a different approach. Instead of writing directly into the theme’s Liquid files, they render the page through their own JavaScript runtime: a script loads in the browser, fetches or interprets the page’s layout data, and assembles the DOM client-side (or through an iframe). This is what makes their visual, drag-and-drop editors possible — the runtime is doing real work to let you build pages without touching code. The tradeoff is that the same runtime has to run again every time a shopper loads the page, adding a JavaScript payload and execution cost that a native Liquid page simply doesn’t have.
Neither approach is “wrong” in isolation — it’s an architectural choice with a real, measurable tradeoff. The question for a merchant is whether the design flexibility a runtime provides is worth the speed it costs on every single page load, for every single visitor, indefinitely.
What this looks like in practice (typical observed ranges)
We tested builds across several runtime-based builders and compared the JavaScript payload added specifically by the builder, isolated from the merchant’s own theme and apps. These are typical ranges we and other builders in the space have observed across different page complexities — not a controlled, peer-reviewed study, and not a claim that every merchant’s build will land in this exact range. Your results will vary with theme, page complexity, and app stack.
| Builder category | Typical added JS (illustrative range) |
|---|---|
| Heavier template-library builders (e.g., PageFly-style) | ~250–350KB |
| Visual drag-and-drop builders (e.g., GemPages-style) | ~200–280KB |
| Testing/funnel-focused builders (e.g., Shogun-style) | ~150–220KB |
| Native Liquid output (Ecomato) | 0KB added by the app |
The pattern that holds across every runtime builder we’ve looked at: the more visual flexibility and template complexity a tool offers, the more JavaScript it tends to ship to render that flexibility in the browser. Native Liquid sidesteps the tradeoff entirely because there’s no runtime to ship — the page is just theme code, the same as any section your theme already includes.
How this shows up in Lighthouse
Extra JavaScript affects two Lighthouse metrics directly: Total Blocking Time (TBT), because the browser has to parse and execute the runtime before the page is interactive, and Largest Contentful Paint (LCP), because content that depends on client-side rendering typically paints later than server-rendered HTML. On mobile devices with slower processors and throttled connections — which is where Lighthouse tests are weighted, and where a large share of Shopify traffic actually comes from — this effect compounds.
In our own testing and in patterns merchants have reported to us, it’s common to see a store’s Lighthouse performance score fall from the 70s or 80s into the 50s after migrating key landing or product pages into a heavier runtime builder, particularly on mobile. That’s a meaningful drop, not a rounding error — Google’s own Core Web Vitals guidance treats scores below 50 as “poor,” and poor Core Web Vitals correlate with both worse organic visibility and higher bounce rates. Again: treat this as a typical pattern to watch for on your own store, not a guaranteed outcome.
Why a 100–300ms delay actually matters for conversion
It’s easy to dismiss “a few hundred milliseconds” as imperceptible, but page speed research from across the industry has consistently linked load time to conversion rate, and mobile commerce is especially sensitive to it — shoppers on mobile networks are more likely to abandon a slow-loading page before it even finishes rendering. If a runtime builder adds meaningful TBT to your highest-traffic product or landing pages — exactly the pages a builder is usually used for — the pages you’re relying on to convert are the ones taking the speed hit.
This is the part that’s easy to miss when you’re mid-build in a visual editor: the builder makes the page easier to create, but every visitor who lands on that page pays the runtime cost, every single time, for as long as the page exists.
What “native Liquid” means for your store
When Ecomato publishes a page, it uploads Online Store 2.0 Liquid sections directly into your selected theme and assigns them to a template through Shopify’s native section architecture — the same mechanism your theme uses for any other section. There’s no iframe, no separate rendering runtime, and no storefront JavaScript shipped by Ecomato at all. Your storefront serves the page the same way it serves every other page in your theme, which means:
- No added JS tax. The page isn’t slower because it was built with a page builder.
- No dependency on the app staying installed. Because the page is theme code, not a rendered runtime output, it isn’t tied to an active Ecomato subscription.
- Consistent behavior with your existing apps and theme. There’s no separate runtime competing for the browser’s attention alongside your other scripts.
How to measure builder JS on your own store
You don’t need to take any comparison post’s word for it — you can check your own store in a few minutes:
- Open Chrome DevTools on a live product or landing page built with your current page builder.
- Go to the Network tab, filter by JS, and reload the page.
- Look for scripts loaded from the builder’s own domain (not Shopify’s core assets or your theme’s own JS) — this is the runtime weight the builder is adding.
- Run the same page through Lighthouse (in DevTools, under the Lighthouse tab) in mobile mode, and note the TBT and LCP figures specifically.
- Compare against a plain theme page that wasn’t built with any page builder, to isolate the builder’s actual contribution versus your baseline theme performance.
This gives you a real, store-specific number instead of relying on any industry-wide average — including the ranges cited earlier in this post.
Migration checklist: moving from a runtime builder to native Liquid
If you’re moving key pages off a runtime builder, a clean migration looks like this:
- Audit which pages actually use the builder. Not every page needs to move on day one — start with your highest-traffic product and landing pages.
- Export or document existing copy and images from the current builder before you touch anything.
- Preview the equivalent layout in a native-Liquid tool against your existing theme before publishing anything live.
- Publish to a staging or unpublished page first and compare Lighthouse scores directly against the old builder version.
- Redirect or replace the old page once you’ve confirmed the new version matches on content and improves on speed.
- Re-run Lighthouse after publish to confirm the improvement actually landed in production, not just in preview.
- Uninstall the old builder app only after every page depending on it has been migrated — uninstalling first on a runtime-based builder can break pages still relying on it.
Ecomato previews are unlimited and free on the Spark plan, so you can build and check the Lighthouse difference on a real page before committing to a migration — see pricing or browse templates to start a preview.
FAQ
Does every Shopify page builder slow down my store? Builders that render through a JavaScript runtime or iframe add some weight to every page they build — the exact amount varies by tool and page complexity. Builders that publish native Liquid, like Ecomato, don’t add storefront JavaScript because there’s no runtime to ship.
How much does page speed actually affect Shopify conversion rate? Industry data consistently shows slower load times correlate with higher bounce and lower conversion, especially on mobile. The exact impact varies by store, audience, and traffic source, but the direction of the effect is consistent enough that it’s worth measuring on your own store rather than assuming it doesn’t apply to you.
Can I check my own store’s builder JS without any special tools? Yes — Chrome DevTools’ Network and Lighthouse tabs (built into every Chrome browser) are enough to isolate a builder’s JavaScript weight and see its effect on your Lighthouse score.
Will migrating to native Liquid pages hurt my SEO in the short term? If you migrate correctly — keeping the same URL, matching content, and confirming the new page renders properly before removing the old one — there’s no inherent SEO penalty. A faster page is more likely to help Core Web Vitals–related ranking signals than hurt them.
Do I have to migrate my whole catalog at once? No. Most merchants migrate high-traffic pages first — top product pages and paid-traffic landing pages — where the speed and conversion impact is largest, then move the rest of the catalog over time.
Bottom line
Page builder speed isn’t a theoretical concern — it’s measurable on your own store in about five minutes with tools you already have. If a runtime builder is adding a meaningful JavaScript tax to your highest-traffic pages, that’s a cost your visitors pay on every single load. Compare the architecture directly in Ecomato vs PageFly, see the full breakdown of features, or run your own Lighthouse test before and after a preview build on Spark, free.