Edge Delivery Services (EDS) represents a genuine architectural shift in how Adobe Experience Manager delivers content — not just a new feature. Content lives in Google Drive or SharePoint, authoring happens in familiar tools, and delivery goes through a globally distributed edge network without a traditional publish tier. For teams that have lived in the AEM Sites / Dispatcher world for years, the mental model shift is real.
Here are the decisions you’ll be making in your first week, and how I’d approach each one.
Document-Based Authoring vs. Universal Editor
The first fork in the road: where does content live?
Document-based authoring puts content in Google Drive or SharePoint. Authors use Google Docs or Word. No AEM UI at all. Franklin’s “blocks” pattern means structured content is expressed through tables in a Word document. It’s fast, familiar, and means zero AEM authoring training.
Universal Editor brings a visual, in-context editing experience similar to traditional AEM Sites page editing, but delivers through the EDS pipeline. Content may live in AEM’s content repository or in an external source, depending on your integration pattern.
In most enterprise contexts, the pressure is toward Universal Editor because:
- Content teams have existing governance workflows tied to AEM
- Legal and compliance teams require approval workflows that live inside AEM
- Personalisation integrations (Adobe Target, Real-Time CDP) are better supported with structured content in the AEM repo
Document-based authoring wins when the content team is small, agile, and technically comfortable. I’ve seen it work beautifully for marketing microsites and campaign landing pages. I’ve seen it become a governance nightmare for regulated content at scale.
The Block Library Is Your Component Library
In the EDS world, “blocks” are your components. Each block is a folder in your project with two files: block-name.js and block-name.css. The block receives a section of the DOM that EDS has parsed from your document structure, and it decorates/enhances it.
This is fundamentally different from AEM Core Components. There is no Sling model. There is no HTL template. There is no dialog definition in a CRX node structure. It’s just JavaScript and CSS running at the edge.
The implications for your component governance process are significant:
- Your component library lives in a GitHub repo, not in CRX/DE
- Versioning is Git versioning — tags, branches, releases
- Component review is a pull request, not a package deployment
- A/B testing a component variant means branching the block folder
Teams that treat EDS blocks like AEM components (designing elaborate config dialogs, complex inheritance hierarchies) fight the framework. Teams that embrace the simplicity ship faster.
CDN Strategy: Franklin CDN vs. Bring Your Own
EDS ships with a Fastly-backed CDN that is genuinely fast and zero-config. For many projects, you’d be done here. But enterprise customers frequently have requirements that push them toward layering their own CDN in front:
- Akamai SureRoute / Ion for specific routing and performance contracts
- WAF rules that must sit at the edge per InfoSec policy
- Custom cache-busting tied to release pipelines
- Regional routing requirements for data residency
If you bring your own CDN, you’re responsible for:
- Configuring origin pull from Franklin’s origin correctly (respect
Surrogate-Keyheaders for cache invalidation) - Forwarding
X-Forwarded-Hostso EDS knows which project config to serve - Not caching error responses — EDS returns transient errors during content publish propagation; caching a 503 for 24 hours will ruin your day
I’ve run EDS behind Akamai in a Sun Life context. The integration works, but the cache invalidation choreography between AEM publish events and Akamai cache purges requires careful design. Plan two weeks for this, not two days.
Performance Budget and Core Web Vitals
EDS’s default block loading pattern is designed for strong Core Web Vitals out of the box. Blocks load lazily, critical CSS is inlined, and JavaScript is deferred. You can break this very quickly by:
- Loading a third-party tag manager that fires 40 scripts synchronously in
<head> - Importing a design system library that ships 200KB of CSS regardless of what’s used on the page
- Adding an authenticated personalisation check that blocks rendering until a session API responds
Define your performance budget before your first block is built. I recommend:
| Metric | Target |
|---|---|
| LCP | < 2.5s on 4G mobile |
| INP | < 200ms |
| CLS | < 0.1 |
| Total JS (first load) | < 150KB gzipped |
Instrument these from day one using Chrome UX Report data and your own RUM implementation. Don’t wait for the performance conversation to happen post-launch.
Content Operations: The Often-Skipped Workstream
Most EDS projects spend 80% of their discovery time on the developer experience and 20% on content operations. It should be closer to 50/50.
Questions to answer before you write a line of code:
- Who approves content changes before they go live? What’s the workflow?
- How do authors handle content that references assets in DAM vs. assets in SharePoint?
- What happens to personalised content variants — do they live as separate documents or as conditions inside a single document?
- How does content rollback work when an author publishes something incorrectly?
EDS does not provide opinionated answers to most of these questions. The flexibility is a feature, but it means your team has to design the content operations process explicitly. Build it before you need it.
My Recommendation
Start with a bounded pilot: a single section of the site (a blog, a product marketing page, a careers section) with a small content team. Use document-based authoring if the team is comfortable with Google Docs or SharePoint. Migrate to Universal Editor if governance requirements demand it — the block code is portable between both authoring modes.
Measure relentlessly, ship iteratively, and resist the urge to replicate your existing AEM Sites architecture inside EDS. The framework rewards simplicity.