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.
ON THIS PAGE
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.
| Dimension | Traditional storefront | EDS-led storefront |
| Initial page experience | Often depends on the origin and application stack | HTML can be delivered from the edge |
| Content publishing | Often tied to CMS workflows and deployments | Document-based publishing can speed up content updates |
| Frontend ownership | Often coupled to Magento theme and module architecture | Independent GitHub-managed frontend |
| Scalability | Requires careful origin and cache scaling | Edge-first delivery reduces reliance on the origin for initial content |
| Core Web Vitals | Can require extensive optimization | Performance 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.


