Magento Checkout Page Speed: Islands Architecture Explained

The Magento checkout page is slow to become usable because the stock onepage checkout waits for window.checkoutConfig, a large per-quote JSON payload, before the shopper can type anything. FastMagento Checkout fixes that with islands architecture: the contact and shipping form ships as static HTML that works immediately, the heavy config loads in the background, and Magento’s own payment component runs as a separate island so every payment method keeps working.

I built FastMagento Checkout because I had a store that was fast everywhere except the last step. Catalog, search and cart were quick, and then the shopper hit checkout and waited on a spinner while the server assembled data none of them needed to start typing their name. This post explains what makes the Magento checkout page slow, how the islands approach changes it, what else the module does, and how to install and roll it back. It is open source under OSL-3.0 / AFL-3.0.

Why Is the Magento Checkout Page Slow to Load?

Magento 2 calls its checkout “onepage,” but the page is really one large block of per-quote data that the server has to build before the browser can render a single input. Until it arrives, the shopper sees a loading state while holding their card.

What window.checkoutConfig carries

Magento assembles window.checkoutConfig from its checkout config providers. It carries every payment method’s settings, the totals breakdown, and the region lists for every country the store ships to. The Luma checkout then builds the page from KnockoutJS UI components that read that object. The problem is the order of operations: the contact and address fields do not depend on any of that data, yet they wait for it.

Why the checkout page cannot be cached

Because the stock page inlines private, per-quote data into the HTML, the whole response is specific to one shopper and one cart. That rules out serving a shared, cached page shell. Every checkout visit is a full server render with the slowest part of the work in front of the first paint.

What Is Islands Architecture in a Magento Checkout?

Islands architecture is a frontend pattern where a page ships as mostly static HTML with a few independent interactive regions, the “islands,” that each load and start on their own. It is common in modern frontend frameworks such as Astro. FastMagento Checkout applies the same idea inside base Magento, with no Hyvä or Breeze requirement and no core patches.

Island one: a static form that is typeable immediately

The contact and shipping form is plain HTML in the first response, mounted by a small vanilla JavaScript widget that runs the same way under stock Magento and under Breeze. There is no skeleton loader and no spinner in front of the inputs. A shopper can start typing their email before the rest of the page has finished starting up.

Island two: the deferred checkout config

After first paint, the page requests the private per-quote config from its own endpoint, fastcheckout/config, and deep-merges it into a small static skeleton of window.checkoutConfig. The merge preserves object identity, so third-party modules that read window.checkoutConfig early (a Stripe minicart integration is the example in the README) do not throw. If the request fails, the loader retries, and if it keeps failing the shopper is redirected to the stock checkout. Nobody is left on a broken page.

Island three: the stock payment component

The payment area is not a rewrite. It is Magento’s own Knockout payment component, booted into its own node through Magento_Ui/js/core/app. Braintree, Stripe, PayPal, Klarna, Amazon Pay, Vault, offline methods and ReCaptcha run on the same code they run on the stock checkout, with no per-method integration work.

Magento Checkout Flow Features Beyond Speed

Once the page was split into islands, a few long-standing checkout annoyances became easy to fix in the same module. None of them change the database schema.

Saved addresses with no SQL on the checkout page

For logged-in shoppers, the address book is delivered once through a customer-data section and cached in the browser’s localStorage. On checkout it prefills the default address and email and shows a swipeable carousel of saved addresses, with a card that clears the form for a new one. The section refreshes only on login, logout, an address change or a placed order, so a returning shopper reaches checkout without a per-visit database call for their addresses.

Google Places address autocomplete and inline validation

Typing a street shows Google Places suggestions. Picking one fills city, state, ZIP and country, and matches the region dropdown by code rather than by text. The module can reuse an existing store key, such as the one from Amasty Address Autocomplete, or take its own, and it ships its own CSP whitelist for the Google Maps hosts. Empty required fields are flagged on blur, and also when the shopper moves to a later field, which catches the state field that browser autofill often skips. The shipping box says what is missing instead of silently showing no rates, and a failed order submission moves focus to the field that blocked it.

Magento guest checkout orders linked to accounts

Guest orders are matched to accounts in both directions. At checkout, a guest whose email already belongs to an account has the order attached to that account, so it appears in their order history. At registration, a new account claims every earlier guest order placed with the same email. It links by email match without a login step, which is why it is a setting you can switch off.

