Microsoft News

Making Sites Look Their Best in Standards Mode

6:29 pm - August 23, 2010 in IEBlog

IE has traditionally drawn a 2-pixel border around the content area of a site. This border, drawn as part of the page rather than IE’s frame, affects calculations of distance from the top and left of the page. It also creates a not-so-modern beveled look.

In the fourth Platform Preview, you’ll notice pages running in IE9’s Standards Mode no longer have the border. Here’s a before and after:

Before
webpage with 2px border

After

Pages that run in legacy document modes will still have a 2-pixel border so that any site calculations dependent on the 2 pixels remain the same as in IE8.

To make sure your site runs in IE9 Standards Mode and gets this and all the other latest features in IE9, use a strict doctype. We recommend the HTML5 doctype (<!DOCTYPE html>) since it’s simple and will put your site in Standards Mode in all current browsers.

John Hrvatin
Program Manager

More from ieblog in Microsoft News

(Navigation)
(Content start)

Microsoft to Co-Chair New W3C Web Performance Working Group

6:34 pm - August 18, 2010 in IEBlog

Earlier this morning the W3C announced the formation of a new Web Performance Working Group chartered with making it easier to accurately measure web application performance. Enabling web developers to understand the real world performance characteristics of their applications is critical to the success of HTML5, and we’re excited to have been selected as co-chairs of the new working group alongside Google. We look forward to partnering with the W3C and the broader web community to enable these scenarios through an interoperable API.

The first deliverable for the working group is to recommend an API that measures the performance of browser navigations. The WebTimings specification provides a good starting point for these capabilities, so this specification will move into the Web Performance Working Group and become the foundation for our recommendations.

The third Internet Explorer 9 Platform Preview was the first browser to implement these portions of the WebTimings specification. Following standard conventions, we used a vendor prefix (ms) on the name because the specification was still under active development and hadn’t been brought into the charter of any working group. Google also recently provided an early implementation of these API’s inside Chrome using their vendor prefix (webkit). Through early collaboration between our engineering teams, we almost have interoperable implementations which is impressive for an API that has only been discussed for a few months. This is a great example of what’s possible through collaborative partnerships at the W3C.

With two early implementations available, it shouldn’t take long to finalize an interoperable API and remove the vendor prefixes. We can’t do this alone though - the new working group needs your feedback to ensure we have the right design. Over the next few weeks we’ll post more details on the working group website and begin to solicit feedback. In preparation, you can try out these API’s using the IE9 Platform Preview or Chrome 6 nightly builds. To help you get started take a look at the msPerformance demo on the IE9 TestDrive which shows these API’s in action.

Jason Weber
Lead Program Manager for IE Performance

More from ieblog in Microsoft News

(Navigation)
(Content start)

IE9, Opacity, and Alpha

8:15 pm - August 17, 2010 in IEBlog

IE9 introduces support for the CSS3 Color Module, including its popular opacity property. As we have done with other standards-based features, opacity is implemented so that the same markup used in other browsers just works in IE9’s standard mode.

Internet Explorer 8 and earlier versions implemented an alternative mechanism to apply opacity using the alpha filter of the IE-specific filter property. This creates a compatibility challenge because IE9’s standard mode supports only opacity and not the alpha filter. (IE9’s compatibility modes Quirks, 7, and 8 still support the alpha filter but do not implement opacity.)

For sites that use best practice feature detection, this is not a problem. They will detect that opacity is supported in IE9 and use it instead of filter. The problem is with sites that use browser detection and mistakenly assume that IE always uses filter alpha instead of opacity and then change only the filter property in script. The opacity effect will appear broken in those Web pages when run in IE9’s default 9 document mode. The fix is to detect the standards-based opacity feature first and browser-specific filter feature second as we’ve described in previous posts.

Example Best Practice CSS

.fiftyPercentOpaque
{
    opacity: 0.5;
    filter: alpha(opacity=50);
}

Example Best Practice Code

// set flags for whether we should use opacity or filter with
// this browser (or browser mode). we prefer opacity.
var useOpacity =
   (typeof document.createElement("div").style.opacity != 'undefined');
var useFilter = !useOpacity
   && (typeof document.createElement("div").style.filter != 'undefined');

function setOpacity(el, value) {
   // let el be either an element object or an id string
   if (typeof el == 'string')
      el = document.getElementById(el);

   // ensure value is in [0-1] range
   value = Math.min(1, Math.max(value, 0));

   // set opacity or filter alpha depending on what's supported
   if (useOpacity)
      el.style.opacity = value;
   else if (useFilter)
      el.style.filter = "alpha(opacity=" + (value * 100) + ")";
}

Alternative Browser-detection Code

In general, we prefer feature detection to browser detection but we’ve see a lot of opacity-related code use browser detection instead of feature detection. If you have a site that does that today, you may find it easier to update your browser detection so it works with IE9. Here’s code that properly detects when IE is running in a browser mode less than 9’s standards mode.

function browserDetectSetOpacity(el, value) {
   // let el be either an element object or an id string
   if (typeof el == 'string')
      el = document.getElementById(el);

   // ensure value is in [0-1] range
   value = Math.min(1, Math.max(value, 0));

   if (navigator.userAgent.match(/\bMSIE\b/)
         && (!document.documentMode || document.documentMode < 9))
      el.style.filter = "alpha(opacity=" + (value * 100) + ")";
   else
      el.style.opacity = value;
}

