I've taken a strong liking to the prototype javascript framework, and a companion library called scriptaculous. The end user experience that you are capable of building with these framework libraries is tremendous, but the downside of their usage is that they can increase page weight dramatically.
Typically, you include the prototype library in the head section of your html document, and after prototype is included, scriptaculous. Finally, you load your own javascript file which makes use of the previous two. Assuming no other images, css files, or other external references instead of taking 1 network request to load your page it now takes 4 - one for each javascript file and one for the base html file. Of course in real practice there are other images and css files loading which can increase the number of requests to 8 or more.
When you include a script reference in the HEAD section of an HTML page, the page cannot render until the script is downloaded. This means that your document won't be viewable. I have previously offered compressed and combined versions of prototype/scriptaculous in order to reduce this problem as much as possible. Using these techniques for this site, my combined fileset is 121866 bytes. Using my previous calculations for 56K modem speeds, this adds approximately 27 seconds to the page load time for a dial-up user. 27 seconds is a lot of time! Compacting the files and gzipping them up reduces the load to 23K, or approximately 5 additional seconds.
This is much more reasonable, but I asked myself - are the scripts I'm adding really worth 5 seconds? Most of what I have enabled in the scripts isn't applicable to every page on the site, but using a single file for (most of) my site will help the user experience on multiple page views because the file will be cached and once cached, that 5 seconds disappears almost completely.
For a first time visitor, however, that 5 second delay for page load is not acceptable. In order to alleviate the delay, I moved the script include to the bottom of the document, just before the closing tag rather than the HEAD section. I then included a small init script into the HEAD of the document that polls for completion of the script load until it is available.
The end result is that the load time for a given page is reduced to what is really necessary - the base html document and the base CSS file. I certainly could think about moving the CSS file out of the HEAD section to reduce timings further, but compressed, it is only about 2.5K, which should take about half a second to load from a modem.
A further optimization technique is in actually including image dimensions in the HTML document, which provides the browser with enough layout information to render the page prior to the images being loaded.
Personally, I question page size and how it equates to search engine optimization. If I were running a major search engine, I would want to ensure that page sizes were reasonable for highly competitive search terms. I'll have to see what google reports as my page size once they cache my current set of pages - I have a plan to "shrink" the number down if it reports a page size that does not reflect my rendering speed.
Optimizing for The First Visit Interaction
