Google On Lazy Loading Scroll Events For Search - Very Interesting...

Oct 31, 2018 • 8:21 am | comments (29) by twitter Google+ | Filed Under Google Search Engine Optimization
 

Last night, John Mueller did a hangout at the GooglePlex and Martin Splitt from the Webmaster Trends Analyst team was with him who was able to answer some really technical JavaScript questions. This one was about lazy loading scroll events and how Google handles them. With it, he brought up on topics on GoogleBot scrolling and the use of the noscript tag.

In short, Martin Splitt explained that they are working on new documentation around how Google handles lazy loading scroll events with JavaScript in search. I suspect this new documentation is being worked on because I really gave Google a hard time about the confusion around communication between John and Gary on these two topics linked above, i.e. does GoogleBot scrolling and the use of the noscript tag.

In short, Martin said GoogleBot does not scroll but said GoogleBot is doing "something slightly different." He also said for these elements, Google will read and use the noscript tag. So maybe both Gary and John were both right?

Let me share the transcript, because Martin goes through three reasons why lazy loading scrolling might not be a good idea:

Here is the transcript:

They have an e-commerce site and the products are changing rapidly and are lazy loaded with JavaScript scrolling events.

What about lazy loaded scrolling stuff Martin.

That's fantastic timing. I kind of feel like some people might know things that we haven't put out yet.

So you've been working on better guidance for lazy loading, we're not having the documents ready yet but we want to publish these as soon as possible. So latest at Chrome Dev Summit, there will be more guidance on lazy loading.

But generally speaking just make sure and test really really carefully that if your content becomes visible in the viewport it should be fine.

Lazy loading scrolling alone is not a good strategy two reasons or three

(1) It is really expensive is one reason.

(2) The second reason why scroll events might be sufficient is that people on desktop might just be sized their window that does not figure scroll events. So you like a tiny window, and a lot of like a lot of people keep forgetting that but there is a bunch of people who watch soap operas while they're working and then they have only half of the screen in their browser or like top half or whatever and then they might resize the window. That does not trigger a scroll event but that does trigger resize events. So if you're only relying on scrolling events you're missing out on these moments when the content should become visible but doesnโ€™t.

So if the solution is only using scroll events, that's not a good solution.

(3) Third and last important piece, is we are not doing it, we're not scrolling. We're doing something slightly different but basically the browser will know that things are becoming visible and if they are visible you should load the content that you have hidden behind. There's a bunch of ways of doing that. One way of doing it is making sure that your library works well with fetch and render. Another possibility of that of doing that is making sure that you're using something like a section observer. Section observer specifically designed to be efficient and working with like these kind of scenarios. Or you can always, if possible you can always try to have links to the content or the content itself in noscript tags. That works as well.

More guidance to come soon.

In short, if you need to use it now, do dynamic rendering or wait for the new Google docs on this.

Here is the video embed at the start time:

Forum discussion at Google+.

Update from Martin Splitt on Twitter:

Previous story: Bing Ads API Version 11 Goes Aways Today
 
blog comments powered by Disqus