Summary

The problem described above occurs only when the opacity of an element is changed using script that doesn’t detect whether opacity is supported before changing filter. Sites that use only declarative CSS markup will continue to work fine even when opacity is changed indirectly by changing the CSS class of an element or using a pseudo-class such as :hover.

W3Schools offers a clear explanation of CSS opacity and IE’s legacy alpha filter.

—Ted Johnson, Program Manager Lead for Web Graphics

More from ieblog in Microsoft News

(Navigation)
(Content start)

Add-ons, and Opting out of Google Analytics Without Them

2:30 pm - August 16, 2010 in IEBlog

Recently, Google made available the “Google Analytics Opt-out Browser Add-on.” This add-on enables consumers to “indicate that information about the website visit should not be sent to Google Analytics.” We agree that making it easy for consumers to protect their privacy is good, and Internet Explorer offers a variety of features to help keep you in control of your information when visiting websites. In this post, we describe how to use some of these built in features to accomplish the same outcome without installing a Browser Helper Object and the Google Update Service.

Users of Internet Explorer 7 and 8 (and soon 9) who wish to prevent Google Analytics’ script from running can follow these steps:

In Internet Explorer, open the Tools menu and click Internet Options.
Click the Security tab and then click the Restricted Sites icon.
Click the Sites button.
In the box at the top, add *.google-analytics.com and push the Add button.
Click the Close button, and then the OK button to dismiss Internet Options.

After this configuration change, script from the Google Analytics website will not run on any webpage, and cookies will never be sent to the Google Analytics server.

Internet Options Restricted Sites dialog

How does this simple procedure work? In IE7, we made a minor change to the Restricted Sites zone. IE will not run scripts that originate from sites the user places in the Restricted zone.

To protect your privacy further, IE will not send cookies to sites in the Restricted Sites zone. In general, you can block script from any other domains by also adding those domains to the Restricted Sites zone.

Add-ons are useful and important. They are also a key cause of performance, stability, and security issues for all browsers. A more trustworthy approach involves building more functionality into the core browser and relying more on data (in the form of declarative descriptions, like XML) than code to extend the browser. For example, Accelerators in IE are XML descriptions of how to get a map, rather than arbitrary script that can get a map and possibly do more (like slow down the browser, or share more information than you’d like). Webslices are XML descriptions of parts of a webpage to show on IE’s Favorites Bar, rather than arbitrary script that can modify IE’s user interface and possibly do more than that under the hood.

In this situation, rather than install and run a lot of additional software on the machine, people can just add a web site to the Restricted Sites zone. Similarly, InPrivate Filtering in IE8 (and IE9) supports Importing and Exporting lists of sites that the user doesn’t want to exchange information with. That’s a simpler, safer, faster and more reliable approach than running more code.

Eric Lawrence
Program Manager

More from ieblog in Microsoft News

(Navigation)
(Content start)

Add-on Guidelines and Requirements in Action – Upgrade Advisor

6:44 pm - August 11, 2010 in IEBlog

We’ve blogged in the past about guidelines and requirements that we’ve published to help add-on developers create quality add-ons. We wrote these guidelines based on years of providing support to users and developers in response to questions from the developer community.

We’ve shared several great examples of these guidelines and requirements in action in the past few months. As part of IE’s cumulative security updates, we’ve released an update to the Internet Explorer Upgrade Advisor list that helps users update to new versions of add-ons that follow the guidelines and requirements. In this post, we highlight the latest add-ons that have made changes based on the guidelines and requirements, and we describe the Upgrade Advisor user experience in detail.

It’s been encouraging to see more add-ons recently release new versions with improvements in functionality based on these guidelines and requirements. As more developers follow them, our users will have a better experience. Here are some of the add-ons that have made changes to their functionality:

Add-on Name	New Version
AOL Toolbar	5.74.1.5498
Ask Toolbar	5.6.2.119
BuySafe Shopping Advisor Toolbar	5.0.1.366
Comcast Toolbar	1.0.0.17
Quero Toolbar	5.0.0.5
XFinity Toolbar	1.0.0.17
Yandex.Bar	5.1.2.1189

It’s important to update users to the new versions of these add-ons so they can benefit from improved stability and compatibility. Today we released an updated Upgrade Advisor list with IE’s Cumulative Security Updates to help users do just that. Users who have specific versions of the above add-ons may see the Upgrade Advisor dialog box when they launch Internet Explorer 8:

The dialog box presents the user with three options to choose from:

Option 1: Check online for an update
When the user selects this option or closes the dialog without making a choice, the dialog box is dismissed and a web page is displayed in a new window that runs in No Add-ons Mode. The user can follow the steps in this web page to install the new version of the add-on. If a link to the new version of the add-on is not provided by the vendor, or the new version does not follow the guidelines and requirements, the web page will inform the user that no update is available yet.

Option 2: Always open Internet Explorer without this add-on
When the user selects this option, Internet Explorer disables the add-on, the dialog box is dismissed, and Internet Explorer continues to launch.

Option 3: Keep using this add-on anyway
When the user selects this option, the dialog box is dismissed and Internet Explorer continues to launch with the add-on enabled until the next refresh of the Upgrade Advisor list which occurs approximately every 8 weeks.

