Select a language to translate this page!
Powered by Microsoft® Translator
We hope you’ve had a chance to try the new version of SkyDrive that we shipped a few weeks ago. You probably noticed that the performance of the web experience has been dramatically improved and redesigned for simplicity. In this post, I’m going to cover a few of the things we did to make the new SkyDrive web experience faster.
Our overall goal in the new SkyDrive architecture is to use HTML5 and modern browser capabilities to reduce or eliminate page loads and make each click feel nearly instant.
The old version of SkyDrive was based on a server-rendered architecture, which meant that every time you clicked on something in a SkyDrive web page, SkyDrive would essentially do a complete server-generated page load. 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.
As our tens of millions of users upgrade to modern browsers, we can take advantage of new capabilities and move to an intelligent AJAX architecture. The key to making AJAX performance great has to do with intelligent client network utilization since the client network is usually the biggest bottleneck to performance. We focused on four distinct things related to intelligent client network utilization:
So, let’s go into the details of what we did.
There is still a page load when you navigate your browser to SkyDrive. The very first time you visit SkyDrive (we call it PLT1 – first page-load) is slower than future visits (we call that PLT2) because we have to download a set of static resources from Content Delivery Networks which get cached on the client.
AJAX generally requires more client-side resources because more is happing on the client. We do some tricks to improve PLT1 such as pre-downloading SkyDrive resources when you’re at the login.live.com page so that they are already on the client by the time you get to SkyDrive. The other trick we do is to delay the download of a specific set of resources that are not needed immediately within the SkyDrive experience. (WebIM is a great example of this.)
Another page load optimization that we made was around how we generate the HTML page from our ASP.NET web servers. We used to wait to return the HTML page to the browser until we had constructed the entire page. To generate the SkyDrive main web page, we have to call multiple back-end systems and returning the HTML page to the browser was contingent upon these back-end calls completing.
The improvement we made was to flush and return HTML fragments to the browser as soon as they’re ready on the server. The key advantage here is that we can give the browser the HTML fragments that reference script and CSS almost immediately so that the browser can start downloading those resources (if not already cached) in parallel to other work that our server is doing (e.g. back-end calls). The idea is to get more working (especially networking calls) happening in parallel across the entire distributed system (client and server).
You may still notice that some parts of the new SkyDrive experience still require a full page load, such as editing the permissions of a folder, deleting a file, or arranging photos in an album. Right now, we only moved the SkyDrive file browsing experience and the photo viewing experience to the new AJAX architecture, but we will move the rest of the site in future updates.
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.
As I mentioned, we also use the JSON data format for this data access protocol which is network efficient, and browsers can parse it really fast. Since we’re almost always fetching just one page of user data, most of our data requests are only a few KB in size and are returned in milliseconds (of course depending on the end-user client network bandwidth).
The data returned via this data access protocol is cacheable by the browser. Client caching is really the biggest win when it comes to improving the performance of the experience. When a data request can come out of the client cache, it’s the most optimal outcome. In addition to the experience being faster, it also means that the request isn’t hitting our servers, which means our servers don’t have to do as much work, and it saves us money (we can have fewer servers). I’ll explain more on how we are caching user data below.
One other trick that we’re doing is that when you first go to SkyDrive and we do a full page load, we return the top-level user data, inline on the HTML page that is returned from the server. This eliminates a second round-trip to the server where we would have had to fetch the top-level user data. This is a good example of batching what would have been two requests into one request.
In the old SkyDrive web experience, if you went to view a particular folder, we would download a web page that contained all of the files in that folder. An example of a typically folder is the Windows Phone camera role folder that is stored in SkyDrive. Around 25% of Windows Phone users have around 1000 photos in this folder. Viewing a camera role folder with 1000 photos resulted in a very slow experience.
The new SkyDrive is much better at handling views of large folders because we added support for virtualized list views. Most people are familiar with this concept because most client applications, like Microsoft Outlook, use virtualized list views to improve performance.
The key idea here is that when a user views a folder with a lot of files, we only fetch and display what’s needed to fill the current screen in the browser. It’s incredibly efficient and fast because we are only fetching a small page of data from the server (few KB) or cache, and we’re only rendering a small amount of HTML. The other really cool thing that we did was utilize the browser scrollbar for allowing the user to scroll through the list. As the user scrolls, we are dynamically fetching data and rendering the list view. The end result is a very fast and smooth experience, regardless of how many files are in the folder.
As I mentioned, the ability to support virtualized list views is supported by our data access protocol because it allows us to fetch a specific page of files. You can test this out by going to a large folder of files in SkyDrive, and then hitting CTRL+END. You’ll see that you can quickly scroll and see the last page in the folder really fast because our storage system is able to quickly execute this query at the database level.
Client-side caching is critical to achieving great web performance because it allows us to completely avoid a certain set of network requests and render our user experience almost instantly, since the data is coming from the local computer. The more we can cache on the client, the better!
We’re doing two levels of caching in the new SkyDrive architecture. As I mentioned above, all of our data requests made to our HTTP/JSON access protocol are cached in the browser’s cache. If the same data request is made as a prior request, it will be served from the browser’s cache instead of actually hitting the network and calling our servers. This allows us to cache user data across SkyDrive browser sessions.
The next layer of caching is an in-memory data cache. This cache only exists for the current SkyDrive session. We have this cache so that moving back and forth between views is incredibly fast. Once we request data via our data access protocol, which may have been served from the browser’s cache, we hold that data in memory for the SkyDrive session. We do some tricks around pruning this cache so that it doesn’t get too large.
Another concept that we’ve introduced into the new SkyDrive architecture is the idea of pre-caching. If you go into the new SkyDrive photo viewer for a photo album, SkyDrive starts downloading photos so that when you get to that photo, it’s already on the local computer. However, if we pre-cache photos that you never view, we will have wasted some networking calls and server cycles, so there is a delicate balance to be maintained with pre-caching. We’re also doing another type of pre-caching in the file list view, where we fetch a few items beyond the current view so that scrolling is smoother.
We’ve embraced a lot of new web standards in the latest release of SkyDrive. As I mentioned, we use JSON to represent user data when we talk to our servers. We’re using HTML5 for CSS animations, reflow animations and other features. We’re using local storage for various parts of our caching support. We’ve also worked on making our HTML more standards compliant, so that everything you see works in as many modern browsers as possible.
We’re still evolving the rest of the SkyDrive experience to the new and faster architecture. Soon we’ll move more things to be “inlined” or driven dynamically from the client, instead of requiring full page loads. And we’ll also be moving actions, such as delete and move, to be asynchronous operations instead of page loads.
We’ll continue to focus on improving SkyDrive performance because we know that speed is an important part of making the SkyDrive experience useful.
Let us know what you think of the new, speedier SkyDrive.
Steven Bailey Development Manager, Windows Live
I really like the new SkyDrive... but it SERIOUSLY needs Mesh integration. Proper Mesh integration. And soon.
Great work guys, the new SD is great! However, there are some items that are boring. For example: not having context menus (right button) on files/folders is a big issue. I would like to right-click the file or folder name and be able to rename/delete/download/etc it. Not to click the (i) icon and click on the option on the menu on the right. Also, hope you bring soon drag-n-drop. The current experience of moving files/folders is not the best.
The good side is the new SD is great, hope to hear more news soon!
I had a really hard time prior to this release viewing photos and docs on my WIndows Phone and stopped using it resorting to loading pictures directly onto the phone. WIth these changes my pictures are loaded much faster and I can view full size faster (still could be faster). If this is a sign of things to come for SkyDrive count me in!
I just keep hoping that you can make HTML support :
- 1 clic fullscreen view
- overlay captions (this is the one feature that may get me bck to Picassa for photo sharing; I understand might not be the priority of everyone, but to me it was a key feature, showing pictures without a story is pointless for my needs, and no-one notices captions on the top-right corner, and if they do is just cumbersome to read).
- richer file handling possibilities (drag&drop, multiple select, whatever); which are now extremely limited.
- better sorting capabilities (want to be able to sort pics/files in both list/thumbnail view) according several criteria, and for it to be remembered across views (right now u lose the order when switching from list to thumbnail).
- remember view settings for each folder, and don't switch back to thumbnail view every-time we made a change on a file (like name change). Bring me back to the view I had selected... This is specially painfull since many operations are simply not possible from the thumbnail view...
And that's the basic stuff I'd like to be sorted...
This clearly is an imaginative but difficult project and my hat is off to you! Unfortunately in the redesign some seemingly minor features were removed or overlooked. User experience is not just defined by speed of access. I want to list just a couple. The first has been decried by many users: the lack of self-running slideshows. Since the technology is so charmingly demonstrated on the folder view with dozens of simulteneous little slideshows, it could not have been expensive in either development effort or time to also do so in the photo pages themselves. Those little shows make the lack of the bigger ones particularly bitter for users. The first release scattered action links all about - some corrections have already been made (the move function is the best example) - thank you. There still is not a way to get to the URL of an image without torture for the user (see ludwigkeck.wordpress.com/.../the-new-skydrive-hobbles-making-zoom-it-images) . I prepare teaching materials and want my students to use Windows Live and SkyDrive effectivly. With constant updates to the user interface this is extremely frustrating, time-consuming with much wasted effort when the instructions have to be redone. Can't you decide what SkyDrive should do, define the UI, then construct the underlying magic without the user needing to know about it? That does not diminish the laurels you deserve, it enhances them.
Ludwig makes good points. I'd just like to reiterate one that I made on the last SkyDrive post: please make the Tag feature display existing Tags that are embedded in the photo metadata.
Even better would be allowed to select multiple files to delete the folder and also move. The way it is is locked and if you have a folder with many photos and need to delete some of them is not practical to go deleting one by one, is very laborious and is not fast to use. The way it is, is very good, but with these suggestions would be wonderful and I would start to use real rather than play to use..
I have really enjoyed the new version of Skydrive and like the speed, neatness and great UI! I too would like to see better integration with Live Mesh and hope its coming .
When you add new features, could you please put a link or something on the main page of Live or Hotmail? You guys are too shy to show your work.
This is so important that I must join in and say; get a proper Live Mesh integration! I want to be able to see and edit all the files I sync in the browser!
I love all of the changes that have been made to SkyDrive! I also would like to second and third the additional changes, fixes, and additions made by controlz, w1ngut, danielgr, Ludwig Keck, Geoff Coupe, and cassiodonato. Thanks Windows Live Team!
Can you make it so we can zoom in on my panoramics? Otherwise, they are small.
I could not delete an empty folder unless I first switched into details list view and selected the (I)nformation icon then delete.
I've just had occasion to post the URL of an image on SkyDrive into a forum message, and as Ludwig says, you have really broken this with this redesign. What used to be a simple copy and paste in the old SkyDrive has now become a maze of twisty little passages, and you have to download the image again to the computer in order to finally uncover the URL.
What on earth are you people thinking of? This is NOT an improvement - it's an order of magnitude worse.
Be nice if I not only trusted this with my files, but I got off my laurels and bothered to use something newer than firefox 3.6
@SkyDrive team. For the past 4 days everytime I have been trying to access my skydrive contents, I keep getting a error
'We can't show you that page
Our server is having a problem. We're working to fix it as soon as we can, so try again in a few minutes.'
I have changed my country to US, signed out, signed back in, cleared every setting in the browser and even tried 3 different machines from 3 different internet connections. I believe this is a specific account problem and this was widespread late last year. Please fix this. my email id is techwhizard (at) hotmail (dot) com
Please look into my account as I need to access my skydrive contents.
@Karan Singh can you post your issue in the WIndows Live support forum and someone will get back to you. http://support.live.com
Wow...I am lost in all this geeky stuff. Oh well. All I care about is the speed, and it's there! Great!
"And we’ll also be moving actions, such as delete and move, to be asynchronous operations instead of page loads." Sounds great as this is among the most annoying things for me. But fixing this please dont forget the backend...the restrictions on what you can move, copy or share are at least strange.
Great job, guys!
Although, small bug on Windows Live Group pages has been found: title of the page is double HTML encoded.
As example for Russian language the title of the https://groups.live.com/ page is:
Группы — Windows Live
Internet browser performs decoding, and now the title looks like:
Группы — Windows Live
But as you can see, this html fragment should be decoded once again. Please correct this bug with double encoding.
Sorry, my previous message was already html decoded by blog engine so the post doesn't reflect the problem.
Please look into this issue on SkyDrive page directly.
@Ludwig Keck, from your blog http://wp.me/p15SHc-iz , if you look at the implementation of CSS3 position-float property on IE10pp2 (testDrive example), you will understand how smooth the future of web gonna be with HTML5 regarding dragging boxes. Well nice work there on your blog and you have raised some wonderful issues raise.
At the moment, the only thing I like to have in SkyDrive is a way (beyond mesh) to sync my IE favorites to SkyDrive. Where I can perform CRUD ops (create, retrieve, update & delete) on my favorites while sitting on web from anywhere & then it can be synchronized back to my IE on my PC or running anywhere (& sync back any change made locally) providing my LiveCredentials. This feature can also be extended to BingBar so I can use my favorites on other browsers (& platforms).
SkyDrive is great - but like many users today I access it from various different devices - and sorry, but the reality of life today is that not all of them are running Microsoft software! I use a PC at work, have a Dell laptop at home, and I also have an iMac and iPhone - the experience on the iPhone is a let down. An app would be good, or at least some way to at least upload /some/ files to SkyDrive - photos for example?
How about making our API public?
The tables are served in Json and could become a widespread enhancement for millions of skydrive users. Turning this API public (cross-domain calls available) would definetly reduce servers overloads that occur due to proxy's used to fetch content (Direct to Tim Acheson's Blog: YQL Example for better understanding).
It is time to keep up with the competition, turn this feature public and available for all developers.