Lazy loading demystified

[MUSIC PLAYING]
JOHN MUELLER: 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.
MARTIN SPLITT: Hi, John.
JOHN MUELLER: Nice to have you here, Martin.
Because I have some questions around making websites and SEO.
MARTIN SPLITT: OK.
OK.
What is your question?
JOHN MUELLER: I heard there was this thing called lazy loading.
MARTIN SPLITT: Oh, yeah.
JOHN MUELLER: 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,
some best practices of what to do,
and all of these kind of things.
Does that sound like an interesting topic?
MARTIN SPLITT: 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.
JOHN MUELLER: Woo-hoo.
OK, so what is lazy loading?
Is it something like lazy developers do or?
MARTIN SPLITT: [CHUCKLES]
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 like,
using all sorts of resources, like battery power and network
traffic, these kind of things.
JOHN MUELLER: OK, but I thought some of that
happens automatically in the browser.
Like, if you open a page and you look at 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?
MARTIN SPLITT: Well, so that's the chunking that HTTP
used to be doing in HTTP 1.0.
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.
JOHN MUELLER: OK, so it's basically something
if you have a long page or a really big page, then it
makes sense to separate things out?
MARTIN SPLITT: 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.
JOHN MUELLER: 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.
Are those the primary drivers behind lazy loading?
MARTIN SPLITT: Yes, those are the primary drivers.
As I said, you want to avoid work that yields nothing.
And also if you have lots of non-critical resources,
as in 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.
JOHN MUELLER: OK, kind of taking a step back,
is this something that has gotten
more popular over the years?
It's like, it feels like for a while,
like, lazy loading was something lots of people talked about.
Is it basically just working nowadays or how do you see that?
MARTIN SPLITT: I think it has become a little more
prevalent when we build more complex websites 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 a website.
So people looked for ways to improve performance for users
as well.
And then they 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 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 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 a couple of 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 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, oh, yeah, they just
put on the loading attribute, set it to lazy, you're done.
It's not as tricky anymore.
JOHN MUELLER: Oh, OK.
So it's like, less JavaScript, more HTML.
Seems like a good move.
MARTIN SPLITT: I think that's a fantastic move, actually.
JOHN MUELLER: OK.
Why doesn't the browser just do this by default for all images?
Or how do you see it, like, with regards to these images?
Why wouldn't you just set it for everything?
MARTIN SPLITT: 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 [INAUDIBLE] for developers.circle.com/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.
No, 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, oh, images are very visual,
so they are 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.
So if you have 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, 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.
That 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.
JOHN MUELLER: OK, and with regards to SEO,
is the performance side the primary aspect
where you would see that?
MARTIN SPLITT: Yeah.
JOHN MUELLER: So I imagine that would go into core web vitals
or?
MARTIN SPLITT: 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 Contentful Paint.
Well, that actually is also most impacted.
Most likely Largest Contentful 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 vitals.
So performance is the primary concern
that lazy loading addresses.
Yeah.
JOHN MUELLER: And for Largest Contentful Paint,
is that always an image?
Do you know?
Or how does that work?
MARTIN SPLITT: It doesn't have to be an image.
It likely is an image.
But if you have 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 Contentful
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
Contentful Paint.
It's almost guaranteed.
JOHN MUELLER: Cool.
OK.
And does it affect indexing in any way, or ranking,
or how does that play in?
MARTIN SPLITT: 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 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.
Indexing, 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 data.source attribute rather
than the source attribute.
And then 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, if it's in some custom attribute.
So yeah, that can have indexing implications.
JOHN MUELLER: Do you know why people would use custom
libraries for lazy loading?
Is that common or how does that work?
MARTIN SPLITT: I think it's still
somewhat common because number one,
if you have a working setup, why would you change it?
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, 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 low resolution preview that
has been saved somewhere on 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.
JOHN MUELLER: 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, there's a lot, I guess,
you can do with the native lazy loading,
but there's still things where people might decide,
well, actually, I want to go further.
MARTIN SPLITT: 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.
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 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.
JOHN MUELLER: Cool.
How would you recognize if there's a problem?
Or 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 would you check
to make sure that it's actually implemented in a reasonable way
or in a way that doesn't affect SEO?
MARTIN SPLITT: 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.
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, 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.
JOHN MUELLER: 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?
MARTIN SPLITT: 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.
JOHN MUELLER: 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 understand what is happening on the page for this.
Is there a way to recognize when there's an issue without knowing
all of the details of HTML?
MARTIN SPLITT: 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 will probably
just use the browser version and that should be just fine.
But 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.
JOHN MUELLER: 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?
MARTIN SPLITT: 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 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.
JOHN MUELLER: 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, oh, should I be loading something here?
And then it goes off and does it.
MARTIN SPLITT: Yeah, yeah.
It can create a little frustrating situation
where you scroll for five minutes, then something happens.
You go to another page, you go back,
and then you've lost your spot.
So you want a way to express in the URL
where in this kind of infinite stream of content you are.
But yeah, there are libraries that help with that, I think.
JOHN MUELLER: Cool.
MARTIN SPLITT: Excellent.
Yeah.
So does that answer your lazy loading questions?
JOHN MUELLER: I think pretty much.
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
to see if it's actually working.
And since it primarily affects images, I think you said.
MARTIN SPLITT: Yeah.
JOHN MUELLER: You can also just focus on the images
and see how they're kind of embedded in-- well,
not embedded.
Findable in image search.
You mentioned videos as well.
How would that work there?
MARTIN SPLITT: Yeah.
So videos are quite resource intensive.
So it oftentimes makes sense to load 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 some sort of 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.
Unless, of course, it's sort of 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?
JOHN MUELLER: So you basically show the thumbnail
and have a text, click here to activate the video.
MARTIN SPLITT: Yes.
Or a play button or something, but not
actually load the video immediately.
JOHN MUELLER: Yeah.
OK.
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 decorative images that you
use in a corner of your boxes or those kind of things.
MARTIN SPLITT: 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,
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.
But I guess decorative images, like, I don't know,
custom bullet points or 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 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 CSS.
We have mentioned that CSS images are not necessarily
picked up for indexing, right?
JOHN MUELLER: Yeah, OK.
But if you load it with CSS, is that also lazy loading,
or is that basically loaded immediately?
MARTIN SPLITT: 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.
JOHN MUELLER: And I mean, since these are small,
it's not like it's going to have a big effect anyway.
MARTIN SPLITT: That's true.
Yeah.
If you load a three megabyte decorative image,
then ask yourself, why are you doing that?
JOHN MUELLER: Every morning.
Yeah.
MARTIN SPLITT: Every morning into the mirror,
why am I loading a multi-megabyte decorative image?
JOHN MUELLER: Yeah.
Oh, my god.
OK.
MARTIN SPLITT: Oh, boy.
OK.
JOHN MUELLER: Well, this was super interesting.
Thanks for joining, Martin.
MARTIN SPLITT: Thanks for having me, John.
JOHN MUELLER: Well, that's it for this episode.
If people want to chat more about lazy loading images,
where would you send them?
MARTIN SPLITT: Probably into the forums, so our Search Central
help community, or onto LinkedIn.
Yeah, I think the forum is probably
the best place to discuss lazy loading with us.
JOHN MUELLER: And would going to web.dev also be a place?
MARTIN SPLITT: 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.
JOHN MUELLER: Thanks a lot, Martin.
And thank you folks for listening in, and goodbye.
MARTIN SPLITT: Bye bye.
[MUSIC PLAYING]
JOHN MUELLER: 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.