Many thanks to the teams that have made changes to follow the guidelines and requirements. We will continue to work with add-on vendors to help them release new versions of add-ons that have better stability, compatibility and performance.

Herman Ng
Program Manager

More from ieblog in Microsoft News

(Navigation)
(Content start)

IE August Cumulative Security Update Now Available

10:34 pm - August 10, 2010 in IEBlog

The IE Cumulative Security Update for August 2010 is now available via Windows Update. This security update resolves six privately reported vulnerabilities in Internet Explorer. The most severe vulnerabilities could allow remote code execution if a user views a specially crafted Web page using Internet Explorer. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

This security update is rated Critical for Internet Explorer 6, Internet Explorer 7, and Internet Explorer 8. The security update addresses the vulnerabilities by modifying the way that Internet Explorer enforces security checks and handles objects in memory. For more information about the vulnerabilities, please see the full bulletin.

The majority of customers have automatic updating enabled and will not need to take any action because this security update will be downloaded and installed automatically. Customers who have not enabled automatic updating need to check for updates and install this update manually. For information about specific configuration options in automatic updating, see Microsoft Knowledge Base Article 294871.

For administrators and enterprise installations, or end users who want to install this security update manually, Microsoft recommends that customers apply the update immediately using update management software, or by checking for updates using the Microsoft Update service.

Tyson Storey
Program Manager

More from ieblog in Microsoft News

(Navigation)
(Content start)

HTML5, Modernized: Fourth IE9 Platform Preview Available for Developers

2:43 pm - August 4, 2010 in IEBlog

IE9 started from the premise that the modern web will deliver HTML5 experiences that feel more like native applications than sites. Building on hardware-accelerated SVG, canvas, video, audio, and text, developers will use the power of the whole PC to achieve great performance. On the modern web, developers will use the same markup across different HTML5 browsers.

With IE9, we have worked much more closely with the developer community. Developers have had an earlier (and more frequently updated) look at the platform. With that early engagement, developer feedback has had a bigger impact than before. People have downloaded IE9 Platform Previews over 2.5 million times. The samples on the IE Test Drive site have had over 20 million visitors. We appreciate the positive feedback and all the specific issues logged in Connect. They’ve helped us make demonstrable improvements that the community has noticed.

The fourth Platform Preview of Internet Explorer 9, available now, shows the opportunity of fully hardware-accelerated HTML5. You can run new test drive samples that show modern SVG and native JavaScript integration in action. In March, we promised to deliver platform preview releases approximately every eight weeks. With this installment, you will find more performance and more support for same markup. You’ll also find many fixes to issues reported in previous Platform Previews. Here is a video of some of the test drive samples:

Note this video uses the HTML5 video tag (with the H.264 codec) if your browser supports it, and falls back to other methods otherwise. It’s a good example of same markup in action.

Fully Hardware-Accelerated HTML5

The performance benefits of hardware acceleration are clear from running different sample sites side by side in IE9 and other browsers. Browsers that implement partial hardware acceleration – for example, text-only, or video-playback only, or image-only acceleration – offer inconsistent and possibly unpredictable platform experiences to developers and end-users.

IE9 offers consistent, fully hardware-accelerated text, graphics, and media, both audio and video. Try Hamster Dance Revolution, IE Beatz, or MSNBC Video in different browsers to experience the difference. Psychedelic Browsing demonstrates what HTML5 canvas can do when it’s fully accelerated with the GPU.

Modern SVG

With Platform Preview 4, we’re excited to show highly-interactive and integrated, or modern, SVG. Typically, developers think of SVG as the graphics format for static engineering diagrams and images. With HTML5 and hardware acceleration, SVG is an excellent choice for a new class of interactive, animated scenarios.

You can see great SVG performance, animated via JavaScript, with the SVG Dice example. The sample shows striking performance differences between browsers animating the same SVG markup, as well as the benefits of being able to style SVG with CSS. Unfortunately, you can see differences in how different browsers display the same SVG; as an industry we have more work to do so the same markup delivers the same results.

Native JavaScript Integration

We’re committed to the right foundation for HTML5 applications, including performance and ensuring the same markup and same script work across browsers. One aspect of doing these things well is integrating the JavaScript engine natively inside the browser, rather than bolting it onto the side to support multiple JavaScript engines as some other browsers do today. How a JavaScript engine is integrated into the browser is as important as the engine itself for real-world HTML5.

The fourth Platform Preview moves the new JavaScript engine, codenamed Chakra, inside IE9 and brings them together into one single, integrated system.

Through this deep integration, the performance of real world websites significantly improves, and IE9 becomes the first browser to have a shared DOM between the browser and the script engine based on ECMAScript5. The benefits start with real-world performance and consistency.

The easiest way to understand the importance of this fundamental change is by looking at how earlier versions of Internet Explorer integrated JavaScript. For the last 15 years Internet Explorer has supported multiple programming languages including JScript, VBScript, and even specialized languages such as Perl. While this gave developers choice it also came at the cost of performance and features. The browser and these script engines communicated through COM which could cause performance problems. Each script engine had its own language specific view of the DOM which created discrepancies. Additionally, the browser was forced to use a least common denominator approach which made adding new features challenging.

