1

I have a series of webpages in which the <html> refers to:

<img src="img1.png" [...] />
<img src="img2.png" [...] />
<img src="img3.png" [...] />

After I realised that multiple server requests were slowing the page down, I compiled a sprite (which contains all the <img>s) and then displayed each <img> using CSS background: co-ordinates instead.

Then I employed mod_rewrite in .htaccess to redirect any .png request to transparent.png, (behind which the background-sprite would be visible), but - here's the thing - even though I had deleted img1.png, img2.png, img3.png from the server, I kept their filenames, unchanged, in the markup.

I have been running some pagespeed tests over at Pingdom and it appears (though I'm not absolutely certain) that although this setup is much quicker than my original setup, it could still be better optimised, because... even with mod_rewrite redirects, absent resources require more server time (to identify they are absent and respond accordingly) than present resources.

My question is:

Should I still have dummy, low bandwidth (ie. 1px x 1px) .png files residing on the server under the names img1.png, img2.png, img3.png, even though the redirect means they will never actually be served on the page?

=====

UPDATE:

To see if I could reproduce what (I thought) I'd observed originally in my just-out-of-curiosity pagespeed tests, I ran a series of 60 benchmark tests on Pingdom.

10 on the Amsterdam server, 10 on the New York City server and 10 on the Dallas server without the dummy 1px .pngs and then another 10 on each server with the dummy 1px .pngs.

There is no significant result.

Amsterdam (by 0.073 seconds) and Texas (by 0.308 seconds) were faster on average across 10 page loads without the dummy 1px .pngs.

New York City (by 0.008 seconds) was faster on average across 10 page loads with the dummy 1px .pngs.

So the obvious conclusion to draw (at this point) is that the dummy 1px .pngs make no difference, present or absent.

=====

UPDATE 2:

Just to be absolutely sure, I ran a second batch of 60 benchmark tests.

This time, Amsterdam was faster with the dummy 1px .pngs and New York & Dallas were both faster without the dummy 1px .pngs.

From fastest to slowest, here are the results of 120 tests:

  • 1.06s Amsterdam (without 1px icons) #1
  • 1.08s Amsterdam (with 1px icons) #2
  • 1.13s Amsterdam (with 1px icons) #1
  • 1.18s Amsterdam (without 1px icons) #2
  • 2.08s New York (without 1px icons) #2
  • 2.09s New York (with 1px icons) #2
  • 2.50s New York (with 1px icons) #1
  • 2.51s New York (without 1px icons) #1
  • 2.89s Dallas (without 1px icons) #1
  • 2.89s Dallas (without 1px icons) #2
  • 3.11s Dallas (with 1px icons) #2
  • 3.19s Dallas (with 1px icons) #1

Final Conclusion: The dummy 1px .pngs make (as @Tim Fountain wrote) absolutely zero difference.

Improve this question
1
  • 1
    Dang good question! One up-vote.
    – closetnoc
    Dec 7, 2014 at 17:24

1 Answer 1

Reset to default
1

Should I still have dummy, low bandwidth (ie. 1px x 1px) .png files residing on the server under the names img1.png, img2.png, img3.png, even though the redirect means they will never actually be served on the page?

No, these would serve no purpose, since your rewrite rules will always intercept requests to those URLs.

Your solution, whilst interesting, and better than what you had before; is not optimal as you're forcing the browser to make HTTP requests to three separate images which have no effect on the display of the page. Even though each URL serves the same (presumably tiny) PNG, the browser has no way of knowing this.

Ideally you'd change the image tags to divs or spans, or some other element which doesn't require any additional requests after your sprite. However, if for some reason this is impractical (say you have thousands of static HTML pages with this code in), then you probably have the best solution for now.

Improve this answer
8
  • Thanks @Tim for coming back so quickly on this one. "Ideally you'd change the image tags to divs or spans, or some other element which doesn't require any additional requests after your sprite" - this is a clever suggestion from a technical perspective. However, my initial thought is that this wouldn't be good SEO. If I have a series of pages which each display 20 <img>s, I'm pretty certain I want the SE to know that it's displaying 20 <img>s and not think it's displaying 1 <img> and 19 <span>s.
    – Rounin - Standing with Ukraine
    Dec 7, 2014 at 17:42
  • "No, these would serve no purpose, since your rewrite rules will always intercept requests to those URLs." - before running benchmark tests, I guessed the same conclusion. Having run the tests, I see a 40% pagespeed improvement. (That doesn't mean, of course, that the improvement isn't due to an unrelated factor which I've missed...)
    – Rounin - Standing with Ukraine
    Dec 7, 2014 at 17:46
  • Please do not put too much importance on the img tag for SEO. It mostly only gives a clue to topic and does not carry much if any real weight. Focus on the four horse-tags of the SEOcalypse- title tag, h1, tag, description meta-tag, and other header tags. Also focus on your internal links and any inbound links. Lastly, work on trust and authority. Spending time on img tags as a part of your SEO strategy is to be misdirected onto the little tasks that have you chasing for scraps.
    – closetnoc
    Dec 7, 2014 at 17:54
  • It's hard to talk SEO specifics without knowing what the content is. The images you're currently displaying are transparent PNGs, so they have no SEO value. It's the text that has value, and that can be there whether you're using an image tag or a div or span. Unless images are the primary 'content' on the page and you want them picked up on google images (e.g. a photo gallery), IMO there's no advantage of using img tags over CSS for the display.
    – Tim Fountain
    Dec 7, 2014 at 18:33
  • 1
    "the images are the primary content" - Well, in this case these images should be in img tags. Background images are not considered part of the page content. This isn't just an SEO issue, but also one of accessibility. Background images also don't get printed (by default) - accessibility (again).
    – MrWhite
    Dec 8, 2014 at 11:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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