I've seen a LOT of sites where people seem to slice up images for no good reason. The most common explanation I've heard is it makes it harder for people to 'copy' the image -- which of course is 100% fiction... oh noes, they save four copies and paste them together instead of a single dl? RIGHT. (or just screencap) -- porn websites and people still building layouts using tables seem to be the only advocates of doing this anymore. USUALLY it's not from a real purpose, but more out of developer ineptitude. The exception to that being HTML e-mails; say hello to one of the reasons I don't advocate HTML e-mails.
More handshakes is bad. Since every file request runs anywhere from 100ms to over a second it's shocking that anyone would make their server work harder on purpose; but then with the megabytes of scripting for nothing, massive background images too big to belong on websites in the first place, massive idiotic bull like bloated HTML/CSS frameworks spending hundreds of K of markup and CSS on tens of K's job -- I'm not shocked by any irrational nonsensical choices site owners make anymore as they shoot themselves in the foot, then a year later cry "Why did we fail?!?"
You mentioned CSS sprites though -- that's a great thing to compare it to. The whole point of CSS sprites being to reduce the number of handshakes, just as switching to a monolithic stylesheet (per media target) and combining together all the JS into a single file does. On a normal site just going from 48 separate files to 16 separate files can shave as much as half a minute off the page load time worst case, and six seconds 'real world average'.
... and even at the bottom end DSL speeds of 768kbps, the file size becomes less of an issue than the number of handshakes unless you're doing something jacktarded like using image files measuring hundreds of K or more apiece that aren't content.
... admittedly, a LOT of the background images people sleaze out and throw on websites are too large to be in a site template in the first place. Of course, you tell the average PSD jockey this and they DON'T want to hear that and go "I don't believe it"
hmph... and that is why you fail.
Your bit about "sprites being worse" as you're loading all the images at once... well, isn't how things work. If you're using all the files, a single image (what the incorrectly named CSS sprites are) will load faster. The only time it might be disadvantageous would be if you are not using them all on the page -- BUT, don't forget the power of pre-caching for subpages.
Sometimes the savings in extra handshakes is so great, you can often spend that savings at first-load on pre-caching presentational stuff for sub-pages. It's why I advocate having only one or two stylesheets per media target; admittedly the largest I think CSS for a site should ever reach per media target (screen, print, etc) is 48k, and that's being generous; I really have to wonder what the blue blazes people could possibly waste hundreds of K of CSS on.
You also have that for certian types of images -- those that share a common hue for example or large areas of transparency / the same background color that they are often smaller saved palettized, and can be even SMALLER in total filesize after being combined.
PNG for example can alternate between multiple encoding algorythms, including LZW and RLL. RLL is BRUTALLY efficient when you have a bunch of pixels in a row that are all the same color; given the right data RLL depending on implementation can result in anywhere from 64:1 to 256:1 compression... the more pixels in a row the same, the more efficient it is. LZW is efficient when the same complex data is repeated time after time, which can peak out at around 8:1 and average 2:1 compression.
Putting multiple images sharing the same data together in a 8 bit PNG, or in some cases even 24 bit PNG can be many times smaller than they would be as separate GIF, PNG or in some cases even JPEG. IF the total filesize is smaller AND you get less handshaking overhead, you might as well stuff things from other pages on the site in so that as visitors go to your sub-pages there's less server load and an overall faster user experience.
jedaisoul;1329725 wrote:Nowadays PNG is largely irrelevant.
GEHUGAFUGAH?!? Did you mean GIF is largely irrelevant unless you're a 4Chan user? (and even they are moving to .webm?)
PNG is the format to use for most template images; gradients, patterns - let's just review the file formats:
GIF -- good if you need animations, which usually have no business in a website template except maybe for something like a blinking "you have mail" notification. Provides the most effecient encoding of 16 color or less images. Can provide palette transparency, cannot handle more than 256 colors.
PNG -- no animation capabilities, most efficient lossless encoding of any image 17 colors or more. Can do both palette and alpha (varying) transparency, and maxes out at 24 bit (16.7 million) colors with a 8 bit alpha channel. IE 6/earlier couldn't handle the alpha transparency versions, which some ignorant halfwits turned into the complete ignorant fiction of "Never use PNG if you care about IE" -- which laughably some people still parrot today even if it is 100% fiction. Even IE 4 could handle non-transparent true-color PNG and palette transparency palettized PNG with the only other issue being it actually obeying the GAMA line resulting in a different gamma. IE was actally obeying it properly, nobody else did, and it makes color matching to page colors impossible. Thankfully tools like PNGFIX and PNGCrush can be set to strip off the GAMA data.
If you "need" alpha transparency, want the most efficient web ready 5 to 8 bit palette encoding, or need lossless true-color, PNG is your only choice.
JPG - No animation capabilities, very efficient LOSSY encoding, which is to say the harder you encode it the more damage it does to the original image. It is IMPOSSIBLE to put an image into a JPEG compressor, even at minimal compression, and get the exact same image data out the other side. Much like MP3 encoding, it is willing to sacrifice quality for size. Because of this it's usually a bad choice for storing line-art. It's also why a LOT of artists HATE it, as it "damages" their work. (though at 5% lossy anyone who can visually see the difference with your head more than 6" from the display is probably one of those placebo 'FLAC' nuttters)
PNG irrelevant? REALLY? Where did you come up with that nonsense?!? It's THE format for making template images. (unless again you're using massive backgrounds that have no business on websites in the first place -- then that's JPEG's job)
Though... did you just come to that conclusion because Adobe wouldn't know image optimization from the hole in their... uhm... DVD? Yeah, DVD. Let's say DVD.