Diagram of IE8 vs IE9 JavaScript Integration Model. In IE8 the JavaScript engine was outside of IE, in IE9 the JavaScript engine is inside IE and shares the IE DOM

In the fourth Platform Preview, we’ve moved the JavaScript engine inside IE9. With this change, communication between the browser and script engine is now direct, which significantly improves performance for real world websites. We now have a single DOM, shared across all browser subsystems including JavaScript. This change ensures a consistent and interoperable view of the document. And this single DOM is now based on ES5, which prepares the entire system for the future.

When programming the IE9 DOM from JavaScript, objects now feel like native ES5 objects because, underneath the covers, they actually are ES5 objects. This approach brings the benefits of ECMAScript5 to the DOM. With the fourth Platform Preview, IE9 becomes the first browser to have a fully discoverable DOM through ES5 reflection features. IE9 is the first browser to apply ES5 bindings to DOM objects, enabling a full Inheritance view of the DOM, and taking advantage of the WebIDL specification as the foundation for this support. Together, these changes provide developers a natural ES5 based programming model. Try some of these enhanced DOM capabilities out for yourself to see how well your browser’s DOM and JavaScript engine are integrated. IE9 will continue to support additional programming languages through the legacy model, but we strongly encourage developers and enterprises to take full advantage of the benefits of JavaScript moving forward.

Platform Preview 4 also continues improvements to the JavaScript engine itself. One measure of JavaScript performance is the Webkit Sunspider microbenchmark. Here is a chart of the latest results:

WebKit Sunspider Results from 8/2/10, IE9 PPB4 get's 4th

The differences between browsers on this microbenchmark are converging within thousandths of seconds on tests that repeat operations many, many times to find any differences at all.

Real-world HTML5 performance often reflects the entire browser’s performance, not just the JavaScript engine in isolation. This video, for example, shows a side by side comparison of different browsers running an HTML5 canvas. The performance differences between browsers are striking and do not reflect relative JavaScript performance. We encourage other browser vendors to consider following our lead in designing for end-to-end performance and natively integrating JavaScript engines rather than treating script as a separable subsystem to be optimized in isolation.

Same Markup, and Tests

To assess the quality and completeness of a browser’s standards support, we look to the official standards bodies. Their open, consensus-based process is the best way to bring the community of browser vendors and web developer and design professionals together in building a test suite.

With Platform Preview 4, we’re contributing 519 new tests to the standards bodies. Based on community feedback, we’ve also updated five of the previously submitted tests. This brings the total number of tests we’ve contributed during IE9 development to 2,138. We welcome your feedback on the specific test cases. Please continue to provide feedback on the test cases to the appropriate W3C working group. In case of ES5 test cases please provide test case specific feedback via Microsoft Connect. We also invite you to submit your own test cases to the standards bodies as well. You can find the test cases Microsoft has developed at the IE Test Center.

These test cases represent a strong start on a complete and comprehensive test suite of the web standards developers expect to work consistently across browsers. While the suite is not complete yet, it is interesting to note how interoperable some of the same markup is across different browsers:

Cross Browser Test Results Summary from IETest

Some people use a particular test or website as shorthand for standards compliance. Different sites test different subsets of different standards to different depths. Acid3 is one that some people in the community have cited. It tests about 100 fragments of a dozen different technologies. Here’s a screenshot of how today’s IE9 Platform Preview runs today’s Acid3 test, going from 83 in the previous platform preview to 95:

IE9 PPB4 showing Acid3 score of 95/100

As IE9 has implemented more of the standards that developers use and value, IE9’s Acid3 score has continued to rise. The remaining points involve two particular technologies (SVG Fonts and SMIL animation of SVG) that are in transition.

Support for SVG Fonts in the web development and font communities has been declining for some time. There’s already been discussion without objection of dropping SVG fonts from the Acid3 test. The community has put forth a proposal in the SVG Working Group to give SVG Fonts optional status.

Instead, developers can use the Web Open Font Format (WOFF, supported in IE9 Platform Preview 3 as well as other browsers) for both HTML and SVG content. It works well in conjunction with the CSS3 Fonts module and has broad support from leading font vendors (e.g. here, “a majority of font makers have already settled on WOFF or services like Typekit as their format of choice”). WOFF fonts are a better long-term solution for many reasons discussed previously.

Similarly, support for SMIL animation of SVG in the web development community is far from strong. The leader of the SVG standardization effort wrote that not supporting SMIL in its current state is probably best “since the SVG WG intends to coordinate with the CSS WG to make some changes to animation and to extend filters.” There’s already work started to reconcile CSS3 animations and SVG. Developers interested in animating SVG can use JavaScript, as the samples in the test drive site do today, with consistent results.

Getting sites ready for Beta

With the fourth Platform Preview, we strongly recommend developers, designers, and partners to start getting your sites ready for the IE9 Beta.

Test your site in IE9 Standards Mode. This mode provides the best performance and interoperability and will offer additional benefits in the IE9 Beta. We suggest using the HTML5 doctype. More details here and here.
We recommend sending IE9 the same standards-based markup your site sends other browsers. More details here and here. From the feedback so far, and our experience with sites, the best way to get your site working in IE9 Standards Mode is to start from the same markup other browsers receive rather than IE6, IE7, or IE8 markup.
Use feature detection, not browser detection to handle any cross browser differences in behavior or feature support. This keeps your site working even as browsers change.
Please continue to report issues on Connect if your site doesn’t look or work right, and you’re giving it the same code as you’re giving to other modern browsers. With IE9 Platform Preview 4, we’ve fixed over 100 community-reported issues. We will fix even more between now and the IE9 beta and want your feedback.
Consider the experience for IE9 Beta users if you find that sending the same markup creates more issues than you can resolve in your production site. It is possible that running your site in Compatibility View is better for your users.
Take advantage of HTML5, CSS3, SVG, DOM, ES5, and more… all described here in the developer guide. We’re excited to run the amazing experiences you bring to the web using these new capabilities, taking advantage of hardware through IE9.

Platform Preview 4 is an important milestone on the way to beta. It is the last preview before the IE9 Beta. The IE9 platform is nearly complete. We ask that developers and partners start testing in preparation for the beta and prepare their sites to take advantage of IE9’s new capabilities. We continue to welcome your feedback via Connect.

Thanks,
Dean Hachamovitch
General Manager, Internet Explorer

More from ieblog in Microsoft News

(Navigation)
(Content start)

Add-on Performance Part 1: Measuring Add-on Performance

2:05 pm - August 3, 2010 in IEBlog

In previous posts, we’ve written about the ways we’re making IE9 much faster, like the new script engine that uses multiple cores, and the new rendering subsystem that uses the dedicated graphics chip found on modern PCs. Another aspect of browser performance involves the external code that IE runs on behalf of users, or add-ons.

Add-ons introduce unique features that can enhance the browsing experience. However, they also decrease the browser’s performance in crucial activities like navigating to webpages and creating new tabs. In this way, add-ons affect key usage scenarios like startup and navigation.

Add-on performance is integral to an overall fast browsing experience. IE users expect the browser to be fast, with or without add-ons. We work towards several common goals with add-on developers: providing valuable features with the smallest performance and reliability impact possible (more on reliability in another post).

This blog post is the first in a series on how add-on developers can improve add-on performance. In this post, we’ll share data on the performance impact of add-ons today and how IE enables users to identify the performance impact of their add-ons and stay in control of their PCs. We’ll describe the user scenarios that are important for measuring performance and will walk through how to measure them.

We want add-on developers to have all the information they need to deliver fast, reliable add-ons that respect user choices. We want to make it clear how to test add-on performance. We ask add-on developers to start measuring add-on performance today and making their add-ons faster.

What is An Add-on?

Add-ons refer to Toolbars, Explorer Bars and Browser Helper Objects today. When add-ons are enabled in the browser, they can cause a performance impact for every tab opened and every webpage the user visits.

Another common type of extension is plug-ins, specifically ActiveX controls, like Adobe Flash, Apple QuickTime, and Microsoft Silverlight. Unlike add-ons that run in the browser across all web-pages, plug-ins run inside webpages and their performance impact is localized to the webpages that use them. The specifics of this post are about add-ons. Plug-in developers have similar opportunities to make the browsing experience faster and more reliable.

Accelerators, Webslices and Search Providers are a third class of extension. These are written in pure XML format, and were designed to not impact page or browser performance, reliability, or security.

Toolbar Buttons are another type of extension but they only impact IE’s performance when users press them and they’re mapped to an action that launches an add-on.

Understanding Add-on Performance Impact

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.

Tab creation is one such scenario. IE initializes add-ons every time the user creates a new tab to make sure that the add-ons can interact with a webpage properly (like the Skype IE add-on, which identifies phone numbers and makes them “clickable”). When the user starts a new instance of IE, one of the first things IE does is create a new tab that, in turn, initializes all the user’s add-ons. The time it takes each add-on to initialize is its load time, and usually depends on the amount of code the add-on executes during its initialization routine.

According to our telemetry data, over 95% of IE8 users today have at least one add-on installed, and users have an average of 9 add-ons installed. If a user’s add-ons each take more than 20 milliseconds to load, his new tabs will take a noticeably longer time to create than usual.

The following chart shows the median load times for the newest versions of the 50 most used add-ons in IE today. Users who have many of these add-ons installed will definitely notice a performance impact when starting IE or creating a new tab:

50 Most Popular Add-ons in IE8

These are just the 50 most popular add-ons. Many add-ons that aren’t listed above may also have a performance impact on tab creation. We recommend users to install the newest versions of add-ons as they generally have the best performance.

End-users and Add-on Load Times

What’s important to an individual user is his or her own experience, not the broad ecosystem data. In IE8, we introduced a feature to enable users to see for themselves how their add-ons affect their browser performance.

IE measures the load time for each enabled add-on every time IE initializes it. In the Manage Add-ons dialog, IE displays the average load time for each add-on based on the last 10 initializations. You can access the Manage Add-ons dialog via the Tools Menu.

With this information handy, users can choose the add-ons they want to keep enabled, and maintain control over their browsing performance:

Manage Add-ons Dialog showing performance information

Add-on Developers and Add-on Load Times

We collected telemetry data on the load times across the add-ons that IE users have installed to evaluate their performance characteristics. The following chart shows the distribution of all add-on load times experienced by all IE8 users:

Distribution of all Add-on Load Times

