Adobe Commerce Integration in Edge Delivery Services: Building the Next Generation Storefront

Key Takeaways

• Edge Delivery Services delivers storefront content directly from global edge nodes.
• Adobe Commerce integrates using drop-ins, Catalog Services, and App Builder.
• Document-based authoring simplifies workflows using Google Docs and Sheets.
• Performance stays consistent through automated Lighthouse checks in pipelines.
• Hybrid migrations allow gradual movement from existing Commerce frontends.
• EDS unifies content and commerce across Adobe’s wider ecosystem.

If you told an Adobe Commerce developer, they’d soon build storefronts using Google Docs, lightweight JavaScript, and a delivery layer that serves pages from servers practically sitting next to the user, they’d probably laugh and get back to debugging Knockout files. But that’s exactly where Adobe has steered the ship.

Edge Delivery Services isn’t another experimental framework. It’s Adobe’s new, fully backed path for building fast, flexible storefronts without the heavy frontends Commerce developers are used to. Instead of wrestling with themes and complex layers, EDS delivers content through the edge, uses simple building blocks, and lets authors work in everyday tools.

The surprising part is how naturally it fits with Adobe Commerce. Same APIs, same services, completely different experience building on top of them.

From Luma and PWA Studio to Edge Delivery Services

Before you can really appreciate Edge Delivery Services for Adobe Commerce, you have to understand the frontend path that led here.

Luma: Complete coverage, dated approach

When Magento 2 (Adobe Commerce and Magento Open Source) launched, the default frontend was Luma. A lot of merchants still run on Luma even after many years and major shifts in frontend technology.

Why it stuck around:

• It supports essentially every Magento 2 feature that has been added over the years
• That includes things like multiple wishlists, B2B features such as requesting a quote, Page Builder content, and even capabilities like AR Viewer support

The tradeoff is obvious:

• It is relatively slow compared to modern storefront expectations
• It uses older technologies like Knockout.js
• The UX no longer feels aligned with modern eCommerce standards

So Luma is highly compatible with Adobe Commerce features, but the performance and developer experience leave a lot to be desired.

PWA Studio: Modern patterns, more complexity

Next, Adobe invested in PWA Studio as a way to bring progressive web app patterns into the Commerce ecosystem.

PWA Studio:

• Provides good coverage of Adobe Commerce B2C and B2B features
• Integrates with Page Builder
• Offers solid performance and PWA benefits like app-like look and feel, offline capabilities, and access to device features through the browser

At the same time, it is also:

• A fairly complex framework to extend
• A significant investment from a development effort perspective

As a result, third-party storefronts gained popularity while Adobe prepared its next move for a more universal, suite-wide approach to frontends.

Edge Delivery Services

Edge Delivery Services (EDS) is described as the next-generation storefront for Adobe Commerce.

It was introduced first for Adobe Experience Manager customers, and has now been extended to cover:

• Sites (content)
• Assets (like images)
• Forms
• Screens (for in-store digital displays)
• Ecommerce experiences

In other words, it is intended to act as a universal frontend solution across the Adobe product suite, including Adobe Commerce.

What Edge Delivery Services Brings To Adobe Commerce

So, what does EDS actually change when you are integrating Adobe Commerce?

A CDN native, edge-focused storefront

The “edge” in Edge Delivery Services refers to the outermost boundary of Adobe’s network from the end user’s point of view. Content is served and processed as close as possible to the user to minimize latency and improve scalability.

Practically, that means:

• All access to the storefront is served through a CDN
• Processing is distributed across many edge nodes, so one user’s activity is less likely to slow down another user
• Performance becomes a default property of the platform instead of something teams endlessly chase

Adobe has adopted an internal principle for EDS development called “Keeping it 100”. After every change, Lighthouse performance is measured, and the goal is to keep the score at 100. You start from a perfect score, and then measure any regression introduced by customizations.

That makes staying fast significantly easier than trying to drag a slow storefront up to acceptable performance later.

