Monday, January 02, 2006

Bad, bad, bad web design

I used to think a certain news organization's homepage ran so incredibly slow (18 seconds to fully load on a T-1) because it had an incessant amount of client-side JavaScript running in the background; or an uncommonly large number of un-precached images; off-site images; an inferior, underperforming CMS; a lack of server memory; or a poorly-selected web server. It's actually a combination of those, but I think I've managed to find the main culprit.

I'm running an HTTP monitoring service on my Windows XP Pro box and watching the request/response traffic for an uncached, cookieless load of the site's main page. Turns out, when requesting the site's homepage, a browser does 10 different DNS queries. Good grief.

Not only does your machine have to map the IP address of the web server (which was for awhile Zeus, in and of itself a problem), but an internal ad server, servers for dynamic remote ads "inserted" on the homepage by way of loading an IFRAME, a stats server to, I assume, log traffic, and other administrative functions. Wow. That's totally inefficient.

Fragment caching and web services, baby - one request, one DNS hit...that's the way to go.

Comments:
intersting read...thanks for sharing it
 
Hi there PWD,

Thanks for reading my article. I did find this rather interesting/amusing/educational/harrowing in a way. Take this as a lesson learned for people developing big, portal-style sites with lots of data to display.
 
Post a Comment



Links to this post:

Create a Link



<< Home

This page is powered by Blogger. Isn't yours?

Subscribe to Posts [Atom]