Skip to content
Adobe Commerce Storefront Logo Adobe Commerce Storefront

Search is only available in production builds. Try building and previewing the site to test it out locally.
Go Live

Performance best practices

If your storefront feels slow or your mobile scores look low, tune delayed.js, CSS load order, and head.html to match the Edge Delivery ServicesAdobe's hosting and delivery infrastructure that turns authored documents into fast HTML pages served from servers close to the shopper. You push code to GitHub; Edge Delivery Services builds and publishes automatically. eager, lazy, and delayed loading pattern.

Start with Keeping it 100 on AEM.live The canonical Keeping it 100 page covers eager, lazy, and delayed loading, Largest Contentful Paint (LCP), fonts, and mistakes such as overusing preload and early hints. Read it before you edit head.html or split CSS.

Run Lighthouse audits

Section titled “Run Lighthouse audits”

PageSpeed Insights runs Lighthouse on Google’s hardware instead of on your computer, so you can compare one test run to the next more fairly than if you only tested locally. It reports Web Vitals, Google’s standard scores for how fast and stable the page feels. The fix list follows Google’s performance guidance. When you change load order or assets, compare those suggestions with Keeping it 100 so resource hints, fonts, and load phases still match what Edge Delivery Services expects.

PageSpeed Insights Enter your storefront production URL (typically *.aem.live) for accurate results. That hostname sits on CDNs close to your customers, on the edge.

Step-by-step

Section titled “Step-by-step”

The following steps run a PageSpeed Insights audit on a URL you choose.

  1. Go to the PageSpeed Insights website .

  2. Paste your storefront URL into the PageSpeed Insights input field.

  3. If you use the default main branch pattern on Edge Delivery, typical preview and production hosts look like this (replace {repo} and {owner} with your GitHub repository name and owner):

    • Preview: https://main--{repo}--{owner}.aem.page/
    • Production: https://main--{repo}--{owner}.aem.live/

  4. Click the Analyze button to run the audit.

  5. You’ll see full Web Vitals reports for mobile and desktop. Scores are often high on tuned Edge Delivery storefronts, but they vary with page content, third-party scripts, and test conditions, so treat the report as a snapshot, not a guarantee of 100 on every run.

Performance in the Commerce boilerplate

Section titled “Performance in the Commerce boilerplate”

Delayed phase

Section titled “Delayed phase”

Keeping it 100 describes a delayed phase for third-party tags, marketing tooling, extended analytics, consent, chat, and similar scripts. Load them through delayed.js so they do not compete with LCP or the rest of the experience.

In the Commerce boilerplate, implement that path in scripts/delayed.js . Keep it off the eager path. For Adobe Experience Platform and related patterns, see Adobe Experience Platform analytics.

Eager vs lazy styles

Section titled “Eager vs lazy styles”

Keeping it 100 treats styles in two phases so LCP stays predictable.

Eager phase

Section titled “Eager phase”

The eager phase covers the markup, CSS, and JavaScript that must load first so the main content can appear quickly and your LCP score can settle. Stay within the network and payload limits the Keeping it 100 page describes.

Lazy phase

Section titled “Lazy phase”

The lazy phase is for styles (and related assets) that can load after the main content and LCP finish so they do not slow the first screen.

In the Commerce boilerplate, eager, site-wide tokens and styles usually start in styles/styles.css . For deferred styles (for example, lazy-styles.css), use the folder-and-import patterns in Branding and styles instead of merging them into the eager file.

After your split matches that guidance, align head.html and load order with Keeping it 100 so you are not maintaining a second rule set. Keeping it 100 also explains why preloading every web font often backfires. Keep the boilerplate font fallbacks unless you have a clear measurement that says to change them.

Load hidden UI on demand

Section titled “Load hidden UI on demand”

Don’t load the scripts, fragments, and styles for UI that shoppers may never need.

Treat any UI that stays hidden until the shopper interacts with it as lazy: load what it needs only on the interaction that reveals it, such as a click or tap.

The Mini Cart panel is a good example. Most shoppers never open it, so the scripts, fragment, and styles it needs shouldn’t load until they do. Load the fragment on the click that opens the panel, and update the item-count badge — the piece shoppers always see — directly from event data instead.

The same rule applies to any drop-in container, fragment, or block that’s hidden by default, such as the header search button. Request what it needs when the shopper’s action reveals it, not on every page load. It stays visible on every page, but the Product Discovery drop-in that powers search results and autocomplete loads only when the shopper opens it.

Edge Delivery Services caps requests from one shopper to 200 per second for each aem.page or aem.live host name. See Delivery rate limits. Loading hidden UI eagerly adds to that count on every page load, even for shoppers who never see it. It also forces the browser to paint that UI before it’s needed, which can slow LCP. One eager panel looks minor on its own, but the cost adds up as you add more blocks and logic to the storefront.

Seeing 429 errors? See Too many requests (429 errors) to find the cause and fix it.

Once you’ve tuned these areas, run Lighthouse audits for a fresh readout, and revisit Performance and monitoring on the launch checklist before you ship.