Lazy loading demystified

0:09Hello, 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, because I have some questions around making websites and SEO. Okay. Okay. What is your question? 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.

1:01Does 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 And for those who have never heard about it, it's probably a good primer. Yeah. OK. So what is lazy loading? Is it something lazy developers do? FRANCESC CAMPOY. 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 a little bit slower for everything that you're loading, and also using all sorts of resources like battery power, network traffic, these kind of things.

1:41OK, 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 HTTP 1. But 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.

2:25Okay. So 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? FRANCESC CAMPOY, Yeah, I would actually say pretty much all pages can benefit from this, especially longer pages. That is true. But even if it's not a super long page, it can probably gain a bit of performance and a bit of, let's say, leniency from the browser by using lazy loading. MARK MANDELADIYIERIENCY, Cool. So 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.

3:09Are those kind of the primary drivers behind lazy loading? Yes, those are the primary drivers. 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 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. MARK MANDELAVYSCHIHLAMPANIUSSKI. Kind of taking a step back, is this something that has gotten more popular over the years?

3:47It feels like, for a while, lazy loading was something lots of people talked about. Is it basically just working nowadays? Or how do you see that? I think it has become a little more prevalent when we build more complex websites and with lots of content. And 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 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 the website so people looked for ways to improve performance for users as well.

4:52And 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 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 of years back, browsers got a native attribute for images and iframes, the loading attribute.

5:32And 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 Felix Arntz from a sister team here at Google, 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, 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 it's like less JavaScript, more HTML.

6:15Seems like a good move. I think that's a fantastic move, actually. Okay. Why doesn't the browser just do this by default for all images? Or is this, like, how do you see it, like, with regards to these images? Why wouldn't you just set it for everything? Ah, that's a fun one. Actually, I got an email from Dave Smart 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 developers.google.com slash search 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 great.

6:58No, no. 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, 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 for the user to see.

7:39So if you have like a hero image, which is the very top of the page, so you will definitely or most definitely see it 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, no, 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.

8:16That also means it probably moves things around if people are not specifying width and height of the image. And that would actually be a pretty jarring experience. So not great. Oh, okay. And with regards to SEO, is the performance side 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. Most likely, largest content full paint. Well, that actually is also most impacted, most likely largest content full paint. And 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.

9:10So it does reflect in the core web vitals. So performance is the primary concern that lazy loading addresses. Yeah. And for largest contentful paint, is that always an image? Do you know? Or 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 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 the largest content for paint. So 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 going to have an impact on your largest content for paint.

9:56It's like almost guaranteed. Cool. Okay. And does it affect indexing in any way or ranking? Or how does that kind of play in? It does influence things a little bit. So if you are using the native lazy loading, it doesn't really have that much of an impact because 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 vitals 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.

10:37Indexing, on the other hand, especially if you're using a 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 attribute rather than the source attribute. And then it might end up, if there are problems with the library, 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.

11:22if 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 lazy loading? Is that common or is it, how does that work? 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 themes that you might have installed five years ago that did not trust or did not use or did not know about the lazy loading attribute that is in HTML.

12:06Number 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 low-resolution 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.

12:44So 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 kinds 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 because it's just 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 people might decide, well, actually, I want to go further. Yeah, I mean, the custom experience might be driving you to a library.

13:25There'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 anew and then show the necessary content, but you might want to use JavaScript to do fancier things. I know that the 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.

14:10So 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. How would you recognize if there's a problem? Like if you look at your site and your developers say, oh, we implemented lazy loading, everything is better now, and you're an SEO, and it's like, how would you check to make sure that it's actually implemented 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 widget, or if it's custom content that you load, So 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.

15:11If 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. MARK MANDELYIERAANIUSSKI - 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? 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.

15:57Is there a way to kind of recognize when there's an issue without knowing all of 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, 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.

16:42But 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 think 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 would you separate that out? I mean, it kind of is. So there is a philosophical difference, I would call it. 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. so it's the same page content it's just parts of the same page content whereas infinite scroll loads additional content and kind of 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 and it's again an approach or technique to progressively load content rather than load it all in one go.

17:52So 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 see, like, oh, should I be loading something here? And then it goes off and does it. Yeah, yeah. It can create a little frustrating situation where you scroll for like five minutes, then something happens, you go to another page, you go back, and then you've lost your spot. So that's, you want a way to express in the URL where in this kind of like infinite stream of content you are.

18:33But yeah, there are libraries that help with that, I think. Cool. Excellent. Yeah. So does that answer your lazy loading questions? I think pretty much. Yeah, Yeah, I think fundamentally it sounds like for the most part, sites don't need to worry about this nowadays because they're 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 it's actually working. and since it primarily affects images, I think you said, you can also just focus on the images and see how they're kind of embedded in, well, not embedded, findable in image search.

19:27You mentioned videos as well. How would that work there? Yeah, so videos are quite resource intensive, so it oftentimes 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 a lot more complicated than with images, but it is definitely possible to do this as well, to not load the video immediately.

20:10Unless, of course, it's like a sort of like a header or a hero video, and you want to autoplay that as 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 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 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 thumbnail and have a text like click here to activate the video.

20:46Yes. Or like a play button or something, but not actually load the video immediately. Yeah. Okay. And the other thing 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 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, 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 parse.

21:29but I guess decorative images like, I don't know, custom bullet points or like little icons here and there, 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.

22:10It is more likely just decorative. And then I would load it through CSS. We have mentioned that CSS images are not necessarily picked up for indexing, right? Yeah. Okay. But if you load it with CSS, is that also lazy loading? or is that basically it's like loaded immediately? I wouldn't call it lazy loading because it's not telling the browser or it's not doing it so that you're loading it as you need it. 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 don't think it's lazy loading if you put it in the CSS.

22:53is. And 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 three megabyte decorative image, then ask yourself, why are you doing that? Every morning. Yeah. Every morning 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, Well, that's it for this episode. If people want to chat more about lazy loading images, where would you send them? Probably into the forum. So our Search Central help community or onto LinkedIn or, yeah, I think the forum is probably the best place to discuss lazy loading with us.

23:41And would going to web.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 web.dev is probably the best place. Thanks a lot, Martin. And thank you, folks, for listening in. And goodbye. Bye-bye.

24:04We'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.