On this forum, I've migrated the static image, css, and javascript files to two http servers specifically purposed for lightweight small static file delivery.

The optimization is not fully complete, but I'm getting there.

First and foremost, the javascript for the forum has been combined to a single file, and the css for this forum has been combined into a single file as well. Combining and shrinking these files dramatically reduces the number of http requests it takes to load the pages. The fact that these files will get cached on a long term basis means that multiple page views will remove those requests altogether, or at the very least, they should be reduced to at least a 304 http response.

According to the speed report (which is wrong, but a close approximation anyways), the forum main page requires 20 http requests to complete - 1 script file, 1 HyperText Meta Language file, 1 css file, and 17 images. Of the images, 2 stand larger than 2K a piece, and 7 are smaller than 1K.

At the time of this post, the separation of requests is as follows:
www.stevekallestad.com -
10 image files totalling 16695 bytes
1 HyperText Meta Language file sized at 5703 bytes

st1.stevekallestad.com
4 image files totalling 11125 bytes

st2.stevekallestad.com
1 css file totalling 9504 bytes
3 image files totalling 1526 bytes

static.stopmomstop.com
1 javascript file totalling 149 bytes

In order to maximize the efficiency of delivery, and to ensure that my server load is as minimal as possible for showing these pages I need to ensure as even a separation as possible between the 2 static servers - both in the size of requests and in the number of requests. I also want to ensure that my main server is only tasked with the responsibility of delivering the main content and none of the fluff.

I also need a more realistic picture of the files being delivered and of the actual file sizes. The speed report is a decent approximation, but it is reporting bad file sizes and doesn't seem to be taking into account all of the files being delivered.

OK... still using the speed report, but making a little bit of progress:

1) removed the link to static.stopmomstop.com

2) now only the HyperText Meta Language page is served up by www.stevekallestad.com

3) current split is as follows:
st2.stevekallestad.com:
1 CSS File - 9504 bytes
11 image files - 17723 bytes

st1.stevekallestad.com:
1 javascript file - 148 bytes
7 image files - 12642 bytes

www.stevekallestad.com:
1 HyperText Meta Language file 5774 bytes

This is from the speed report, but I am aware that there is a 64K javascript file being pulled as well from st1.stevekallestad.com - and I believe there are some image files being brought in via css to one of the servers.

OK, now that I've done some work, I'm actually reading through the logs:

I cleared my cache and see that there are 28 http requests distributed as follows:

st2.stevekallestad.com:
1 css file - 2738 bytes
12 image files - 19351 bytes

st1.stevekallestad.com
2 javascript files - 65276 bytes
6 image files - 5422 bytes

www.stevekallestad.com
1 HyperText Meta Language file - 5707 bytes
4 css images - 5793 bytes
1 favicon 3638 bytes
1 RSS file 28151 bytes

==============
What was most surprising here was the rss file - 28K?!? I'm definitely going to have to re-think the rss feed autodiscovery strategy.

28 http requests is way too many, but at the same time, you have a lot of images implied in a message board context. I'm curious if I throw out proper etag headers if the requests will go away entirely or if they will simply be turned into request/304 response exchanges.

I revisited the main page and I see that the request is now down to 3 http requests - the request for the HyperText Meta Language page, responded with a 200, and the 2 javascript files - both returning 304 - which means that a repeat visitor to the home page should see a response extremely fast. Page generation takes .02777 seconds, transfer of the html file would take between .79 and 1.36 seconds for a dialup user. I can't imagine rendering time would be longer than 1 second even on an extremely slow machine - meaning that a repeat visit to the forum home page would take 2.5 seconds for a dialup user at the outside.

For the page to display for a first time visitor - at the very least the HyperText Meta Language file and the CSS file need to be downloaded. (I'm not sure if the CSS Images are necessary). Those two elements provide the Layout information for the page - everything else is superfluous. I actually created a vBulletin plugin this evening to ensure that all of my image dimensions are included in the HyperText Meta Language to alleviate any layout dependencies on image information. This means that a first-time dialup user would see information in the time frame between... 1.17 and 2.01 seconds. Images file transfer would take between 4.25 and 7.27 seconds. Javascript files would additionally require between 9.06 and 15.54 seconds. Superfluous files would add between 4.42 and 7.56 seconds.

It appears from looking at the logs that the javascript download happens before the images are completely loaded, but I'd have to run my system through a proxy to see exactly what the order of things is. It also appears that the RSS File is one of the first files downloaded, which is troublesome.

A dialup user sees information within 2 seconds. They get a full experience within 33 seconds (ouch!). I could easily trim that down to 25 seconds by removing the RSS auto-discovery and that's probably about as good as I'll get for the short term. I certainly could save a few hundred bytes on the image files, but nothing that would even translate into a full second cumulatively. If I look at the optomistic numbers rather than the pessimistic ones, I see a dialup user having full experience as quickly as 18.9 seconds, 14.5 seconds without the RSS feed. Realistic expectations (4.392K/second) put the total load time at 30.25 seconds.

30.25 seconds seems like forever, but...

30.25 seconds is the time it will take for the entire experience to load. The user should see information and clickable links within 2 seconds. If they don't want to stick around for everything to load, the files will eventually get to the user if they stop on any given page for any length of time.

My own broadband testing shows page visibility within 1 second and full download within 4 seconds.

I still have some adjustments to make, but worrying about this kind of stuff at the early stages makes for much easier scalability and for a positive experience for casual visitors. I think if I etag the javascript files I can get the whole thing down to a single request.

This whole post is firefox related. The files change slightly for IE so I'll have to check that one out separately.

I've done a good deal of work on my main site to increase the display time of data for dialup users and I hope to do the same thing here in the forum. Essentially, in order to get the page to display for a given article, in firefox the end user needs to download three files - the favicon, the man HyperText Meta Language page, and a 2K adsense file. IE will ignore the favicon, so two files within IE. From there, the page doesn't look great, but good enough to read until the remaining page elements download. I've built a plugin for vBulletin that provides size information for all of the images on a given page, and that's one of the primary factors in slowing down page visibility for IE. It appears as well, that moving stylesheet information into a javascript file, and including a basic set of style data on page to account for main layout parameters is the singlemost dramatic improvement that can be made - especially when you consider large CSS files like the ones that I push out. Of course, proper cache-control headers at the HTTP protocol level become absolutely necessary.