Document - Based Content Authoring in Adobe Edge Delivery Services vs Classic AEM Sites: DevHandler’s Experience
DevHandler is a new company, and from day one we decided to build our website using the latest Adobe Edge Delivery Services (EDS) with document-based content authoring. Our public site was created from scratch and launched in April 2025 — we did not have any previous site to migrate. Why is this significant? Because the DevHandler team has 10+ years of deep Adobe Experience Manager (AEM) expertise, and our early choice to embrace EDS was a conscious strategic move. In doing so, we send a message to the market that we champion the modern AEM stack (a Git-first approach, document-based authoring, and Core Web Vitals optimization) and are eager to implement cutting-edge solutions.
In this article, we share our experience of building a site with document-based authoring in Adobe EDS and compare it to the traditional AEM Sites approach. We’ll discuss how the new approach works, the benefits it brought to our team and business, and why we intentionally chose it over the classic model.
What is Document - Based Authoring in Adobe EDS?
Adobe Edge Delivery Services (EDS) is a composable cloud platform from Adobe for rapid website development and content delivery, supporting multiple content authoring paradigms. One of these paradigms is Document-Based Authoring, which essentially allows you to create and edit website content in familiar documents (like Google Docs or Microsoft Word) instead of using AEM’s traditional authoring interface. Formerly known under codenames like AEM Franklin or Project Helix, this document-driven approach integrates with the AEM Cloud infrastructure and automatically transforms document content into ready-to-serve web pages.
In our case, each page of the DevHandler site is represented by a document in Google Drive, structured in a specific way. By using special tables in the document (so-called “blocks”), we define the page layout, components, dynamic elements, metadata, and even content localization. The EDS platform connects to these documents, converts them into HTML (with an intermediate Markdown representation), and delivers them to end users via a global CDN network. Thanks to edge caching, pages load virtually instantly for users around the world.
Classic AEM Sites: How It Used to Be
To appreciate the advantages of the new approach, it’s worth recalling how content authoring works in a classic AEM Sites setup. Traditionally, content is created and edited directly in the AEM Author environment – via AEM’s TouchUI interface using components, templates, and other tools. This is a powerful and flexible system, but it tightly couples content with the project’s codebase. For example, in the past even a small text or image change on the site often required going through a full build and deployment cycle – especially if that content was part of a component or template. Content editors had to work in AEM’s specialized UI, and developers were responsible for maintaining the components and the underlying content structure.
As a result, minor updates could require developer involvement or wait until the next release. The content update process was slower and dependent on development cycles. Additionally, dynamically rendering pages in classic AEM carries some performance overhead – each page is assembled from the JCR repository on the fly, which adds server load. For large, complex projects this approach is justified by powerful personalization and integration capabilities, but for a smaller marketing site like ours it can be overkill in complexity and resources.
The document-based approach addresses many of these issues in a completely different way. Content is decoupled from the AEM instance – it can be updated more quickly and flexibly, without a full deployment or developer intervention each time. Let’s dive into why we opted for this new path.
Why We Chose EDS with Document - Based Authoring
Why did DevHandler opt for Edge Delivery Services with Document-Based Authoring, given our extensive experience with “classic” AEM? There are several reasons:
1. Speed and agility of content updates.
The document-driven process greatly simplifies site maintenance. Our content team can work in the familiar Google Docs environment without touching code or needing access to AEM Author. A new page or article can be prepared in a document and, after review, published to the site without a full code deployment. Content changes are no longer tied to developer release cycles – updates can go live several times a day if needed.
2. Improved collaboration between authors and developers.
We have completely separated content work from code work. Editors focus on writing text and managing media, while engineers concentrate on functionality, design, and integrations. Developers no longer need to support complex authoring interfaces or content structures in AEM – instead, they work with clean code in a repository (a Git-first workflow). Conversely, content managers aren’t dependent on developers for daily updates. This decoupled workflow removes bottlenecks and accelerates the publishing process.
3. Performance and Core Web Vitals.
The Edge Delivery Services architecture is all about high performance. A site built from static content (generated from documents) loads extremely fast. Our front-end has been optimized for Google’s key metrics – the Core Web Vitals. The results speak for themselves: Lighthouse scores – Performance: 99, Accessibility: 100, Best Practices: 100, SEO: 100. For a modern website, this is critical – speed, clean HTML structure, and accessibility directly impact SEO and user experience. The new approach allowed us to achieve essentially top-tier page quality metrics from the outset.
4. Strategic innovation.
As Adobe consultants, we wanted to showcase the latest technology stack in action. By choosing EDS over the traditional AEM Sites for our own site, DevHandler underscored its expertise and innovative spirit. We know the classic AEM stack inside-out, and that’s precisely why we can appreciate the benefits of the new approach. This was a signal to the market that we embrace modern solutions – cloud-native, Git-driven, and highly efficient. In other words, we’re not just talking about cutting- edge approaches; we’re implementing them ourselves.
How Our EDS - Powered Site Works Under the Hood
Now let’s look in detail at how the DevHandler site is implemented on the Adobe document-based stack. The architecture consists of two main parts: the code (the site’s presentation logic) and the content (documents with the site’s copy). These come together via the Edge Delivery cloud platform.
Codebase. We used Adobe’s official AEM Helix boilerplate to kickstart the project – a template repository that provides the baseline structure for an EDS site. Our GitHub repository contains all the scripts and styles needed to render the content, including the implementations of blocks (special JavaScript modules that define how a given block in a document is transformed into HTML), style sheets (CSS, including defined design tokens for consistent design), configuration files, and so on. To connect this repository with Adobe’s infrastructure, we set up integration through Cloud Manager – every commit to the main branch automatically builds and deploys a new version of the site to Adobe’s servers (a staging environment for preview). This is enabled by the AEM Code Sync service, which synchronizes our Git repository with the Edge Delivery cloud environment. Connecting the content. We store our content in cloud storage – we chose Google Drive as the content source. In a dedicated Google Drive folder, we have all the documents corresponding to site pages (including both the Ukrainian and English versions). To let Edge Delivery know where to fetch content, we added a configuration file called fstab.yaml to our repo (used in the Helix 4 architecture). In it, we map the site’s content to our Google Drive folder:
mountpoints: /: https://drive.google.com/drive/folders/<ID_of_our_content_folder>
This entry basically says: “all requests to the root of the site get content from the specified Google Drive folder.” We shared that folder with Adobe’s service account (helix@adobe.com), which allows the EDS platform to read the documents. After updating fstab.yaml, we committed the changes – and the service kicked in, connecting our documents as the content source.
Structuring pages in documents. As mentioned, each Google Doc corresponds to a page on the site. It’s important to follow a certain structure in the documents so that the system can correctly interpret the content. We created document templates using tables, where the first column can serve as the block name and the second column contains the content. For example, to define a hero banner on a page, the document includes a table like:
In this example, the first row’s first cell has the text “Hero” – this signals to our system that this section should be rendered as a hero banner. The subsequent rows contain key-value pairs: Title, Description, Image. Our custom scripts (block modules in the codebase) recognize this structure and generate the corresponding HTML – a <section class="hero"> with the heading, text, and background image. We’ve implemented similar patterns for other section types: text content blocks, image galleries, lists, forms, etc. Everything is driven by the content in the document. Developers can define a new block type in code (say, “Testimonial” or “FAQ”) with its styling and behavior; then content managers simply insert a table with that block name in a document and fill in the fields – the new component will appear on the site without additional AEM-side development. This approach gives us a lot of flexibility to create rich layouts by combining content and code in a loosely coupled way.
Content structure. Because the site is currently English-only, each Google Doc maps directly to a single page. Page layout is driven by simple table-blocks (hero, columns, cards, etc.), so authors just drop the right block name into the first cell, fill in the fields, and publish. If we ever add more languages, EDS can scale effortlessly—separate docs per locale or JSON-based string collections are both viable—but for now the workflow stays lean:
one document → one page → instant publication.
Design tokens and styling. To ensure a cohesive look and feel, we implemented a design tokens system. In a configuration file, we defined our core style constants: brand colors, fonts, heading sizes, spacing values, etc. These token values are used in both the CSS and, to some extent, in the documents themselves (for example, color names or style classes correspond to token-defined values rather than arbitrary styles). This means that even if content authors add a new block or element, it is automatically styled according to DevHandler’s design system. Consistency is maintained centrally, rather than manually tweaking styling in each document.
Preview and publish workflow. Once the code is set up, content is connected, and the initial page documents are created, we had a working site that updates almost in real time. Editors can write or edit articles in Google Docs and save them – changes are almost immediately ready to preview on the staging version of the site. We use the AEM Sidekick browser extension for working with our Edge Delivery project. Through the Sidekick, our content managers can refresh the content on the preview environment at any time by clicking a Reload button. The site in preview mode is available at a development URL (of the form https://<branch>--<repo>--<org>.hlx.page), so we can verify everything looks correct. When a page is ready to go live, we simply hit Publish in Sidekick – and Adobe EDS publishes the new content to the production domain (devhandler.com, which corresponds to an ...aem.page address under the hood). There are no manual deployments – it all happens literally in seconds. This process is drastically different from classic AEM, where publishing content involves replicating it from an author instance to a publish instance and depends on the server’s state. In EDS, it’s all implemented as a serverless CDN: a published page is a static HTML file that is instantly globally cached.
Results and Conclusions
The switch (or rather, our start) to document-based authoring via Adobe EDS has delivered tangible results. First, our development and update speed increased – we launched the new site in a short timeframe, and content updates now take minutes instead of days. Second, team collaboration improved: everyone gets to work in their zone of expertise, and everyone benefits. Content editors are happy with the intuitive process of working in Google Docs, and developers enjoy a clean, lightweight codebase without unnecessary overhead. Third, the site itself has become a showcase of our capabilities: its performance, responsiveness, and technical elegance are noticeable at a glance. The Lighthouse scores of 99–100 speak for themselves – the chosen architecture truly “delivers where it matters most” in terms of speed and user experience quality. For DevHandler, this project is not just a website, but also a demonstration of our approach to digital solutions. We deeply understand the classic AEM stack and value its strengths, but as a team of experts we deliberately placed a bet on the new generation of tools. Adobe EDS with document-based authoring proved to be the optimal choice for us, combining the best of both worlds: the reliability and integration of AEM’s cloud infrastructure with the modern efficiency of static content managed via Git and cloud services. Our experience shows that even with years of familiarity in “traditional” methods, it pays to embrace innovation. The web development landscape is moving towards lighter, faster solutions that empower content teams. Edge Delivery Services is a prime example of this evolution. By launching our own site on EDS, DevHandler affirmed its role as a trailblazer in modern Adobe solutions – we aren’t afraid to experiment and implement new technologies that bring real benefits to businesses. Document-based authoring has been a key differentiator for us, enabling us to stand out and offer our clients state-of- the-art approaches within the Adobe Experience Manager ecosystem.
Read more:
· AEM as a catalyst for business scaling – how Adobe Experience Manager helps accelerate growth and deliver exceptional digital experiences.
· 5 Types of Testing for AEM Projects – the most important testing methods to ensure quality in your AEM implementations.