As I mentioned previously, the team has been working on a new online experience for the MSDN Library.  This experience is known as ‘Lightweight'.  It balances features and performance, while improving the user experience.  Users have been able to opt-in to use an early beta version of this view of the MSDN Library since Visual Studio 2010 Beta 2.  You can see it here: To make this view your default use the "big orange button" on the bottom-right side of the page. (Note: the "big orange button" is temporary for discoverability.)

In parallel, the team has been busily updating the MSDN/TechNET Publishing System (MTPS) Rendering subsystem to use ASP.NET MVC 1.0.  The team adopted MVC because it provides a number of technical and business benefits.  To list a few it provides an elegant way to bind multiple experiences simultaneously, gives greater control over the request/response pipeline and enables better global performance tuning.  As part of the adoption of MVC, the team has also significantly increased unit test coverage. 

The first site that will be available on this new system is the MSDN Lightweight experience.  You can see the work in progress at  Please expect some quality and availability issues with this beta site given its refresh model.  This site is updated frequently, sometimes as often as each source code check-in and with a current cadence of about once a week as we near release. 

The team's current release plan is to have the MVC version of the MTPS Rendering subsystem serving the Lightweight experience at  on March 4th.  The view will still be an opt-in option with this release.   Between March 23rd and April 7th, the Lightweight experience will become the default MSDN Library experience, with ongoing additional releases occurring weekly for the next month to address customer feedback.  Users will still be able to see the current ‘Classic' experience by selecting it on the preferences page.

With the Rendering subsystem release on March 4th, there will be a number of performance improvements.  The team took advantage that this was essentially a subsystem rewrite to improve and extend platform features that improve global response time. I would like to highlight some of these improvements:

1.       Enabling CDN caching for .js, .css and image files

Content Delivery Networks (CDNs) will be used to serve javascript, css, xap and image files.  NOTE: this is not enabled on the Beta site (, since it incurs a cost.  This makes the Beta site significantly slower than what the experience is on the official MSDN site.

2.       Using a hash of a file's content instead of a build number to version .css and .js files.

In the previous version we cached .css and .js files for 6 months by appending a build number to the file names. But in reality we were only caching them for at most 1 month since we were updating the build number with each monthly release. With this release we create a MD5 hash of the file's content and use the generated hash string as the file name, which allows it to be cached for 6+ months on CDNs and browsers.

3.       Enabling CDN caching for images on disk

In the previous version we were only caching images for 24 hours because we were not appending build numbers to the file names. With this release we cache the images on disk for 6+ months due to the fact that their hashed string will be referenced instead of their file names.

4.       Using image sprites for images on disk

With this release we also support images being repeated on backgrounds, which we were not doing in the previous release. In addition, the process to generate image sprites is much simpler.

5.       Crunching of .css and .js files

This is being done during build time, previously this done by individuals at code check-in.

6.       Removing  all unnecessary whitespace from the HTML response stream

In analyzing our generated HTML pages, we determined that unnecessary whitespace in the files accounted for about 10% of the total uncompressed file size. With this release we are removing unnecessary whitespace from the output html files in an response filter.

7.       Enabling raising ETW (Event Tracing for Windows) events in MVC projects

We are now able to raise different ETW events in the codebase to be able to accurately measure and track the code path while the application is running. The ASP.NET response filter is already raising these events to be able to measure the performance of that module. And all other parts of the pipeline are also able to raise these events.

8.       Adding support for dynamic images

In the previous release, if a user were to browse two different library pages such as System.Xml and System.IO, all images in the content have different URLs from page to page, even if the images were identical. For example, the pubclass.gif in the examples below has the following URLs:



This resulted in the same image being retrieved from the backend database and downloaded multiple times. These images were cached only for 24 hours.

With the support of dynamic images all images will have a unique URL (like that can be referenced by multiple topics, and the images will be cached for 6+ months.  This will significantly improve both client and server performance and also will decrease 404s errors for images in the database.

9.       Generating an image sprite for the most frequently used images in the backend database

We used the top 200 library page views list and also the top 100 images being referenced in content to identify a list of the most commonly used images in the database and added them to our current imagesprite.  These images will be served from a single imagesprite HTTP request rather than being downloaded via individual HTTP requests. This will reduce the total number of http requests. For example, in the System.Xml page there are 5 HTTP requests for images in the backend database that will be no longer be needed since those images will be retrieved by a single imagesprite request.

10.   Generating a single composite .css file during build time

All common .css files will be combined into a single composite .css file during build time. There will be a single HTTP request for .css files.

11.   Generating a single composite js file during build time

All common javascript files will be combined into a single composite javascript file during build time. There will be a single HTTP request for .js files.


The team is excited about this release and the improvements it will provide for the MSDN library and MTPS platform.   It continues our commitment to producing the best online and offline reference documentation experience - helping developers succeed with Microsoft's great technologies. 

We look forward to your continued feedback and we really appreciate it!  You can provide feedback right on the site by using that little orange balloon in the upper-right-hand corner of every library topic.