Even though most of the time add-ons load in less than 100 milliseconds, add-ons take longer than 200 milliseconds to load over 25% of the time. Users will perceive a noticeable impact on performance in these situations, more so if several of their add-ons have long load times. Measuring your add-on’s performance allows you to identify how often these long load times occur.

Let’s look at some specific examples of slower add-ons from our measurements, and some of the reasons these add-ons have such a large effect on IE’s performance during tab creation. If you are an add-on developer and would like to receive the following load time data for your add-on, you can email us at ieaddonp@microsoft.com.

Sample Add-on #1

Users with this add-on enabled typically see noticeable delays during tab creation. The majority of load times for this add-on are greater than 200 milliseconds. The amplitude of the curve is higher than that of the previous chart. Further investigation revealed that this add-on is generally running more code than is minimally required during initialization.

Sample Add-on #1 distribution of load times

Sample Add-on #2

This add-on also incurs an impact on the user’s tab creation performance as evidenced by the majority of load times that take over 200 milliseconds. We found that the add-on is performing operations that take a consistent amount of time to complete across all machines (600-1500 milliseconds). We recommend moving these operations off of the initialization routine to expedite tab creation.

Sample Add-on #2 distribution of load times

Sample Add-on #3

Even though the distribution of load times for this add-on is different from the others, it also incurs an impact on tab creation performance. We investigated the cause behind the uniform distribution of load times beyond 100 milliseconds and found that the add-on is making network calls during initialization. Since network calls take a variable time to complete depending on the connection speed and locale, add-ons must refrain from making network calls during initialization. We recommend spinning off background threads to make these calls at a later time instead.

Sample Add-on #3 distribution of load times

It’s clear that some IE8 users experience significant performance problems with add-ons during tab creation. Add-on developers who improve add-on load time take an important step towards improving IE performance for end-users. At the same time, we know that add-on performance extends beyond tab creation. Let’s look at the other scenarios in more detail.

Recommendations to Add-on Developers around Performance

In this post, we focus on understanding and measuring scenarios in terms of the elapsed time with the add-on enabled. There are additional metrics that are also important, such as CPU time (amount of time the CPU spent to complete the scenario) and working set (amount of memory required to run the scenario). We’ll cover these two metrics in a future post.

Tab creation and webpage navigation are two of the most relevant scenarios for IE performance. Add-ons have a large impact on the performance of these scenarios because they can block IE from completing the user task. Depending on how the developer wrote the add-on, IE may have to wait for the add-ons to finish running code before IE can finish creating the tab or navigating to the web page.

We recommend add-on developers start by measuring add-on performance in these two scenarios:

1. Tab Creation, Switching, and Closing
Some add-ons call across the network during tab create (which causes users to wait), or choose to save their state (with registry reads and writes) as the user is closing a tab, or to repaint their UI as the user is switching between tabs.

Because add-ons can interrupt IE as it handles the user’s request to create a tab, switch between tabs, or close a tab, add-ons can make these operations far from instantaneous.

2. Webpage Navigation
As the user navigates to a webpage, Internet Explorer fires a set of browser events. Add-ons can choose to run code in response to these events. Add-ons that handle one or more of these events can delay users from finishing the web page navigation. The impact is profound on webpages that users expect to open immediately, such as search results or stock market tickers. Some examples:

BeforeNavigate: A security add-on inspects the destination URL before allowing the navigation to proceed.
DocumentComplete: Once a webpage finishes loading, an add-on searches through the entirety of every webpage to add a button next to all the email addresses in order to launch a custom mail application
NavigateError: If an error occurs during webpage navigation, the add-on redirects the user to a custom error page.

Given how important performance is for users, transparency and control of add-ons will also be important to them.

We also recommend that add-on developers measure and optimize their add-on performance using the publicly available Windows Performance Tools.

Specifics about Measuring Add-on Performance with Windows Performance Tools

We’ve recently blogged about how to measure browser performance with the Windows Performance Tools. Add-on developers can use these tools to measure various performance characteristics of the browser with their add-on(s) enabled. Here are the steps you can take to measure the tab creation and tab close scenarios for an add-on with the Windows Performance Tools installed.

Start an elevated command prompt and execute the following command to start a performance trace and log the results to a file (such as AddonTrace.etl):
xperf -start browselog -on Microsoft-IEFRAME -f AddonTrace.etl
Make sure that your add-on is enabled.
Launch Internet Explorer to your home page. Wait several seconds after the navigation completes, and then open several new tabs.
Close each tab in order until the browser window shuts down.
Stop the trace by executing:
xperf -stop browselog
Convert the contents of the .etl file into a text file that you can parse and measure for:
xperf -i AddonTrace.etl -o AddonTrace.txt

Next, inspect the text file to find the following pairs of ETW events that correspond to the scenarios. To find the elapsed time for the event, subtract the timestamp of the end event from that of the start event:

Scenario

Start Event

End event

Tab Creation

(Load time)

CoCreateInstance():

Microsoft-IEFRAME/ExtensionCreate/Start

SetSite():

Microsoft-IEFRAME/ExtensionSetSite/Start

CoCreateInstance():

Microsoft-IEFRAME/ExtensionCreate/Stop

SetSite():

Microsoft-IEFRAME/ExtensionSetSite/Stop

