Minimizing Page Load times in vBulletin is a matter of following simple optimization techniques. For my particular implementation, I am adding a menu script and a lightbox script that significantly increase the weight of the pages, but in the end my optimization includes this functionality with page load times faster than out-of-the-box vBulletin.
I looked primarily at three pages - the main forum page, the thread view page, and the forum view page which lists all of the threads. Looking at the javascript included in these pages, I came up with a list of several javascript files that are included as part of regular viewing:
- vbulletin_global.js
- vbulletin_menu.js
- vbulletin_read_marker.js
- vbulletin_ajax_threadslist.js
- vbulletin_post_loader.js
- vbulletin_ajax_reputation.js
- vbulletin_textedit.js
- vbulletin_quick_edit.js
- vbulletin_quick_reply.js
- vbulletin_ajax_threadrate.js
- vbseo_ajax.js
Add to this list of files my menu script, lightbox script, and of course prototype and the scriptaculous builder and effects files. Additionally, I found some common javascript included in the templates and I built my own javascript file to include these small functions.
That's a lot of javascript. And a boatload of http requests! To top it off, there are a few CSS files - one for vB, one for the lightbox, and one for the menu system.
To resolve the CSS issue, I combined my CSS files into the main vBulletin CSS - appending them at the end of my MAIN CSS section. I then took the produced CSS file and ran it through a CSS compression utility. From there, I moved the CSS stylesheet off to lighttpd, where the file can also receive gzip compression. (This isn't for everyone - some browsers and I don't know what they are don't like gzipped CSS - IE7 and Firefox 2 don't seem to have a problem on WinXP). The savings in the CSS without gzip compression was approximately 2K (from 11297 bytes to 9237 bytes). Gzip Compression takes it down to 2742 bytes.
To resolve the Javascript issue, I combined the javascript files into a single file - taking a bit of care to ensure that the order of these files was preserved. I then ran them through my combination of jscompact and jspacker. The resulting file brought the load from 334054 bytes to 116477 bytes, and with gzip compression the reduction meets 48672 bytes, more than an 85% reduction in file size.
I also took a look at most of the images on the main page. I saw that there certainly was room for improvement in file size, so I took advantage of Fireworks export utilities and compressed the images as much as I could, although a thorough look at the images is definitely in order. I mainly concentrated on images with offensive file sizes.
When I first ran a speed report, I saw 22 objects with a size of 393184 bytes. On a 56K modem, according to http://www.websiteoptimization.com the load speed was 82.76 seconds. The speed report now shows 34.39 seconds, but I am noticing that it does not take into account gzip compression and that the number of files is not accurate. I plugged the values into excel and ran my own numbers. Using their calculations of page load speeds, the load time for my main forum page should actually be 17.63 seconds. This does include latency adjustments, and my own conservative 56K speed guestimation puts the load time at 17.75 seconds. Looking at raw figures, however - multiplying the number of bytes by 8, and then dividing by 56000, I show a page load time fo 11.24 seconds under ideal conditions on a 56K modem.
These numbers reflect an initial page view load time. A repeat visitor, or a visitor perusing multiple pages would see a very significant reduction in load times because the images should be cached, as well as the javascript and css files - consecutive load times would be less than 1 second (or .79 seconds to be exact) with proper caching techniques in place.
There is some work to be done. I want to move all my static images and files over to lighttpd for increased processing speed server side, and to achieve the best pipelining performance. Further, I do take advantage of eAccelerator caching mechanisms, but using a file based templating mechanism or exporting templates using a combination of the vBulletin data manager and memcached would decrease server load and increase processing power a good deal.
I also have a thought on load detection and output caching. Most caching mechanisms that I see deal with caching certain templates or query results. During peak load times, especially if you are getting hammered by a social networking rampage, output caching for not-logged-in users could increase the capability of your vb Server from the neighborhood of 10-20 requests per second to several thousand requests per second. I've done a little testing and I absolutely like what I see. I will release a caching plugin once I get around to it, hopefully this month in conjunction with my MT/VB Integration, my MT Syntax Highlighter utility, a couple of other MT Plugins, the stopmomtop website, and my web development toolkit. I have a lot of projects coming up for completion right now which is one of the main reasons my last several blog posts have included a fair amount of babbling as I'm more concentrating on getting some things done than in comprehendable communication. :)
Discuss Minimizing vBulletin Page Load
