Optimizing UI respons'ness with sprites

Topics: Feature requests, General
Oct 30, 2010 at 11:59 AM

I know sprites is something most people think of as old 80's games but it got its renaissance again by showing its worthiness on webpages as well. A quick count just on the setup page (Composite/top.aspx) reveals 27 requests for small icons, none of them being more than 2kb in size, mostly around a few hundred bytes actually. This means that size of headers sent back and forth easily exceed the size of the actual file requested and thats a waste. Remember, bandwidth is usually not a problem anymore, its latency that kills the user experience.

By using sprites we can load ALL necessary icons in one single request and greatly improve speed by saving requests (requests are SLOW) and pre-loading all icons. 

I've been working purely with sprites for the last 1½ year so i can come with many recommendations and even spend some time looking at your CSS and making necessary changes.

Oct 30, 2010 at 4:52 PM

Old-style sprite graphic is cool :)

I know that Google uses this  approach, but is it really relevant for C1 console?

Imo it is not likely that amount of users that have turned-off browser cache and at the same time have small network bandwidth is more than %1 out of those who're using C1 administration console.

Nov 2, 2010 at 10:09 AM

Like i said, bandwidth is not a problem anymore, its latency. And even by using caching the browser normally has to send a request to the server to make sure the version of the file is up-to-date.

With files with a size of a few hundred bytes you can end up with the request-headers exceeds the size of the actual file and then caching doesn't do any difference. Remember that the browser has to send whatever cookies it has with EVERY request to the server, so limiting number of requests would have an immediate impact.

Nov 2, 2010 at 12:48 PM

>> And even by using caching the browser normally has to send a request to the server to make sure the version of the file is up-to-date.

Well, it does not. This behavious is controlled by http response headers, and we're setting 7 days expiration period.

You can find some info here http://www.httpwatch.com/httpgallery/caching/

Nov 2, 2010 at 2:03 PM

Using CSS sprites (or a single CSS supersprite, negative performance implications aside) would require the client to be aware of all icons befoe they are rendered. We need to download the image and slice it with CSS. But in theory, this is never the case inside the C1 console. When you open a folder in a tree, the request for tree-children may be forwarded to another server. You could be browsing a remote SharePoint directory, for example. The foreign server will respond with label text and URLs for the images. These URLs may point to yet a third server. So the icons in C1 are never known - at least in theory - before the button, tab or treenode is rendered on screen.

It would be possible to setup this simple demand: An icons normal-state, mouseover-state, pressed-state and disabled-state is served in a single image and sliced on the client using CSS. This will prevent a flash-of-no-image when the mouseover event triggers a new image download. But since we don't always control the images ourselves, you would have to convince our SharePoint developer to assemble the sprite using Photoshop. And this raises other problems :) especially when we ask him to decorate the user icon with a graphic that shows if the user is currently online, busy or sleeping. Or to show the users avatar image, which may have changed seconds ago, as an icon. So it's a flexibility trade-off.

Nov 3, 2010 at 8:15 PM

@moth i'm fully aware that the client gets all the icons needed in one file, but thats also the whole point. If you know what files are going to be used anyway, then serve them all at once to save requests. This is for instance what it looks like for one of our customers.  I understand that icons served by a third party is impossible to have control over, but at least for your own icons it would be a manageable task.

Nov 4, 2010 at 12:01 PM
burningice wrote:

... at least for your own icons it would be a manageable task.

I tend to agree. Especially since we have an icon refactoring task scheduled already. But it all hangs on the resulting size of the 24bit PNG image with 100+ icons multiplied by 3 sizes up to 32x32 pixels with various combinations for mouseover and disabled state (although these can now be implemented by techniques rather than images). With this amount of icons, we may take a performance hit compared to the current setup, where icons are downloaded as they are discovered. I'll keep you posted on our findings.