Tab Close

SetSite(NULL):

Microsoft-IEFRAME/ExtensionSetSiteNull/Start

SetSite(NULL):

Microsoft-IEFRAME/ExtensionSetSiteNull/Stop

In addition, you can use the Windows Performance Tools to measure add-on performance in the other scenarios we described earlier. Here are the ETW events that correspond to the other scenarios:

Scenario

Start Event

End event

Tab Switch

Microsoft-IEFRAME/ LeftButtonAction/win:Info

The following sequence of events:

Microsoft-IEFRAME/Browseui_Tabs_SwitchTabs/win:Stop;

Microsoft-IE/MSHTML_CDOC_ONPAINT/win:Stop;

Microsoft-IEFrame/Browseui_Tabs_WaitMessage/win:Start

Webpage Navigation

Microsoft-IEFRAME/FRAME_URLENTERED/win:Info

The following sequence of events:

Microsoft-IE/MSHTML_CMARKUP_ONLOADSTATUSDONE/win:Info

Microsoft-IE/MSHTML_CDOC_ONPAINT/win:Stop

Microsoft-IEFrame/Browseui_Tabs_WaitMessage/win:Start

We recommend running these tests on a fixed environment against a set of the most popular websites to realistically measure performance. Caching these sites on a proxy server helps minimize variance in the website content. We also recommend running these tests across multiple machine configurations.

Add-on Performance: We’re all in, together

Performance is important to end-users: they’re paying attention and will take action to get better performance.

We encourage users to look at the performance impact of the various add-ons installed on their machines using the IE8 Manage Add-ons dialog. This information helps users stay in control of their browsing performance while using the add-ons they want.

We also encourage add-on developers to make those decisions easier for end-users by writing faster add-ons. We recommend developers start by measuring add-on performance using the Windows Performance Tools and follow the guidance we’ve included with this post. Set up a performance lab infrastructure with a server of cached websites and multiple machine configurations. While the IE8 add-on load time measurements serve as a gauge for end users, we recommend measuring performance across all the tabbed browsing and webpage navigation scenarios as well.

Using these measurements and our guidance above, you can tune your add-on for the best performance. As you find optimizations or best practices, we encourage you to share them with the developer community blog post comments here or on Connect.

Improving add-on performance is critical to building a fast and highly compelling browsing experience and we’re all in it together. We want IE users to enjoy great add-on functionality and great performance.

Herman Ng
Program Manager

More from ieblog in Microsoft News

(Navigation)
(Content start)

Online privacy, Tracking, and IE8’s InPrivate Filtering

10:22 pm - August 1, 2010 in IEBlog

Online privacy and tracking have been in several news articles and public hearings lately. The recent attention has been on how visiting one site shares information with many sites, and how those sites can then share the information and effectively ‘track’ your activity on the web. The articles certainly show the complexity of the topic. This blog post offers some context on online safety and privacy and specific information about InPrivate Filtering, a feature in IE8 designed to help protect users from some tracking scenarios, as well as several other features IE8 offers users to help protect their privacy online.

Part of what makes online privacy tricky is that browsing the web is fundamentally an information exchange. Your web browser offers information in order to get information. That information can identify you. Often, that information is sent automatically for your convenience (like the languages you prefer to read) to tailor the content for you.

Because some of the technologies that can be used for tracking are also essential today for basic functionality, there is no “Just give me perfect privacy” feature. The way different tracking and anti-tracking technologies interact can read like a Spy vs. Spy comic strip. Distinguishing between a tracking technology (a beacon) and a useful piece of web content (a stock chart used as a beacon) is not obvious. Some people are concerned about Adobe Flash’s “super cookies”; IE8’s InPrivate browsing clears these as well with newer versions of Flash. As another example, InPrivate Browsing in IE8 “clears your tracks” and removes information from browser history when you close IE. During the actual browsing session, before you close it, IE still records history (so the back button continues to work) and cookies (so that logins and shopping carts continue to work). Ultimately, people want the web to work and privacy protection.

We designed InPrivate Filtering to help users control who can get information about their browsing. IE enables users to choose how privately they want to browse. Users are in control of several privacy protection features in IE, and how automatically they function. Specifically, users can keep browsing information from going to sites they don’t actually visit directly. IE determines the potential tracking sites on the list based on the sites you browse to directly and how those sites were written. Different sites on the web have articles about more advanced features, like always browsing with InPrivate Filtering on, and importing and exporting InPrivate Filtering lists.

People who are concerned with tracking may be interested in how to use InPrivate Filtering in IE. (People interested in how it works can read more here and here.)

1. From the Safety menu, choose “InPrivate Filtering.”

2. Choose “Block for me” to turn on automatic filtering.

Alternatively, you can choose “InPrivate Filtering Settings” from the Safety menu at any time to see a list of sites that are in position to track your browsing based on the sites you browse to in IE. You can find more detailed instructions in several places around the web with some basic web searches.

