Friday, August 24th, 2007

YUI’s Experimental ImageLoader Utility

<p>YUI version 2.3.0 introduced some cool features including a Rich Text Editor and a Color Picker Control. One control that really stands out, the YUI ImageLoader Utility, aims to handle the issue of image pre-loading and the negative impact it has on page performance.

ImageLoader operates on the premise that image data for some images is unnecessary at the initial paint of the page, usually for one of two reasons:

1. The image is “below the fold” — that is, outside of the viewport;
2. The image is in the DOM but will not be made visible until some user interaction takes place, as is the case in some TabView implementations.

In the following video, Yahoo! Travel engineer Matt Mlinac, developer of the YUI ImageLoader Utility, discusses the use cases for the new component along with examples on how to leverage it:

A detailed description can also be found on the YUI blog.

Related Content:

Posted by Rey Bango at 2:38 pm
11 Comments

+++--
3.6 rating from 32 votes

11 Comments »

Comments feed TrackBack URI

The on-screen person might not have been the best choice. Learning some public speaking or presentation skills would have made this video a lot better.

Still, this looks like a very cool utility.

Comment by EB — August 24, 2007

EB: I disagree. I think the presentation was fine. I, for one, would prefer to have an introduction from the original engineer rather than a slickly produced, corporate compatible guide. I say: Give us more videos just like this!

Comment by Julian — August 24, 2007

Yeah, give the guy a break. How can you become a better presenter if you never get to practice? Yet another chicken and egg thing… I think the presentation was fine, and gives a good all around introduction of this great new component.

Comment by Julien Lecomte — August 24, 2007

Hmm, if originally all those images are missing “src” attribute this solution suffers from inability to gracefully degrade…

Comment by Vasili Sviridov — August 24, 2007

I think the presentation is fine. Sure, the guy could be more fluid in his speech pattern, but who cares? Everyone can be better than whatever their current level of skill is. If you can lift 100 pounds, you could be lifting 120 and if you can lift 1000, you could be lifting 1050, etc. At some point you have to realize that you just have to start doing it, whatever “it” is, and not wait until you are “perfect” or even “good”, because in real life one is never either perfect or absolutely good, or alternatively, everything is already good and perfect as is.

I am not sure the image loader is a good idea though. Is it fast enough to load the image over the modem? It seems like if the site relies on the image loader it really makes some assumptions about network latencies and the speed with which the user clicks too. When the weather is good, I am sure this kind of utility will work just fine, but how well does it work in adverse conditions? And also, does it degrade well when Javascript is off?

Comment by Leo Lipelis — August 24, 2007

Leo and Vasili, you both bring up some great points.
First, you’re right; the utility does make an assumption regarding users with slow connection speeds. The assumption is simply that if a user is willing to wait for an image to download at page load, they would be willing to wait the same amount of time (worst case) at a later point. To your benefit, these users have the most to gain because you’re saving them the most time at initial page load. Whether you agree with this assumption, how many of your users have slow connection speeds, and how you want to service those users should factor into your decision to use ImageLoader.
As for browsers without JavaScript, no, the utility won’t cater to them automatically. The onus is on the developer to recognize, server side, JS capability and then accordingly either write ImageLoader JS to the page or stick in src attributes like normal. Unfortunately, we haven’t yet figured out a way to make the utility do the work for you.

Comment by Matt Mlinac — August 24, 2007

I have a hard time seeing what real benefit this would add for the users. It adds a lot of complexity, for very little gain. If the page / site you’re working on has serious issues with load times, then you’re probably better off refactoring parts of it, to make it easier on the user, rather than adding a lot of complexity. Consider the amount of developer time vs benefit to the user, and then consider if you could give the user more benefit doing something different.

I feel that sometimes the YUI developers have a little too much “tweak-time” available to them. Maybe I am just jealous ;-)

Comment by Morgan Roderick — August 27, 2007

ImageLoader seems like a good idea to me. It does what is advertised on the box, and what more can you ask for?

I disagree with the wording “browsers that don’t support Javascript”. I broswer with Firefox which supports Javascript and with NoScript plugin which disables it by default. So obviously my browser supports it, but I chose to not allow it by default.

Ideally I would like the browser to offer Javascript hooks so that you can have src=”" in your image tags, and have your Javascript function intercept the loading and do something special, like ImageLoader. Then if Javascript is disabled, src=”" will still work as usual. It seems like the browser’s standard Javascript API can use some improvement here.

Comment by Leo Lipelis — August 27, 2007

Oh, I almost forgot … CTRL + P

Comment by Morgan Roderick — August 28, 2007

There’s no difference in the printed page once the images are loaded. So unless your user very quickly prints the page after arriving at it, it’ll be the exact same.

Comment by Matt Mlinac — August 28, 2007

So a print event fires all images to load immediately? If not, how else is the printed page going to retain the same layout? The user hasn’t scrolled or or moused over anything…

Comment by Barnaby Claydon — August 28, 2007

Leave a comment

You must be logged in to post a comment.