Lazy loading question

Is this an issue for Blocs? (For those who check off the box at export)

Google lazy loading

Hi @bourne

My 2 cents:

It depends on your page structure and especially your content. Should you only have text content and no images it would probably not matter.

Question is why would you want to tick it off ? It is integrated in Blocs to help with faster loading which Google will recognize and provide viewers with a better experience (provided you have optimized your content as well).

MDS

I know for certain that lazy loading in Blocs interferes with the actions of certain site map generators, so images and other content are excluded, unless it is switched off before exporting the site.

My understanding was that Google is now able to process pages with lazy loading and index them properly, though perhaps that depends on what system is used, as indicated by that article. I have a little app called Robotize that emulates what a search engine sees when it visits your website and sure enough it says there is only one image on a website I have just completed in Blocs 3, which appears like example.com/imag/lazyload-ph.png

I have just looked inside Google webmaster tools and I can see that the sites done in Rapidweaver without using lazy load have lots of indexed images. On my Blocs sites not a single image has been indexed, so this is disappointing to say the least and needs some sort of fix without a doubt.

Are you referring to when lazy loading is selected?

Yes this is when lazy load is in use. I’ve gone to the trouble of ensuring there are alt tags and the images are named for SEO, then I ensured they were included in the sitemap, yet still not a single one has been indexed.

I take it there’s been no progress on this?

Perhaps even more worrisome than the lack of indexing is how it looks visually, especially in XS. I am finding that my graphics are not displaying until I scroll down to about 98% the height of the graphic! I’d much rather it trigger when I scroll down about 25% into the graphic. But being forced to scroll almost the entire height of the graphic before it displays is visually troublesome. And yet, to disable Lazy Load invites a host of other problems.

What to do…

:thinking:

1 Like

Google has confirmed within the last week that the most recent version of Googlebot now uses the latest version of chromium to render javascript and lazy loading is crawled and indexed now.

I’ve noticed my lazy loaded images are indexed quite happily.

Thanks for this info @DaveC

1 Like

This sounds like excellent news. If Google is now able to index lazy loaded images from Blocs I’ll enable it everywhere. Previously no images were being indexed, even with a detailed sitemap. I’ve just tried searching for some sort of specific announcement on this but not seen anything.

EDIT: It mentions lazy loading here with recommended methods.

Am I right in thinking you are scanning the site using Integrity for the sitemap without lazy loading enabled, then uploading the site again with it enabled afterwards? I just tried uploading a site with lazy load switched on and Scrutiny isn’t seeing any of the images.

Yes at the moment, I believe Shiela is looking at away around this.

I believe it is something that could be done, but it involves steps she really didn’t want to include in the app, because it would impact performance. It would be good if she was on the forum to explain these things.

She’s definitely responsive and I think she would be a great help.

I’ve only been using Blocs since January, all of websites created used the standard sitemap. All of the images have been crawled and indexed, so I think I must have been lucky and uploaded at a time when the more advanced Googlebot was doing its rounds.

I basically stopped using lazy loading about that time because it had become evident nothing was being indexed up to that point. I’ve just enabled it on one of my own sites where the sitemap from Scrutiny is in place and includes the images. I’ll be able to see quickly enough if they remain indexed but your findings are encouraging. I really want to use lazy loading, but only if it helps me stay on page one.

Hi @Flashman

It’ll be interesting to see. They recommend IntersectionObserver method, instead of the old getBoundingClientRect method, mainly due to increase basic loading speeds. But, I did watch other vids from Google and discovered that the new chrome crawler is a phone-based app, thus it doesn’t scroll when crawling and will only pick up images w/in the viewport.

Bill
BricsDesign

Am I right in thinking the javascript for google analytics seems to interfere with blocs lazy loading? My tests seem to indicate in that direction.

@Flashman Have you seen the new speed improvement news from Cloudflare? Looks quite promising, features seem to be split between pro and business packages. Cheers.

Yes I did see them actually. I was on a pro package for a few sites over a couple years, but now just on the free packages, though I do have Railgun enabled :wink:

It looks like Cloudflare are now doing more to separate their packages, which was inevitable sooner or later. I ran the speed check inside the admin panel that was briefly available and according to their figures some of my sites made decent speed improvements using Cloudflare, while others were modest at best.

Despite the options in Cloudflare I still think it is important to have good web hosting as a starting point. I’ve been through several over the years.

Yeah I agree, quality hosting is a must. I got into using Cloudflare a few years back to protect some of my WordPress sites.

I like the look of http2 prioritisation and parallel streaming of progressive jpegs, those will boost my already very quick blocs sites.

I’m currently playing about with pre gz files via apache, it definitely increases speed of non Cloudflare cached content, but unfortunately not every browser seems to be compatible.

I’ve messed around with preconnect, preload and prefetch, but it sounds like this is going a step further with prioritisation.

Try adding this to the header of your Cloudflare web pages:

<link rel="dns-prefetch" href="//ajax.cloudflare.com" />
<link rel="preconnect" href="//cdnjs.cloudflare.com" crossorigin>

My web server is actually Quic enabled, which has now been recognised as http3 and that is where the big changes will come. Cloudflare will enable this sooner or later as well with lots of extras no doubt.

For compression I’m also using brotli, both on Cloudflare and the Litespeed webserver. You “might” want to investigate hsts preload, which I have enabled on my sites as well, but be careful on that one. Only to be used if you are absolutely certain your site and subdomains will always be accessible via https.

1 Like