Order summary, cart types and the checkout prefetch

The order summary shows product thumbnails (for configurable products, the chosen child’s image, falling back to the parent) and scrolls internally so it never pushes the Place Order button off-screen. Physical, virtual and mixed carts all place real orders: virtual carts hide shipping and treat the form as the billing address. When the cart has items, a small site-wide script asks the browser to prerender the checkout page with the Speculation Rules API, or to prefetch it where prerender is not supported, so the click to checkout has less to wait for.

Your logo follows the shopper into checkout

On a store using Hyvä’s theme fallback, checkout renders in a different theme from the rest of the storefront. Magento then resolves the default logo against the rendering theme, so a Breeze storefront can show a Luma logo at the moment of payment. The module resolves the logo against the theme the store is configured to use. It does nothing when a logo has been uploaded in the admin, because that one is already theme-independent.

All settings live under Stores, Configuration, ParkkTech, FastMagento Checkout. Check the Checkout Style value after installing so you know which checkout your shoppers are getting.

How to Install FastMagento Checkout on Magento 2

Requirements are Magento 2.4.6 or later and PHP 8.1 or later. It does not need a search engine, a special theme or core patches. It is a standard Composer package:

composer require parkktech/fastmagento-checkout
bin/magento module:enable ParkkTech_FastMagentoCheckout
bin/magento setup:upgrade
bin/magento setup:di:compile        # production mode only
bin/magento cache:flush

The README states it has been verified end to end on Hyvä, Luma and Swissup Breeze: catalog, product page, cart, checkout and a placed order on each. The live demo is DIYoffroad.com, where you can add any product to the cart and open the checkout.

Running Hyvä? Add the Luma checkout fallback

The module renders through the Luma/Knockout checkout.root block, which Hyvä’s default theme does not output. Without Hyvä’s free Luma-checkout fallback the module stays inert and you get Hyvä’s own checkout:

composer require hyva-themes/magento2-luma-checkout

Deploy static content for the fallback theme too

This is the most confusing failure the module has, and it is not a module bug. The Hyvä fallback swaps the design theme at runtime for /checkout/index, so checkout renders in Magento/luma and that theme needs its own deployed static content. When it is missing, checkout returns HTTP 200 while every Luma CSS and JavaScript file returns 404, RequireJS never loads, and you see an unstyled page. Pinning the deploy to your storefront theme skips the fallback theme every time:

# deploys your theme AND the checkout fallback theme
bin/magento setup:static-content:deploy -f -a frontend --exclude-theme Vendor/broken-theme en_US

# skips Magento/luma: catalog styled, checkout not
bin/magento setup:static-content:deploy -f -a frontend --theme Your/theme en_US

# quick check
ls pub/static/frontend/Magento/luma/en_US/css/styles-m.css

Once theme fallback is enabled it applies globally, so Luma and Breeze storefronts also route checkout through it. If you run FastMagento, bin/magento fastmagento:doctor reports whether the fast checkout is enabled, whether the Hyvä fallback is present, and whether the checkout theme’s static content is deployed, per store view and locale.

How Do You Turn Off FastMagento Checkout?

There are three ways back to the stock checkout, from lightest to heaviest:

1. One request Append ?fastcheckout=0 to the checkout URL. That request renders the stock onepage markup. Useful for support and side-by-side comparisons.
2. Whole store Set Checkout Style to Default (2-Step) in the admin, or set the same value from the command line (below).
3. Remove it Run bin/magento module:disable ParkkTech_FastMagentoCheckout. The module never makes schema or data changes, so there is nothing to migrate back.

bin/magento config:set fastmagentocheckout/general/enabled 0
bin/magento cache:flush

Does FastMagento Checkout Improve Magento Checkout Performance?

It changes when the shopper can start: the form is usable in the first response instead of after the config arrives, and the page shell no longer carries private data. What it does not have yet is a published, standalone timing benchmark, and I am not going to put a number on it until there is one in the repository with the test conditions stated.

The checkout numbers I have published are for a different layer. Fast Checkout, built into FastMagento, speeds up the backend cart and totals work that runs behind every checkout, and those warm-render results are in my comparison of Magento 2 checkout extensions, alongside one-step checkout extensions, Hyvä Checkout and Bolt. If your whole store is slow, not just checkout, start with why Magento is still slow after Varnish.

Frequently Asked Questions