Shopify Custom Theme vs Page Builder: Which Is Faster?

Page builders make it easy to launch Shopify pages quickly. You can drag sections around, swap out content and publish without touching any code. For a lot of teams, that speed is genuinely useful.

But there's a trade-off. Most page builders load a broad set of JavaScript, CSS and layout logic to support every possible design combination. Your store only uses a fraction of it. The rest still loads.

A custom Shopify theme is usually faster than a page builder because it is built around the store's actual design, content and functionality. Page builders often load generic code to support many possible layouts, even when most of that code is not needed on the page.

That does not mean page builders are always the wrong choice. It means the performance gap matters more as your store grows, especially when Shopify performance optimisation, Core Web Vitals and conversion rate are on the line.

This article explains why page builders can slow Shopify stores down, when a custom theme is the better option, and how to know when it is time to make the switch.

The short answer: custom themes are usually faster

Short answer: In most Shopify stores, a well-built custom theme will outperform a page builder on speed, Core Web Vitals and long-term maintainability.

Custom themes can be written with only the code your store actually needs. No unused layout logic, no generic section handlers, no JavaScript that exists in case someone wants to add a countdown timer six months from now.

Page builders work differently. They are built to be flexible across thousands of different stores and layouts. That flexibility requires loading broader assets upfront, whether your specific page uses them or not.

A few important caveats worth being honest about:

• A poorly built custom theme can still be slow if it has unoptimised images, too many apps or heavy third-party scripts
• A lean page builder setup on a well-managed store can still perform acceptably
• Speed depends on the full picture: build quality, app stack, media, tracking scripts and theme structure

The performance advantage of a custom theme is not automatic. It is the result of building with performance in mind from the start. In most scaling Shopify stores, that approach wins on both speed and maintainability.

Why Shopify page builders can slow stores down

Page builders are designed to give non-technical teams maximum flexibility. That is a genuine strength. But flexibility in software almost always means more code, and more code means more for the browser to load, parse and execute before your page is usable.

Here is what that typically looks like in practice:

• Extra JavaScript — page builders load their own JS framework to power the drag-and-drop editor, section logic and interactive elements, even on the live storefront
• Extra CSS — generic stylesheets cover every layout option the builder supports, not just the ones you are using
• Layout wrappers — page builder sections often add multiple nested HTML elements around your content, increasing DOM size
• Generic section logic — code that handles every possible configuration of a section, even when your version only uses one setting
• App dependencies — many page builders pull in additional apps or scripts to power specific features
• Third-party scripts — widgets, chat tools, review apps and tracking pixels often load alongside page builder code, compounding the weight
• Inline styles — some builders inject styles directly into the HTML rather than a stylesheet, making caching harder
• DOM bloat — more elements on the page means more work for the browser to render and respond to interactions
• Repeated code across pages — the same builder assets load on every page, even when only one page uses a particular section type

None of this is unique to one builder. It is a structural characteristic of how page builders work. The more flexible the tool, the more code it needs to carry.

How page builders affect Core Web Vitals

Google's Core Web Vitals measure three things: how quickly the main content loads, how fast the page responds to interaction, and how stable the layout is as it loads. Page builders can create problems across all three.

Largest Contentful Paint (LCP)

LCP measures how long it takes for the largest visible element on the page to load. This is usually a hero image, banner or product photo.

Page builders often make LCP worse by:

• Loading hero sections with large, unoptimised images that have not been compressed or sized correctly
• Using background videos or full-width sliders that are render-blocking
• Stacking multiple sections above the fold, each with their own assets
• Delaying the main image because JavaScript has to initialise before the section renders

When the browser has to wait for the page builder's JS framework to load before it can display your hero image, LCP suffers.

Interaction to Next Paint (INP)

INP replaced First Input Delay as a Core Web Vital in 2024. It measures how quickly the page responds when a user clicks, taps or types.

Page builder pages tend to score worse on INP because:

