ÃÛ¶¹ÊÓƵ

Transcript

Welcome to this video where we’ll provide a high-level overview of how Edge Delivery Services creates and delivers ultra-performant websites capable of achieving 100 Lighthouse scores. We’ll focus on the delivery of HTML page-based websites as opposed to JSON-powered single-page apps. Before delving into the technical details of delivery and web page rendering, let’s quickly review the authoring layer, where content authors write, review, and manage content. Edge Delivery Services can utilize content from various sources to power the websites it delivers, including content via document authoring through Microsoft SharePoint Word docs or Google docs. AM’s Universal Editor enables content authoring of any source, but most often AM content fragments or AM pages, while AM’s traditional page editor stores content on AM pages. All of these methods provide ways to reference media, be it images, videos, documents, and more, to enhance the web experience delivered by Edge Delivery Services. Edge Delivery Services supports diverse authoring sources through the API for Edge Delivery Services. This API fetches converted content that is in the optimized Edge Delivery Services formats and stores it for delivery. For example, content representing a web page must be transformed into the semantic Edge Delivery Services formatted HTML, and we’ll explore that format in more detail in a moment. ÃÛ¶¹ÊÓƵ has implemented converters for document authoring and certain AM content types, but custom converters that expose the content to the API for Edge Delivery Services can be created as well. Understanding the structure of this transformed HTML is vital to comprehending how an Edge Delivery Services website operates. Let’s examine it by viewing the HTML source of ÃÛ¶¹ÊÓƵ’s own Experience League website, which is powered by Edge Delivery Services. Note we’ll view the source of the web page instead of inspecting the DOM directly here, allowing us to see exactly what HTML is delivered to the browser. Let me copy the HTML over into VS Code for easier analysis. Ok, there we go. Starting with the HTML document’s head, we find metadata about the page. And at the bottom, the CSS and JavaScript entry points for the Edge Delivery Services website implementation. The body is structured with header, main, and footer tags. The header and footer tags are delivered empty and populated via fetch requests to specific documents in Edge Delivery Services that hold their content. The main tag contains the content in Edge Delivery Services HTML format, representing the page, organized by HTML element nesting levels. As you’ll see in a moment, the nesting of HTML elements under main is very important to how Edge Delivery Services renders the website. Divs that are direct children of the main tag represent a section, with optional section metadata child divs containing information for the application processing and decoration of that section. So here we can see the Experience League home page is broken up into several sections. Each of these top-level divs under main maps to a section of the website here on the right. Let’s open the first section that corresponds to this hero area on the website. Divs that are direct children of a section div and not marked as section metadata represent blocks, which are akin to components in classic AM development. Blocks require specific CSS or JavaScript for display, identified by at least one applied class name. So in this section we have a single block, specifically a marquee block, as denoted by the first class name. Expanding this block, we can start to see the content that fuels the hero experience on the website. We have the image, eyebrow text, title header, description, and buttons. This section happens to have a single block in it, but sections can have as many blocks as needed. Each block would just be another div in the section. It’s also worth mentioning, non-div direct children of a section are referred to as default content, such as H tags for headers, P tags for paragraphs, picture tags, etc. and are typically styled using global CSS or JavaScript. These elements can have auto-blocking applied for a more customized display, but that’s a little bit too advanced for this video. If you’re interested in learning more, you can always check out the Edge Delivery Services documentation on Experience League. With an understanding of the HTML output delivered by Edge Delivery Services, let’s explore how an Edge Delivery Services website uses client-side JavaScript and CSS to enhance the web page’s DOM, creating a customized and highly performant web experience. Before we jump over to the code, let’s compare the HTML delivered by Edge Delivery Services here on the left versus the HTML DOM of the page at render time. So, again, let’s use our marquee example. Inspecting the rendered DOM, we can see it looks similar, but quite a bit different from the HTML delivered from Edge Delivery Services. We see a number of different CSS class names, some data attributes, and as we click down into the marquee itself, we can see that the underlying HTML structure has changed. So in the rendered marquees DOM, we have a marquee foreground div, and within that, we have things like the eyebrow, the title, etc. You’ll also notice that there are a number of extra CSS classes applied to these DOM elements, such as marquee eyebrow, marquee title, marquee long description, etc. We can also see that these new CSS class names have accompanying styles that dictate how these elements are rendered on the page. So how did we go from the semantic HTML representing the content over on the left to the transformed HTML DOM on the right that renders this experience? Well, that’s where the Edge Delivery Services codebase comes into play. So let’s take a moment and look at that. Your Edge Delivery Services website code, stored in your github.com Git repository, starts from the AEM boilerplate template project. Your website’s codebase is built upon the starting point, and is deployed to the production website whenever code is committed to the main branch by way of the AEM code sync github app. All code is executed client-side. There is no backend code inherent in an Edge Delivery Services website. Any server-side interactions are managed via HTTP API calls to other systems or workers directly from the client browser. It’s worth noting that the codebase, while entirely JavaScript and CSS, is not built or compiled using common JavaScript build tools such as Vite, Webpack, or Rollup. Instead, this code is copied as-is from the Git repository into Edge Delivery Services for inclusion on the website, with JavaScript imports to conditionally load files, ensuring only necessary code is loaded per page. Let’s look at the app’s entry point, the scripts.js file. This file orchestrates the application lifecycle in three phases, critical to achieving optimal performance scores. The first phase is eager, which handles tasks essential to the largest contentful paint, and further prepares the DOM. The second phase is lazy, and this loads everything else that is not included in eager that’s part of this website, such as JavaScript and CSS for blocks, images, and web fonts. And the third phase is delayed, and this deals with third-party tags such as MarTech, integrations, and non-essential assets, ensuring they don’t impact website performance. While there is other code as part of an Edge Delivery Services website implementation, blocks play a central role. Let’s take a look at the Experience Leaks marquee block that turned the simple semantic HTML delivered by Edge Delivery Services into a compelling web experience. For this, let’s head over to Experience Leaks’ code repository on github.com and open up the marquee block’s supporting files. We can easily find the block by looking for marquee, which again was the first CSS class name on the block element in the Edge Delivery Services HTML. So here it is. And there are two files in it, sharing that same name. The marquee.css contains the block’s CSS styles, and the marquee.js contains the JavaScript to decorate and transform the block’s HTML DOM as served by Edge Delivery Services into the DOM that drives the experience we see in our browser. Block implementations can range from simple CSS tweaks to complete DOM transformations, like we see in the marquee block, and can even support data fetching via XHR and interactive functionality via event handlers. The browser’s full JavaScript API is at your disposal. Ultimately, this codebase is all about the controlled manipulation of the DOM and the painting of the page. So there you have it. A 10,000 foot technical overview of how Edge Delivery Services websites are implemented and deliver performant experiences. Remember, this overview covers the core concepts but only scratches the surface. Edge Delivery Services includes many more value-add features like ROM, experimentation, data services, asset delivery, and much more. The ability to deliver content and create high-performance web experiences is just the beginning. Thanks for watching, and I hope this has given you insight into the technical workings of an Edge Delivery Services website.