A truly headless, framework-agnostic model

From Adobe’s own description and the Blue Acorn ICI experience, Edge Delivery Services is treated as true headless:

• The EDS deployment process and boilerplate are detached from Adobe Commerce and AEM themselves
• It does not take a strong opinion on how you connect to Adobe Commerce or AEM
• Integration happens through connectors and “drop-ins”, not through tight coupling to a specific platform framework

On the frontend, one of the core foundations is simplicity:

• Vanilla JavaScript
• HTML
• CSS

That reduces the learning curve for developers and allows organizations to staff projects with more general frontend talent instead of only deep, platform-specific experts.

For Adobe Commerce integration, the building blocks include:

• Catalog Services
• App Builder for custom applications and integrations
• GraphQL, which remains a critical part of how Adobe Commerce is accessed programmatically

Composability at the Core: Boilerplate, Drop-Ins, SDKs

On the Vaimo side, Edge Delivery Services for Adobe Commerce is framed around three composable layers.

1. Boilerplate

This is the base technology that accelerates the development of an Edge frontend. It gives you:

• A starting point for your storefront implementation
• Patterns and structure that are aligned with the way EDS expects content and blocks to be delivered

You are not reinventing the wheel every time you start a new storefront.

2. Drop-in components

Drop-ins are readymade components for core eCommerce experiences, such as:

• Product Listing Page (PLP)
• Product Detail Page (PDP)
• Cart
• Checkout

These are used to build the core store experience on top of Adobe Commerce data and services, while still benefiting from the edge-optimized delivery model.

Adobe is actively rolling out new commerce storefront drop-in capabilities, and partners are encouraged to stay close to Experience League documentation to track what is available.

3. SDKs for custom development

SDKs allow teams to develop custom frontend components while still fitting into the EDS ecosystem.

Combined with APIs from Adobe Commerce, Catalog Services, and App Builder, SDKs make it possible to:

• Extend the store experience beyond the base drop-ins
• Integrate bespoke functionality or unusual presentation needs
• Still keep everything deliverable through edge-optimized infrastructure

From an integration perspective, you can think of EDS as:

• Boilerplate sets the scaffolding
• Drop-ins cover the standard eCommerce flows
• SDKs plus Adobe Commerce services handle the custom or complex requirements

The Architectural Role of Edge Delivery Services with Adobe Commerce

The Adobe webinar describes a helpful mental model for EDS architecture.

A content parsing and translation engine

Historically, Edge Delivery began as an engine designed to:

• Take documents authored in tools like Microsoft Word or Google Docs
• Parse and translate them into a normalized format (internally, markdown)
• Regenerate that as HTML for the storefront

This creates a translation layer for content coming from multiple sources in the wider Adobe ecosystem and beyond.

Today, that vision extends further:

• Content can originate from AEM
• It can live in Word documents on SharePoint
• It can even originate from Adobe Commerce
• EDS can normalize all of these into a consistent structure that is then rendered at the edge

For commerce teams, this matters because it unifies content and commerce as part of one supply chain, rather than forcing everything through a single CMS or frontend framework.

A bridge between AEM and Adobe Commerce

One of the recurring themes in the Adobe webinar is that bridging enterprise-grade platforms like AEM and Adobe Commerce has historically produced mixed results.

Edge Delivery Services positions itself as:

• The common bridge layer that does not dictate a specific way of connecting to AEM or Commerce
• The infrastructure for deploying applications that consume both content and commerce APIs
• A way to shift the conversation from infrastructure constraints to API surfaces and experience design

Instead of being locked into a platform-specific frontend framework, teams can:

• Use more generic developers with JavaScript skills
• Focus on solution design and API integration
• Reuse components and patterns across multiple platforms, not just Adobe Commerce

Content and Commerce Together: Authoring and Workflow Changes

Integration is not only about APIs and frontend code. EDS also changes how content that supports commerce is produced and shipped.

Document-based authoring with real tools people already use

Edge Delivery Services supports document-based authoring using tools like:

