 Hi, I'm Ricky. I'm a front-end developer at previous next and this session is about lazy loading and how to apply that to partially to couple projects Lazy loading isn't new, but let's do a quick recap. We're talking about the loading of render blocking resources being CSS and JavaScript non-critical being, you know, roughly below the fold and Basically being more targeted with what and when we load things And not lazy loading things that are above the fold which can have negative results It takes a bit of work to do so why bother, you know performance Good performance has so many added benefits How many of you have just given up and closed the web page because it took too long to load? Especially during your mobile phones or at times when you have poor internet connection In this industry, we tend to have good internet and good devices, but we're certainly not the norm, you know There's a link on my resources slide to a series Jake Archibald did on the formula one Comparing formula one websites. It's really good. There's like really good before and after page load Videos that Really explain how much of an impact this can have There's some basic principles that apply. I'm kind of gonna skim through these. There's tons of info on this online So style sheets are render blocking you want to determine critical or above-fold CSS and in line it and then once you've done that you can defer the rest with JavaScript attribute-stopping And use your library system to reduce the unused CSS on pages JavaScript is also render blocking again determine like really critical JavaScript is if there even is any Maybe in line it. This is a bit touchy in triple Definitely defer the rest to load asynchronously where applicable ES6 modules are great They're deferred by default and when you combine this with code splitting and again using Drupal's library system You can really reduce the unused JavaScript on page Media can slow down pages as well. The loading lazy loading attribute is gaining support in both Drupal and in browsers Image definitely has the widest support You definitely just use the native implementation for images. Don't use JavaScript and don't lazy load images that are above the fold like hero images or you know Always put a height and a width attribute to permit layout shift and use the responsive images module What else can be lazy load and how we're just going to talk about the intersection observer API Here's some nice techie language The purpose of this talk we just mean tell me when an element has scrolled into or out of view These aren't new. They're around five years old, but I didn't support them So usage was less than it should have been And yes, no code in this presentation is going to work. You know, sorry I frame lazy loading isn't yet supported in Firefox. So let's just use it as an example for how to do a basic Intersection observer lazy loading scenario For our HTML, we've just got a data source instead of a source attribute. So nothing at this point is going to load Quick caveat, I don't actually recommend this for iframes maybe if you have like a massive amount of Firefox users and The content in your fames is really important and you want that to load fast and then do the intersection observer approach otherwise just The native implementation is still going to be quicker for everyone else So this scope will just make a really quick reusable JavaScript function that takes an element We create an observer just with the default settings and we start observing the element, which is that last line We live through the results and grab the is intersecting property is Intersecting returns true just as the element hits the bottom of the viewport and you can increase or decrease this point with the settings We populate the source at which point the iframe loads and Then we unobserve the element, which is important. Otherwise, this keeps firing, you know as you scroll up and down the page The usage is simple. We just find all the iframes with data source, but not source And load call the lazy load function But let's get more interesting. Let's say we've got a normal Drupal side. We've got some JavaScript apps embedded here in there They could be written in react or view or whatever. They may fetch some JSON data from Drupal or elsewhere They may load their ncss and they may be multiple of these apps on page How this normally loads is you visit a page all the apps and their dependencies load This is JavaScript on possibly JSON and CSS And this repeats per app Even if it is deferred, it's not render blocking. Hopefully But users who don't scroll to it still downloaded and the initial load time is longer So how can we improve this we take our intersection observer and we combine it with dynamic imports to To only load resources once they scroll interview and this can significantly reduce the page load times And yet bonus points if you also use dynamic imports inside of Europe So we make another reusable function with an intersection observer and an asynchronous load function takes container element a component pastoring a props object and an optional callback function The load function dynamically imports the app component, you know and plus whatever we need to render it We use the dynamic import syntax to load our modules Dynamic imports return a promise. So we use promise.org to ensure that all of our dependencies are met And we can add error handling in here too is catch Then we step through the results of each import. We do structure render from the rack DOM import React just needs to be included at this point. So we just import it as well and We take the default export from our component path argument and call it something generic like component or app And then we render it passing in our props our container and our callback function The load function you can adapt to your needs. The basic premise remains the same if you free example and 18 example The observer down the bottom is the same as our frames one. It's just the default settings. Nothing fancy It just calls the load function instead of swapping attributes over Usage was looked something like this you find your unmounted container diff Call our lazy load function and set its arguments The HTML element to render to the path to the specific component are up to use The prop subject which can be simple values data attributes or durable settings and The callback function if needed. There are some accessibility considerations here. We take has findability rules for hidden content I like to add a heading and a button inside the container that triggers the load function And this just gets replaced by the rendered app anyway So you need to think about how important the content in your JavaScript app is Is it shown elsewhere or can it be and is the app itself successful as well? And also think about what should happen if JavaScript isn't enabled There's some UX improvements that can be made as well So the intersection observer as I said has a lot of fine-tuning options to change when Support things like a sticky header offsets and stuff like that There are also great candidate for a simple skeleton UI Just give the container a great background and a height and a width This prevents layout shift issues and makes the jump of the suddenly rendered app less jarring And don't forget to notify the user if something has failed to load The observer API is more performant than listening to window scroll events So really any JavaScript that does that now you can improve by converting over to an intersection observer Then when browser world is full of observers There's the mutation observer that listens to DOM changes like attributes or markup or content injection the resize observer listens to element dimension changes and It's also a more performant version of the window dot resize event And they all follow the same observe unobserved pattern. So once you get your head around one of them the rest is it pretty easy to master So quick recap performance really matters and observers are more performant than the older methods Dynamic imports are a great way to progressively load things So think about what else can be lazy loading lazy loaded inside and outside of your apps Um Lee's talk tomorrow is called improving core web vitals. He goes into more specifics about how to do this stuff in Drupal resources and Anyone any questions? Can I ask about the Google indexing? because I always found that when you Hide stuff and Google can't run a JavaScript, right? So yes, yeah failing to index our content and that can affect SEO negatively. Yes. Yeah So that's the thing if there's like really important content in those apps you want to sort of You can either make sure there's another way that it's on the page Maybe even just visually hidden sort of content. That's pretty simple and easy to understand It really depends on what the app does and what's inside it. Yeah