On 1 Oct 1998, Scott McNeill wrote:

> But isn't it also true that since the image map is one image, albeit larger in
> file size, the server retrieves it faster due to the fact that it only makes one
> connection?  I am under the impression that the server opens up a new connection
> for each image.  "Goes and gets it" so to speak.  Each trip increases the
> overall download time.

There are a few factors that come into play when figuring out what is
fastest.

1) Server type/speed
   How fast is the server you are getting the images from?  How many
   connections can it handle simultaneously?
2) Browser type/configuation
   Most browsers can be configured to attempt more than one retrieval at
   a time.  If there are 10 images to download, it will send requests for
   all 10 of them (all in separate socket connections)  The more
   connections from the browser, the faster the overall download
   tends to be (because of reason #3)
3) Connection speed/reliability
   There is almost always at least some dead space in a connection.  For
   whatever reason, a request to download an image won't be sending data
   every millisecond.  This is particularly true when dealing with
   extremely busy web servers.  The interesting thing is that if you have
   multiple connections going, they can "overlap" these dead spaces to
   create an almost steadily full data stream.  So if a server is
   responding to you  slowly (say at 1KB/sec) then if you are downloading
   3 files at once, you could get a combined transfer of 3KB/sec.  So if
   you have one image that is 20KB total in one large image, it will take
   20 seconds to download on a bogged out 1KB/sec pipe.. if you split
   that into 3 7KB files, the combined effort of the three connections
   could download them all in 7 seconds.  Of course, this is not always the
   case, so yes, the question to split them up or leave them whole is
   really "It won't make that much difference unless you extremely change
   the overall filesize"

One reason for an INCREASE in download time due to splitting up images is
the fact that the content length alone is not all that is being
transmitted in an HTTP connection.  There is overhead both in the TCP/IP
layer, the socket layer, as well as the HyperText Transfer Protocol
itself, which some servers honor and others don't (a true HTTP header can
be quite large, in the neigborhood of 300-500 bytes, if all the
"required" directives are sent both on the request from the client and the
response from the server) So if you have only saved 4000 bytes by
splitting the image into 10 different images, then the savings will almost
assuredly be eaten up by the extra protocol headers needed to get the
file.  This can be offset by number 3 above, but only in certain cases.

Here, for example, is the header information sent by Netscape Navigator
3.01 when retrieving a document.. this header is 180 bytes long:

GET /hello.html HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/3.01Gold (Win95; I)
Host: indy4.indy.net:6669
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*


The request header for IE4.0, however, is quite a bit longer (330 bytes):

GET /hello.html HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
 application/vnd.ms-excel, application/msword,
 application/vnd.ms-powerpoint, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows 95)
Host: indy4.indy.net:6669
Connection: Keep-Alive

Other browsers:

Netscape 1.22:  144 bytes
Netscape 4.0:   252 bytes
Lynx 2.8:       218 bytes
 (text browser)

Pat

HWG: hwg-graphics mailing list archives, maintained by Webmasters @ IWA