• Google Docs and Sheets
• Microsoft Word and Excel

Teams can create content in these tools and then deliver it directly to the storefront via EDS.

Some key capabilities:

• Images and videos
  • Images can be dragged and dropped into documents and used directly
  • Videos can be uploaded to Slack, then referenced via URLs in the document
• Links and sections
  • Documents can contain both external and internal links, with internal links adapted to the website domain
  • Sections can be marked using horizontal lines or triple hyphens in docs, which map to sections on the website
• Metadata and SEO
  • Metadata can be defined in simple tables that EDS understands as SEO related configuration
• Structured data in spreadsheets
  • Content in spreadsheets can automatically be turned into an API
  • That API can then be used for things like data tables, navigation, or feature comparison blocks
  • This effectively turns spreadsheets into a light headless CMS for structured website content

For Adobe Commerce, this means marketing and merchandising teams can work in familiar tools while still feeding structured data into the storefront.

Previewing, publishing, and approval workflows

EDS also introduces changes to how content moves from draft to production.

• Authors can preview and publish using Sidekick, which can be installed as a bookmarklet or browser extension
• Sidekick can be preconfigured per project so that authors simply use shared links and do not have to worry about deeper config
• Teams can comment on documents, view revision history, and even publish previous versions directly from Google Docs

For larger organizations, Adobe also highlights:

• Using Workfront for content approval workflows
• Integrations between SharePoint, Google Drive, and Workfront for document management and task assignment

When this is combined with Adobe Commerce:

• Commerce teams can keep a separate cadence for core commerce code changes
• Marketing teams can iterate on content and campaign pages more quickly
• Both streams can be deployed via EDS without stepping on each other

Operational Impact: Releases, Performance, And Accessibility

The Blue Acorn ICI experience gives a practical view of how EDS changes day-to-day operations for Adobe Commerce implementations.

Decoupled release cadences for content and commerce

One of their clients experienced a significant mindset shift when they realized they could:

• Separate commerce code releases from content-centric releases
• Avoid blending promotions, new product enhancements, and general marketing content into a single, overloaded release schedule

With Edge Delivery Services:

• Commerce content, like new product promotions and offerings, can follow its own release lane
• Marketing landing pages and similar content can follow another
• Teams move from a single congested release lane to multiple “swim lanes”

This separation becomes particularly powerful in Commerce environments where promotions and content updates are constant.

Automated performance and accessibility checks

Blue Acorn ICI also migrated its own website to Edge Delivery Services. One of the biggest operational changes they saw was tied to the CI pipeline:

• GitHub Actions are integrated so that for every pull request, Lighthouse scans run automatically
• Each PR shows whether the change has negatively impacted performance, SEO, or accessibility
• Automated accessibility scans run at the PR level, not only in big test cycles

Because EDS starts from a 100 Lighthouse score, teams can:

• Immediately see when a customization drags performance down
• Treat performance and accessibility as continuous constraints, not nice-to-have goals “for later”

This is especially important in commerce, where high performance and accessibility are directly linked to conversions and regulatory expectations.

Real Commerce Integration Scenarios with Edge Delivery Services

The webinar also shares concrete ways EDS is already being used alongside Adobe Commerce.

Reusing React-based product experiences

One client had a very customizable product experience:

• They were on an Adobe Commerce monolith with Page Builder
• Their customizable product flows were built as micro React applications
• These micro apps were served on top of the Magento frontend

With Edge Delivery Services, the team:

• Built pipelines to compile those React applications into JavaScript
• Served those compiled applications through EDS instead of the old monolith frontend
• Leveraged EDS performance while reusing existing React work

In effect, they could:

• Take React applications built for an Adobe Commerce frontend
• Translate them into an Edge Delivery frontend
• Serve the exact same React applications through EDS

This makes EDS not only a content authoring and delivery solution, but also a powerful way to host application-level experiences around commerce.

Partial lift and shift: hybrid models

Edge Delivery Services does not force an “all or nothing” migration.

