Shopify Plus stores do not get slow at the platform layer. They get slow at the merchant layer. Shopify’s own infrastructure, global CDN through Cloudflare, automatic WebP image conversion, HTTP/2 and Brotli by default, keeps time to first byte under 300ms for most regions, and none of it is configurable enough for you to break. As Shopify’s performance documentation puts it, the biggest factors you control are your theme, your installed apps, and any third-party code you have added, including tag managers.
The field data backs that up. Per the CrUX Technology Report figures collected in the corewebvitals.io Shopify guide, Shopify passes mobile Core Web Vitals on roughly 65 percent of measured origins against 43.4 percent for WordPress. Yet a Shero Commerce benchmark of 1,000 real Shopify stores found only 48 percent pass all three vitals on mobile, and the median mobile LCP sits at 2.26 seconds, uncomfortably close to the 2.5 second threshold. One more app or one oversized hero image pushes a passing store into failing territory. We do performance work on both Adobe Commerce with Hyva and Shopify Plus, and the Shopify playbook is different: it is subtraction, not tuning.
Which Core Web Vital actually fails on Shopify Plus?
LCP is the one that fails. The other two vitals are largely solved by the platform: the same benchmark data puts Shopify’s median CLS at 0.01, which is excellent, and median INP at 153ms, comfortably inside Google’s 200ms good threshold. Largest Contentful Paint is where stores miss, and the LCP element is almost always the homepage hero, the featured product image, or the collection banner.
That narrows the job considerably. Before touching anything else, pull your store’s field data from Google Search Console’s Core Web Vitals report, not the Shopify admin Speed Score. The Speed Score is a simplified lab number from a single simulated visit; Search Console reflects a 28-day window of real Chrome users on real devices, which is what Google actually ranks on and what your customers actually feel. If Search Console says your product pages fail LCP on mobile, that one sentence is your entire optimization brief.
How much are apps really costing you?
Apps are the strongest predictor of failure in the data. Real-user monitoring cited in the same corewebvitals.io analysis shows stores loading more than 8 third-party app scripts run a median mobile LCP above 3.0 seconds, while stores with 3 or fewer keep median LCP under 2.0 seconds. A typical new app adds 50KB to 150KB of JavaScript to every page load. In one documented cleanup, removing three dead apps, a disabled popup tool, a loyalty program, and a defunct chat widget, cut 380KB of JavaScript and improved mobile LCP by 1.1 seconds. Removing a single unnecessary review-widget script improved median INP by 45ms on another store.
The audit is unglamorous and it works. List every installed app, then open Chrome DevTools’ Coverage tab on a product page; on bloated stores, 60 to 80 percent of loaded JavaScript never executes on the page that loaded it. Toggle app embeds off one at a time in the theme editor and retest. Then check your theme’s snippets and sections folders for leftovers, because uninstalling a Shopify app does not remove code it wrote into your theme during installation. Every app that survives the audit should justify its ongoing rent in conversion, not in the enthusiasm someone had for it two Black Fridays ago.
What fixes LCP on a Shopify Plus store?
Treat the hero image like the most important asset on the page, because to Google it is. Shopify’s image_tag Liquid filter can send a preload hint in the HTTP response header itself, the earliest signal a browser can get, and it will emit responsive srcset markup and width and height attributes automatically. Combine that with high fetch priority on the hero and eager loading above the fold. Many themes lazy-load every image including the hero, which tells the browser to deprioritize the exact element your LCP is measured on; excluding above-the-fold images from lazy loading is one of the highest-yield single changes we make on Plus engagements.
Two more patterns matter. First, if your theme paints the hero as a CSS background image, the browser cannot start fetching it until the stylesheet is downloaded and parsed, and you lose preloading and responsive sizing entirely; converting it to a real image element is theme surgery worth doing. Second, request images at the size they render. Shopify’s CDN resizes on the fly through URL parameters, but your templates have to ask, and a 2000-pixel image squeezed into an 800-pixel slot is pure LCP tax. Shopify’s own guidance adds one more: high section counts on a template measurably drag performance, so a homepage assembled from fourteen stacked sections is a design decision with a speed invoice attached.
What fixes INP when it does slip?
Get third-party scripts out of the startup path and off the interaction path. Chat widgets, review apps, personalization popups, and analytics pixels do not need to load during initial render. The right pattern is idle-time loading: the browser fetches them a few seconds after the page settles, when the main thread has nothing better to do. The wrong pattern is loading them on the first tap or scroll, which stacks a 500KB script download onto the same event as the user’s interaction and hands that interaction a terrible INP. Google’s INP documentation is the reference worth reading before touching this; the metric measures the slowest meaningful interaction, so one heavy handler on your add-to-cart button outweighs a fast homepage.
Theme JavaScript is the other half. Mega menus, quick-view modals, animated sliders, and AJAX cart drawers all ship script, and on many third-party themes that total clears 200KB before a single app loads. Shopify injects its own mandatory scripts through content_for_header on every page, and you cannot remove that baseline, which means everything you add competes for what is left of the main thread. A theme audit with the Coverage tab, plus replacing script-driven effects with CSS where the visual result is identical, routinely buys back more responsiveness than any clever deferral trick.
Does this actually show up in revenue?
Yes, and the effect size is larger than most owners expect. The Google-commissioned Deloitte study of 30 million user sessions across 37 brand sites found that a 0.1 second improvement in mobile speed metrics lifted retail conversion rates by 8.4 percent and average order value by 9.2 percent, with progression from product page to add-to-cart up 9.1 percent, per the web.dev case study summary. A tenth of a second. Most of the app-bloat cleanups described above move LCP by ten times that.
That is why we treat speed work as revenue work, not hygiene. For a DTC brand doing $20M through the storefront, the Deloitte multipliers price a passing-to-failing CWV regression in six figures a year, which reframes the annual cost of that heat-map app nobody has opened since 2024.
When do you need a developer, and when do you not?
A motivated merchant can get real gains without touching code: uninstall dead apps, toggle off unused app embeds, compress and correctly size images before upload, limit font weights, and turn off theme animations you do not need. That covers maybe half the typical gap.
The other half is template work: hero preloading, converting background-image heroes, pruning theme JavaScript, gating scripts to the page types that use them, and setting up real-user monitoring so regressions surface the week they happen instead of the quarter after. That is developer territory, and on Plus stores with custom themes it is senior-developer territory, because the checkout and the app ecosystem punish careless edits. It is also worth doing before you conclude your platform is the problem; we have talked more than one brand out of a replatform by fixing the storefront they already own, and we have also told brands honestly when the comparison runs the other way, as we laid out in when Shopify Plus beats Adobe Commerce for mid-market DTC.
Speed on Shopify Plus is not a mystery and it is rarely a platform limitation. It is an inventory problem: every script, app, and oversized image on the page is stock, and most stores are overstocked. Count it, cut it, measure it in field data, and repeat after every app install and seasonal campaign, because the most common regression in the monitoring data is simply something new that somebody added and forgot.
