What We Found Under a Stuck Shopify Page Speed Score

Quick Answer: Half the weight we saw in every audit was Shopify's own platform code loading on every storefront page: payment-sheets, checkout-web, monorail-edge, storefront-bars, and shopify-boomerang. None of it is removable at the merchant level, and together it sets a shopify page speed ceiling around 55-65 on mobile even after a clean app purge.

The 2026 audits of larger Shopify storefronts kept landing in the same place. One weekend project on r/shopify tested 269 live stores and reported a median mobile Lighthouse score of 48. Gymshark measured 39. Skims 42. Steve Madden 25. Those are brands with real performance budgets and real engineers. When we started running the same test on the much smaller stores that come through our chat, we saw the same shape. A merchant would do everything the standard playbook asked for, land somewhere in the 55 to 65 band on mobile, and then stall. The last 15 to 20 points refused to move no matter what came off next.

The pattern we kept seeing

The stores were not identical, but the arc of the audit was. A merchant on Dawn or Sense would come to us at 34, 38, sometimes 42 on mobile. We would run through the standard app-and-image pass and land them somewhere in the high 50s or low 60s. Then everything we tried after that produced nothing. Compress another image, save 3 points. Defer a residual chat widget snippet, save 1 point. Remove a tracking pixel we'd already removed once, save 0.

We started noticing this in about the sixth audit of a small run we did in early 2026, and by the tenth we stopped pretending it was random. Different themes. Different niches. Different app stacks. Same terminal number.

For a while, our working assumption was that we were missing something. Every audit has a stone left unturned somewhere. We started running audits twice, three times, on the same store two weeks apart to make sure nothing had drifted. Same number.

What we checked first

The standard playbook comes off the shelf in a specific order and it works, up to a point. We ran it in that order:

1. Uninstall every app the merchant is not actively using this month. Read the leftover code out of the theme by hand. Delete the render calls the vendor left behind after uninstall.
2. Compress every image over 200KB. Ship them in WebP at the actual width the theme renders them.
3. Set the LCP hero image to fetchpriority="high" and remove any lazy attribute that got applied to it by mistake.
4. Audit tracking pixels. Consolidate the ones that duplicate each other. Move what can be moved to server-side via Customer Events or the Facebook CAPI.
5. Turn off announcement bars and marketing pop-ups that fire on first paint.

On a merchant starting at 38 on mobile, that pass usually returns 15 to 25 points. On a merchant starting at 45, it returns 10 to 15. If you would like the app-layer version of this in more detail, our earlier post on the Shopify page speed floor apps cannot cross covers where the theme itself sets the lower bound before any app decision matters.

But the ceiling we kept hitting was not the same as the theme floor. It sat above it. On Dawn stores, the theme floor with all app embeds off will run 78 to 85 on mobile if you check it in a duplicate theme with no apps active. The stores we were auditing had all their apps and were sitting at 60. That gap was not the theme.

Where the trail went cold

On one audit we got the store to 57 mobile with the app list down to two, images at real sizes, hero image priorities correct, tracking consolidated. The PageSpeed Insights report at the top of the run flagged the usual "reduce unused JavaScript" warning and listed a handful of scripts as the offenders. Two of the scripts we could not attribute to any app the merchant had installed. They were not from Klaviyo. They were not from Shop. They were not any pixel we had touched.

PageSpeed Insights labels these in its Network Dependency Tree under a category called "Unattributed." That category is a giveaway if you know what you are looking at, and for a couple of months we did not. We assumed "unattributed" meant "some obscure app I have not identified yet." It does not always mean that. It sometimes means the script does not carry the standard headers that let Lighthouse tag it as belonging to a known third party.

An r/shopify thread from March 2026 about a mobile LCP of 12.7 seconds surfaced the same category and moderator advice: the "Unattributed" bucket in that specific store was consistent with platform-hosted assets that Lighthouse could not name. We had seen a version of that in every audit. We had just been reading the label wrong.

The DevTools filter we should have run sooner

Once we knew what to look for, the fastest way to see it took about 90 seconds.

1. Open the storefront in Chrome, incognito, on a phone-sized viewport.
2. Open DevTools, switch to the Network tab, hard-refresh the page.
3. In the filter box, type cdn.shopify.com/shopifycloud.
4. Read the list.

On a typical store the filter returns four to six files with names that look like they belong to the checkout, the payment sheet, the announcement-bar infrastructure, and Shopify's own performance monitoring. They are hosted on Shopify's CDN. They load on every storefront page including product pages that have nothing to do with checkout. Together they add hundreds of kilobytes of JavaScript to the initial parse.

We ran this filter across every audit we still had open at the time. Same cluster showed up on every store. The names varied a little in build hash. The origin and the shape did not.

The five scripts that were always there

Here is the group we saw on nearly every audit, with what each one is and why it matters for a shopify page speed score. Numbers on individual impact come from merchant-run measurements posted on the Shopify Community; we are pointing you at the shape, not asking you to trust our arithmetic.

1. payment-sheets JS (cdn.shopify.com/shopifycloud/payment-sheets/assets/). The bundle that powers Shop Pay, Apple Pay, Google Pay, and PayPal on the product page. A merchant on the Shopify Community running a Sense theme in December 2022 measured what happened when they blocked five of these files in a test: TTI improved about 2 seconds, LCP about 0.8, FCP about 0.5, TBT about 400ms. Standard async and defer attributes on theme.liquid do not touch this bundle because Shopify emits the tags through its own render pipeline.

