Shopify Plus Speed Problems: An Enterprise Diagnostic

What Plus does and does not establish

Shopify currently positions Plus around features such as B2B, headless commerce, POS Pro, checkout customization, Functions and international commerce. Current prices and transaction terms vary by region, term and business structure, so use the official localized page and the signed contract for commercial decisions. For the platform-versus-custom decision itself, see Shopify compared with a custom storefront.

The plan label does not tell you which scripts execute on a product page, whether a hero is correctly prioritized, how an app embed behaves or whether an interaction blocks the main thread. Those are implementation questions. Our Shopify store speed checklist works through them in order.

What is actually different about a Plus store

• ✓
  The integration load is heavier as a result. Plus merchants commonly run classes of system a smaller store does not: ERP or inventory sync, loyalty, subscriptions, personalisation, tax and compliance. Each tends to contribute its own script to the storefront, and the theme layer gives you no built-in way to isolate or defer them per route.
• ✓
  Checkout customisation moved. Stores that built custom logic into checkout.liquid have to rebuild it as checkout extensions. Careless extensions put scripts back into checkout, and checkout is the one place a Plus store can be slow in a way a smaller store never is.
• ✓
  Catalogue scale is a per-request cost. Collection and search templates get more expensive as SKU and variant counts grow, because that markup is produced per request rather than served pre-built. It is why benchmarks taken on small catalogues describe a different store than yours.
• ✓
  Multi-market and multi-currency add work to the same templates. Every additional locale or currency is more logic on the routes that already do the most.

And one thing worth knowing before headless is proposed as the fix: Plus features survive a custom storefront. Flow, Checkout Extensibility, multi-location inventory and multi-currency all continue to work behind a separately built frontend, because they live in the commerce layer rather than the theme. Whatever the argument for or against rebuilding, losing what you pay Plus for is not part of it.

"Plus gives you more enterprise features. It does not explain why your storefront is slow, and paying more for it will not fix that.

1. Define the incident or objective

Do not flatten all five into the site is slow. Each one needs different evidence, a different owner and a different test to prove it is fixed. Starting before you know which one you have is how a team spends a month on the wrong thing.

• ✓
  A Core Web Vital is Moderate or Poor for a meaningful real-user segment.
• ✓
  A route or interaction regressed after a named release.
• ✓
  Customers encounter a functional delay, error or instability.
• ✓
  A campaign, market or device segment cannot complete an important task reliably.
• ✓
  A contractual performance target is not met under the documented conditions.

Do not collapse all five into “the site is slow.” Each requires different evidence, owners and acceptance criteria. If the vitals themselves need defining first, start with what LCP, INP and CLS measure.

2. Use the Shopify field view

Shopify's Web Performance reports provide real-user LCP, INP and CLS over time, by URL and by page type. The summary uses the 75th percentile and separates device experiences. Review releases and traffic changes across the same period.

• ✓
  Prioritize routes with both poor experience and material traffic or business importance.
• ✓
  Compare mobile and desktop rather than averaging them together.
• ✓
  Separate templates and markets that carry different content or integrations.
• ✓
  Allow for Shopify's documented reporting delay before closing the investigation: the web performance report lags real traffic, so a change made today does not appear in it today. Check the current delay in your own dashboard rather than assuming it.

3. Trace the production page

Trace the real page, not a staging copy, because apps and tags behave differently in production. Five areas account for most of what you will find, and each row pairs what to inspect with what to do about it. Refactor only the bottleneck the trace actually named.

The table tells you what to look at. Attributing a slowdown to one named app takes a procedure, and this is the part most audits skip because the obvious version of it is unsafe. Work on a duplicate of the live theme and test through its preview URL. Nothing you do there is visible to customers.

• ✓
  Duplicate the published theme. In the theme editor for the duplicate, open App embeds: this is where most apps inject their global script, and it is toggleable per theme, so switching one off affects the preview only.
