One of the more interesting things that Microsoft has been doing lately is providing some nicely detailed background on the work that has gone into re-designing some of its web services.

The latest one to get this treatment is SkyDrive’s web page with some background on how it was built previously to the newest refresh, and then what went into its HTML5 re-birth.

In the older version of the site the code behind the SkyDrive pages were what is called “server-side” or “server-rendered”, which means that all the heavy lifting was done on the originating Microsoft servers. This essentially means that ever action you wanted to carry out on the page needed to be sent to the server, handled, and then the results of those requested actions were returned to your browser and after the page was refreshed.

A page load is a very slow process which generally takes many seconds to complete due to the lack of client-side caching and numerous client-server round-trips. This meant that every user action would take at least a few seconds, which was clearly not ideal. This was a “least common denominator” approach that catered to people with old browsers.

With the redesign, the SkyDrive team went back to using AJAX, which they had tried to use originally but found that at that point in time AJAX wasn’t up to the task.

However, with both the improvements in browsers and AJAX, along with the introduction of HTML5, the team felt the time had come to revisit its use where they focused on the following four key points:

1. Reduce the number of client-server requests (client-side caching).
2. Reduce the payload size of each request (get only what you need and compact protocol).
3. Reduce the number of “miles” a request has to travel (put servers/Content Delivery Networks close to users).
4. Make the most out of each request (utilize batching and pre-fetching).

With all this work, there were a couple of things that made a real difference, especially with regard to optimization, was by moving as much of the workload to the client side using HTTP and JSON,

As I mentioned, the biggest change we made was around moving the SkyDrive file browsing experience to AJAX, which means we render the SkyDrive user experience on the client. This allowed us to eliminate full page loads and make browsing feel instant. To move to this client-driven, client-rendering model, we needed the ability to fetch SkyDrive user data (not HTML) from our servers, so we built a data access protocol which is based on HTTP and JSON.

The data access protocol allows us to efficiently fetch the user’s data that is required for whatever the view the user has chosen in the web experience (e.g. show the first 20 out of 100 documents sorted by name, in the “School Project” folder).

The data access protocol supports sorting, filtering, and paging; and the API essentially maps one-to-one with the types of views that the user can generate from within the experience. The key is that we can perform one server request to fulfill a view.

It’s important that our servers are able to execute and return data via this API quickly. We achieved this by performing all of the data sorting, filtering, and paging in our SQL Server database tier. We used to pull a large swath of data out of our SQL Server and then manipulate it on our ASP.NET servers, which was inefficient. The optimal thing to do is rely on the power of SQL Server to optimize and execute queries in a way that lets us get back and return only the data that we need.

There is a lot more to this,and it’s well worth taking the time to give it a read to understand all the work that went into improving the SkyDrive experience, so head on over to the Inside Windows Blog and check it out.

[Cross-posted at Winextra]