I have audited 100+ Shopify stores in 12 years of development work. Every store paying $29 to $99 a month for PageFly, Shogun, or GemPages tells me the same thing: we need it for landing pages. In 7 of 10 audits, the math says they don’t. Here is the number none of the vendors put on their own comparison page: Shogun blocks the main thread for 320ms on every page it renders.
TL;DR: Measured by blocking time, the metric Core Web Vitals actually scores, Shogun is the heaviest builder at 320ms, then PageFly at 280ms, GemPages at 240ms, EComposer at 220ms, and Replo at 180ms. Native Liquid sections add 0ms. Payload size ranks them in a different order, which is why the vendors quote payload. Builders earn their keep above 6 landing pages a month. Below that, Liquid wins on both numbers.
Why this comparison matters for your store
- A 1-second mobile load penalty drops mobile conversion by up to 20% (Google 2017)
- Page builder pricing scales with page count or MTUs, turning a $24 trial into a $199+ bill at 25,000 monthly tracked users
- Migration off a page builder is page-by-page because content lives in the app’s database, not your theme files (vendor lock-in)
Which Shopify page builder is actually the slowest?
Shogun. It blocks the main thread for roughly 320ms on every page it renders, the heaviest of any builder I measure. If you have read the vendor comparison pages, that will surprise you, and the reason it surprises you is the interesting part.
There are two ways to measure “heavy”, and they disagree.
Payload is how much JavaScript the browser downloads. On payload, PageFly looks like the worst offender at roughly 340KB, while Shogun and GemPages look lighter at 260 to 300KB. That is the number vendors quote and the number most comparison posts repeat.
Blocking time is how long that JavaScript holds the main thread once it lands, so the page cannot respond to a tap. It is what feeds Interaction to Next Paint, one of the three Core Web Vitals Google ranks on. A small bundle doing heavy main-thread work blocks longer than a bigger bundle that defers, so payload tells you what you downloaded, not what it cost you.
On blocking time, the order flips. These come from Lighthouse third-party attribution across the stores I audit, and they are the same figures my free Shopify app detector hands back when you scan your own store.
| Page builder | Blocking time | Typical price | JS payload |
|---|---|---|---|
| Native Liquid sections | 0ms | $0 | 0KB |
| Replo | 180ms | from $49/mo | not measured |
| EComposer | 220ms | not verified | not measured |
| GemPages | 240ms | $29 to $199/mo | ~260-300KB |
| PageFly | 280ms | $24 to $99/mo | ~340KB |
| Shogun | 320ms | $39 to $499/mo | ~260-300KB |
Shogun ships less JavaScript than PageFly and still blocks the thread longer. If you chose Shogun because a comparison table called it the lighter app, you optimized for the metric Google does not score.
None of this makes Shogun a bad product. It has the best CRO tooling of the three, and I say so below. What it means is that the comparison pages leave out the number that decides your Core Web Vitals score, which is why I published the blocking figures rather than the payload ones.
What you actually choose between in 2026
There are dozens of page builder apps in the Shopify App Store. Three dominate: PageFly, Shogun, and GemPages. The fourth option, which most comparison posts skip because there is no affiliate commission on it, is native Shopify sections in Liquid with full theme editor controls.
PageFly: cheap entry, biggest JavaScript payload
PageFly has 200,000+ active installs, the biggest install base of any builder. Free plan: 1 published page. Pay-as-you-go: $24 per month for 10 slots. Unlimited: $99 per month.
Strength: template variety, lowest entry price. Weakness: it downloads the most code of the three, roughly 340KB per page, and ThunderPageSpeed tests put PageFly pages around 52 on mobile Lighthouse. Blocking time lands at 280ms: heavy, but still below Shogun.
Shogun: the best CRO tooling, the worst blocking time
Build: $39 per month for 25 pages and 2,000 MTUs. Grow: $199 per month. Advanced: $499 per month. Payload: 260 to 300KB, lighter than PageFly. Blocking time: 320ms, the heaviest of any builder I measure.
Those two facts sit together uncomfortably, and it is the blocking number your Core Web Vitals score reacts to, not the payload one.
The edge is genuine: built-in A/B testing and personalization. If you run 4+ landing page experiments a month, Shogun saves the cost of a separate CRO app. The catch: Shogun + A/B Testing Pro + Smart Pages Pro stacks to $437 per month.
GemPages: middle of the price-performance grid
Build: $29 per month for unlimited pages on 3 page types. Optimize: $59 per month. Enterprise: $199 per month. Mobile Lighthouse around 64. Payload: 260 to 300KB. Blocking time: 240ms, the lightest of the big three.
GemPages ships an AI Image-to-Layout tool that converts a mockup PNG into editable sections. Useful for design-led teams. One catch: GemPages dropped annual billing for new customers in 2025, so you pay monthly only.
Native Liquid sections: $0 forever, 0KB third-party JS
Cost: $0 per month. Cost in dev hours: 30 to 60 minutes per section. You build sections in Liquid with JSON schema settings; merchants control them from the standard theme editor.
This is the approach I ship on every client store where mobile performance matters. On the Enea Studio engagement, all 5 Core Web Vitals pass green on CrUX field data, with mobile LCP at 2.1 seconds, INP at 129ms, and CLS at 0.05. Total custom JavaScript across the entire theme: under 15KB. No page builder app can touch those numbers, because no page builder app ships zero JavaScript.
Trade-off: a marketer cannot drag-and-drop a new landing page in 20 minutes. They file a ticket for a new section, which takes a developer 30 to 60 minutes. For stores launching 2-3 new layouts a quarter, that trade-off pays off. For stores launching 2-3 a week, it does not.
Shopify page builder comparison matrix
| PageFly | Shogun | GemPages | Native Sections | |
|---|---|---|---|---|
| Price/mo | Free / $24 / $99 | $39 / $199 / $499 | Free / $29 / $59 / $199 | $0 (dev time only) |
| Blocking time | 280ms | 320ms (worst) | 240ms | 0ms |
| JS Overhead | ~340KB | ~260-300KB | ~260-300KB | 0KB |
| Mobile Lighthouse | ~52 | ~71 | ~64 | ~87 |
| Customization Ceiling | High (in app limits) | High (in app limits) | High (in app limits) | Unlimited |
| Ease of Use | Drag-drop, no code | Drag-drop, no code | Drag-drop + AI assist | Requires Liquid |
| A/B Testing | Via GA4 integration | Built-in (paid tier) | Via integrations | Manual or free tools |
| Best For | Budget-tight teams | CRO-heavy brands | Mid-market stores | Performance-first stores |
Where page builder apps actually earn their subscription cost
Apps win the math when team velocity matters more than per-page performance. Four scenarios where the spend is defensible.
Marketing teams shipping 5+ campaign pages a week
Waiting on a developer to build a Black Friday landing page, a product drop page, and three ad-specific pages in the same sprint is not realistic. Page builders ship those pages in hours, not days.
High-frequency landing page A/B testing
Shogun’s built-in tester is genuinely useful at 4-8 experiments per month. Custom Liquid + a free A/B tool works too, but at that experiment velocity you burn developer hours faster than the subscription.
Disposable seasonal pages
If you build 20 landing pages for a 3-week holiday push and then archive them, throwaway sections are hard to justify as developer work.
Pre-revenue or sub-$100K stores without developer access
A free-tier page builder is a reasonable bridge. Worry about the JS tax once you have enough traffic for it to matter.
Where page builder apps quietly bleed margin
The subscription is not the real cost. Six places where the math turns against you.
The JavaScript tax on Core Web Vitals
A 260-340KB JS payload adds 0.6 to 2.4 seconds on 4G mobile. Google ranks on CrUX field data, so real users on real devices set your search position. If page speed drops from “good” to “needs improvement,” you lose ranking signal across your full URL surface, not just the builder pages.
Vendor lock-in
Cancel PageFly and every PageFly page breaks. The content lives in their database, not your theme files. You cannot export a Shogun page as a Liquid template.
Pricing that scales with growth
PageFly bills by page slot. Shogun bills by MTU. As traffic grows, so does the bill. Native sections cost the same at 1k sessions and 1M.
Theme update fragility
Builder apps render markup on top of the theme. When Shopify updates Dawn or you switch themes, builder layouts break because the app’s CSS and DOM assumptions no longer match.
App bloat compounding
I audit stores running a reviews app + popup app + loyalty app + analytics app + page builder. Combined third-party JS routinely hits 1.2MB. You can measure that combined third-party JS on your own store instead of taking the anecdote on faith. The page builder was the single largest contributor in 8 of 14 cases I audited in 2025.
Server-side rendering gaps
PageFly and GemPages render parts of page content client-side. Googlebot sees less HTML on first crawl than a Liquid section ships, which slows indexing and risks under-indexed content on competitive queries.
The Liquid hero section in 30 minutes
A functional hero section with merchant theme editor controls takes 30 to 60 minutes to build from scratch. The pattern is <style> + HTML + schema JSON. The structure:
{% comment %} sections/custom-hero.liquid {% endcomment %}
<section class="custom-hero" style="min-height:{{ section.settings.height }}px">
{% if section.settings.image != blank %}
{{ section.settings.image | image_url: width: 1920 | image_tag:
loading: 'eager', sizes: '100vw', widths: '375, 750, 1100, 1920' }}
{% endif %}
<div class="custom-hero__content">
<h2>{{ section.settings.heading }}</h2>
<a href="{{ section.settings.cta_url }}">{{ section.settings.cta_text }}</a>
</div>
</section>
{% schema %}{ "name": "Custom Hero", "settings": [
{ "type": "image_picker", "id": "image", "label": "Background" },
{ "type": "text", "id": "heading", "label": "Heading" },
{ "type": "text", "id": "cta_text", "label": "CTA text" },
{ "type": "url", "id": "cta_url", "label": "CTA URL" }
], "presets": [{ "name": "Custom Hero" }] }{% endschema %}
That section ships zero JavaScript, weighs under 2KB, and gives merchants 4 theme editor controls. For accordions, testimonial carousels, comparison tables, and countdown timers, see custom Liquid section examples for the full copy-paste set.
Compare what PageFly or Shogun ship for the same hero: 260 to 340KB of JS runtime, plus a CSS framework, plus their rendering layer. For a heading, a button, and an image.
How to decide: 3 variables that settle it
The right pick depends on developer access, page launch cadence, and how much your revenue depends on mobile traffic.
Build native Liquid sections if you have a developer on staff or retainer, you ship fewer than 4-6 new layouts a month, and mobile speed drives revenue. Upfront cost is higher; ongoing cost is zero.
Use a page builder app if you have no developer, your marketing team ships landing pages independently, and you publish 6+ layouts a month. Pick Shogun for built-in CRO testing, GemPages for the best price-feature balance, or PageFly when budget is the only constraint.
Audit your current builder if you are unsure. Run Lighthouse on a builder page and a native page on the same store. If the builder page scores 15+ points lower on mobile, calculate whether the convenience is worth the ranking and CVR cost. The data settles the debate.
How to verify the impact on your store in 5 minutes
Three checks. Do them today before you renew or cancel anything.
- Lighthouse delta. Open PageSpeed Insights. Run a builder page (e.g.
/pages/landing-bf) and a native page (e.g./). Note the mobile score gap. - CrUX field data. Open Search Console > Core Web Vitals report. Filter URLs by the builder slug pattern. Compare LCP/INP/CLS to your site median.
- Conversion rate split. GA4 > Reports > Engagement > Pages and screens. Compare CVR on builder pages vs native template pages. A 2-percentage-point gap on your top 20 landing pages is the real builder bill.
If the builder pages score 15+ Lighthouse points lower AND show worse CrUX AND show measurably lower CVR, the subscription costs more than its price tag.
Migration path: weaning off a page builder app
Six steps. I have run this with clients across PDP rebuilds and full landing page migrations.
1. Inventory. List every page the app controls. Categorize: hero sections, landing pages, PDP customizations, collection layouts, blog templates. Count them.
2. Sort by traffic. Pull GA4 or Shopify Analytics. Migrate highest-traffic pages first because they carry the most JS penalty.
3. Build native replacements. For each page type, build a Liquid section that replicates the layout. Match content structure and merchant controls, not pixels.
4. Template suffix routing. Shopify lets you create page.native.liquid. Assign pages to the new template one at a time from admin. Both versions live simultaneously while you cut over.
5. Verify per page. Lighthouse + mobile/tablet/desktop QA + theme editor control test. Keep the app disabled (not uninstalled) for 2 weeks as a safety net.
6. Clean up leftovers. Builder apps leave snippet files, asset files, and config/settings_data.json entries. Grep snippets/ for pagefly-, shogun-, gempages- prefixes. Remove all of them so dead code stops loading on every request.
On a recent product configurator rebuild, this migration pattern delivered a 40-point Lighthouse improvement on the affected pages over two weeks.
What this costs your bottom line
The real cost is not the subscription. It is the compounding performance penalty on every page the app touches.
A 300KB JS payload that adds 1.5 seconds to mobile load on your top 20 landing pages affects every visitor to those pages. At $49/month over 12 months, the app costs $588. Google research puts each added second of mobile load at up to a 20% conversion drop. On a $1M store with 30% of sessions touching builder pages, a 5% conversion drop on those pages costs $15,000 per year. The subscription is rounding error. To add up what your app stack actually costs against that, total your monthly and annual spend before the renew call.
That does not mean every store should rip out its page builder tomorrow. It means the renew decision deserves more analysis than “which one has the nicest drag-and-drop editor.”
Audit one high-traffic builder page this week. Build a native Liquid replacement. Deploy it with template suffix routing. Run both for 14 days. Let the Lighthouse, CrUX, and CVR data settle the call.
The takeaway
- Judge builders on blocking time, not payload. Shogun ships less code than PageFly and still blocks the thread longest, at 320ms.
- Scan your own store with a free app detector before you renew; the builder is usually the single heaviest app on the page.
- Default to native Liquid below 6 new layouts a month, a builder above it. That cadence is the real deciding variable.
- If you stay on a builder, pick Shogun for CRO testing, GemPages for the lightest blocking time of the big three, PageFly for budget.
- Never uninstall a builder before migrating every page off it. The content lives in the app’s database, not your theme.