Question

So I have my own webpage here, which is a sortable thumbnails page. The load() event activates each thumbnail when the first related image is loaded. Since I’m grabbing <img> tags and text content from a hidden div on the page, the thumb activation prevents the user from clicking through to a yet-unloaded image and then waiting while the preload takes place in the background.

The call is pretty simple:

$('#content img:first-child').load(activateThumb).each(function(){
    if(this.complete || this.complete === undefined)this.load();});

the .each() catches any cached images and manually triggers the load() event. Worked great and was a fast and lean website. Now, as the site continues to grow, there are over 100 <img> tags in the single HTML file and I’m wondering if there’s a conventional limit that I’m approaching. Should I split the page onto 35 different html files? Should I lose the tags and the slick preloading effect in favor of a server-side request for the images on demand?

What’s your instinct, as a good programmer?

Answer 1

Well there is no clear limit. You can continue doing the way you have done on your site for as many images as possible.

But it’s just that the user might get frustrated while waiting for all the images to get ‘activated’.

So in turn what you could do is to have pagination & display say 20 images per page. This way you make the image loading relatively faster.

Also after you load page1, if the user is still in page1 you could start pre-fetching page2. So as the user clicks page2 he sees a very responsive site 🙂

There is no one rule here. In fact if you see Google Images now a days they do something like what you have done.