The sheer complexity of privacy and online safety spans many disciplines. We’ve posted here about different aspects of web browsing safety. Bad things can happen to good people on the web in many ways. Internet Explorer includes protections for many different kinds of threats people face on the web. People often focus on malicious sites that exploit unpatched security issues in different devices and software. (Microsoft regularly releases updates; please turn on automatic updating if you haven’t already.) Sites host seemingly good downloads (“Free Emoticons! Puppy screensaver!”) that are actually malicious, or attempt to lure people to visit them; users often download them and run them anyway. Otherwise “good” sites unintentionally host malicious content. Phishing sites pretend to be one site (perhaps your bank) but are actually malicious in their use of information. IE’s SmartScreen has protected users over a billion times by blocking these kinds of attacks. Protecting children online is another set of challenges entirely. Some kinds of trust violations that are lower in severity go unhindered. Browser add-ons can leak information across sites, even though add-on developers can prevent it. Protecting a user’s online privacy is just as important to Microsoft as protecting the user from malicious sites.

The web today has lots of great innovation. Unfortunately, threats to online safety and privacy also see rapid innovation. The communities working together to combat online safety issues span the technology industry, financial and commercial institutions, academia, government, and law enforcement agencies.

Dean Hachamovitch

More from ieblog in Microsoft News

(Navigation)
(Content start)

DOM Traversal

2:07 pm - July 30, 2010 in IEBlog

The latest Platform Preview Build includes two great interoperable features for working with the DOM – DOM Traversal and Element Traversal. These features provide web developers with simple, flexible, and fast ways of traversing through a document using the same markup across browsers. These features come in the form of flat enumeration, simplifying the DOM tree to an iterative list, and filtering which enables you to tailor the set of nodes you traverse. These features work with the same markup across browsers – you can try out any of the code here in the IE9 platform preview and other browsers.

Without these features, finding an element of interest on a page requires you to do one or more depth-first traversals of the document using firstChild and nextSibling. This is usually accomplished with complex code that runs slowly. With the DOM and Element Traversal features, there are new and better ways of solving the problem. This blog post is a primer and provides a few best practices to get you on your way.

I’ll start with Element Traversal, since it’s the simplest of the interfaces and follows familiar patterns for enumerating elements in the DOM. Element Traversal is essentially a version of DOM Core optimized for Elements . Instead of calling firstChild and nextSibling, you call firstElementChild and nextElementSibling. For example:

if (elm.firstElementChild)
{
    elm = elm.firstElementChild;
    
    while (elm.nextElementSibling)
    {
        // Do work...
    }
}

This is faster and more convenient, saving you the trouble of having to check for text and comment nodes when you’re really only interested in elements.

DOM Traversal is designed for much broader use cases. First, you create a NodeIterator or a TreeWalker. Then you can use one of the iteration methods to traverse the tree:

var iter = document.createNodeIterator(elm, NodeFilter.SHOW_ELEMENT, null, false); // This would work fine with createTreeWalker, as well

var node = iter.nextNode();
while (node = iter.nextNode())
{
    node.style.display = "none";
}

The codepath above iterates through a flat list of all nodes in the tree. This can be incredibly useful since in many cases you don’t care whether something is a child or sibling of something else, just whether it occurs before or after your current position in the document.

A big benefit of DOM Traversal is that it introduces the idea of filtering, so that you only traverse the nodes you care about. While nodeIterator only performs flat iterations, TreeWalker has some additional methods, like firstChild(), that let you see as much or as little of the tree structure as you want.

The SHOW_* family of constants provides a way to include broad classes of nodes, such as text or elements (like SHOW_ELEMENT in the earlier example). In many cases, this will be enough. But when you need the most precise control, you can write your own filter via the NodeFilter interface. The NodeFilter interface uses a callback function to filter each node, as in the following example:

var iter = document.createNodeIterator(elm, NodeFilter.SHOW_ALL, keywordFilter, false);

function keywordFilter(node)
{
   var altStr = node.getAttribute('alt').toLowerCase();
   
   if (altStr.indexOf("flight") != -1 || altStr.indexOf("space") != -1)
      return NodeFilter.FILTER_ACCEPT;
   else
      return NodeFilter.FILTER_REJECT;                
}

For a live example, check out my demo for DOM Traversal -- I used NodeFilter extensively there. Complex filtering operations on the list of media elements were as simple as using a NodeFilter callback like the one above.

In this post, I showed that you have options in how to traverse a document. Here are suggested best practices for when you should use the various interfaces:

If the structure of the document is important – and you’re only interested in elements – consider Element Traversal. It’s fast and won’t leave a big footprint in your code.
If you don’t care about document structure, use NodeIterator instead of TreeWalker. That way, it’s obvious in your code that you’re only going to be using a flat list. NodeIterator also tends to be faster, which becomes important when traversing large sets of nodes.
If the SHOW_* constants do what you need for filtering, use them. Using constants makes your code simpler, as well as having slightly better performance. However, if you need fine-grained filtering, NodeFilter callbacks become indispensable.

I’ve already found these features to be a great help in my own coding, so I’m really excited to see what you do with them. Download the latest Platform Preview, try out the APIs, and let us know what you think.

Thanks!
Jonathan Seitel
Program Manager

More from ieblog in Microsoft News

(Navigation)
(Content start)

(Navigation)
(Content start)

Microsoft News

Example Best Practice Code

Alternative Browser-detection Code

Summary

Fully Hardware-Accelerated HTML5

Modern SVG

Native JavaScript Integration

Same Markup, and Tests

Getting sites ready for Beta

It's All About Search | © clsc.net |