Who Deserves Blame For Microsoft's Slow Site?

Yesterday I had a brief oh-<em>that</em>-would-explain-it moment when I read <a href=" http://informationweek.com/news/showArticle.jhtml?articleID=205602129">Windows Server 2008 Behind 'Slow' Microsoft.com</a>. I spend a lot of time on Microsoft's sites, and they have been horribly slow the past few months. But after further investigation, I don't think the problem is Windows Server 2008. Or, at least it's not the main problem.

Dave Methvin, Contributor

January 11, 2008

2 Min Read

Yesterday I had a brief oh-that-would-explain-it moment when I read Windows Server 2008 Behind 'Slow' Microsoft.com. I spend a lot of time on Microsoft's sites, and they have been horribly slow the past few months. But after further investigation, I don't think the problem is Windows Server 2008. Or, at least it's not the main problem.Let's take the MSDN site as an example, because I visit it almost daily. The home page makes 69 HTTP requests, a total of 419 Kbytes of files. On my 15 megabit-per-second Verizon FIOS connection, it took 12 seconds to load the entire page. Just for fun, let's compare that to the Google home page, which makes only three requests for 18 Kbytes of data and loads for me in 230 milliseconds. No matter what you do, fatter pages will always take more time to load.

The problem isn't just the size of the data, though. The design of the MSDN page contributes to the glacial sluggishness as well. There are about 30 scripts on that page, and they are embedded in a way that prevents the page from even appearing on the screen until all 30 scripts are loaded and run on your system. In the meantime, you're stuck looking at a blank browser window.

If you need proof that larger pages can be fast, go to the InformationWeek home page. It loads about as many bytes as the MSDN site, but uses fewer requests and structures them so that some of the page is visible after one or two seconds. The rest of the data fills in the blanks as it is pulled from the site, and it's done in about four or five seconds.

It's especially ironic that the Microsoft Developer Network site is so poorly designed. Are customers supposed to use the development tools and techniques espoused on a site that takes double-digit seconds to load a page? What is the root problem here? Is it just sloppy work, or is there a fatal flaw in ASP.NET technology that makes it difficult to write fast Web pages?

By the way, I'm able to pull out the detailed information about these pages because I'm using an awesome tool: Firefox. When you combine it with the Firebug debugger and Yahoo's YSlow, it's even better. I sure hope Microsoft uses something like it.

So my take is that the problem isn't an inadequacy of Microsoft's server operating system, it's the design and complexity of the Web pages. Microsoft is definitely making itself look bad by running a sluggish site, but the Web site designers (not the Windows Server group) should take the heat. And just in case you're wondering, the Microsoft site isn't faster in Internet Explorer than it is in Firefox. It's slow no matter which browser you use.

Read more about:

20082008

About the Author(s)

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights