I called Kim, the Development Manager for the project and I asked as many leading questions as I could, in order to find out what they were planning to do with this, how it was done, and if there were any hidden features. Sometimes folks kind of give MSDN a hard time for having fat HTML, lots of scripts, etc, and generally being slow. Turns out there's a whole ongoing project to make MSDN way faster and it's already seen some really significant improvements. I've got some internal slides she smuggled my way that I'm going to share with you here, so don't tell. I figure show first, ask question later, right? This is great stuff.

MSDN Performance

They use a number of tests at MSDN to see how fast the site is running, including Gomez and Keynote. Keynote and other tools not only do testing like YSlow and the like, but they do location testing to make sure the site is fast all over the world. That means testing it on a modem in China and DSL in Australia, etc. For example, you'll see Guangzhou, China appear in the slide deck a lot because it happened to be where MSDN loaded the slowest. The roll-up slides (for bosses) show Seattle, Paris and Beijing. In some places there was missing data.

Here's a slide from last Feb before the big performance push started. Notice the page sides is between 200-250k and the response time in China is 10 seconds. Good, I suppose, but not fast.

They'd test MSDN on first load, then second (cached) load. They called that PLT1 and PLT2 respectively. The first load of MSDN was like 1.3 megs. Insane. Adobe's site was 800k+, Java's was 800k+, but library sites like Ruby and Eclipses around 200-300k. A meg is not cool. They broke it down by JavaScript, HTML/CSS, Images, etc.

Over the next few months, they started moving CSS and scripts to separate DNS for HTTP Pipelining, reduced the number of redirects, were smarter about JS caching, lazy-loaded the Table of Contents. They started caching scripts at CDNs like Akamai and ChinaCache, reduced or removed ViewState.

Then the idea of flipping the whole thing on its ear happened. Rather than removing this and that, why not remove EVERYTHING, and only add back what was needed. Hence, the loband version was created.

Here's some performance tests between the loband MSDN on an unnamed technologies very-fast library site (you'll have to click the image to see the numbers):

The loband MSDN site can get sub-second times in the states and very close to one-second times outside the states, including Guangzhou, our previously slowest location.

Early versions of loband were 25k, but some changes brought the average down to just over 15k. Caching changes and other optimizations brought the performance by region down to under 2 seconds basically world-wide.

Here's an interesting graph showing the size of JavaScript, HTML and images on MSDN and a bunch of other sites, including http://www.asp.net. In this chart, regular full MSDN in Feb of 2008 is the FAR left bar, and MSDN in July is the second from the left. The loband size is the second from the right.

You can click "persist low bandwidth view" if you want to make it your default. Also, they are paying close attention to the Feedback forum, so click that if you have more ideas. The next version of the loband site will be coming out in the next month and looks like this (sneak-preview):

Additional MSDN "Switches"

I figured there can't just be the (loband) "switch" and I mentioned I thought that having to hack the URL was kind of wonky. Turns out that the whole MSDN system isn't a bunch of files on disk, but files in a database with an ASP.NET Virtual Path Provider. Tim Ewald wrote about how they did this WAY back in February of 2005. This was, at the time, kind of a poor-man's ASP.NET Routing:

The normalized path points to a file that does not exist on disk. Rather, the page data is stored in the content cache. The system uses a VirtualPathProvider (VPP) to bridge the gap between the two. In essence, a VPP intercepts all of the ASP.NET plumbing's requests for file streams and gives you a chance to load them from wherever you like. Every ASP.NET app uses a default VPP that simply maps to the file system. An MTPS-based site registers a custom VirtualPathProvider, which sits in front of the default VPP, forming a chain. The custom VPP uses the DocumentInfo and ContentSet objects that the HTTP module's OnPreResolveRequestCache event handler stored in HTTP context to load a topic from the content cache and return it as an .aspx file stream.

All of this is abstracted away, and what I'm calling a "switch" in the URL is what MSDN calls a "device" internally. The URL is just one way to indicate to their routing system that you are a certain device. The other way is via a User-Agent string, as you'd expect.

The content in MSDN is stored as XHTML, but then other controls are injected around it, similar to master pages. The whole page doesn't yet validate. If you think that's important, put it in the comments. If we get hundreds of comments here I'll pass them on to the team as "evidence," heh, heh.

There are in fact many "devices" for various reasons in MSDN. Most are turned on my User-Agent differences or for things like the Printer-Friendly view. However, you can force the device by inserting the device name in to the URL like:

Printer-friendly - (printer)

MSDN Inside the (IDE)

