Start Here

Performance best practices

If your storefront feels slow or your mobile scores look low, start here.

You’ll walk through delayed.js, CSS load order, and head.html next to Keeping it 100 , the Edge Delivery guide many teams keep open while they tune loading. After you change how things load, run Lighthouse audits for a fresh readout. Before launch, review Performance and monitoring on the launch checklist.

When you already have the project from Create a storefront, leave the repo open in your editor so you can open files such as scripts/delayed.js and styles/styles.css when this page points to them.

The Commerce boilerplate uses the same Edge Delivery Services pattern as other Edge storefronts: eager, lazy, and delayed loading, fonts, and LCP (Largest Contentful Paint, how fast the main content shows).

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

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

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

Go to the PageSpeed Insights website .
Paste your storefront URL into the PageSpeed Insights input field.
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/
Click the Analyze button to run the audit.
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

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

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

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

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.