Cant you just have one mega CSS Sprite?

Lone Wolf

Well-known member
The Xenforo 1.1 release was the first time I'd ever heard of CSS Sprites. I almost gave up when I first heard about them but after looking into it, I can see that they're easy enough to use (even for luddites like me).

However one thing is confusing me. Why not just have one images folder for all styles with one mega CSS Sprite which contains node icons, smilies, default avatars, social bookmark icons, post/thread buttons and navigation icons.

Is it because inexperienced webmasters would find that too daunting or because there is an optimal size for CSS Sprites and a mega CSS Sprite would be too big and defeat the purpose of optimisation?
 
The Xenforo 1.1 release was the first time I'd ever heard of CSS Style Sheets. I almost gave up when I first heard about them but after looking into it, I can see that they're easy enough to use (even for luddites like me).

However one thing is confusing me. Why not just have one images folder for all styles with one mega CSS Style sheet which contains node icons, smilies, default avatars, social bookmark icons, post/thread buttons and navigation icons.

Is it because inexperienced webmasters would fin that too daunting or because there is an optimal size for Style Sheets and a mega style sheet would be too big and defeat the purpose of optimisation?
If you mean the rendered CSS, its because XenForo only renders what is needed per page.
 

That's exactly what I mean. If all the default images are in one style sheet then you would only ever query one image per page
That's actually completely invalid thinking.

What's the reasoning behind saying no?
Logic.

In a system like XenForo it makes no sense to have a single file without having any control over it.
You do not need to load everything, for every browser, for every section of the site, every time.

I kinda wrote about this on one of my sites here http://mycoffeecupisempty.com/article/48/making-a-css-php/
 
That's actually completely invalid thinking.


Logic.

In a system like XenForo it makes no sense to have a single file without having any control over it.
You do not need to load everything, for every browser, for every section of the site, every time.

I kinda wrote about this on one of my sites here http://mycoffeecupisempty.com/article/48/making-a-css-php/

I agree that not every image is loaded on every page but the thread page always loads default avatars, social icons, navigation icons, thread/post buttons and smilies. So wouldnt it significantly reduce the load to have all of those in one image file?
 
Certain images can't be sprited, some gradients for example.

Personally I prefer it with the various images separated into different sprites; node icons, smilies, other icons, etc.

I don't use node icons so that would be wasted being loaded on my site, ditto for the XenForo smilies.

It's a single GET request for each sprite, so it's not exactly a major issue if there are 3 requests versus 1.
 
@Brogan

I mean making custom CSS Sprites. For example on my site I am going to have usergroup images and custom smileys. If I put my smilies, default avatars and usergroup icons into a custom CSS Sprite.

Would that reduce the requests for each loaded thread page?
 
It would reduce the number of GET requests, but the total amount of data would be more or less the same as 3 x 10kb sprites ≈ 1 x 30kb sprite.

Nothing to stop you doing it though.
 
Hopefully we'll see that in a future version.

The fewer images the better IMO, especially for those of us who are challenged in that department :D
 
I kinda wrote about this on one of my sites here http://mycoffeecupisempty.com/article/48/making-a-css-php/

Perhaps you should check out SASS. I've actually been planning on making a suggestion about this for some time.

As to the original topic, a very large CSS sprite may be counter-productive. Two things in specific come to mind. The first is the bin packing problem, that is minimizing wasted space when combining all of these images. It could be that having multiple sprites and single images is more space efficient than one large one. Then again with internet speeds what they are, this may not make a huge difference.

The second problem which I think is far more problematic is caching. How often is a new node icon added compared to an emoticon? I know some websites that add emoticons fairly regularly, but node icons are basically set in stone. So while you may only be doing one image request, the cache expiration will probably have to be set lower, meaning you'll be downloading the entire image more often. If you have several different sprites then things like node icons can be served from cache most of the time while the emoticons sprite can be updated periodically.

Of course I don't have any statistical study to say which is better, but downloading a larger file more often is probably worse than downloading a smaller one at the same rate.
 
I think the difference is in what is saved. Node icons are only loaded on the homepage, so it makes sense for them to only have to be included on the homepage. However, having one mega sprite including everything will create a massive waste of bandwidth. For example, you'll be getting smilies on the home page and node icons on thread listings. The idea for CSS sprites is optimization, and this effectively de-optimizes the optimizations in my mind...
 
Size... as I have always told my girlfriend, is not as important as you 1st may think

Edit: skip to lower part if you dont want to read my brain splat
---------------------------------------------------------------------------------------------
Once you have the image, you have the image cached (unless you are in a no-cache environment), the biggest issue with large sprites is the huge amount of memory and bloat you add to the browser.

Having huge sprites and only displaying a small pixel in part of the background several times causes the browser to feel very laggly and bloated, that's why as much white space as possible should be removed from sprites (the data saving you gain from removing the white space from sprites is insignificant)

However, downloading even the tinest of images can sometimes take ages... some times it's just as fast to download a 1byte jpg as it is to download a 16kb jpg (keep in mind bytes are sent in packets, 1.4kB I believe?)

Most of the time is spent trying to get to the image:

* looking up DNS info,
* performing security handshakes,
* connecting to the server..
* waiting for responses..
* and then finaly downloading/trasfering the data

Actually downloading the data is often an insignificant fraction, so size is not that important, that's why as few http request should be done as possible (but still allowing for parallel requests) optimising the size of the image is no where near as important as spriting and keeping the number of request to an optimal number (but it's still worth optimising the images to some degree... but think packets, not size)

Images/ any http request will be downloaded in parallel (so it's almost shooting your self in the foot, even for performance, having one large sprite). Differenet browsers will have a different limits for the number of http request that they can do in parallel

Often people don't realise they also send header information when sending images (cookie information, etc), this can also tip an image over an optimal packet size (so using an external data provider can be useful if it's fast, a CDN could improve things). If the images are serverd from the same server, it's very important to keep your eye on header information that might build up (don't store user history in cookies, that's what a database can be used for!)

---------------------------------------------------------------------------------------------

Edit... there's way too much gumph up there, and I feel like I had only just started my brain dump, read here instead (I'm procrastinating):
.. Huge sprites = a no-no
* bloats browsers
* doesn't help spilt up requests for parallel downloading
.. sprites = good, huge sprite = bad
 
Top Bottom