When MSDN library content is viewed inside the Visual Studio IDE, a few things are added. First, the ability to Add Content via the MSDN Wiki is promoted to the top, as well as a "send" and "give feedback" feature. This is the view you get when you're inside the "Document Explorer" - the Visual Studio MSDN help browser.

MSDN for Visual Studio 2010

Here's a zoom in to a nice detail. Currently on MSDN online there's a filter dropdown to choose what language you want to see code samples in.

This live prototype has the languages for code samples appearing as tabs (as see above) including the option to "View Plain" or "View Colorized." There's also links to Copy to Clipboard or Print just the sample directly.

Future MSDN Plans

From what I hear from Kim, there's plans in process now for the loband site to become the default site this fall. They'll call it something like lobandlight and it'll have some small additions like a search box, selectable codeblocks, but the focus will be on being fast and clean. If you have opinions either way, leave them in the comments here or in the loband forums and they WILL be read by the MSDN team. Also, right now loband only works on the library, so while you can try these "devices" on other parts of MSDN, it's only currently designed to work with the MSDN Library itself. If you feel strongly that other parts of MSDN need loband lovin', let me know here and I'll pass your comments on directly to my boss.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

I've been using the lowband for quite a while, but I had to write a Greasemonkey script to hide the languages I'm not interested in (otherwise there's often a lot of scrolling)

Do you know if there's any plan to add language filtering to lowband? And hopefully the vs10 version is not going to default always to VB on the visible tab...

Will Dean

Saturday, April 18, 2009 12:01:52 AM UTC

As far as recommendations, there are some client side filter/search things you can do, it takes about 6 lines of jquery so if you get to a page like http://msdn.microsoft.com/en-us/library/system.linq.expressions(loband).aspx and you are looking at the crazy list on the bottom left and are kind of sick of hitting Ctrl+F in your browser all the time, they can have a box to filter that list on the client. Would make it much easier to get to System.Workflow if you just type Workflow in a box and everything else goes away, for example, and once you load jquery once there is no more overhead. I'm always scrolling and Ctrl+F'ing on MSDN.

Jarrett

Saturday, April 18, 2009 1:19:51 AM UTC

Thanks for sharing!

I like the loband version much better. The slow loading of the msdn page is actually the #1 reason why I avoid msdn if possible.

And yes, XHTML validation of the whole msdn page would be a nice addition, too.

Thomas Krause

Saturday, April 18, 2009 2:33:36 AM UTC

Being on low bandwidth, I used to hate having to visit msdn. Thanks. This is some sickeningly fast speed. Would it be possible to incorporate something similar in http://forums.asp.net?

Can you get them to fix the url's with (what I assume) hashes in them?

http://msdn.com/library/jk2h42jk3(vs23.7).aspx is not the easiest to read.

What's wrong with MSDN.com/library/system.windows.forms.form

Also IMHO, it would be better if the .NET people did what the win32 people do and instead of having multiple versions of the docs and having to compare them manually, they would just call out the differences. The confusion between VS and Framework is also irritating.

Fowl

Saturday, April 18, 2009 3:29:24 AM UTC

Oh yeah and brackets (parenthesis) break the automatic link detection of ~95% of websites, so they should be prepared to take urls that have been truncated to http://msdn.com/library/system from http://msdn.com/library/system(web).aspx

Fowl

Saturday, April 18, 2009 3:47:30 AM UTC

I suggest the MSDN server also be capable of detecting the case of a user coming in from a low bandwidth connection and automatically trigger the low bandwidth/lightweight browsing mode.

Hey, Scott! Please tell them they must add the language filter to loband view and ability to persist it's state to all views. I'm sure, for 90% of users that's one time choose for their only language.

It's very embarassing - having to select c# everytime when looking at msdn, including IDE view.

p.s: i understand, that's probably undoable, but would love to see c# as default (first in case of 2010 view)

Alexander Gornik

Saturday, April 18, 2009 9:11:19 AM UTC

Scott - is there any way to persist any of the other "devices" - e.g dev10ide - as the default? dev10ide is clean and seems to load faster. And the language tab seems to stick on the last setting - I like that. I've never been able to get my language settings to persist on the "regular" version - I sure get tired of setting that again and again. Is there a language setting the loband version?

MSDN has been getting better over time - probably both due to the work you've outlined in your post and faster browsers. I'm glad to hear about the focus on it at Microsoft and new, faster versions being engineered.

What they really should do is a silverlight version :)The treeview on msdn always bugged me.. i hate scrolling around in it and i wish it'd autohide/appear like it does in dexplore (in vs)another thing i totaly miss at the msdn site is the index feature also available in dexplore :/One thing i do miss in dexplore though, is the community features (i usually go for the offline version of the docs for speed)

