would lazy-loading img src negatively impact SEO
Asked Answered
P

8

7

I'm working on a shopping site. We display 40 images in our results. We're looking to reduce the onload time of our page, and since images block the onload event, I'm considering lazy loading them by initially setting img.src="" and then setting them after onload. Note that this is not ajax loading of html fragments. the image html along with the alt text is present. it's just the image src is deferred.

Does anyone have any idea as to whether this may harm SEO or lead to a google penalty box now that they are measuring sitespeed?

Pridgen answered 26/3, 2011 at 7:34 Comment(1)
On Webmasters StackExchange: Lazy loading images and effects on SEOMattison
D
6

Images don't block anything, they are already lazy loaded. The onload event notifies you that all of the content has been downloaded, including images, but that is long after the document is ready.

It might hurt your rank because of the lost keywords and empty src attributes. You'll probably lose more than you gain - you're better off optimizing your page in other ways, including your images. Gzip + fewer requests + proper expires + a fast static server should go a long way. There is also a free CDN that might interest you.

I'm sure google doesn't mean for the whole web to remove their images from source code to gain a few points. And keep in mind that they consider anything under 3s to be good loading times, there's plenty of room to wiggle before resorting to voodoo techniques.

Dudeen answered 26/3, 2011 at 7:58 Comment(19)
per Alex, check out the waterfall in firebug for google image search: google.com/… And observe the red line (onload) is after the images are downloaded and rendered.Pridgen
Of course. But there's no solid indication that Google relies on the onload event for that purpose. The only thing they say is that timings come from both google bot and google toolbar.Dudeen
also, be sure that if there was anything to be gained from this, amazon/ebay/content farms/whatever would already be doing it. You could also load the entire page via Ajax requests for stellar performance ratings :)Dudeen
there is alot of discussion about what signals google use for measuring page speed. The consensus has largely been that they consider the document.complete event as the deciding metric. Document.complete is also known as window.onload. Some people worry that lazy loading image content might be regarded as "black hat seo". See - webpagetest.org/forums/…Pridgen
However, if I had to guess, I would lean in the direction that lazy loading images should not incur penalty. The methods of prioritizing your own content should be up to the site operator, and frankly, even apple uses on-demand (scroll triggered) image loading. There's even a jquery plugin.Pridgen
there is no such a thing as document.complete. If you're referring to Microsoft's non-standard DocumentComplete event , it's akin to DOMContentReady, firing way before the load event.Dudeen
@ricardo - actually, ajaxifying your base page content is not advisable, as that would not be crawl-indexed by google bot.Pridgen
You can actually make it crawlable, but that's not the point. I think it's a stupid idea.Dudeen
by document.complete i mean "document complete" - i.e. when the document has completely loaded, synonymous with the onload event.Pridgen
Technically the document is complete when the browser has received and parsed all of the mark-up. Images are loaded after that. Hence, DOMContentLoaded vs onload. Here's a detailed explanationDudeen
I've looked at google's crawlable ajax specification before, and as far as I can tell, that is meant to define "ajax" links, commonly implemented using the hash symbol in an anchor href along with an onclick action. Otherwise, how would a crawler find your ajax URL in the page? For automatic lazy loading via $(window).load(function() { $.get()...}), google bot isn't going to find that.Pridgen
sure, i'm familiar with DOMContentLoaded vs window.onload. I haven't found a definition for "document complete", but I've seen it referenced by many as equaling window.onload. I'd like to find an authoritative article clarifying the pagespeed metric used by google, but the best I could do is determine what I deem to be a consensus describing it as "document complete / onload"Pridgen
@ricardo - the article you mention says: "Internet Explorer 6 reports a state of loading while the document is parsing, constructing the DOM and loading any images. I made a small experiment polling document.readyState for either the loaded or complete states. Comparing the results from similar experiments for bottom script and the defer technique make it clear that document.readyState reports neither loaded or complete states until after after the images are loaded. This is very late and around the same time as the window.onload event."Pridgen
Internet Explorer 6? What's that?Dudeen
@ricardo - it says the same about IE7: "Internet Explorer 7 reports a state of interactive while the document is parsing, constructing the DOM and loading any images. The leaves only the complete state as the first state that guarantees that the DOM ready. Unfortunately this state is only reported after images are loaded which is very late and experiments show that the complete state is reported about the time of the window.onload event."Pridgen
anyway, thanks. this has solidified my perception that "document complete" is well regarded as "window.onload"... which is helpful, because it's a fairly important distinction from dom-ready, since optimizing for dom-ready will tend to hurt, or at least not help, window.onload.Pridgen
That's exactly why solutions like this were created, and used by jQuery/prototype. But we digress, it's a broken implementation and Google is certainly not using IE to time page loads. This is also the longest thread I've seen on SO :) I stand by my original answer.Dudeen
p.s. we had, for a while, been lazy-loading (prioritizing) third party content to the dom-ready point. unfortunately, this didn't do anything for window.onload. Of late, we've been moving whatever we could to after window.onload. I've noticed competitor sites moving ads to after window.onload as well. Still, you are right, we simply don't know for certain what/how google is measuring page speed via the google toolbar.Pridgen
I was thinking the same thing. Cheers!Pridgen
P
3

From a pure SEO perspective, you shouldn't be indexing search result pages. You should index your home page and your product detail pages, and have a spiderable method of getting to those pages (category pages, sitemap.xml, etc.)

Here's what Matt Cutts has to say on the topic, in a post from 2007:

In general, we’ve seen that users usually don’t want to see search results (or copies of websites via proxies) in their search results. Proxied copies of websites and search results that don’t add much value already fall under our quality guidelines (e.g. “Don’t create multiple pages, subdomains, or domains with substantially duplicate content.” and “Avoid “doorway” pages created just for search engines, or other “cookie cutter” approaches…”), so Google does take action to reduce the impact of those pages in our index.

