AEM Edge Delivery Services Partners

Document-based authoring versus the Universal Editor

Document-based authoring means content is written in Google Docs or Microsoft Word, with tables used to express structured blocks, and published to the site from there. The Universal Editor is a visual, in-context editing interface where authors click on the rendered page and edit what they see, with content stored in AEM. Both feed the same delivery architecture, but they suit different organizations, and the choice shapes everything about how content work feels.

Document-based authoring wins where speed and volume matter and where the people writing are not CMS users: campaign teams, product marketers, regional offices, anyone who already lives in a word processor. It has almost no learning curve and content can be drafted, commented on and approved in tools people already have. The Universal Editor wins where you need structured content reused across channels, real approval workflow, fine-grained permissions, or where the same content must also feed an app or a second site. Many estates end up mixed, with documents for high-churn marketing pages and the editor for structured evergreen content.

The governance consequences people underestimate

• Permissions become file permissions — in the document model, who can publish is a question about a shared drive folder structure, not about CMS roles, so the drive layout is a governance design task.
• Versioning lives in the document tool — rollback, comparison and audit history come from the document platform's revision history rather than from AEM, which matters if you are regulated.
• Content reuse is weaker in documents — repeated content tends to get copied between files, so plan a mechanism for shared fragments if the same legal text appears in fifty pages.
• Structured output needs the editor — if content must be consumed by an app or a feed with named fields, the document model will fight you.
• Switching later is a migration — moving from documents into the editor or back means re-homing content and re-training, so treat this as a decision, not a default.

What a block actually costs to build

A block is the unit of functionality in Edge Delivery: a piece of markup, CSS and a small amount of JavaScript that turns an authored table or structured element into a rendered pattern such as a hero, an accordion, a card grid or a filtered listing. Most of a site is built from a surprisingly small block library, and a typical initial build lands somewhere between fifteen and thirty blocks depending on how varied the design is.

The cost of an individual block is dominated by three things: how much of it is pure presentation versus fetching data, whether it needs to work in both authoring models, and how much JavaScript it drags in. A static content block is cheap. A block that queries an index, filters results, paginates and updates the URL is an application in miniature and should be estimated as one. Blocks that pull in a third-party library are where performance budgets quietly die, because each one is a payload the rest of the page was designed to avoid.

Mapping an existing design system onto blocks

Design systems drawn for component-based CMS platforms often contain dozens of variants that differ only in spacing or arrangement. Rebuilding each as its own block is the fastest way to a bloated library. The productive exercise before development is a rationalisation pass: lay the existing patterns side by side, and collapse anything that differs only by layout or emphasis into a single block with variants expressed through a section or block option that authors select.

Expect that some patterns will not survive. Carousels with heavy motion, large above-the-fold video, embedded third-party widgets and font-heavy treatments all cost more in this architecture than in a conventional one, and the entire point of the platform is that page weight has a visible price. It is much cheaper to have that argument with the design team during rationalisation than to build the pattern, watch the field metrics degrade, and then negotiate its removal after launch.

Core Web Vitals as field data, not lab scores

A perfect score in a lab tool tells you the page can be fast on a fast machine on a fast connection with no third-party scripts loaded. The measurements that matter are field data: what real visitors on real devices and networks experienced, gathered from actual sessions. Largest Contentful Paint measures when the main content becomes visible, Interaction to Next Paint measures how quickly the page responds when someone taps or clicks, and Cumulative Layout Shift measures how much the page moves around while loading. Field versions of these are reported at the seventy-fifth percentile, meaning three-quarters of visits were at least that good.

The gap between lab and field is almost always caused by things the lab test did not load: consent banners, tag managers, chat widgets, personalization scripts, ad pixels and fonts. Those are added by other teams after launch, which is why a site that shipped fast can be slow six months later with no code change. The only reliable defense is continuous real-user monitoring with an owner, plus an agreed budget that any new third-party script has to fit inside.

Adding analytics and personalization without giving back the advantage

• Load measurement after content — instrumentation should never compete with the main content for the first moments of a page load.
• Count the tag manager, not the tags — a container that lets any team add anything is an uncapped performance liability; require a review before new tags ship.
• Prefer server-side or edge decisioning — deciding a variant before the page reaches the browser avoids the flicker and the blocking script that client-side testing tools introduce.
• Watch layout shift from injected content — banners, badges and personalized blocks that appear late are the usual cause of a Cumulative Layout Shift regression.
• Budget consent tooling explicitly — consent management is often the single heaviest script on a compliant site, so its configuration is a performance decision as much as a legal one.
• Re-measure after every marketing release — the regressions come from campaign activity far more often than from engineering releases.

Keeping search visibility intact through the move

The commercial risk in an Edge Delivery migration is not that the new site is worse, it is that search engines temporarily cannot tell the new site is the same site. Four things have to hold. Every existing URL needs either the same address or a server-side permanent redirect to a genuinely equivalent page. Structured data markup describing products, articles, events or organizations has to be reproduced, because it is invisible in a design review and easy to drop. Canonical tags, hreflang annotations for multi-language sites and pagination signals need to survive. And the crawlable content of each page must match what the old page offered.

Verify this with a crawl comparison rather than a spot check: crawl the old site, crawl the staging version of the new one, and diff titles, meta descriptions, headings, canonical values, structured data blocks and word counts page by page. Discrepancies show up in the hundreds on a large site and almost all of them are fixable before launch. Doing this afterwards means diagnosing a traffic drop while it is happening, which is slower and considerably more stressful.

Running alongside an existing AEM Sites estate

Very few organizations move everything at once, and they do not have to. Edge Delivery can serve a defined set of paths while the existing AEM Sites implementation continues to serve the rest, with the routing handled at the edge so visitors experience one site. The usual sequence is to start with the pages where speed has the clearest commercial value, typically campaign landing pages, high-traffic editorial content and the top of funnel, and leave complex transactional or logged-in journeys where they are.

What has to be shared across the boundary is the part people forget. Navigation, footer, search, consent state and analytics identity all need to behave as one site or the seams become obvious. Assets can continue to come from AEM Assets. Decide explicitly which system owns each shared element, because duplicated navigation maintained in two places will drift within a quarter. Plan the boundary as a deliberate architecture with an owner rather than as a temporary state you intend to clean up later, since these hybrid estates usually last years.

Programs rarely stop at one product. Buyers hiring for AEM Edge Delivery Services often pair it with Adobe Analytics partners , Adobe Brand Visibility partners or Adobe Campaign partners , or review the whole Adobe landscape before committing.