Blue Acorn ICI describes different patterns they see:

• Starting with a blog
  • A merchant without a blog wants to drive more traffic and sales
  • They set up a new blog channel on EDS as a new sales entry point
  • The main commerce site can remain on its existing frontend while the blog proves out the EDS benefits
• Hybrid “lift and shift”
  • Home page, marketing pages, catalog pages, and product pages are moved to Edge Delivery Services
  • Cart and checkout remain on Magento for now because of heavy customizations
  • Over time, more of the experience can move across once it makes sense

This flexibility is particularly useful for Adobe Commerce customers who:

• Have a heavily customized monolith today
• Want to improve performance and content workflows
• Cannot justify a full frontend replacement in a single step

How Partners and Teams Should Approach Enablement

Adobe is quite explicit about how partners should get ready for Edge Delivery Services with Adobe Commerce. The enablement recipe is grouped into three main parts.

1. Foundational enablement

Teams should:

• Stay up to speed with Experience League documentation for commerce drop-ins
• Follow what Adobe engineering and product teams are publishing about Edge Delivery Services
• Build competency in frontend development specifically for EDS-based storefronts

This is the theory and conceptual grounding.

2. Hands-on experience

Enough theory, you then need to build things.

Recommended paths include:

• Performing a lift and shift of your own sandbox or demo storefront to Edge Delivery Services
• Using internal or low-risk projects as a playground to learn how commerce drop-ins and EDS concepts work in practice
• Participating in Adobe’s VIP motion, where eligible customer projects can get support from Adobe’s engineering teams for code delivery of commerce storefronts

3. Translating into practice and sales

Finally, partners need to:

• Update how they scope and staff projects, given the shift to generic JS skills and headless patterns
• Adjust sales narratives away from “out of the box Luma demo” thinking toward fit-for-purpose storefronts built on EDS
• Acknowledge that EDS does not yet replicate 100 percent of Luma’s out-of-the-box feature coverage, and instead lean into its flexibility and performance benefits

Why Edge Delivery Services Matter for Adobe Commerce Long Term

Putting all of this together, the integration of Adobe Commerce into Edge Delivery Services is not a cosmetic layer. It is a multi-layer change in how commerce experiences are delivered:

• Technologically
  • CDN native, edge optimized delivery
  • Vanilla JS, HTML, and CSS-based frontends
  • Boilerplate, drop-ins, and SDKs for composable storefronts
  • Deep use of Catalog Services, App Builder, and GraphQL for Commerce integration
• Operationally
  • Separate swim lanes for commerce code and content changes
  • CI pipelines with Lighthouse and accessibility checks on every pull request
  • Hybrid migration paths rather than big bang rewrites
• Organizationally
  • Shift from platform-specific frontend roles to more generic engineering talent
  • Easier reuse of components and frameworks from other ecosystems
  • A more flexible way to connect AEM, Adobe Commerce, and other systems

Edge Delivery Services is positioned by Adobe as a long-term, sustained area of investment. Content and commerce integrations across the Adobe ecosystem will increasingly center around this technology.

For Adobe Commerce teams, that means:

• Treating EDS as the next-generation storefront model, not just a nice optional integration
• Using it to gradually unwind old monolithic frontends while preserving Commerce investments
• Leveraging document-based authoring, edge performance, and composability to build storefronts that actually match modern expectations

If your current Adobe Commerce frontend feels stuck between feature coverage and performance compromises, Edge Delivery Services is the path Adobe is opening to reconcile the two and give you room to design the storefront you actually want, instead of endlessly patching the one you inherited.

Conclusion

Edge Delivery Services gives Adobe Commerce a modern storefront path that focuses on speed, simplicity, and flexibility. Instead of working inside heavy frontend frameworks or tightly coupled themes, teams can build with vanilla JavaScript, reuse existing components, and deliver everything through a globally optimized edge layer. It also reshapes operations by separating content releases from commerce deployments and enforcing performance and accessibility through automated checks.