http://www.mattcutts.com/blog/search-results-in-search-results/

This isn't to say that you're going to be penalised for indexing the search results, just that Google will place little value on them, so lazy-loading the images (or not) won't have much of an impact.

Pantaloons answered 26/3, 2011 at 9:35 Comment(0)
M
2

There are some different ways to approach this question.

Images don't block load. Javascript does; stylesheets do to an extent (it's complicated); images do not. However, they will consume http connections, of which the browser will only fire off 2 per domain at a time.

So, what you can do that should be worry-free and the "Right Thing" is to do a poor man's CDN and just drop them on www1, www2, www3, etc on your own site and servers. There are a number of ways to do that without much difficulty.

On the other hand: no, it shouldn't affect your SEO. I don't think Google even bothers to load images, actually.

Misdirect answered 26/3, 2011 at 7:39 Comment(2)
so, the onload event is pretty well defined. It waits for your content to finish fully loading, including scripts, iframe content, and images. scripts are the worst offenders because they don't parallel load, but all of these do block the onload event. I think google measures real-world page load times vis a vis installations of the google toolbar. The page load time they monitor is document.complete, a.k.a. window.onloadPridgen
FYI: Modern browsers sometimes have different max-connections-per-server settings. It usually isn't only 2 anymore. But most (right now) don't default to any more than 8.Goodfellowship
A
2

We display 40 images in our results.

first question, is this page even a landing page? is it targeted for a specific keyword? internal search result pages are not automatically landing pages. if they are not a landingpage, then do whatever you want with them (and make sure they do not get indexed by google).

if they are a landingpages (a page targeted for a specific keyword) the performance of the site is indeed important, for the conversion rate of these pages and indirectly (and to a smaller extend also directly) also for google. so a kind of lazy load logic for pages with a lot of images is a good idea.

i would go for:

load the first two (product?) images in an SEO optimized way (as normal HTML, with a targeted alt text and a targeted filename). for the rest of the images make a lazy load logic. but not just setting the src= to blank, but insert the whole img tag onload (or onscroll, or whatever) into your code.

having a lot of broken img tags in the HTML for non javacript users (i.e.: google, old mobile devices, textviewer) is not a good idea (you will not get a penalty as long as the lazy loaded images are not missleading) but shitty markup is never a good idea.

for general SEO question please visit https://webmasters.stackexchange.com/ (stack overflow is more for programing related questions)

Avocet answered 28/3, 2011 at 9:25 Comment(0)
S
0

I have to disagree with Alex. Google recently updated its algorithm to account for page load time. According to the official Google blog

...today we're including a new signal in our search ranking algorithms: site speed. Site speed reflects how quickly a website responds to web requests.

However, it is important to keep in mind that the most important aspect of SEO is original, quality content.

http://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-web-search-ranking.html

Sequin answered 26/3, 2011 at 7:45 Comment(1)
yes, it's because of this in particular that I'm looking to optimize the page load time (window.onload). I'm wondering if this method will be characterized by google as "cheating" or "invalid", since they are expecting the image content to contribute to the page load time they are measuring. I'm hoping that methods of prioritizing content by way of lazy loading, be it scripts, images, even html fragments will be considered valid, but there's also the question of whether initially empty img.src values will affect how google indexes the page. maybe google will ignore the alt text in my images.Pridgen
J
0

I have been added lazyload to my site (http://www.amphorashoes.ro) and i have better pagerank from google (maybe because the content is loading faster) :)

Judgeship answered 2/2, 2013 at 1:33 Comment(1)
Pagerank as measured by the Google toolbar, or better rankings in the search results?Mattison
I
0

first,don't use src="",it may hunt your page,make a small loading image instead it. second,I think it won't affect SEO, actually we always use alt="imgDesc.." to describe this image, and spider may catch this alt but not analyse this image what id really be.

Irrefrangible answered 2/6, 2015 at 5:0 Comment(0)
E
-2

I found this tweet regarding Google's SEO

There are various ways to lazy-load images, it's certainly worth thinking about how the markup could work for image search indexing (some work fine, others don't). We're looking into making some clearer recommendations too.

12:24 AM - 28 Feb 2018

John Mueller - Senior Webmaster Trends Analyst

From what I understand, it looks like it depends on how you implement your lazy loading. And Google is yet to recommend an approach that would be SEO friendly.

Theoretically, Google should be running the scripts on websites so it should be OK to lazy load. However, I can't find a source(from Google) that confirms this.

So it looks like crawling lazy loaded or deferred images may not be full proof yet. Here's an article I wrote about lazy loading image deferring and seo that talks about it in detail.

Here's working library that I authored which focuses on lazy loading or deferring images in an SEO friendly way .

What it basically does is cancel the image loading when DOM is ready and continue loading the images after window load event.

...
  <div>My last DOM element</div>
  <script>
    (function() {
      // remove the all sources!
    })();

    window.addEventListener("load", function() {
       // return all the sources!
    }, false);
  </script>
</body>

You can cancel loading of an image by removing it's src value or replacing it with a placeholder image. You can test this approach with Google Fetch You have to make sure that you have the correct src until DOM is ready so to be sure that Google Fetch will capture your imgs original src.

Enclitic answered 20/10, 2018 at 3:38 Comment(2)
You should place the answer here on Stack Overflow, and not offsite in an article you wrote. It is OK to cite your article; in fact it is good when you cite your sources.Bah
@Bah I've updated the answer to include the core concept.Enclitic

© 2022 - 2024 — McMap. All rights reserved.