11

Consider this conditions for my website:

  • I don't support IE8 and below so browser support is not a problem.

  • I also use gzip that would avoid data overload in CSS in cases that I copy and paste data URI images in my CSS file.

  • I only have one CSS file that is generated by LESS.

  • To make it easy, I use LESS variable for each image data URI.

  • I put images variables in a separated LESS file to keep my codebase clean

With all this I am still not sure if it's best approach for loading images. Loading small images with this approach reduces number of HTTP requests and also we don't have to maintain a sprite image.

Is there any drawback in this approach you can think of?

Mohsen
  • 64,437
  • 34
  • 159
  • 186
  • 1
    Some mobile devices/browsers won't cache files that are over a certain size (I think iPhone is 24kb?). If you have a very large CSS file as a result of the data URI, you could be shooting yourself in the foot there. – cimmanon Nov 17 '12 at 02:08
  • @cimmanon I believe that is not the case in year of 2012. Check [this](http://www.yuiblog.com/blog/2010/07/12/mobile-browser-cache-limits-revisited/) out – Mohsen Nov 17 '12 at 02:21
  • there's pro and con pitfalls using sprites or URI. I'll recomends to read this great article: http://www.alistapart.com/articles/sprites/ from A list apart. Hope this helps. – wandarkaf Nov 17 '12 at 12:41

1 Answers1

2

If any image changes, the entire css file has to change. This breaks HTTP cache. With a sprite image, the css file itself would be served from cache, and only the changed image would have to be downloaded again.

It may be better to generate a css file only for the data:URI images, and another for the regular CSS stuff. This way, regular css updates don't require re-downloading the data:uri images.

Second problem is with foreground images, those that are served with <img> tag in the html. If it is a frequently used image, it will unnecessarily increase the size of the html.

Sripathi Krishnan
  • 30,948
  • 4
  • 76
  • 83