September 1st, 2010
The platform previews show the focus in IE9 on performance, interoperable HTML5 through same markup, and hardware acceleration. We’ve also posted here about the work we’ve done with add-on developers, and we shared some data about add-on performance and how we measure it.
In this post, we cover more of our thinking about measuring add-on performance and how to help consumers to stay in control of their browsing experience.
Add-on Performance and Site Performance
We’ve written about the different dimensions of performance in the web platform. We have also talked about the role add-ons play in overall browser performance. Site developers want a reliable, fast platform to run their web sites. Consumers (site visitors) want a reliable, fast experience of those sites. The perception of site speed includes the user’s experience of the site, the browser, and the installed add-ons.
As discussed in Add-on Performance part 1, add-ons can have a material impact on site performance and the consumer experience. Our goal with IE is that users have everything they need to make informed decisions and remain in control of their browsing experience.
Measuring performance to inform decisions
It is important that people stay in control of their browsing experience. This includes many aspects of using the browser including downloads, privacy, security, and controlling which add-ons to use. The ideal experience allows people to have exactly the add-ons they want – no more no less.
For users, there is a basic cost to benefit decision to make with add-ons. To make an informed decision, the user needs to have a clear view on the costs of the add-on as well as the apparent benefits. Most people understand the benefit they get from using an add-on they choose to install. It is more difficult to understand the full cost that add-ons bring to your browsing experience in terms of performance, responsiveness, and reliability.
When we introduced Web Slices, Accelerators and updates to search providers in IE8 we started a pattern of making sure that people are in control of the add-on capabilities in their browser. These types of declarative add-ons do not have performance or reliability costs to the browsing experience. The main impact they have is taking up space in the favorites bar or right click menu. Sites can promote web slices or add-ons, and the user is in control to decide whether to add them or not. This is an important part of the add-on experience even for savvy users; namely that people must consent to have the add-on.
For the types of add-ons that do have a potential performance and reliability cost (toolbars and BHOs), the user needs additional information. IE8 users can see the load time for add-ons in the Manage add-ons dialog. This is a good start, but there is more IE can do to help people fully understand the impact an add-on has on browsing performance.
Ideally IE would measure both load time and the additional time it takes to navigate to sites (navigation time). Measuring this time for every navigation, including the first time the add-on runs, is crucial because it represents how long the user actually had to wait to load IE and navigate to their favorite sites on their PC.
An important part of informing users is providing a threshold to understand the impact of add-ons have on performance. No matter what hardware you’re running on – from low end netbooks which throttle the CPU for long battery life or high end gaming desktops – human perception thresholds don’t change. Several studies regarding website response time report that users notice any delay over 0.2 seconds. Actions that are faster than 0.2 seconds appear instantaneous. Scenarios with response times slower than that threshold can feel “slow” to users. Of course, the individual person should be free to choose a different threshold that matches their particular browsing needs.
When considering the performance of add-ons, it is useful to do so in relationship to this threshold. People think about the speed of actions in the browser, like opening a new site, rather than the speed of individual add-ons, so what matters to the user is the total amount of time taken by add-ons. From the user’s point of view, they don’t care if it’s one add-on taking 2 seconds or 10 add-ons each taking 0.2 seconds. Informing users means providing the visibility on everything that is contributing to the performance they experience, with enough detail that the user stays in control. With this information people can make decisions about individual add-ons in the context of all the other add-ons that they’re running.
A personal decision
In part 1 of this series we shared statistical data about add-on performance which is compiled from people who opt into sending telemetry. Because this data is anonymous it’s useful for spotting broad trends and working with add-on partners but it’s not useful for helping a specific person in their environment. What matters to a person is what happens on his or her own machine. So, they need data that’s specifically about their add-ons on their machine with their browsing habits; purely local data. This enables them to make the most informed decision about the add-ons they use and to stay in control over their browsing experience
More details for add-on developers
For background, we’ve talked about using windows tools to measure load and navigation performance of add-ons. Here’s more detail about the load and navigation measurements so add-on developers can test the performance of their products or do something more like build capabilities into their products to detect when browsing is slowed and tune the add-on experience appropriately.
Add-on Load time (Load Time)
IE8 measures load time when a new tab is created and IE initializes all enabled add-ons (and IE9 will do this too). IE calls CoCreateInstance(), ShowDW() and SetSite() for each add-on. In IE8, an add-on’s load time is the total time it takes to return from the CoCreateInstance() and SetSite() calls. In the future, we’ll also measure the ShowDW() function call.
Webpage Navigation (Navigation Time)
Earlier in this post, we talked about the importance of measuring navigation time. Here’s how we do it on the IE team and how we recommend add-on developers do it. An add-on’s navigation time is the time it takes to handle the following three DWebBrowser2 events while navigating to a webpage:
We start measuring a navigation time for all enabled add-ons once IE fires a top-level BeforeNavigate event.
Sites may cause several navigation events to fire as they download images or content in frames. So, we keep an open tally of the time the add-ons take for each event on that page until the user:
- Navigates (another top-level BeforeNavigate)
- Cancels the navigation
- Closes the tab
- Closes IE
Once that occurs, we append the navigation time data point for each of the add-ons to the list.
When showing the load or navigation time data to users, we average up to the last 10 data points. We don’t measure the performance of disabled add-ons since they aren’t running or taking any time to load or navigate. Instead we show the latest data we have in parenthesis to inform the enable decision for people.
In everything we do including add-on performance measurement, IE treats all add-ons from all developers the same. Only the user makes decisions to enable or disable add-ons.
Edit on 8/31 – replaced ExtensionShowDW with ShowDW() and refer to it as a function call rather than an event in ‘Add-on Load time (Load Time)’ paragraph. Also removed extra period.