Lazy loading demystified

Key Takeaways

[Music] Hello and welcome to a new episode of Search Off the Record, a podcast coming to you from the Google Search team where we talk all about search and I don't know, maybe have some fun along the way. My name is John and I'm a search advocate here at Google in Switzerland. And today we have Martin joining us. Hi Martin. >> Hi John. >> Nice to have you here Martin. Uh because I have some questions around making websites and SEO. >> Okay. Okay. What is your question? >> I I heard there was this thing called lazy loading. >> Oh yeah. And I would like to know more about whether or not it has SEO effects, if it's something you have to watch out for, kind of like some best practices of what to do and all of these kind of things. Does that sound like an interesting topic? >> That sounds like a very interesting topic. And I think we haven't been speaking about this for a while now, so it's probably a good refresher for those who have heard us speak about it before. And for those who have never heard about it, it's probably a good primer. Yeah. >> Woohoo. Okay. So, what is lazy loading? Is it something like lazy developers do or? >> No. The idea with lazy loading is to only load resources when you need them rather than load everything at the same time and then making it like a little bit slower for everything that you're loading and also like using all sorts of resources like battery power, network uh traffic, these kind of things. >> Okay. But I thought some of that happens automatically in the browser. Like if you open a page and you look at kind of the network tab, you have that waterfall diagram and it's like, oh, it does five and then it does five more. These kind of things. Is there more involved? >> Well, so that's the chunking that HTTP used to be doing in HTTP1. But um there's more than just that. So even if you look at this kind of chunking eventually it will start to load let's say like images or videos that are at the very bottom of the page even if you never ever get close to the bottom of the page. It will be loaded unless there is lazy loading implemented in some way. >> Okay. So it's it's basically something if you have a long page or a really big page then it makes sense to kind of separate things out. Yeah, I I would actually say pretty much all pages can benefit from this. Um, especially longer pages. That is true. But even if it's not a super long page, it can probably gain uh a bit of performance and a bit of like let's say like leniency uh from the browser by using lazy loading. >> Cool. So you you mentioned performance. I suspect that's a big aspect of this as well. And also kind of especially on things like mobile browsers, you don't want to download everything if you don't need it. Are those kind of the primary drivers behind lazy loading? >> Yes, those are the primary drivers. Um, as I said, like you want to avoid work that yields nothing. And also if you have lots of non-critical resources as in like images that the article would be fine without if necessary then loading them just doesn't make that much sense because it keeps the browser busy with things that it won't need in the end maybe unless the user navigates to the part of the website where this resource is necessary. >> Okay. Kind of taking a step back. Is this something that has gotten more popular over the years? It's like it it feels like for a while like lazy loading was was something lots of people talked about. Is it basically just working nowadays or how how do you see that? >> I think it has become a little more prevalent when we build more complex websites uh and with like lots of content and um you can save on a lot of resources. So notice that I say resources even though it is mostly used for images and iframes and maybe videos. It can be used for all sorts of things. Let's say like you have a stock quote ticker thing and you actually have to pay for the API calls that you make. You might be able to save some of them. If people are not scrolling to this ticker, then you don't have to load it. So you can implement this yourself. And there used to be a time where you had to implement this yourself. So as websites grew more complicated, performance took a bigger hit from all these resources being employed in a website. Um so people looked for ways to improve performance for users uh as well. And then they kind of had to come up with their own ways. They had to be creative to find ways to detect if a resource is possibly visible to a user or not and like deciding when to load them and deciding how to load them. And that has been a phase or an era where lazy loading libraries have proliferated and there's like so many of them still to this day. I don't think very many of them are still maintained. A few of them probably still are maintained uh because they do very specific custom things but a couple of years ago and I can't remember how long ago that was but like a couple years back browsers got a native attribute for images and iframes the loading attribute and there you can specify lazy which makes the browser take care of the lazy loading for you rather than having to use some sort of JavaScript API to do that. And I think that became more widespread. So more people are using it. I know that uh Felix Arns from uh a sister team here at Google um he contributed to WordPress. So WordPress uses image lazy loading now I think by default. And as that is spreading the discussion gets a little quieter because it's kind of like a oh yeah they just like put on the loading attribute set it to lazy you're done. It's not as tricky anymore. >> Oh okay. So there's like less JavaScript, more HTML seems like a good move. >> I think that's a fantastic move actually. >> Okay. Why why doesn't the the browser just do this by default for all images? Or is this like h how do you see it like with regards to these images? Why why wouldn't you just set it for everything? >> Ah, that's a fun one. Um, actually I got an email from Dave Smart uh about this a couple months ago, a couple of years ago, I can't remember, but the content management system that we are using for onesie for developers.google.com/arch is doing exactly that. It defaults all images to lazy loading, which is not great. And you could ask like, but why? I mean, that's that's great. No, no. Um because if every image gets lazy loaded that means that images that are immediately visible or should be immediately visible are also being lazy loaded and there is a caveat to lazy loading where browsers have something called a resource scanner. So they look for images for instance specifically um and they might understand like oh images are very visual so they're probably very noticeable when they're missing. So they try to start loading images as early as possible. So as they are going through the HTML they see an image they would would immediately start loading it so that it is available uh for the user to see. So if you have like a hero image which is the very top of the page. So you will definitely or most definitely see it um as you come to the page. They would do that unless there is a loading equals lazy because loading equals lazy tells the browser oh no no no no no only only load it when it's necessary. So it kind of parses the entire page, gets everything ready, loads the non-lazy loaded resources and then looks at the lazy loadable things and only then would recognize oh the header image, the hero image needs to be downloaded now downloads it and then eventually it pops into the page. That also means it probably moves things around if people are not specifying width and height of the image. Um, and that would actually be a pretty jarring experience. So, not great. >> Oh, okay. And wi with regards to SEO is the performance side the the primary aspect where you would see that? >> Yeah. >> So, I imagine that would go into core web vitals or >> correct. So, if you're not using lazy loading where you should, that will probably impact some aspect of the core web vitals. Uh, most likely largest content full paint. Well, that actually is also most impo impacted most likely largest content full paint. That is actually most likely also impacted if you use it for images where you shouldn't use it because that means that the painting happens later than it could happen or should happen. So, it does reflect in the core web vital. So, performance is the primary concern that lazy loading addresses. Yeah. >> And for largest contentful paint, is that always an image? DNL or like how how does that work? >> It doesn't have to be an image. It likely is an image. But if you have like most of your article copy for instance coming in client side rendered uh from an API that is slow and you're not doing this efficiently, then there's likely a large block of content popping in pretty late and that would also impact uh the largest content for paint. It doesn't always have to be images, but if you are using lazy loading on an image that is immediately visible, that is most likely uh going to have an impact on your largest content full paint. It's like almost guaranteed. >> Cool. Okay. And is does it affect indexing in any way or ranking or how how does that kind of play in? >> It does influence things a little bit. So if you are using um the native lazy loading it doesn't really have that much of an impact because you after all you have an image with a source attribute where the image is linked and then it's just loaded a little later. So it has like some rendering implications and it has some core web vital implications which goes into ranking but is a tiny minute factor in most cases. There are exceptions but most cases it doesn't matter that much. Indexing on the other hand, if especially if you're using a um custom technology to do lazy loading like a library or some JavaScript that you wrote yourself, then very likely this can impact indexing if it's not done correctly in the sense of we've seen multiple lazy loading libraries for instance that use some sort of like data.source source attribute rather than the source attribute and then it might end up if there are problems with the the library. Um it might end up actually not loading the image at all. And loading in this case means putting the actual source image into the source attribute. And if it's not in the source attribute, we won't pick it up if it's in some custom attribute. >> Oh, okay. >> So yeah, that can have indexing implications. Do you know why people would use custom libraries for for lazy loading? Is is that common or is it how does that work? >> I think it's I think it's still somewhat common because number one, if you have a working setup, why would you change it? Like people might not have updated their website for the last couple of years or maybe have updated it but haven't actually touched the technology that powers the website. That's especially true for like themes that you might have installed 5 years ago that did not trust or did not use or did not know about the lazy loading attribute that is in HTML. Number one. Number two is you can do things that the native lazy loading can't do. For instance, you might want to load a low resolution preview either from a lowresolution preview that has been saved somewhere in a different URL or from a data URL that you put into the source and then swap it out for the high resolution version as the user goes there. That simply isn't possible with just HTML these days. You would have to use some JavaScript to make that happen. The other thing is what if you are not using images or iframes? Those are the only two elements that lazy loading is implemented in the browser for. So if you want to lazy load videos or if you want to lazy load I don't know article content that comes from an API or if you have your stock ticker or if you have your comments these kind of things if you want to lazy load those you very likely have to rely on JavaScript to do that as well. So, it's unlikely that all of these custom libraries will go away uh because it's just uh a bunch of stuff that it's like you there's a lot I guess you can do with with the native lazy loading, but there's still things where where people might decide, well, actually, I want to go further. >> Yeah. I mean, the custom experience might be driving you to a library. There's a very simple stock implementation. It's a bit like using JavaScript to do fancy things where content transitions rather than reloading the page, right? Links do the trick. They load the page a new and then show the necessary content, but you might want to use JavaScript to do fancier things. I know that the the transitions view transitions API is coming which will make things a little easier there, but it's still not baked in default behavior. So, you would have to do something to get custom behavior. And to be fair, I'm not sure, but I'm pretty hopeful that most of the libraries will actually do this properly and will not break things for search if you use them. So if you use a custom library, that doesn't mean that you have a problem. It just means there is potential for a problem. >> Cool. Um, how how would you recognize if there's a problem? Like if you're if you look at your site and your developer say, "Oh, we implemented lazy loading. Everything is better now >> and you're an SEO and it's like how how would you check to make sure that it's actually implemented in in a reasonable way or in a way that doesn't affect SEO?" >> That's a lovely question and the easiest way probably is to go to search console, use the URL inspection tool and look at the rendered HTML. If the rendered HTML, ignore the screenshot. If the rendered HTML looks like it contains all the image URLs in the source attribute of an image tag, if it has all the content that you lazily loaded, if it's like a custom vidget, or if it's custom content that you load, like if you use, I don't know, a thing to load comments under an article, then if the comments are there, you will be fine. If the comments are missing, then it might be that the lazy loading is implemented in a way that does not work properly in Googlebot. And then you might want to have a look at why that is and how you can fix that. >> So from a practical point of view, would you just copy and paste the rendered HTML into a doc and then search for the image tags and go through it like that or >> Yeah, I think that's the easiest way. You can use the little search icon in the search console itself, but I guess it's easiest to just copy and paste it out. >> So, I guess if you're an SEO and your developers just implemented lazy loading, it's good to make sure that you have some knowledge of HTML so that you kind of understand what is happening on the page for this. Mhm. >> Is there a way to kind of recognize when there's an issue without like knowing all of the the details of HTML? >> Yes. So, if you know that you have specific content that you want to rank for and that is lazy loaded, then if you're not showing up for the relevant queries, uh it might be that the content is just not there. So, then you can spot check that. The other alternative is if it's images specifically, you can check if the images are indexed. So if the images are not being picked up at scale, then that might mean that your lazy loaded images are not properly implementing lazy loading. With images, it's less likely because you probably just use the browser version and that should be just fine. But um if you are not using the default lazy loading for images, then that could be the reason why your images are not showing up in the index. >> Cool. I I think that's that's super helpful. And another topic that's kind of I guess related is infinite scroll. Is that a kind of lazy loading or how how would you separate that out? >> I mean it kind of is. So there is a philosophical difference I would call it. Uh the philosophical difference being lazy loading is loading non-critical resources of a page. So let's say images or additional content like comments and these kind of things. Um, so it's it's the same page content. It's just parts of the same page content. Whereas infinite scroll loads additional content and kind of like makes the page infinite in terms of content like all the content lives on this page. Now it has its own challenges and potential pitfalls. But it is somewhat related in it's again a approach or technique to progressively load content rather than load it all in one go. So it is somewhat related but it has slightly different aims or goals I would say. I guess if you're implementing it yourself or with a JavaScript library, it would be similar in that you look at the viewport and sees like, oh, should I be loading something here? >> Yeah. >> And then it it goes off and does it. >> Yeah. Yeah. It can create a little frustrating situation where you scroll for like 5 minutes, then something happens, you go to another page, you go back, and then you've lost your spot. So that's >> there you want a way to express in the URL where in this kind of like infinite stream of content you are but um yeah there there are libraries that help with that I think. >> Cool. >> Excellent. Yeah. So does that answer your lazy loading questions? >> I I think pretty much. Yeah. I I think fundamentally it sounds like for the most part sites don't need to worry about this nowadays because there are native solutions and if a developer does something custom or uses a special library it's easy to check in search console. Yeah. >> Kind of to see if if it's actually working. And since it primarily affects images, I think you said, >> yeah, >> you can also just focus on on the images and see how how they're kind of embedded in well, not embedded or like findable in image search. >> Mhm. >> Um, you you mentioned videos as well. How would that work there? >> Yeah, so videos are quite resource intensive. So it often times makes sense to load like a poster image and then only load the video as it becomes available in the viewport. And I believe there are ways in HTML to do that with the poster attribute. But I know that a bunch of people are having like some sort of like custom implementation to do this kind of thing. So you're only starting to load the video as it becomes available. But then for very large videos, you likely use things like streaming anyway. So, it's it's a lot more complicated than with images, but it is definitely possible to do this as well to not load the video immediately. Um, unless of course it's like a sort of like a header or a hero video and you want to autoplay that as the the user comes onto the page, then lazy loading doesn't really make sense there. The other thing is some people do it for privacy reasons that they only load external video content um when the user consents to it. That's kind of lazy loading, I guess, because you're not loading a non-critical resource for the for the page immediately. So, you could call that lazy loading, I think. I don't know. Would you call that lazy loading? >> So, you basically show the uh thumbnail and have a text like click here to activate the video. >> Yes. Or like a play button or something, but not actually load the video immediately. >> Yeah. Okay. And the the other thing I I was thinking of as we were going through this is what about small images? It sounds like this is mostly something for big images, but if you have like decorative images that you use in a corner of your boxes or like those kind of things. >> Oh, that's a that's an interesting one. That's not super trivial because there is a fuzzy border in between what is and isn't a decorative image. I mean, for instance, hypothetically, hypothetically, you could use data URLs for most of your images, and that would be a terrible idea because you're just making the HTML really large and hard to pass. But I guess decorative images, like, I don't know, custom bullet points or like little icons here and there. Um, you would most likely not put them into the HTML as an img, as an image tag. you most likely would use CSS to kind of display them but make clear that this has no semantic meaning. So if my article is about I don't know the fish of the great barrier reef then the images of the fish of the great barrier reef are not decorative. They are actually explanatory and part of the main content. So semantically they are part of the article. Whereas a little fish icon somewhere is probably not semantically part of the article content. it is more likely just decorative and then I would load it through uh CSS and we have mentioned that CSS images are not necessarily picked up for indexing right >> yeah okay but like if you load it with CSS is that also lazy loading or is that basically it's like loaded immediately >> um I wouldn't call it lazy loading because it's not telling the browser or is not doing it so that you're loading it as you need it is going to be loaded pretty much instantly when it's found in the CSS, I believe, but it is decorative, so it's outside of the semantic image situation. So, I I don't think it's lazy loading if you put it in the CSS. >> And I I mean, since these are small, it's not like it's going to have a big effect anyway. >> That's true. Yeah. If you load like a 3 megabyte decorative image, then ask yourself why are you doing that? >> Every morning. Yeah. every morning in into the mirror like why am I loading a multi-megabyte decorative image? >> Oh my god. Okay. >> Oh boy. Okay. >> Well, this was super interesting. Thanks for joining, Martin. >> Thanks for having me, John. >> Well, that's it for this episode. If people want to chat more about lazy loading images, where would you send them? um probably into the forums. So our search central help community um or onto LinkedIn or Yeah. I think I think the the forum is probably the best place to discuss lazy loading with us. >> And would.dev also be a place? >> Oh yeah, I think web.dev has lots of documentation on lazy loading. We also have some documentation on our site as well, but uh web.dev is probably the best place. >> Thanks a lot, Martin. And thank you folks for listening in and goodbye. Bye-bye. [Music] >> We've been having fun with these podcast episodes. I hope you, the listener, have found them both entertaining and insightful, too. Feel free to drop us a note on LinkedIn or chat with us at one of the next events that we go to if you have any thoughts. And of course, don't forget to like and subscribe. Thank you and goodbye. [Music]