• Heavy JavaScript execution blocks the main thread, making the page feel unresponsive
• Interactive widgets (accordions, filters, pop-ups, sticky headers) add event listeners that compete for processing time
• App scripts from review tools, loyalty programmes and chat widgets often run on page load regardless of whether they are needed immediately
• Tracking scripts from ad platforms compound the problem

Cumulative Layout Shift (CLS)

CLS measures visual stability. A high CLS score means elements are moving around as the page loads, which is frustrating for users and signals poor build quality to Google.

Page builders contribute to CLS when:

• Sections load in after the initial render and push content down
• Embeds (video players, review carousels, social feeds) reserve no space and jump into position
• Banners or pop-ups inject into the layout dynamically
• Fonts or images load late and cause surrounding content to shift

If you are seeing unexplained CLS issues, page builder sections and Shopify app bloat are two of the most common culprits.

Why custom Shopify themes are usually faster

Short answer: A custom theme is faster because it is written for one store, not every store. The code is scoped to your actual templates, sections and functionality.

This is the fundamental difference. When a developer builds a custom Shopify theme, every decision is made in the context of your store: your product structure, your content types, your design, your customer journey. Nothing is included speculatively.

In practical terms, that means:

• Leaner JavaScript — scripts are loaded only on the templates that need them, not sitewide by default
• Scoped CSS — stylesheets cover your design, not a library of every possible layout option
• Purpose-built sections — each section is designed for a specific use case, so there is no unused configuration logic
• Fewer third-party dependencies — functionality is built into the theme rather than bolted on via apps where possible
• Better asset control — images, fonts and media can be optimised specifically for your templates
• Template-level optimisation — product pages, collection pages and the homepage can each be optimised independently
• Easier to maintain over time — developers can find and remove code because it was written with a clear purpose

The result is a smaller page weight, less browser work on load, and a codebase that stays manageable as the store grows.

This is also why custom Shopify theme development tends to be the right investment for stores where performance, conversion rate and long-term scalability matter. The upfront cost is higher than installing a page builder, but the technical debt is far lower.

Page builder vs premium theme vs custom Shopify theme

Not every store needs a fully custom theme. The right choice depends on where you are in your growth and what you need from your storefront. Here is how the main options compare:

The last option, a custom theme built with reusable native Shopify sections, is what most growing stores should be aiming for. It gives your content team the ability to edit and build pages without a developer, while keeping the codebase clean and the performance strong.

Premium themes are a reasonable starting point, but they tend to accumulate technical debt as stores install more apps, override styles and add custom code on top of a base that was not designed for their specific needs.

When a page builder is still useful

This is not an argument against page builders in every situation. They exist for good reasons and they solve real problems for certain types of stores and teams.

Page builders tend to work well when:

• You are early stage and need to get something live quickly without a developer
• You are testing campaign pages and want to iterate on layouts without code changes
• You need temporary landing pages for a promotion, product launch or seasonal sale
• The pages are non-critical and not driving the majority of your revenue or organic traffic
• Your team has no developer access and needs to manage content independently
• You are experimenting with page structure before committing to a permanent design

The risk is not in using a page builder at all. The risk is in letting it take over your core commercial templates.

Where page builders become a problem is when they are powering your product pages, collection pages, homepage and high-traffic paid landing pages. These are the pages where speed and Core Web Vitals have a direct impact on SEO, ad quality scores and conversion rate. Running those pages through a page builder, especially at scale, is where the performance cost starts to compound.

When to rebuild page builder pages as custom Shopify sections

There is usually a point where page builder dependency stops being a convenience and starts being a liability. Here are the signs that it is time to move away from it for your core templates.

Signs the page builder is holding your store back

