Performance is no longer a “nice to have” for digital storefronts. Shoppers expect pages to load quickly, marketers want to publish content without waiting for release cycles, and engineering teams need architectures that can scale without constant operational overhead.

Adobe Edge Delivery Services (EDS) addresses all three needs. Originally evolved from Project Franklin and Helix, EDS is now a key part of Adobe’s approach to delivering high-performance digital experiences across Adobe Experience Manager (AEM) and Adobe Commerce.

Understanding Edge Delivery Services (EDS)

Edge Delivery Services is a composable delivery framework that helps deliver content as fast, lightweight HTML through a globally distributed edge network. Instead of relying on a traditional origin-centric application stack for every page request, EDS uses edge delivery and pre-published content to reduce the work required at the origin.

In practical terms, EDS changes three fundamentals of how websites are built and delivered:

  • Authoring becomes document-based
    Content can be authored in familiar tools such as Microsoft Word, Google Docs, and SharePoint, as well as through Adobe authoring experiences such as Universal Editor and Document Authoring.
  • Code lives in GitHub
    Frontend code is managed in a Git repository. Changes can move through Git-based development and deployment workflows without requiring traditional server provisioning for the storefront delivery layer.
  • Pages are delivered from the edge
    Content can be served from geographically distributed edge locations, helping deliver the initial page experience quickly before heavier commerce or personalization APIs are called.

EDS is not simply another CDN. It combines content delivery, edge caching, document-based authoring, and a frontend development model designed to support performance, Core Web Vitals, and SEO.

Why EDS Matters for Commerce Teams

Traditional Adobe Commerce and Magento storefronts often follow a request path like this:

Browser → CDN → Origin (PHP / Magento) → Full page render → Response

Even with Full Page Cache, Varnish, Redis, and CDN layers, the origin can remain a critical dependency for many page types. This becomes more challenging when personalization, catalog complexity, or custom modules reduce cache effectiveness.

An EDS-led storefront changes the delivery sequence:

Browser → Edge → HTML first → Browser loads interactive blocks → Commerce APIs called when needed

That shift can have a meaningful impact on the customer experience.

DimensionTraditional storefrontEDS-led storefront
Initial page experienceOften depends on the origin and application stackHTML can be delivered from the edge
Content publishingOften tied to CMS workflows and deploymentsDocument-based publishing can speed up content updates
Frontend ownershipOften coupled to Magento theme and module architectureIndependent GitHub-managed frontend
ScalabilityRequires careful origin and cache scalingEdge-first delivery reduces reliance on the origin for initial content
Core Web VitalsCan require extensive optimizationPerformance is a core part of the architecture

For both B2C and B2B brands, faster pages can support better engagement, conversion, and organic visibility, particularly on mobile.

Architecture Overview

A typical EDS and Adobe Commerce setup can be viewed as four layers:

1. Content Source

Authors create pages using documents such as Word, Google Docs, or SharePoint, or through Adobe authoring tools. Structured content, such as navigation, redirects, and metadata, can also be managed through spreadsheets and other supported sources.

2. Edge Delivery Services

EDS processes authored content and delivers it through the edge. Content updates can be published quickly without rebuilding a traditional application monolith.

3. Frontend Blocks and Drop-ins

Developers build reusable page “blocks” using JavaScript. For Commerce, Adobe provides drop-in components for experiences such as cart, checkout, product details, and customer accounts.

A block can load the relevant drop-in and connect it to the required Commerce APIs or services.

4. Commerce System of Record

Adobe Commerce remains the source of truth for core commerce operations, including:

  • Product catalog and pricing
  • Promotions and business rules
  • Cart, checkout, and orders
  • Customer accounts and entitlements
  • ERP, OMS, payment, tax, and shipping integrations

In simple terms, EDS accelerates experience delivery while Adobe Commerce continues to manage transactional commerce.

┌──────────────────────────────┐

│  Authors (Docs / AEM / DA)   │

└──────────────┬───────────────┘

               │ publish

               ▼

┌──────────────────────────────┐

│   Edge Delivery Services     │

│  (HTML at edge + GitHub FE)  │

└──────────────┬───────────────┘

               │ page + blocks

               ▼

┌──────────────────────────────┐

│  Browser (drop-ins hydrate)  │

└──────────────┬───────────────┘

               │ GraphQL / REST / Commerce Services

               ▼

┌──────────────────────────────┐

│ Adobe Commerce (system of    │

│ record: catalog, cart, etc.) │

└──────────────────────────────┘

Document-Based Authoring: A Practical Shift

One of the most distinctive capabilities of EDS is document-based authoring.

Instead of relying entirely on a complex CMS page-building workflow, content teams can create and manage content using familiar tools. Developers can then focus on reusable blocks, integrations, and performance rather than handling every page update.

This approach can be especially useful for:

  • Campaign landing pages
  • Category and editorial content
  • Corporate and brand pages
  • Content experiments and frequent updates

For enterprises that need stronger governance around workflows, DAM, localization, and permissions, EDS can also work alongside AEM as a Cloud Service. This allows teams to adopt the architecture gradually instead of taking a “big bang” approach.

Adobe Commerce on EDS: What Changes and What Doesn’t

Moving to EDS changes how the storefront is delivered, but it does not mean replacing Adobe Commerce.

What changes

  • Storefront rendering moves toward EDS-delivered HTML and browser-side blocks
  • Dependence on theme and module-based presentation logic is reduced
  • Performance becomes a core architectural consideration
  • Marketing teams can publish content more quickly

