Shopify Scripts Are Dead: What the Forced Functions Migration Did to Your Checkout Speed

Shopify Scripts execution ended permanently on June 30, 2026. Editing was disabled on April 15, so any store that did not migrate to Shopify Functions by mid-April lost the ability to change discount logic well before checkout stopped running Scripts entirely. There was no third extension. The full timeline is in the Shopify changelog.

If your team missed the deadline, checkout is now running with either your migrated Functions, or nothing. If discount logic simply vanished on July 1, you are in the second category, and the fix is a rush Functions build, not this post. If your team migrated in time, the question is whether the rewrite made checkout faster, slower, or the same, and whether the business rules still match what marketing intended.

Shopify Functions run as compiled WebAssembly modules at the edge, close to the shopper. Scripts ran as interpreted Ruby inside Shopify's checkout stack. On a like for like discount rule, the compiled Wasm path is measurably faster, typically shaving 40 to 120 milliseconds off checkout total blocking time, depending on how much logic you had.

Where Functions are not faster is when the rewrite pulled in extra network calls. A common pattern we see: the old Ruby script inspected the cart in place, and the new Function was written to call an external API for tax lookup, loyalty tier, or fraud scoring. If that external call blocks the cart response, you have replaced a fast in-process check with a round trip. The compilation win is real but small. The extra network call is the thing that dominates checkout latency now.

The second common regression is a poorly written GraphQL query inside the Function. Functions have a query budget, and a Function that requests every product's full metafield set on every cart update will hit that budget and slow to a crawl, even though the compiled code itself is fast.

You need three sources of truth to know whether the migration helped or hurt checkout.

The Web Performance Dashboard in Shopify Admin. Since the Spring 2026 Edition, this dashboard reports checkout-level performance metrics, including Total Blocking Time and Time to Interactive for the checkout pages. Compare the four weeks before your migration against the four weeks after. If TBT is flat or higher, your Function has extra work in it that Scripts did not have.

Checkout conversion rate, segmented by device. Speed regressions show up first on mid-tier Android over 4G. Pull your conversion rate for that segment across the same four-week windows. A drop of half a percentage point that lines up with the migration date is a signal, not noise.

Native checkout A/B testing. The Spring 2026 Edition also added native A/B testing for checkout configurations. Use it to run your migrated Functions against a control that skips the Function entirely, on the segment where the Function's discount logic would not apply. This isolates the Function's overhead from everything else on the page.

If all three agree the migration was neutral or positive, you are done. If any one disagrees, treat it as a real problem to investigate, not a rounding error.

The four failure modes we have seen most often since June 30:

• Discounts silently not applying. The Function compiles and returns, but the discount object is malformed and Shopify drops it. Symptom: order review shows full price for orders that should have had a promo. Watch for a rise in support tickets about missing discounts.
• Checkout latency spikes on peak traffic. A Function that hits a slow external API works fine at low traffic and falls over during a flash sale. Symptom: TBT on the Web Performance Dashboard doubles during marketing sends.
• Abandoned cart rate rising. If your Function adds 300 milliseconds to shipping calculation, shoppers on flaky connections drop off during the shipping step. Symptom: abandoned cart rate ticks up 1 to 3 points after June 30 with no other changes.
• Discount stacking rules broken. Scripts allowed complex rule ordering. Some Function rewrites implemented single-rule logic and lost the stacking, so combined discounts under-apply. Symptom: AOV drops on orders that historically combined promos.

If you see one of these, the Function needs a fix, not the theme, and not the checkout UI.

Two other Shopify releases from June are worth using in the audit.

Checkout Components GA for Plus. Plus merchants can now ship the modular Checkout Components in production alongside Extensions. If your migration exposed that your custom checkout UI was carrying dead weight, Components is the cleanest path to a lighter checkout.

Bulk queries running roughly 4X faster. Any Function that reads bulk data (segments, customer tags, order history) benefits from the June bulk query performance work with no code change. If your Function was rewritten before that change landed, retest its runtime against the new baseline. You may find the query budget concern that shaped the original implementation is no longer a constraint.

If you want a second opinion on whether your Functions migration held checkout speed, we run a fixed scope audit against the three data sources above and hand back a written diagnosis of any regressions, tied to specific Function calls or third-party API dependencies. Start with our Shopify speed optimization service. For the deeper platform background before that call, the ultimate Shopify speed guide has the full context on where checkout speed comes from and where it goes.