In June, we wrote about IE9’s support for ECMAScript 5 (ES5) and published a TestDrive demo to explore some of the features. With IE9 Beta available, it’s a good time to talk about how developers can use ES5 to improve their code. Many of the features in ES5 are designed to help developers working with very large code bases by making the language both more robust and easier to maintain. In this series of blog posts we’ll look specifically at how ES5 helps you write more reusable code.
For this post, we’ll focus on how ES5 makes it easier to create and clone objects and helps you ensure that your code is robust to mistakes when it is reused – even if you’re the only developer who will be using it.
When we released the IE9 beta about a month ago we talked about the importance of trust and confidence when working with downloads. Today, we are enabling the SmartScreen application reputation service to improve download protection for IE9 beta users. This feature works together with the SmartScreen anti-malware service that protects IE8 and IE9 beta users every day.
You can experience the protection of the SmartScreen application reputation service yourself by ensuring SmartScreen is enabled. Just click the Tools Button | Safety | Turn on SmartScreen Filter menu item, then choose Turn on SmartScreen Filter in the following dialog.
In the first post of this series, we described how add-ons can decrease IE’s performance during tab creation. Many users with add-ons enabled have noticed a performance improvement when they open new tabs after disabling their add-ons. We also walked you through how to measure add-on performance and identify areas of impact using the Windows Performance Tools.
In this post, we delve into methods and best practices developers can use to improve their add-ons’ start-up performance, first time and every time. A great place to start is by minimizing the number of DLLs and dependencies associated with an add-on and by delay-loading these DLLs where possible. We show the bare minimum amount of code an add-on needs to run during initialization to ensure the fastest performance, and show how using the SetSite() implementation in the example below, we built a toolbar that has only a 0.01 second average load time in IE. We’ll also show you how to investigate add-on performance problems using the Windows Performance Tools, and will use the data to highlight the various performance footprints that are the results of several common add-on coding mistakes today.
Once again, we ask add-on developers to use the information from this post and start applying performance optimizations today. Improving your add-on’s load time also differentiates your add-ons from other slower add-ons when compared to each other via the Manage Add-ons window.
Typically in blog posts we focus on the negative feedback we’ve heard, and the changes we make in the product as a result. In this post, we’re going to do something a little different. Below, we share the public feedback about the add-on performance advisor that we’ve heard, as well as some comments that show how aligned we are as an industry around performance.
From the Houston Chronicle:
One of the most interesting features of IE9 is its improved ability to manage browser add-ons.… You can turn all or some of them off, and you’ll like how much faster IE launches when you do.