Adobe Commerce on Edge Delivery Services is Adobe's storefront for Commerce, which Adobe calls Adobe Commerce Storefront. Authors write pages as documents, and Edge Delivery Services turns them into fast HTML served close to the shopper. Drop-in components then add the cart, checkout, product pages and accounts by calling Commerce APIs from the browser.
It's included with Adobe Commerce as a Cloud Service and Adobe Commerce Optimizer. Commerce on Cloud or on-premises stores need an Optimizer license to use the drop-ins. This guide explains how it works, how it compares with Luma, PWA Studio and custom headless builds and what Adobe claims about speed. It also covers authoring, requirements, limits, migration and who it suits.
What is the Adobe Commerce storefront on Edge Delivery Services?
It's a headless storefront split into three layers: documents for content, Edge Delivery Services for delivery and drop-in components for live commerce data. Adobe describes Commerce Storefront as "a collection of tools and technologies" from Adobe. It brings together Document Authoring, a visual editor, asset management, content and commerce blocks, and Edge Delivery Services.
Here's how a page comes together:
- Authors write pages as documents in Document Authoring (DA.live), Google Docs or SharePoint. Tables in a document become blocks on the page.
- Edge Delivery Services converts those documents into HTML and serves them from servers near the shopper. When developers push code to GitHub, it builds and publishes automatically.
- Commerce blocks load drop-in components, which call Adobe Commerce GraphQL APIs from the shopper's browser for products, carts and accounts.
The Commerce Admin, catalog and order tools stay on the backend. You change how storefront pages are put together, not how Commerce stores its data. Teams start from Adobe's Commerce boilerplate repository. Adobe says that with accounts and a backend ready, you can have a working preview in less than a day.
What are drop-in components?
Drop-in components are ready-made npm packages that each handle one shopper task, such as the cart, checkout or sign-in. Each ships its own interface and Commerce logic, so developers configure and style them instead of building those screens from scratch.
| Type | Drop-ins available |
|---|---|
| B2C | Cart, Checkout, Order, Payment Services, Personalization, Product Details, Product Discovery, Recommendations, User Account, User Authentication, Wishlist |
| B2B | Company Management, Company Switcher, Purchase Order, Quote Management, Quick Order, Requisition List |
Developers can change drop-ins in layers. Most projects only need design tokens and CSS classes for branding. Beyond that, slots add or replace parts of a component, and a drop-in can be extended with new Commerce API calls. Adobe also offers a drop-in software development kit for building your own.
Licensing matters here. Adobe states that drop-ins are available "exclusively to customers with active Adobe Commerce as a Cloud Service or Adobe Commerce Optimizer licenses" and not for other deployment types. Commerce on Cloud or on-premises customers get drop-in support by adding an Optimizer license. The B2B drop-ins arrived in January 2026 and have since moved from beta to stable 1.x releases.
How does it differ from Luma, PWA Studio and a custom headless build?
The main differences are where pages are built, who hosts the front end and what skills you need. Luma builds pages in PHP on the Commerce server. PWA Studio is a React app your team builds and hosts, and a custom headless build uses whatever framework you choose. The Edge Delivery Services storefront serves document-based pages from Adobe's edge and adds commerce in the browser.
| Option | How pages are built | Who hosts the front end | Main skills |
|---|---|---|---|
| Luma | PHP templates on the Commerce server | Runs with Commerce, PaaS only | PHP, Magento theming |
| PWA Studio | React progressive web app | Your team | React, GraphQL |
| Custom headless | Any framework on Commerce APIs | Your team | Your chosen stack |
| Edge Delivery Services storefront | Edge-served HTML plus drop-ins | Adobe | JavaScript, CSS, blocks |
The authoring model is the biggest practical change. On Luma, merchandisers edit content in the Commerce Admin, and layout changes go to PHP developers. On the new storefront, a content author edits a document or uses a visual editor. A page designer maintains the blocks and layouts the author picks from.
A custom headless build gives you full freedom, but you own hosting, performance and every commerce screen. PWA Studio sits in between, with Adobe's React libraries as a starting point. Already running a headless front end? Adobe says Optimizer can plug into it through APIs or drop-ins, with no move to its storefront.
How fast is the Edge Delivery Services storefront?
Speed is Adobe's headline claim. Its storefront product page claims Google Lighthouse scores of 90 to 100. Its Optimizer page says the storefront "starts with a 100 Lighthouse score." Even the developer documentation is headed "Create the fastest storefronts on the web."
Treat those claims as a starting point, not a promise. Adobe's own performance guide says scores "vary with page content, third-party scripts, and test conditions" even on tuned storefronts. It calls each report "a snapshot, not a guarantee of 100 on every run" for that reason.
Tag managers, chat widgets and heavy hero images are common reasons scores fall. That's why Adobe's guide pushes third-party scripts into a delayed phase.
A few mechanics explain the speed:
- Three-phase loading. Pages load in eager, lazy and delayed phases. Third-party tags go in the delayed phase so they don't compete with the main content.
- Checks on every code change. Adobe's Edge Delivery Services guidance describes a GitHub bot that fails a pull request when the mobile Lighthouse score drops below 100. It allows a small buffer.
- Prerendered product pages. Product pages can be built before anyone visits, and Adobe says such pages can load in under one second. Prices, stock and personalized recommendations still load separately so they stay current.
- Catalog Service. Drop-ins read product data from Catalog Service, which Adobe says is up to ten times faster than core Commerce GraphQL.
Measure your own baseline before and after launch. Adobe's launch checklist asks teams to record Web Vitals and Lighthouse baselines and to switch on Operational Telemetry before cutover.
How does authoring work: documents, Experience Workspace and Universal Editor?
Authors build storefront pages in Document Authoring, Adobe's document-based content tool known as DA.live. A visual editor on top lets them edit pages as shoppers see them. For new projects, that visual editor is Experience Workspace. Adobe now marks the Universal Editor as deprecated for Commerce storefronts, though it still supports existing projects and customers who use it.
What authors can do without a developer:
- Write and edit pages as documents, using tables to place content and commerce blocks.
- Edit text and images directly on the rendered page in Experience Workspace.
- Add page metadata, schedule publishing and manage redirects from a spreadsheet.
- Translate content and prepare localized pages.
- Create A/B test variants of a page, once developers have set up the experimentation plugin.
Experience Workspace is in early access, but Adobe says it is "fully supported for Commerce authoring" during that period. It adds AI-assisted authoring and layout, content and split editing modes. Some plugins the Universal Editor has, such as the product picker, experimentation and image variations, are listed as coming soon. If your team depends on those, check before you switch.
Two more points help with planning. Content can also come from AEM Sites instead of DA.live, and Adobe says Optimizer doesn't require AEM Sites. Any new block or layout option is developer work, so budget for a page designer after launch, not only during the build.
What do you need to run Adobe Commerce on Edge Delivery Services?
You need a supported Commerce backend, a license that covers drop-ins, a GitHub repository and an Adobe ID with access to DA.live. What you install depends on your backend.
| Backend | License includes storefront | Setup | Version |
|---|---|---|---|
| Adobe Commerce on Cloud or on-premises | No, add Optimizer for drop-ins | Manual installs | 2.4.8 or later |
| Adobe Commerce as a Cloud Service | Yes | Managed by Adobe | Continuous release |
| Adobe Commerce Optimizer | Yes | Managed by Adobe | Continuous release |
On PaaS, the checklist is longer. You install the Storefront Compatibility Package so drop-ins get the GraphQL they need, and connect Catalog Service through the Commerce Services Connector. Then you add Live Search, Product Recommendations and Data Connection as your rollout needs them.
B2B stores also need the B2B compatibility package, installed after Adobe Commerce B2B. Magento Open Source isn't supported on this storefront at all.
Developers need GitHub, plus the AEM Code Sync app if they skip Adobe's Site Creator tool. If your organization restricts GitHub apps, ask for approval early. For local work they also need Node.js, npm and the AEM command line tool.
Live Search and Product Recommendations depend on storefront events, which this storefront sends through the Adobe Client Data Layer. For the roles you'll need on the team, see our guide to Adobe Commerce experts.
What are the limits of the Edge Delivery Services storefront?
The limits are mostly about URLs, request rates and content files, plus some storefront features that are still arriving. None are unusual, but several affect SEO and migration planning.
- URLs: only lowercase letters, numbers and hyphens, with a 900-character path limit. Product SKUs in URLs must be lowercase, so plan redirects if yours aren't.
- Request rate: Edge Delivery Services caps one shopper at 200 requests per second per host name. Loading hidden UI on every page uses that budget faster.
- Sitemaps and redirects: index, sitemap and redirect files have size and count limits. Large catalogs need several sitemaps.
- Files: uploads through Document Authoring have size limits, so large files belong on a CDN or asset service.
- Rendering: product pages that aren't prerendered load product content in the browser. Adobe suggests choosing which pages to prerender from Google Search Console data, not catalog size.
- B2B features: in June 2026, the company hierarchy block handled a parent and its direct children only.
- Phased migration: Luma Bridge shares sessions with a Luma site, but it's only supported for Edge Delivery Services plus Optimizer plus PaaS.
How do you migrate to the Edge Delivery Services storefront?
Migrate in phases where you can, and treat it as a front-end replatform with real SEO risk, not a theme change. The right path depends on your backend.
- PaaS with Luma: add Optimizer, then move content and marketing pages first. Luma Bridge lets Edge Delivery Services pages and Luma's cart, checkout and account pages share one session on the same top-level domain. You'll need PHP engineers for the bridge, and you move those flows later.
- PaaS with PWA Studio or another headless front end: Adobe says Luma Bridge isn't suitable here. Plan a cutover page type by page type using drop-ins.
- Moving to the cloud service: Luma isn't supported there, so the storefront moves with the backend. Adobe provides a bulk data migration tool and a migration assessment tool for the backend side.
Whichever path you take, protect search traffic:
- Map every old URL to its new one and load redirects before launch.
- Switch to lowercase product URLs before go-live, since changing them later affects indexing.
- Split sitemaps before you turn on prerendering for a large catalog.
- Submit sitemaps in Google Search Console and watch the coverage report.
- Update password reset and other email links to the new URLs.
- Record analytics and Web Vitals baselines, and walk a test order through every tracked step.
If the backend is moving too, our guide to choosing an Adobe Commerce cloud development company covers that side of the work.
Who should consider Adobe Commerce on Edge Delivery Services?
It suits merchants who care about page speed and organic traffic and want content teams to publish without developers. It fits best if you're on, or moving to, the cloud service or Optimizer. For those buyers it's already part of the license, which changes the business case.
It's a strong candidate if:
- You're starting a new Adobe Commerce as a Cloud Service build.
- Your Luma storefront is slow and hard to change.
- You run several brands or regions and want shared blocks with local content.
- Your marketing team wants to test pages without waiting for a release.
Think harder if:
- You're on PaaS and don't plan to buy Optimizer, since drop-ins won't be licensed.
- You rely on custom storefront features that drop-ins don't cover yet.
- You recently invested in a headless front end that already performs well.
- Your team has no front-end JavaScript skills and no budget to build them.
Our Adobe Commerce solutions overview explains how the packages fit together. Our Adobe Commerce B2B guide covers the trade-portal side, including what the B2B drop-ins do.
What should you do next?
Confirm your license first. Then prove the storefront on one real page type before you commit to a full Adobe Commerce Edge Delivery Services rebuild.
- Check whether your contract covers drop-ins, or price an Optimizer license if you're on PaaS.
- On PaaS, confirm you're on Adobe Commerce 2.4.8 or later.
- Build a preview with Site Creator and test a real category page.
- Run PageSpeed Insights on the preview and compare it with your current site.
- Have a content author try Document Authoring and Experience Workspace.
- List storefront features you need that drop-ins don't cover.
- Plan redirects, sitemaps and analytics baselines before you set a launch date.
To find implementers with this experience, use our Adobe Commerce partner finder or the Edge Delivery Services partner finder. Then brief them with the Adobe Commerce RFP template.
Frequently Asked Questions
Is Edge Delivery Services included with Adobe Commerce?
It depends on your package. Adobe's storefront documentation says Commerce Storefront is included with Adobe Commerce as a Cloud Service and Adobe Commerce Optimizer. A license for Adobe Commerce on Cloud or on-premises doesn't include the drop-in components on its own, so those customers add an Optimizer license to use them. Confirm what your own contract covers before you plan the build.
Do I need AEM Sites to use the Adobe Commerce storefront?
No. Pages are normally authored in Document Authoring, also known as DA.live, or in documents stored in Google Docs or SharePoint. Adobe says Commerce Optimizer doesn't require Adobe Experience Manager Sites, although existing AEM Sites customers can use it as the content source for their storefront. In that case, DA.live access isn't required for the project.
Can Magento Open Source use the Edge Delivery Services storefront?
No. Adobe's storefront documentation says Magento Open Source is not supported for this storefront path, and the drop-in components are licensed only to Adobe Commerce as a Cloud Service and Adobe Commerce Optimizer customers. Open Source stores that want a faster front end usually look at PWA Studio, a custom headless build or a move to Adobe Commerce.
What are Adobe Commerce drop-ins?
Drop-ins are npm packages that Adobe publishes under the @dropins scope, each covering one shopper task such as cart, checkout, product details, sign-in, wishlist or, for B2B, quotes and purchase orders. Developers wire them into commerce blocks in the boilerplate, then brand them with design tokens and CSS. Slots and extension points cover deeper changes when configuration isn't enough.
Is the Universal Editor still supported for Commerce storefronts?
Yes, for existing users. Adobe marks it as deprecated for Commerce storefronts but continues to support customers already using it, projects already being built with it and customers whose licenses were based on its features. New Commerce customers are onboarded to Experience Workspace instead, and existing teams can switch whenever they're ready.
How long does it take to launch a storefront on Edge Delivery Services?
Adobe says a team with accounts and a backend ready can get a working preview in less than a day, but a production launch takes much longer. Branding, custom blocks, integrations, redirects, SEO checks, analytics and testing all take time. Treat the preview as a quick proof, then plan the real project around the page types and features you need.