Live Search is a Web-based search engine launched by Microsoft in September of 2006. The application offers users the ability to search a variety of different types of information, including but not limited to Web sites, news, images, videos, music, and maps. The team recognizes that, to be competitive in the search market, a well-performing product is a necessity to winning with users who have come to expect near immediate results from the competition. This passion and commitment is evident in the way the team approaches the performance of the application; however, this was not always the case.
Shortly after Live Search launched in 2006, the team realized that its performance was suboptimal. Although team members had spent a lot of time testing the application, they did not adequately test the page rendering performance and subsequently released a product that did not perform as well as they would have liked. Fortunately, these issues were quickly recognized, and the team began making changes to improve the performance of the site.
The team realized that several of the application’s performance issues were related to user interface and architectural design decisions whose implications were not fully understood. The application’s design was promptly re-evaluated, and the team moved to implement many of the best practices mentioned in this chapter, including specific practices like combining scripts and redesigning the page to reduce the size and number of images. The results of the team’s efforts included an equally attractive but improved page loading experience for the users, as well as a newly discovered dedication to performance for the team. Eventually, the Live Search team became one of the most performance-focused Web application teams within Microsoft, and its focus is evident in the way it incorporates performance best practices into its end-to-end application development process.
The Live Search engineering team has developed a great deal of experience over the years in the delivery of high performance Web applications to a global audience. As a team, it recognizes the depth and complexity of the engineering challenges it faces and has spent many release cycles perfecting its practices. The team adheres to a set of guiding principles that govern how it considers performance when delivering its software application to market. These principles include:
The team believes strongly in setting budgets for certain page load characteristics like the number of get requests, the time to load the page, or the total byte size of the page. These goals help to drive rigorous application design practices or feature tradeoffs to ensure that pages that enable key usage scenarios continue to perform well. Oftentimes these budgets require very creative design tradeoffs that could change the way a specific feature is developed. The team believes, though, that this principle is the first line of defense against developing poorly performing Web application pages.
In conjunction with setting goals and budgets for page load characteristics, the team also believes strongly in running performance test cases before features are checked into the source library and after features are complete. While this practice does not necessarily prevent features from being checked in that exhaust the budget, it does introduce a certain rigor into the development process that provides early insight into poorly performing code changes. Additionally, this practice also ensures that performance bugs are being logged early and often so that developers have time to address the issues with the code before the application is released.
Experimentation, or A/B testing, is a more advanced approach to understanding user behavior on Web sites. It generally requires a mechanism that allows certain features or application changes to be released to a small subset of users so that behavior can be observed through instrumentation and used to drive feature decisions. The Live Search team has leveraged this methodology to increase its understanding of how performance affects user behavior. The team subsequently incorporates the knowledge gained from these experiments back into the features of the application. The team has used this approach to learn the impact of page size, load times, and even the number of search results displayed to the user. While this requires an investment in a mechanism to enable this type of testing, the results are clearly valuable to product development and improvement.
The team has learned that, if it can anticipate user behaviors, it can improve the performance of the pages that the user subsequently visits. The team accomplishes this by preemptively downloading scripts asynchronously prior to a user actually visiting the page that requires those scripts. For example, if usage data indicates that a user who wishes to search for images will generally want to preview those images before clicking on them, then the application is built to proactively download the scripts required to render the image preview, before the user even gets to that page. This approach does not interfere with the use of the initial page, and it speeds up the loading of the subsequent page, which is beneficial to the user. Although not listed as a best practice, this approach clearly demonstrates a certain creativity and level of dedication to ensuring application performance is maximized for the user.
Since becoming keenly focused on application performance, the Live Search team has found the above-mentioned set of principles to have had a very positive impact on the quality of the code and the overall application performance. These principles collectively have helped the team to incorporate performance excellence into its engineering processes and continuously innovate on its services while still achieving a high level of quality and performance. Although the team continues to learn about the usage of its application and how best to optimize performance for its key usage scenarios, it has found the following lessons and practices have yielded the best results.
The Live Search team has learned that poor end-user perceived performance has little to do with server latency or server health but rather the number of get requests, the number of serialized get requests, and the way in which the user receives the page. Therefore, the team spends a lot of time and energy optimizing the way in which it delivers the pages to the users and less time worrying about how quickly the server is processing the page request.
As previously mentioned, the team has incorporated performance analysis and testing into several different places within the engineering process. To enable that testing, the team built a number of custom test tools that leverage applications like Network Monitor, Fiddler, HTTPWatch, Firebug, and others to monitor certain page load characteristics in its development and production environments. These tools continuously evaluate the application and ensure that bugs get logged when issues are discovered and appropriately assigned to developers to address.
The team strongly believes that application developers should learn and incorporate the performance best practices whenever possible. More specifically, the team believes that the most impactful changes that can be made to any Web application include making fewer requests, consolidating scripts, reducing image sizes, using CSS Sprites, enabling HTTP compression, and incorporating edge caching using a CDN.
The Live Search team clearly believes strongly in the importance of incorporating performance excellence and best practices into its engineering processes. This is evident from both the way the team governs its engineering processes with respect to performance as well as the way the application performs in the production environment. The team continues to raise the bar with respect to Web application performance best practices among all Web-focused teams within Microsoft.