• Core Web Vitals are failing on product or collection pages, especially on mobile
• Product pages are slow and you cannot identify a clear cause without digging into the page builder's output
• The mobile experience feels clunky with layout issues, slow interactions or content that does not render cleanly
• Paid traffic landing pages are underperforming relative to what the traffic spend should deliver
• Your team is scared to edit pages because something always breaks when they move sections around
• Apps are duplicating theme functionality because the page builder cannot do something natively and a workaround was installed
• The theme is hard to maintain and developers cannot easily understand what is custom code versus page builder output
• Unused scripts and duplicate code keep appearing in audits, slowing load times without any clear owner
• Speed gets worse after every campaign as new sections, embeds and tracking pixels are added and never cleaned up

If several of these apply, rebuilding the affected templates as native Shopify sections is likely to be more cost-effective in the long run than continuing to patch around the page builder.

The goal is not necessarily a full rebuild of the entire store. Often the right approach is to identify which templates are causing the most performance damage and rebuild those first, while leaving lower-traffic pages on the page builder until they need attention.

How to keep a Shopify store fast as it grows

Performance is not something you fix once. It degrades over time as stores add apps, campaigns introduce new scripts, and teams make changes without a clear process for reviewing their impact.

The stores that maintain strong Core Web Vitals as they scale tend to treat performance as an ongoing discipline, not a one-time project.

A practical performance checklist for growing Shopify stores

• Audit new apps before installing — check what scripts they inject and whether the functionality is worth the load cost
• Avoid page builders for core templates — product pages, collection pages and high-traffic landing pages should use native Shopify sections
• Use native Shopify sections where possible — they are leaner, better supported and easier for developers to maintain
• Compress and resize media — images are one of the biggest contributors to slow load times and are often overlooked
• Test product and collection pages separately — these templates have different load profiles and need individual attention
• Monitor Core Web Vitals monthly — Google Search Console shows field data for your actual users, not just lab scores
• Remove unused code after campaigns — tracking pixels, A/B test scripts and embeds that were added temporarily should be cleaned up when the campaign ends
• Keep tracking scripts under control — each ad platform, analytics tool and pixel adds to the main thread load; audit them regularly
• Rebuild repeated page builder layouts as native sections — if the same page builder layout appears across ten product pages, it is worth rebuilding as a proper Shopify section

This is the kind of process that Shopify performance optimisation work is built around. Not just fixing what is slow today, but putting the right foundations in place so performance does not erode as the store grows.

You can also read our guide on Shopify technical SEO for more on how speed and site structure affect organic rankings.

How Futur Media builds faster Shopify stores

We are a UK Shopify agency with a founder-led team focused on performance, custom development and stores that are built to scale.

Most of the stores we work with have the same underlying story: they grew quickly, added apps and tools to keep up, and now the store is slower than it should be and harder to maintain than anyone expected. The page builder that made sense at launch is now powering the product pages, and every new campaign adds another layer of code that nobody has time to clean up.

Our approach is to audit first. We look at what is actually loading on your storefront, what is affecting Core Web Vitals, and where the biggest performance gains are. From there, we recommend whether the right move is cleaning up what you have, rebuilding specific templates as native sections, or starting with a custom Shopify theme.

That means:

• Custom Shopify theme development built around your store's actual requirements, not a generic base
• Performance-first builds where speed decisions are made before the store goes live, not patched in afterwards
• App rationalisation to remove unnecessary scripts and replace app functionality with leaner theme code where possible
• Page builder replacement for stores where builder dependency is causing measurable performance issues
• Native Shopify sections that give your team editorial flexibility without the overhead of a third-party builder
• Ongoing performance support for stores that want to maintain Core Web Vitals as they grow

We do not tell every store they need a full rebuild. Sometimes the answer is targeted fixes. But when a custom theme is the right long-term option, we build it properly.

Want a faster Shopify store without page builder bloat?

If your Shopify store relies on page builders, apps or years of accumulated theme edits, we can help you work out what is slowing it down and what should be rebuilt.

Our free Shopify performance audits show exactly what is loading on your storefront, what is affecting Core Web Vitals, and whether a custom Shopify theme would give you a faster long-term setup.

Get a free Shopify performance audit, or if you would rather talk it through first, speak to our Shopify team.