Handling image-heavy web pages

Question

I have a list of TV shows which is about 200 shows long. Each of these shows has a little image, 40x60 pixels and 3 kB, and they are all listed on the same page at the same time.

Now I'm starting to think that maybe it's not such a great idea to have about 200 requests to the server each time the page is being viewed.

What is the best way to solve things like this without having to deviate from the graphical design of the page? Should I use some sort of "lazy loading" using JavaScript? Should I stick all of these in one big image and use a bunch of hackish CSS to make it only one request?

Answer 1

I think you may have a few options

• Paginate
• Lazy load via JavaScript
• CSS sprites
• and/or a CDN

Pagination is very common and I think works well with users. Lazy loading works for every JavaScript user (almost all).

Spriting could be achieved by grabbing 20 at a time for example and making one large image. I'd say use 20 at a time so the user doesn't have to wait for a super large image to download before they can see any.

You could use PHP and GD to grab each image in groups of 20, and then stitch them together, record their offsets and then print it to your stylesheet.

Your CDN should be setup to not have cookies sent (different domain, or subdomain if your site uses www). You can also configure this server to optimise it for delivering static content.

Wrikken also makes a good point about sending far forward expiry headers (vote him up!). Don't forget to add some sort of versioning in case you need to update the images, and want to keep the same filename.

Answer 2

Your best option would be to page your list.

If you have to have all items on one page, then using sprites will get it down to one image, and is a perfectly valid way to do it (i.e. not really a hack).

Answer 3

For statics, I'd recommend something like nginx on a static.example.com subdomain, a very lightweight webserver, which can serve the images with less overhead then more 'traditional' webservers. And set proper expire & cache headers of course, someone visiting your site should have all your images in cache for a reasonably long time.

Answer 4

There is one more option: Data URIs in your css. Basically, you base64 encode the images and stick them directly in to the css file. One request serves up the css AND all the images, and the whole thing can be gzipped for even more savings.

The downside? IE 5-7 don't handle data-uri natively (IE 8+ does support this). You can get around that by having two versions of the stylesheet (one with embedded images, one without) and have apache choose which one to serve up. Alternatively you can use a javascript solution that adds data-uri support to the older IEs.

http://www.websiteoptimization.com/speed/tweak/inline-images/

For the Rails crowd, there is a gem called Jammit that does this automatically. It generates the data-uri and the regular versions, as well as zipped equivalents of each.

Answer 5

i'd recommend using 200 divs with each of their background-images loaded from one single image file thats a strip of all the images joined together, ala css sprites

Answer 6

I would create image sprite and use CSS to display images in divs like this scroll -10px 30px. This is a simple web based sprite and CSS generator http://spritegen.website-performance.org/

Answer 7

Use CSS sprites. The total image size for all your images by the sounds of it is around 600kb, which is probably too large to load in one go, so you can seperate the images into several sprites, each ~100k. You can then prioritise their loading order dependant on what is being viewed.