Adobe Edge Delivery Performance Demystified

We've seen websites running on Adobe Edge Delivery Services (EDS) achieving record Lighthouse scores for performance. But, what is the secret behind Adobe's approach towards such great front-end performance

Article Image

Try It Yourself

One thing Adobe did really great with project Felix, aka EDS, is making it available for everyone to try out. Every developer with basic HTML/CSS/JS skills can visit the tutorial site and create an EDS website in just 10 minutes. The site goes live in record time and the CI/CD process with GitHub is incredibly simple. It takes another 20-30 minutes to develop a first custom block/component. On top of that, no one requires onboarding for editing content in Word documents, making the complete solution very easy to start with.

Edit Content

In this article, we'll focus on the document-based editing approach. We can define our site content in a simple Word document published on Google Docs. To create content, we add text, images, links, or in case of more complex components, tables. When using a table, the name in the table header needs to match the block/component name in the EDS GitHub codebase.

HTML Output

When developing classic AEM components, we are used to define the HTML output for a component. However, with EDS, there are no HTML or HTL component definitions. So where does the HTML come from? It's created automatically from the Word document. We can define only CSS and JS in the GitHub codebase for a block. Therefore, even for simple tasks like adding a new CSS class, we need to rely on manipulating the DOM with JavaScript.

Layered Rendering

The minimalistic HTML output makes sense when we look at the EDS layered rendering approach. When we inspect how components are loaded, we observe a strict order. This layered rendering approach has a very concrete purpose, to achieve a maximum Lighthouse score. First, the EDS core libraries are loaded. It's important to note that the two scripts have less than 9 kB, as they are lightweight and based on plain JavaScript. Then, the component that contains the Largest Confentul Paint (LCP) is loaded. In our case, the hero component gets rendered first. Next, all components below the LCP are loaded and rendered. Interestingly, the header and footer components load and render last. Finally, any 3rd party libraries ideally get loaded with a 3-second timeout, ensuring that the browser focuses first on what the end user wants to see.

Consequences

One thing no one can argue with is that EDS is achieving great Lighthouse scores. However, the real end-user experience may look a bit weird with the header containing the main navigation rendering last. To keep the performance scores high, teams should develop custom blocks without introducing heavy JavaScript frameworks. This can potentially cause some unhappiness for frontend developers used to working with frameworks like React, Angular, or Vue.

Conclusion

EDS is a really interesting approach that delivers concrete performance improvements. These performance improvements directly correlate with measurable business KPIs like page views, unique visits, average time on page, and conversion rate. While most other CMS solutions focus on introducing heavy frontend frameworks, Adobe turned to core web technologies and argues that all sites can be built with plain HTML/CSS/JS. EDS can be a great fit for clients looking to optimize for mobile devices and Google search ranking, like B2C commerce sites. On the other hand, it may not be ideal for clients who look to completely decouple their frontend and avoid vendor lock-in. At Meticulous Digital, we offer concrete and frank consulting for any specific situation and requirements.