• ✓
  Record a baseline on the preview URL first: three runs of the same template, same device profile, same network setting. One run is noise.
• ✓
  Turn off one app embed, re-run the same three, write the number down, turn it back on. Changing two at once tells you the pair matters and not which one.
• ✓
  In Chrome DevTools, use the Coverage panel to see how much of each script is actually executed on that route, and the network waterfall to see what blocks rendering. An app costing 200KB that runs on every page but only functions on the cart is a routing problem, not a removal decision.
• ✓
  Rank what you found by cost per route, not by total weight, because the template your traffic lands on is the one that matters.

Each row above has a longer write-up. Inventorying what the store carries is covered in our breakdown of a Shopify app stack, and theme-level work is covered in Dawn theme performance.

4. Separate storefront and checkout evidence

Product discovery, product detail, cart and checkout have different code boundaries and business controls. Record where the delay occurs. A slow theme route does not prove checkout is slow, and a payment or validation problem is not fixed by replacing the catalog frontend. The conversion side of that split is examined in Shopify conversion and speed diagnostics.

5. Optimize with enterprise controls

At Plus scale the problem is rarely the technique, it is that nobody owns the decisions. Five things make a speed fix stick: every app and tag has an owner and a reason to exist, each page has a weight limit checked before release, changes roll out in phases with a named point at which you undo them, and accessibility, analytics and cookie consent survive the change, and vendor changes tracked on the same timeline as your field data.

• ✓
  Assign an owner and business justification to every app, tag and customer-facing feature.
• ✓
  Set route-specific performance budgets and enforce them in preview or continuous integration.
• ✓
  Test feature flags and phased releases with named rollback criteria.
• ✓
  Preserve accessibility, analytics, consent and commerce behavior as guardrails.
• ✓
  Track vendor and internal changes in the same timeline as field performance.

6. Decide whether headless is justified

Shopify supports headless through Hydrogen and the Storefront API. It can provide deeper storefront control, but Shopify also states that headless adds engineering dependency, maintenance responsibility and architectural complexity. Performance still depends on the implementation. Our own write-ups of that decision are headless Shopify and what headless commerce means.

• ✓
  Choose headless for accepted experience, channel or integration requirements that justify it.
• ✓
  Inventory apps and commerce workflows for API and headless compatibility.
• ✓
  Plan analytics, consent, SEO, Merchant Center, structured data and checkout continuity.
• ✓
  Budget security, monitoring, upgrades, incident response and internal ownership.
• ✓
  Retain a migration and rollback plan for high-revenue routes.

7. Agree what done actually looks like

A 90-plus Lighthouse target can be an accepted delivery term under recorded conditions. It should not be restated as a permanent guarantee for every route, visitor, app state or future release. Six things make the term enforceable, and the run count and the recorded conditions are what separate a criterion from a screenshot.

• ✓
  Name representative routes, devices and required page states.
• ✓
  Record network, geography, cache, consent and authentication conditions.
• ✓
  Run three consecutive mobile and desktop tests for each agreed representative page and profile.
• ✓
  Require functional, accessibility, SEO, analytics and error checks.
• ✓
  Monitor real-user Core Web Vitals after launch.
• ✓
  Define the remedy in the signed scope if an agreed target is missed.

A 90-plus Lighthouse target can be an accepted delivery term under recorded conditions. It should not be restated as a permanent guarantee for every route, visitor, app state or future release. The method behind that kind of target is described in how we approach PageSpeed scores.

8. Model value without inventing lost revenue

Use first-party traffic, funnel, margin and experiment data. Treat any forecast as a range and compare it with observed post-release results. A performance metric can support a prioritization decision, but it does not calculate an exact revenue loss by itself.

We scope this work as e-commerce development, with project tiers on the pricing page and build examples in our client work.

Primary sources

• Shopify Plus pricing and features
• Shopify: web performance reports
• Shopify: improving web performance
• Shopify theme performance best practices
• Shopify Storefront API reference
• Shopify: headless benefits and tradeoffs