[ 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
content...
> 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
effectively...
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