AEM Edge Delivery Services: How It Works, What It Replaces, and When Not to Use It

Edge Delivery Services is the most significant change to how Adobe Experience Manager delivers a website since Dispatcher. It is also the part of the AEM stack most often described in marketing terms and least often explained. This page does the explaining, including the cases where it is the wrong answer.

What EDS actually is

Adobe describes Edge Delivery Services as "a modern content delivery framework that re-imagines how websites are built and delivered, optimizing for speed, simplicity, and scalability." Concretely:

• It replaces the Publish and Dispatcher tier. Rendering and delivery move to an Adobe-managed CDN.
• Code deploys from GitHub. A push to your repository publishes. There is no content package, no Cloud Manager pipeline for the front end, no build artefact to promote.
• The front end is plain HTML, modern CSS and vanilla JavaScript. No transpilation, no bundler, no framework requirement. This is a deliberate constraint, and it is the mechanism behind the performance claim rather than a stylistic preference.
• It is composable SaaS, and it coexists with AEM Sites — the two can serve the same domain and consume each other's content.

The two authoring models

This is the decision that shapes everything else, and the two options suit very different organisations.

Document-based authoring

Content lives in Microsoft Word on SharePoint, or in Google Docs on Google Drive. Authors write in the tool they already use; publishing is a direct action from the document. There is no authoring UI to learn and no copy-paste step.

Suits: marketing teams that already draft in Word or Docs, high-volume content operations, organisations where the authoring UI was a barrier rather than a benefit, and sites where content is mostly prose and images.

Does not suit: complex structured content, heavy governance and multi-stage approval workflows, deep content reuse and fragment architecture, or authors who need to see the rendered page while editing.

In-context editing with the Universal Editor

A WYSIWYG editing experience inside AEM, editing the live page, retaining AEM's workflows, permissions and governance.

Suits: organisations that need AEM's governance model, structured content, or an editorial process with real approval gates — which is most enterprises, and the reason they bought AEM.

The two are not exclusive. A site can use document-based authoring for the campaign and blog sections and the Universal Editor for the governed, structured parts.

The performance argument

Adobe's stated target for EDS is a 100 Lighthouse score, and the architecture is designed backwards from that: no framework runtime to hydrate, no bundle to parse, content served from an edge CDN, and a rendering model that gets meaningful content on screen before JavaScript matters.

This is worth taking seriously for two reasons beyond user experience:

• Core Web Vitals are a measurable, contractable outcome. In enterprise CMS work you can rarely put a before-and-after number in front of a CMO. Here you can.
• Adobe positions EDS as optimised for SEO and for generative-engine optimisation — how LLM-driven search surfaces read and cite a page. Clean semantic HTML with content in the initial response is exactly what both crawlers and LLM retrieval prefer.

A caution worth stating: a 100 Lighthouse score is a lab measurement on a synthetic profile. It is a good proxy and it is not the same as your field Core Web Vitals, which depend on your images, your third-party tags and your real users' devices. A marketing team that adds four tag-manager scripts will lose the score regardless of the platform.

What you give up

• Your existing front-end stack. If your site is React or a component library built over years, EDS is a rebuild, not a migration. The plain-HTML constraint is not negotiable — it is the product.
• Dispatcher-level caching control. You are on Adobe's CDN with Adobe's model.
• Some familiar AEM authoring affordances, particularly if you choose document-based authoring.
• Framework ecosystem. No React component library, no npm build pipeline for the delivery layer.

When EDS is the wrong choice

Said plainly, because the case against is harder to find than the case for:

• Your site is a web application, not a content site. Heavy interactivity, authenticated state, complex forms — EDS is built for content delivery and fighting it is expensive.
• You have just finished a front-end rebuild. The payback on rebuilding again is poor and the LCP gain may not clear the cost.
• Your content is deeply structured and reused. Fragment-heavy architectures fit the Universal Editor path, and document-based authoring badly.
• Your governance is strict and multi-stage. Document-based authoring will not satisfy a legal review workflow.
• You are mid-migration to Cloud Service. Do one thing at a time. EDS can be adopted progressively afterwards, section by section, at far lower risk.
• Performance is not your problem. If your Core Web Vitals are already green, EDS buys authoring-model change, not speed — decide on that basis instead.

How to adopt it progressively

Because EDS and AEM Sites coexist on a single domain and can consume each other's content, the low-risk path is incremental:

1. Pick one section that is content-heavy, performance-sensitive and low-governance — usually the blog, resource centre or campaign landing pages.
2. Build it on EDS. Measure real Core Web Vitals before and after, in the field, not just in Lighthouse.
3. Decide on evidence whether to extend it, and to which sections.

This also gives your team a real project to learn the block-development model on, before it is on the critical path for the homepage.

What we do

Block development, document-based authoring and Universal Editor setup, GitHub deployment wiring, progressive adoption planning alongside a Cloud Service migration, and Core Web Vitals work measured in the field rather than in the lab. Where we think EDS is the wrong answer for your site, we will say so and explain why. See Adobe Experience Manager services.

Common questions

Is Edge Delivery Services the same as AEM as a Cloud Service?

No. EDS is a delivery framework that runs alongside AEM as a Cloud Service and replaces the Publish and Dispatcher tier. You still have AEM; what changes is how pages are built and served.

Can we use EDS and AEM Sites together?

Yes. They can serve the same domain and pages from either can consume content from the other, which is what makes progressive adoption practical.

Does EDS really deliver a 100 Lighthouse score?

That is the design target and it is achievable on a clean implementation. It is a lab score. Third-party tags, unoptimised images and heavy embeds will erode it the same way they erode any platform's score.

Do we have to author in Word or Google Docs?

No. Document-based authoring is one option; in-context editing with the Universal Editor is the other, and it keeps AEM's workflows and governance. Both can run on the same site.

Does EDS need Cloud Manager?

The front end deploys from GitHub rather than through a Cloud Manager pipeline. Cloud Manager remains in play for the AEM application itself. See Cloud Manager CI/CD pipelines.

Is EDS cheaper than AEM Sites?

It removes the Publish and Dispatcher tier and the operational cost attached to it, but it is licensed as part of your Adobe agreement and it carries a front-end rebuild cost. Treat it as an architecture decision, not a cost-reduction one. See what AEM costs.

---

Related reading: Adobe Experience Manager services · AEM 6.5 end of life · AEM cloud migration