2. checkout-web / app.latest (cdn.shopify.com/shopifycloud/checkout-web/assets/). Two files, app.latest.en.[hash].js and Redesign.latest.en.[hash].js, that together run past 800KB on many stores. They load on every storefront page, not only checkout. A merchant on the Shopify Community first documented these in March 2023 with a score drop from 90+ to 75 and no reply from Shopify Staff. Community speculation is that Shopify pre-loads the checkout code on product pages to reduce cold-start time when a customer clicks Buy. It has never been confirmed on the record.

3. monorail-edge (monorail-edge.shopifysvc.com/v1/produce). This is Shopify's internal analytics beacon. It is a POST, and it does not always fire once per page. One community audit of a single storefront counted around ten separate calls in a single load. Shopify Support has historically told merchants the individual calls are small enough not to matter for page speed, which is fair for any one of them in isolation and misleading in aggregate.

4. storefront-bars JS (cdn.shopify.com/shopifycloud/shopify/assets/storefront/bars/). The plumbing behind Shopify's built-in notification and announcement bar. A single file around 240KB. A merchant on the Shopify Community documented a mobile Lighthouse regression from 61 to 58 the day their theme update pulled this in. There was no reply from Shopify or the theme vendor about whether it could be removed.

5. shopify-boomerang (shopify-boomerang-1.0.0.min.js). Around 20KB. This is Shopify's own real user monitoring library, reporting browser performance events back to Shopify's own infrastructure. On a Shopify Community thread about third-party code impact, a community advisor spelled out the same conclusion: the file is small, it comes from Shopify itself, and merchants should leave it alone. That is roughly where every serious thread on it lands.

There used to be a workaround for a subset of this. A few merchants had figured out how to capture the content_for_header Liquid object into a variable, chain remove calls to strip specific script URLs, and re-emit the head with those files gone. The same Shopify Community merchant who had first documented the checkout-web files in 2023 returned in January 2025 to report that the technique no longer worked, that their score had drifted from 90+ down to the 60-70 band since 2023 as more scripts were added, and that Shopify appears to have restricted access to content_for_header processing in a way that blocks the filter. If a guide from before 2025 tells you to use content_for_header to remove payment-sheets, that guide is stale.

What Winter 2025 fixed and what it left alone

There is real news to report on top of this. The picture has moved in the last eighteen months, and it is worth being precise about what has and has not changed.

In August 2024, Shopify moved the accelerated checkout buttons into a closed shadow DOM custom element. That was the architectural change behind the Winter Editions '25 announcement in December 2024 claiming a 58% faster load on those buttons and a 50% faster cart. The improvement is real; the mechanism is that the button paints as a placeholder sooner and hydrates asynchronously. What the announcement does not say is whether the underlying payment-sheets bundle itself is any lighter. From the community evidence, it is not: the bundle still loads. The visible button paints faster. The Lighthouse TBT contribution may or may not have improved on your specific store; run a fresh audit and compare against any baseline you took before December 2024, because that is the only way to know.

Shopify's automatic Early Hints rollout in August 2026 improves LCP by around 100ms at p75 by preloading render-blocking CSS and JS earlier in the response. It excludes payment-sheets and checkout-web because those are loaded as async or ES module scripts, not synchronous render-blocking scripts. The Early Hints improvement is real and it is welcome. It does not apply to the specific files that generate the community complaints.

The May 2026 upgrade of Speculation Rules from "conservative" to "moderate" improves in-session navigation LCP by about 228ms on desktop Chrome and Edge. It does not help the cold initial load from a search result or an ad click. For a merchant whose traffic mix is Meta ads landing on product pages, this improvement does not apply.

What we tell merchants now

The version we run in chat today is different from the version we ran twelve months ago. The differences are honest ones.

We ask the merchant to run the DevTools cdn.shopify.com/shopifycloud filter themselves, in Chrome incognito, on their own product page. We ask them to send us the count of files they see. We label those separately from any app scripts in the audit output before we set a target for the run. A store with a clean app list will show four to six platform-origin scripts, and no amount of merchant-side work will reduce that count. If the realistic ceiling for that store is 62 mobile, we say 62 out loud so the merchant is not spending a weekend chasing a number they cannot reach.

We do not disable dynamic checkout buttons to hit a higher lab score. The Safari-only PayPal hang from 2023 is a genuine exception; if a store is reproducing it, that is a real bug and the button toggle is a real fix. Outside that case, the accelerated checkout buttons pay for themselves in conversion on mobile at a rate that dwarfs the TBT gain. We would rather have the 400ms and the sales.

We look at real-user data before we accept that a lab score is hurting SEO. Search Console under Core Web Vitals and Chrome User Experience Report data reflect actual visitors on actual connections. A store at 55 on the Lighthouse simulator often passes CWV in the field because real visitors are on faster hardware than the simulated mid-tier phone. Shopify's own 2026 figure that 76% of stores pass CWV lines up with this: the simulator and the field are not measuring the same thing, and the field number is the one Google uses for ranking.

If you have been at this for a weekend, your score has stalled at 58, and you want a second pair of eyes before you spend another Saturday on it, the first 15 minutes with a help1 expert is free. Bring the DevTools filter list, your current mobile score, and the last change you made. That's usually enough to tell you whether the ceiling you're hitting is the app layer, the theme floor, or the platform floor underneath both.

So here is the question worth sitting with. If your store's realistic shopify page speed ceiling is 62 on mobile because of the platform scripts you cannot remove, and your current score is 55, what would you rather spend the next weekend on: chasing the seven points that are still yours to take, or the fifteen points that will never move no matter how many audits you run?