Webmasters Stack Exchange is a question and answer site for pro webmasters. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

For images loaded via AJAX, or that I don't want indexed, use the data-* attribute approach:

<img data-src="path/to/image.jpg" class="js-lazy-load" />

The javascript maps the data-src attribute to the src attribute:

<img src="path/to/image.jpg" />

But for images in the HTML that I do want indexed:

<a href="path/to/image.jpg" class="js-lazy-load">Image alt text here</a>

The javascript replaces the anchor with an image tag:

<img src="path/to/image.jpg" alt="Image alt text here" />

Seems that would preserve index-ability and the intent of the page (for accessibility) without affecting SEO (hopefully). But would love a second opinion.

Edit: Any feedback on how this approach - page with links to images versus page with inline IMG tags - would compare in regards to page rank. I'm guessing the inline IMG tags would fare better since each outgoing link would detract from the overall page rank (unless they had rel="nofollow" which would be counter productive).

share|improve this question
Outgoing links don't detract from your page rank. That's not how PR works. – Lèse majesté Feb 20 '12 at 21:38
Would the total number of outgoing links detract from the PR that each link has? So if originally the page had 5 links - each with 20% PR - but with this approach there would be 50 - would each now have 2%? – Aeron Feb 20 '12 at 22:25
That's correct. The amount of PR that is passed is divided by the number of links on the page, but due to PR sculpting, nofollow links are now also included when dividing PR between links. So even if you have 45 nofollow links and 5 regular links, the 5 regular links would still only pass 2% of the link juice. Though if Google were smart, they'd treat image links differently than HTML links, as your solution is a valid one for usability and accessibility, and it shouldn't be discouraged by diluting your PR flow. – Lèse majesté Feb 21 '12 at 0:48
up vote 11 down vote accepted

That's a good approach. Another approach you could take is to use the <noscript /> element to store the normal version of the img tag, which would be indexed by Google, and use JS to create the lazy loading version.

Alternatively, you could use Google's hashbang AJAX conventions combined with HTML5's history API to make bookmark- and index-able page states. This is especially preferable if you're doing some kind of infinite scroll page, as it provides a form of pseudo-pagination—something which most infinite scroll implementations desperately need (::cough:: Google Images ::cough::).

Edit: Using links as placeholders for the images could cause the PR flow from the page to be divided amongst more links, though PR is always conserved unless you use nofollow so in theory this would increase the PR of those images for image searches.

If you don't want that, or you want the page to degrade gracefully for non-JS users, you could go the opposite route and start with regular images but using blocking JS to substitute the src attribute of the images at page load (or even just delete the image elements and store the src attributes in your lazy loading queue). If you do it correctly, you can get this done before any of the images actually begin downloading.

share|improve this answer
I would love to see that - Google does not look at <noscript> and I have not found a way to block image loading in Firefox yet; substituting src (even with a <script> tag immediately after the <img> tag) doe not seem to prevent the image from downloading in latest version of Firefox. If you know of another way to do that, please share! – mindplay.dk Sep 21 '12 at 13:39
@mindplay.dk: Google may opt to not use noscript text in snippets, but everything I've read leads me to believe it does index noscript content in general. However, you're right about substituting src. My original thought was to put a script before the first image, so that it blocks the loading of the images until after the script has loaded and executed. But upon more examination, this wouldn't work since the images wouldn't show up in the DOM at that point. You could block downloading by maxing out concurrent connections to the host, but that's impractical these days. – Lèse majesté Dec 21 '12 at 23:29
A dirty hack someone else came up with is to use JS to comment out the JS-free images like so (there's a longer version that deals with speculative parsing): <script>document.write('<'+'!--');</script><img src=...><!---->. You'll have to decide for yourself whether that's an acceptable approach. – Lèse majesté Dec 21 '12 at 23:35

I have seen images loaded with this pattern:

<img data-src="path/to/image.jpg" class="js-lazy-load" />

get picked up by Google and Google Image Search and others have spotted it too. Since Google now executes javascript on your page, there may be no need to put the actual image into the src attribute. Neglecting a src attribute might lead to a grey border around your image, so probably best to go with something like:

<img src="placeholder.gif" data-src="path/to/image.jpg" class="js-lazy-load" alt="Image alt text here" />

Nb. this doesn't necessarily apply to other search engines.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.