A silverlight client for msdn could bring the best of both worlds, localstore for caching and connectedness for the community stuff :) this is something anyone could build if there was an xml version of msdn with nothing but the data.. (if such a version exsist pleeeease publish/point me to the api)

hey there apparently IS an api for msdn (and technet)check this out:http://www.pluralsight.com/community/blogs/craig/archive/2006/06/12/27273.aspxand thishttp://services.msdn.microsoft.com/ContentServices/ContentService.asmx (includes the wsdl)

Scott, thanks for highlighting these features. I am stoked to hear that MSDN striving to reach a broader audience of device-types. If they do it well, that'll mean increased searchability by the predominant search engine(s).

Myself, I haven't actively searched MSDN because I felt it was way too heavy with their treeview, etc. The presentation was not easy to look at. I appreciated the new view in loband.

I have no need for document explorer, at all. Never used it since I started using VS in 2005. Then again, I'm _never_ offline, so the website always works.

Also, a designer should have a look at some of the details. This is really nitty gritty, but the little icons etc have _never_ lined out right on MSDN. Look at the little lock icon on http://msdn.microsoft.com/en-us/library/system.xml.xmlnode(dev10ide).aspx or the collapse icon on http://msdn.microsoft.com/en-us/library/system.xml.xmlnode(ide).aspx It's minor, but I always wondered how something like that could not be noticed for 4 years (at least), as a webdesigner working on a page, I would immediately go and change the inline img tag for a background-image css rule with some padding...

Mike

Monday, April 20, 2009 4:43:26 PM UTC

Does somebody else host http://blogs.msdn.com ? I always suspected that someone else must host it because the availability is pretty awful while the normal msdn site seems fine. I've thought, - What a terrible showcase for MS technology. "We're unable to service your request at this time" - Ugh. Can't tell you the times I've seen that message.

Dave T

Monday, April 20, 2009 5:34:08 PM UTC

This looks absolutely awesome! I hope they find a way to implement some performance changes for blogs.msdn.com as well because that site is always *dog slow*. It's like its under a constant DDOS attack even when no one is really using the site. Just try visiting any blog hosted there like Raymond Chen's or whatever during various times of the day...terrible.

Terry

Monday, April 20, 2009 7:35:16 PM UTC

I love the view, and will use it exclusively when reading online. However, using IE "Send to OneNote", it does not render in OneNote well at all. I prefer the "pda" view for rendering to OneNote. Any chance of getting the usability of "loband" with the OneNote rendering of "pda"?

Nick

Tuesday, April 21, 2009 4:51:48 AM UTC

The lobandlight version is a great idea, and i look forward to the new styling (as the current loband styling is a bit ugly).

What i would hope for is a way to persist your preferred language(s), or in the very least being able to select it with one click and not having to uncheck several checkboxes. I can't think of a time when i have needed to view the same example in more than one language.

Xian

Tuesday, April 21, 2009 6:02:39 AM UTC

What about offline reading? I would like to be able to create a pdf of a WHOLE section like say WCF at:http://msdn.microsoft.com/en-us/library/ms735119.aspx.

For example, be able to rightclick on the "Windows Communication Foundation" node and create a single pdf of all the pages between the "Windows Communication Foundation" node and the "Windows CardSpace" node so I can read it top to bottom. This experience for me is better than bouncing between the treeview to expand nodes and reading in the right pane. This does not work in many eReaders.

Abdu

Tuesday, April 21, 2009 5:36:29 PM UTC

Searching it is still a pain. For a lot of topics, when I google search I end up in either the Japanese or .NET 1.1 version of the documentation. Is this a known issue and one of the "benefits" of using Live Search, or something that no one else has noticed?

Abdu,You can do the packaging through PackageThis at http://packagethis.codeplex.com/

Package This is a GUI tool written in C# for creating help files (.chm and .hxs) from the content obtained from the Library via the MSDN Content Service. You select the content you want from the table of contents, build a help file, and use the content offline. You are making personalized ebooks of MSDN or TechNet content. Both help file formats also give full text search and keyword search.The code illustrates how to use the MSDN Content Service to retrieve documentation from MSDN or TechNet. It also shows how to build .hxs files and .chm files programmatically.

Got one thing to say. All the programming codes are displaying in "Courier" font, instead of "Courier New" font. Thats an annoying font. "Courier New" is more pleasing to read. The other font is really annoying (atleat for me) to keep on reading.

I wonder how come the "courier new" font is changed that "courier" font. Is that another "hidden (annoying) feature"? or else is there any tag there to read the programming codes in more pleasing way.