- Core Web Vitals, LCP, Performance Shopify, Sviluppo Liquid
- Francesco Guiducci
Page Builder or Liquid on Shopify? Performance and Maintenance
Direct answer: a page builder does not automatically slow Shopify down, and Liquid does not automatically make a store fast. The right choice depends on generated markup, JavaScript, dependencies, the level of autonomy the merchant needs, required features and future maintenance. Before replacing a technology, I measure the real page and compare its technical cost with the value it provides.
In my work I almost always start from Shopify Online Store 2.0 and the theme's native capabilities. I do not use page builders as the baseline, but that does not mean I consider them inherently wrong: they can make sense when the required editorial autonomy goes beyond what the theme offers and the technical cost remains acceptable.
Correct decision
Do not choose between “builder” and “Liquid” in the abstract. Compare the actual feature you need, the resources it adds, how often it will change and who will have to maintain it six months from now.
1. What actually changes between page builders, native sections and custom Liquid
| Approach | Main strength | Main risk | When I consider it |
|---|---|---|---|
| Native theme sections | Simpler integration and maintenance | Configuration limits | First choice when they cover the requirement |
| Liquid / custom section | Control over markup, CSS, theme logic and settings | Code that must be maintained and tested | When the requirement is stable and belongs in the storefront |
| Page builder | Editorial autonomy and complex landing pages | Dependencies, additional assets and lock-in | When the team frequently needs layouts outside the theme |
| App / backend | Application logic, persistent data and APIs | Greater system complexity | When the feature is not really a theme concern |
2. Does a page builder slow Shopify down?
It can add scripts, stylesheets, HTML wrappers, fonts, components and dependencies that the theme would not load on its own. The impact varies greatly depending on the tool, the sections used and how assets are loaded. That is why the builder's name is not a diagnosis.
I check network requests, executed JavaScript, CSS, DOM size, the LCP element and key interactions. If the actual bottleneck is a huge hero image, an external app or a tracking script, rebuilding the page in Liquid may leave the real problem untouched.
Practical example
A landing page built with a builder can be slow because it loads an above-the-fold video and three external widgets. Rebuilding it in Liquid without changing the video and widgets may produce only a small improvement. Measure the cause first, then decide whether the builder is part of the problem.
3. When I prefer native theme sections
If the theme already provides a section that covers the requirement with sufficient settings, I prefer to reuse it. That means less proprietary code, fewer dependencies and a more coherent Theme Editor experience.
Before developing a new section I therefore check whether the same result can be achieved with composition, blocks, metafields and settings that already exist. “Custom” is not automatically better.
4. When I prefer Liquid and custom sections
Liquid is suitable when the feature belongs stably in the storefront: an editorial section, a grid, a product component, a metafield-driven block, presentation logic or a configuration the merchant needs to manage from the Theme Editor.
A good custom section should not be a rigid piece of HTML. I design it with schema, settings, blocks, sensible limits and responsive behavior so the merchant can manage it without entering the code.
A custom section is ready when
- it uses settings that fit the Theme Editor;
- it does not duplicate a feature already available in Shopify or the theme;
- it loads CSS/JS only when needed;
- it handles mobile and long content;
- it has sensible fallbacks when a field is empty;
- it does not break the editor, translations, app blocks or connected components;
- it can be maintained without remembering hidden “tricks” in the code.
5. When Liquid is not the right layer
If the feature requires authentication, protected API calls, webhooks, asynchronous processing, persistent data, billing or external processes, the theme is not the right place. In that case I consider a Shopify app or a separate backend service.
Forcing application logic into Custom Liquid or public JavaScript often creates a fragile system that is difficult to secure. The theme should present data and frontend interactions; it should not replace a backend when a backend is actually required.
6. The hidden cost: maintenance and dependencies
Performance is not the only criterion. A solution can be fast today but expensive to maintain, or slightly heavier but much easier for a team that publishes landing pages every week.
| Question | Why it matters |
|---|---|
| Who edits the page? | A non-technical merchant may need more autonomy than a store supported by a developer. |
| How often does it change? | A weekly landing page has different needs from a stable PDP section. |
| What happens if I remove the app? | I need to know which assets, templates, metafields and content depend on the builder. |
| Are assets loaded everywhere? | A feature used on one page should not necessarily add weight to the whole store. |
| Can the theme still be updated? | Code and integrations must remain understandable after future changes. |
7. How I compare two solutions without distorting the test
I do not compare two pages with different images, content and features. I keep as much as possible constant; otherwise I would not know whether the technology caused the difference.
- save a baseline of the real page on mobile and desktop;
- identify LCP, INP, CLS, network requests and major scripts;
- define the same feature to compare;
- keep content and assets as equivalent as possible;
- measure added dependencies and executed JavaScript;
- test the Theme Editor and merchant autonomy;
- run regression checks on menus, variants, search, cart, tracking and apps;
- evaluate future maintenance cost, not just a laboratory score.
8. How I migrate from a page builder to Liquid without breaking pages
The correct sequence starts with inventory, not uninstalling the app.
- Map the pages: which templates and landing pages depend on the builder?
- Inventory the features: which components are really needed and which are leftovers?
- Check data and dependencies: metafields, app blocks, scripts, assets and snippets.
- Rebuild on a theme copy: create the required sections and blocks.
- Compare content and features: URLs, headings, media, forms, tracking and CTAs.
- Test mobile and desktop: including edge cases and long content.
- Only at the end remove what is no longer needed.
Mistake to avoid
Uninstalling the builder first and discovering later that pages, metafields or assets still depended on it.
9. Page builders and SEO: what I actually check
I do not consider a page builder “non-SEO” by definition. I inspect the actual output: headings, links, content available in HTML, images, performance, canonicals and duplication. If the builder produces an accessible, coherent and useful page, the name of the tool is not the issue.
The problem starts when the technology introduces redundant markup, duplicated content, unnecessary dependencies or makes it difficult to maintain a consistent structure over time. A poorly written Liquid section can cause exactly the same damage.
10. Which solution I choose in my Shopify projects
My baseline is Online Store 2.0 without a page builder: native sections first, then custom development when needed. This gives me better control over dependencies and maintenance in projects I manage directly.
That does not become an absolute rule for diagnosing existing stores. If I enter a project that already uses a builder, I first verify whether it is causing a real problem and what replacing it would cost. Removing a working technology only to match my preference would be an intervention without evidence.
Decision checklist
- Does the theme already cover the feature?
- Does the feature belong to the storefront or require backend/API logic?
- Who needs to edit it and how often?
- How many resources does it add to the storefront?
- Does it load assets even where it is not used?
- What dependency does it create on an app or vendor?
- How does it behave on mobile?
- What happens if the solution is removed?
- How will it be tested after a theme update?
- Does the editorial benefit justify the technical cost?
I am Francesco Guiducci, a freelance Shopify specialist and Shopify app developer. If you need to understand whether the problem is really in the page builder, the theme or the apps, these checks are part of my Shopify Audit.
Updated September 13, 2026.
