# Checkout Page Speed: The LCP Line That Decides Whether Shoppers Wait

Source: https://checkoutoptimizelab.com/2026-11-11-checkout-lcp-speed-line-shoppers-wait.html

*A shopper reaches checkout and the page takes four seconds to settle. The button is there but the total is not, or the total is there but the button is greyed out, and the shopper is staring at a page that looks broken. The largest contentful paint number is the measure of that moment, and at checkout the line between waiting and leaving is thinner than anywhere else on the store.*

## The checkout has one LCP element, and it is the button

Largest contentful paint measures when the biggest thing on the screen finishes rendering, and at checkout the biggest thing is usually the pay button or the order summary total. That is the element the shopper is waiting for, and the number Shopify reports in the web performance dashboard is the time from navigation to that render. Google's guidance puts a good LCP at 2.5 seconds or less, and a checkout that renders its pay button in four seconds is asking the shopper to wait through a moment of doubt at the exact step where doubt costs the sale.

The LCP element at checkout is almost never an image. It is text and a button, which is why checkout LCP problems are script problems, not image problems. The page is waiting on JavaScript: the checkout extensibility scripts, the payment method scripts, the analytics scripts, and the app scripts that inject into the checkout. The [third-party script problem](https://checkoutoptimizelab.com/2026-10-23-checkout-speed-third-party-scripts.md) is the same diagnosis from the storefront side: the scripts are the weight, and the weight is what the shopper waits for.

Measure it the way the shopper experiences it. Open the checkout on a mid-range Android phone on a 4G connection, the way the [mid-range Android test](2026-10-30-checkout-load-mid-range-android.md) does, and watch the pay button. If it takes more than three seconds to become usable, the LCP number will confirm what your eyes already told you, and the fix is in the scripts, not the images.

## What actually slows it down

The usual suspects, in order of damage: checkout UI extensions that load synchronously and block the render, payment method scripts that fetch before the button can paint, analytics pixels that fire before the page settles, and app scripts that inject content into the checkout and force a re-layout. Each one is small. Together they are the four seconds.

The UI extension limit matters here. Shopify allows a small number of extensions per target, and each one is a script that runs before the checkout renders. The [three-per-target limit](2026-11-07-checkout-ui-extensions-limits-three-per-target.md) is a ceiling, not a recommendation: three extensions that each load a script will slow the checkout more than one extension that does the same work. Audit the extensions the way you audit the scripts, and remove the ones that do not earn their render time.

The payment method scripts are the hardest to fix, because the store does not control them. But the store controls the order: load the payment scripts after the pay button paints, not before. The button is the LCP element, and anything that delays it is a conversion cost, no matter whose script it is.

## The two fixes that move the number

First, defer everything that is not the pay button. Analytics, pixels, chat widgets, and app scripts that do not touch the payment flow should load after the LCP element renders, not before. The web pixels sandbox exists for exactly this reason: it isolates the tracking scripts from the render path, and the [pixels sandbox comparison](2026-11-08-checkout-web-pixels-vs-pixels-sandbox.md) shows which scripts belong in it.

Second, cut the extensions to the ones that earn their place. Each extension is a render cost, and the checkout that carries five extensions for decoration is paying for decoration with conversion. Remove the ones that do not change the shopper's decision, and measure the LCP again on the same mid-range phone. The number that moves is the number that matters, and at checkout it moves when the scripts get out of the way.

## Frequently asked questions

### What is a good LCP for a checkout page?

Google's guidance puts a good largest contentful paint at 2.5 seconds or less. At checkout the LCP element is usually the pay button or the order summary total, and a checkout that takes four seconds to render it is asking the shopper to wait through a moment of doubt where doubt costs the sale.

### What slows down checkout LCP the most?

JavaScript, not images. Checkout UI extensions that load synchronously, payment method scripts that fetch before the button paints, analytics pixels, and app scripts that inject content and force a re-layout. Each one is small. Together they are the delay.

### How do I measure checkout LCP the way shoppers experience it?

Open the checkout on a mid-range Android phone on a 4G connection and watch the pay button. That is the shopper's experience. The number in the web performance dashboard should confirm what your eyes tell you.

### Do checkout UI extensions slow down the page?

Yes. Each extension is a script that runs before the checkout renders, and Shopify's per-target limit is a ceiling, not a recommendation. Audit the extensions and remove the ones that do not earn their render time.