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. The three apps inject 260 to 340KB of JavaScript into every page they render, drop mobile Lighthouse by 16 to 35 points, and lock your content inside the app’s data layer.
TL;DR: PageFly, Shogun, and GemPages add 260 to 340KB of JavaScript to every page they touch, costing 0.6 to 2.4 seconds of mobile load time. They earn their cost when your marketing team ships 6+ landing pages a month without developer help. Below that, native Liquid sections cost $0 forever and score 30+ Lighthouse points higher.
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)
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, heaviest performance tax
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: performance. ThunderPageSpeed tests put PageFly pages around 52 on mobile Lighthouse, a 35-point drop from native. JavaScript overhead: roughly 340KB per page.
Shogun: premium, with built-in CRO testing
Build: $39 per month for 25 pages and 2,000 MTUs. Grow: $199 per month. Advanced: $499 per month. Mobile Lighthouse lands around 71, the best of the three apps but still 16 points below native. JS overhead: 260 to 300KB.
The edge is 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. JS overhead: 260 to 300KB.
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) |
| 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. 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.
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
- Run Lighthouse on a builder page and a native page on the same store; record the gap
- Pull CrUX field data in Search Console for builder URLs vs site median
- Default to native Liquid below 6 new layouts a month, builder above
- If you stay on a builder, pick Shogun for CRO testing, GemPages for design tools, PageFly for budget
- Never uninstall a builder app before migrating every page off it; content lives in the app’s database, not your theme