Slicing images?

This site is best viewed in a modern browser with JavaScript enabled.

bleck

Hey all,

Just signed up to ask a simple question. Working with someone new, and designed part of a site which had some images in the background. The request was made to have the images then sliced (say into 4 parts) versus keeping it at one. The images in question were around 90-110 kb.

Is this something that people do normally? I could understand with maybe a very large image, but any benefit to the perceived loading time seems so minor in this case. I was also told that you can compress the image better that way, but I have a feeling that just isn't the case. 4 images containing the same information, at the same quality would be identical in size. Plus now there are 4 HTTP requests. And a lot more HTML added to page for something that doesn't seem worth it.

I searched Google and didn't see much related to slicing images (except really old 2009-2011 stuff). Was this common practice back then, but has fallen out of favor with sprites? Sprites seem like it would be worse in this situation (since it would have to load all 5 of those images).

ShrineDesigns

Using one image versus using multiple images (slices of an image)?

Using one image only requires have to make one request to get the image. Reducing the number of requests the user or browser needs to make to load a page is highly beneficial.

Using multiple images requires make multiple requests, this also increases bandwidth with consumption because each request must send/receive headers.

Years ago we used to split large images. Mostly because DSL/cable was not widely available. On a slow connection multiple images MAY load slightly faster versus one image. The more wide range of high speed connections has all but made this requirement obsolete. Nowadays, its more about reducing requests.

I personally would suggest trying different settings when saving the image to get the file size down, without sacrificing too much quality.
One good method is to use JPEG and use the progressive scan option. And adjust the quality setting to get a desired file size.

If you are dealing with an image that has fewer than 255 colors or is in black and white. Using either GIF or PNG is a way to go. PNG will generally look much better, but it will be slightly larger in size compared to GIF. Be sure to use the best palette for the situation.

jedaisoul

Is your site designed for viewing on low-spec mobile phones? Even if not, not everyone is on cable. So it is important to view your site on mobile (if supported) and via ADSL. Then the reason for splitting large images (and optimizing them) might be more apparent.

Oh, and about GIF and PNG...

The only way to optimize GIFs is to reduce the color palette, which supports only 256 colors to start with. I use them frequently, but only for graphics and animations. Also they become very blocky when magnifies, so cannot compete with JPEGs for large background images etc...
Whereas, PNG was created because (back then) GIF was a proprietary format which was subject to royalties. Nowadays PNG is largely irrelevant.

deathshadow

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.