What does not change

  • Adobe Commerce continues to manage pricing, promotions, inventory rules, cart, and checkout
  • Existing backend customizations and integrations can continue to provide business value
  • Order management and other transactional processes remain connected to Commerce and adjacent systems

A useful way to think about it is:

EDS delivers the page experience quickly. Adobe Commerce handles the business logic behind the transaction.

Teams can also pair EDS storefronts with Adobe Commerce services such as Catalog Service, Live Search, and Product Recommendations to support product discovery and catalog experiences at scale.

Technical Building Blocks Developers Should Know

If your engineering team is evaluating EDS, these are some of the concepts worth understanding.

Blocks

Blocks are reusable page sections defined through content. Each block maps to frontend JavaScript that controls how that section is displayed and behaves.

Drop-in Components

Drop-ins are packaged Commerce capabilities for experiences such as cart, product details, checkout, and customer accounts. They can be composed into storefront blocks and connected to Adobe Commerce APIs and services.

GitHub-Centric Development

Frontend code, styles, and block logic are managed through Git. This provides a familiar development workflow for teams while separating storefront development from traditional Magento theme and static-content deployment processes.

API Contracts

GraphQL, REST, and Commerce Services become important interfaces between the frontend and backend. Clean API design, appropriate payload sizes, and efficient data fetching become increasingly important in a decoupled architecture.

Performance as Architecture

EDS encourages teams to consider performance from the start. Metrics such as Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) should be part of the architecture and development process, not something addressed only after launch.

Implementation Considerations and Common Pitfalls

EDS can deliver significant benefits, but adopting it is an architecture change, not simply a theme upgrade.

1. Don’t Migrate Everything on Day One

Start with high-traffic content or selected commerce journeys. A hybrid approach can allow teams to introduce EDS gradually while existing Commerce or AEM pages continue to serve other experiences.

2. Reassess Custom Storefront Logic

Heavy Magento theme customizations, RequireJS widgets, and tightly coupled UI logic may need to be redesigned as reusable blocks or drop-in extensions.

3. Keep Commerce Ownership Clear

Pricing rules, B2B company structures, custom checkout logic, and ERP-driven business rules should remain in Commerce or carefully designed middleware rather than moving into the document layer.

4. Define the Authoring Model

Decide early how your content teams will work. This could include Word or Google Docs, Document Authoring, Universal Editor, or a combination of approaches.

The choice can affect governance, localization, workflows, and publishing expectations.

5. Invest in Observability

Measure Core Web Vitals, edge delivery, API latency, and conversion performance together. Fast HTML does not automatically mean a fast customer experience if the APIs behind interactive commerce features are slow.

6. Keep SEO and Content Quality in Focus

EDS can support strong technical performance and crawlability, but it does not replace good SEO strategy. Information architecture, structured data, internal linking, and relevant content still require ongoing attention.

Who Benefits Most from EDS?

EDS can be a strong fit if:

  • Your storefront struggles to consistently meet Core Web Vitals targets
  • Marketing teams need to publish content faster
  • You want a composable frontend without replacing Adobe Commerce
  • You are modernizing AEM and Commerce together
  • You need strong global performance without relying entirely on origin infrastructure

EDS may be a lower priority if your main challenges are backend-related, such as complex pricing, ERP synchronization, or order orchestration, and your current storefront already meets your performance goals.

In those cases, improving the backend architecture may deliver greater value before changing the frontend delivery model.

A Pragmatic EDS Adoption Roadmap

Assess

Start by measuring your current storefront. Look at Core Web Vitals, cache performance, content publishing time, API response times, and the amount of custom storefront logic you currently maintain.

Pilot

Start with a focused EDS experience, such as brand pages, landing pages, or selected product and category experiences. A hybrid implementation can reduce migration risk.

Integrate Commerce

Connect the storefront to Adobe Commerce APIs and Commerce Services. Validate important journeys such as product discovery, cart, checkout, tax, and customer account experiences.

Operationalize Authoring

Train content teams, define reusable blocks, and establish clear publishing and governance processes.

Expand

Move additional templates and traffic to EDS gradually. As confidence grows, retire legacy presentation code where appropriate.

Optimize

Continue monitoring performance, API payload sizes, Core Web Vitals, and customer behavior. Treat optimization as ongoing product work rather than a one-time migration task.

Conclusion

Adobe Edge Delivery Services gives Adobe Commerce businesses a way to deliver faster, more flexible storefront experiences without replacing their core commerce platform. But getting the architecture, integrations, and migration strategy right is key to making EDS work.

As an experienced Adobe Commerce development partner, Klizer helps businesses modernize their storefronts through our Adobe Commerce services, from EDS implementation and frontend development to integrations and performance optimization.

Planning to modernize your Adobe Commerce storefront? Contact us to explore the right approach for your business.

Picture of MS Alavudeen
BLOG BY

MS Alavudeen

Mohamed Sheik Alavudeen is a Senior Developer at Klizer with over 9 years of experience in Adobe Commerce (Magento) development and enterprise system integrations. He specializes in building scalable, secure, and high-performance ecommerce solutions, with expertise in Adobe Commerce Cloud, custom module development, App Builder, middleware, and Epicor Prophet 21 (P21) integrations.
Fix What’s Holding You Back

With 20+ years behind us, we build AI-powered ecommerce experiences that help businesses scale faster and stand out online.

© Copyright 2026 Klizer. All Rights Reserved

Scroll to Top