This project is read-only.

How much do your background images weigh? - Questionnaire

Topics: Announcements, General
Dec 10, 2011 at 11:54 PM
Edited Dec 11, 2011 at 12:23 AM

I would greatly appreciate if you'd answer the following questions. I will use the results to improve the Combinator module's performance (details below).

  1. On average, how big are the images you reference in your stylesheets? Please answer in KBs.
  2. On average, how many images do you reference in your stylesheets?
  3. How many of the images counted in 2. are from a different domain?

The next version of the Combinator module will have a feature that embeds the base64-encoded data of images into the stylesheet. The question is whether the download of images should happen asynchronously or not (the current implementation will change). If there are many big remote images, then it's worth making it async, otherwise most possibly not. But to make a good decision for a one-size-fits-almost-all solution, I need more data than my own.

Thank you for your answers!

Dec 11, 2011 at 1:26 AM

My 2 cents: I would prefer to have automatic sprite combination than base-64-embedded images: those take 30% more space and don't work on old browsers.

Dec 11, 2011 at 12:01 PM

Yeah the most important disadvantage is that with not supporting older browsers *cough*IE*cough*.

Sprite generation would be a more serious task. While there are many sprite generator solutions available I couldn't find any that could do an "images, stylesheet -> sprite image, stylesheet" or even "stylesheet -> sprite image, stylesheet" style workflow, exposed as a service, not in other ways like an HttpModule. Since currently I don't have enough time to implement such a solution on a lower level I won't deal with it in the near future.

Either way, this statistics would help me in deciding on the mentioned implementation detail.

Dec 11, 2011 at 9:04 PM
Edited Dec 11, 2011 at 9:10 PM
bertrandleroy wrote:

My 2 cents: I would prefer to have automatic sprite combination than base-64-embedded images: those take 30% more space and don't work on old browsers.

Automatic sprite combination would be amazing!

I think for inlining images, this could be very good if kept to a size limit (and make this size limit configurable in Admin). So maybe 5k and lower images could be inlined - of course with 2 versions of the stylesheet and a UA check so you could serve a back-compat version to older / unknown browsers.

CSS sprites aren't conceptually that hard; once you're parsing the stylesheet for background images and substituting some of the code anyway, it's not a huge extra step to add a background-position to use the sprites. Of course it gets tricky to work out what to do for anything that already specifies background width and height. Maybe a sprite combinator could actually be a separate feature with a certain amount of manual configuration. You could do other interesting things like allowing image filter plugins; so you create a series of icons with a recolouring filter or by compositing smaller images, so reducing the number of source images you need in your project.

I've seen a decent algorithm for sprite combination in an open source game I was looking at the code of. Actually they have a web version of the game which I think uses a CSS sprites stylesheet generated from the usual tileset files, so that might provide more pointers. Unfortunately the tileset code is largely C++ so you can't directly borrow it ... but give me a shout if you want a look and I'll it dig up.

Edit: Further note answering the original question. I find there tend to be a lot of images of smaller size - sprites, icons, chrome and whatnot - and probably a few larger images - usually backgrounds, but sometimes banners, logos and things like that. My latest site has large, HD background images, but these aren't even in the stylesheet, they're set per-page in the content editor and the url is in a style=".." attribute because it'd be fairly pointless in this case to have them all in CSS.  So, I think for a small number of larger images it's fine to load them separately, and once they're cached on the client it's fine anyway. But you'd probably get a big gain from inlining lots of small files and reducing the overall requests. Actually if you put loads of big images into a stylesheet it could take an *age* to download, so it'd either take the page *longer* to appear, or you'd get a FOUC glitch (Flash Of Unstyled Content). Especially consider that a larger amount of the images in the stylesheet won't even be used on all pages, so you are forcing the client to download data they might not even need yet.

Dec 12, 2011 at 1:21 AM

@pete: Thanks for the detailed answer.

Sprite generation is quite a minefield. Things get worse with image handling as here many images, often of different type should be combined and maybe compressed. One of the reasons I'm not going to work on this for now is the lack of a central image library in Orchard.

However if you know any solutions that could come handy here, just shoot!

The embedding part is quite complete, although no UA check here. There is an exclusion filter though for stylesheets, so conditional stylesheets for <IE 8 users can be created.