Spacen Jasset wrote
Do you have any idea at all how the internet works internally? Sorry to be
blunt but you are missing quite a few vital facts.
Traffic:
A page with SSI on it (lets forget about images for the moment) requires one
hit on the server. That is, two set of HTTP headers and TPC/IP packet
overhead, one up, one down.
A typical frame page requires four hits on the server, one for the frameset
and one for each frame (assuming header, nav, content). This uses eight sets
of headers etc. These are not small, haven't looked closely but I'd imagine
a couple or three hundred bytes at least. Yes, the returns appreciate after
the frameset is loaded but the first hits on the server are a bastard.
Server:
A page with SSI on it requires one transaction schedule. That is,
marshalling the incoming request, queing it if the server is busy, actioning
it and getting the results out the door. The time spent by the server to
actually assemble the SSId page is a small proportion of this whole. The
execution path length in the TCP/IP stack alone would be greater.
Of course the server has to read the page from its local storage BUT, after
the first hit the included bit is in the servers file system cache.
A hit on a framed page requires 4 of these. 4 times the processing. Once
again appreciating returns but that first hit is a bastard.
Network.
A page with SSI on it requires one round trip to the server. From where I am
a trip to a server in the U S of A costs me 400 milliseconds. So, my UA
sends off a request and waits... For 400ms... This is *not* a small amount
of time when one is looking at a screen waiting for something to happen.
A framed requires 4 trips to the server. 1600ms. 1.6 seconds overhead, over
and above the usual transport times.
Content.
SSI delivers one page, with one set of <!doctype, <head> etc. Frames deliver
four of this overhead.
The bottom line.
It is *quite* expensive to set up a transaction with the server. The actual
processing of that transaction is minimal, compared to the turn around time
over the net.
We went through this a while ago with regard to slicing up images, under the
misapprehension that a sliced image downloads quicker. An experiment
revealed that slicing an image into 9 bits resulted in an end user loss of
performance by a factor of 10.
Frames, while not quite so bad, are still bad from a network point of view.
Any savings made by sending out a slightly smaller package (once the
frameset has been set up on the browser) are far far outweighed by the vast
overhead of setting up that frameset to start with.
Any savings made by not sending the "included" stuff, usually a text menu
bar, are usually far outweighed by the size of the content in the "content"
frame. Why bother saving a couple of hundred bytes of menu when a single
click on that menu spews down tens of thousands of bytes of <img>?
Don't worry about it. Just use SSI and be done with it. If you are really
worried about performance issues simply up the compression on your logo
jpeg. You'll be better off.
So? Once you have worked out how your server works you are done with that
bit. You simply do it that way from now on.
