[ 60K ] RE: [thelist] File size limit?

aardvark roselli at earthlink.net
Sun Jun 3 11:10:43 CDT 2001

[bad deke, no trim]

> From: "deke " <web at master.gen.in.us>
> Not to be picking on Nate, but this thread is getting to be rather
> confusing because people are answering a different question than
> Flavia asked. She was specifically asking about *IMAGE* file size, not
> the total of all files used to build a page.

yes, she asked about images specifically, but since you really 
can't answer that in a vacuum, since so many people have more 
than one image on a page, and the total size of images and the 
code really make up the experience, of course we're going to end 
up talking about overall page weight... which is why i framed my 
response the way i did...

yeah, 20k may be great optimization from a huge image, but if you 
have 12 of them on one page, you're looking at 240k, at which point 
the size of the individual image is only part of the issue...

> I generally look to shrink photos until they are under 20K. There
> rarely is any visible difference, and I deal with that on an
> individual basis. Other images are usually GIFs, not JPGs, and tend to
> be under 10K and often under 4K.

i don't try to get all my images in general to a specific file size, 
that's too broad... on some sites the photos are ~3k, on others 
they are ~15k... however, i can say that most of my navigation 
images are 8-color .gif files at <1k... that's the best, when you can 
keep all your branding and navigation to 5k or less... that gives you 
more room for other elements, like photos and the like, in the 

> Because large files compress more effectively, slicing an image
> into many pieces *increases* the number of bytes that must be
> downloaded. 

this has been addressed over and over in articles and elsewhere... 
no, it is not faster to push a bunch of images instead of one 
image... however, as we all know, it's the perception...

as such, if parts of an image are important, but part of a larger 
image, i'll often consider slicing it so that a logo or a chunk of text 
is likely to render before the rest of the overall image... at that 
point, the user sees the important stuff while the eye-candy 
continues to pipe in...

also, slicing can be advantageous when you have the ability to set 
different compression settings and file formats... an example is a 
photo that merges with line-art... slicing that into .gif and .jpg can 
result in a more appropriate color palette in a smaller color space 
for the .gif, and even some blurring for the photo to get it smaller as 
a .jpg... in these cases, large files *don't* compress more 

so, no, your average FW/IR-sliced site will not win any speed 
awards and is usually a bloated mess of overly-large and poorly-
compressed images, but with careful control, you can not only 
increase the perceived download time (thanks to affecting the 
rendering time), but you can even decrease all the file sizes and 
truly get a faster download time...

More information about the thelist mailing list