Why Custom Liquid Code Beats Every Shopify Page Builder

Every Shopify developer has had this conversation. A client wants custom landing pages, so they install Pagefly or Gempages. Drag, drop, done. It looks great in the editor. Then you run PageSpeed Insights and the mobile score is 28. The builder injected 400KB of JavaScript, six render-blocking CSS files, and a widget loader that fires on every page even when no builder content is present. This is not a bug. It is the architectural reality of every visual page builder. Custom Liquid does not have this problem.

What Page Builders Actually Load

To understand why page builders are slow, you need to understand what they actually load. A visual builder is essentially a rendering engine. It takes a JSON structure stored in metafields or a custom database, interprets it at runtime, and builds the DOM in the browser. This runtime rendering requires a substantial JavaScript payload on every page that uses the builder, and often on pages that do not.

• ◆Pagefly: 380–520KB of JavaScript on every page it renders (uncompressed)
• ◆Gempages: similar payload, plus additional CSS framework overhead
• ◆GemPages and Pagefly both load their asset bundles site-wide by default, not just on pages where they're used
• ◆Builder-generated HTML is often deeply nested and not semantic — bad for accessibility and Core Web Vitals CLS scores
• ◆Inline styles injected by builders override your theme's styles and can't be purged by CSS tree-shaking

Real comparison — same landing page content, two approaches:

Page Builder (Pagefly) build:
  Total JS:          487KB
  Total CSS:         210KB
  Requests:          38
  LCP (mobile):      5.8s
  PageSpeed mobile:  31

Custom Liquid section:
  Total JS:          0KB (no JS needed for this page)
  Total CSS:         12KB (scoped to section)
  Requests:          9
  LCP (mobile):      1.6s
  PageSpeed mobile:  94

Why Liquid Wins on Performance

Liquid is a server-side templating language. When Shopify renders a Liquid template, the work happens on the server and the result is plain HTML sent to the browser. There is no runtime rendering engine, no JavaScript framework bootstrapping, and no JSON-to-DOM interpretation happening in the user's browser. The HTML arrives ready to paint. For performance, it does not get better than this.

{%- comment -%}
  A custom hero section in Liquid.
  Zero JS. No builder overhead.
  Outputs clean, semantic HTML — ready to paint on first byte.
{%- endcomment -%}

<section class="hero" style="background-color: {{ section.settings.bg_color }}">
  <div class="hero__content">
    <h1 class="hero__heading">{{ section.settings.heading }}</h1>
    <p class="hero__subtext">{{ section.settings.subtext }}</p>
    <a href="{{ section.settings.button_url }}" class="hero__cta">
      {{ section.settings.button_label }}
    </a>
  </div>
  <div class="hero__image">
    <img
      src="{{ section.settings.image | image_url: width: 1200 }}"
      srcset="
        {{ section.settings.image | image_url: width: 600 }} 600w,
        {{ section.settings.image | image_url: width: 1200 }} 1200w
      "
      sizes="(min-width: 768px) 50vw, 100vw"
      width="{{ section.settings.image.width }}"
      height="{{ section.settings.image.height }}"
      fetchpriority="high"
      alt="{{ section.settings.image.alt | escape }}"
    >
  </div>
</section>

The 'But Clients Can't Edit It' Objection

The reason clients reach for page builders is control. They want to change headings, swap images, adjust colors without calling a developer. That is a completely valid need, but it is solved by Shopify's native section schema system, not by a third-party builder. A properly built custom section exposes every editable element through the Theme Customizer. Clients get a point-and-click editor with exactly the controls they need and nothing they do not. No coding required.

{% schema %}
{
  "name": "Hero Banner",
  "settings": [
    { "type": "text",         "id": "heading",      "label": "Heading",         "default": "Welcome" },
    { "type": "textarea",     "id": "subtext",      "label": "Subtext"                               },
    { "type": "image_picker", "id": "image",        "label": "Background Image"                      },
    { "type": "color",        "id": "bg_color",     "label": "Background Color", "default": "#ffffff" },
    { "type": "text",         "id": "button_label", "label": "Button Text",      "default": "Shop Now"},
    { "type": "url",          "id": "button_url",   "label": "Button Link"                           }
  ],
  "presets": [{ "name": "Hero Banner" }]
}
{% endschema %}

That schema gives the client a full editing UI in the Theme Customizer: text fields, an image picker, a color picker, a URL field. No builder subscription, no runtime JavaScript, and no performance cost. The same approach works for testimonials, FAQs, feature grids, countdown timers, and virtually any layout you would build in a page builder.

The Hidden Costs of Page Builders

• ◆Monthly subscription — Pagefly charges $24–$99/month, Gempages $29–$99/month, on top of Shopify's own fees
• ◆Vendor lock-in — pages built in a builder are tied to that builder. Uninstall it and your pages break
• ◆Update conflicts — builder updates can break existing pages, requiring reactive fixes rather than scheduled maintenance
• ◆Limited customization ceiling — when the client needs something the builder doesn't support, you're stuck adding hacky overrides on top of an already heavy stack
• ◆SEO impact — slow pages rank lower. A 30-point PageSpeed drop on a product landing page has measurable conversion and ranking consequences

When Page Builders Are Acceptable

There are legitimate cases for page builders. If a non-technical merchant needs to build and publish unique landing pages weekly without developer involvement, a builder may be the right call. If the store's traffic is low enough that a PageSpeed drop does not meaningfully affect conversions or ranking, the convenience may outweigh the cost. And if the project budget does not allow for the time to build custom sections, a builder is better than nothing.

What I Deliver Instead

On every Shopify project I take on, I build a library of custom sections tailored to what the client actually needs. A hero, a feature grid, a testimonials block, a product highlight, a FAQ accordion. Each one is a clean Liquid file with a schema that exposes the right settings. The client edits everything through the native Theme Customizer. No subscription, no vendor lock-in, no runtime overhead. This is what professional Shopify development looks like. Not because page builders are wrong in principle, but because performance is a business outcome, not a nice-to-have.