Much of the functionality of WebDriver is implemented using so-called “automation atoms”. These are JavaScript functions that are used to ensure consistency and reduce maintenance across the different drivers. Some of these functions are fairly straightforward, and delegate down to the browsers’ native code fairly quickly. Finding an element by ID, for example, pretty clearly translates to document.getElementById().

Other operations, on the other hand, are much more computationally expensive. For example, getting the text of an element is one of the most expensive things you can do, Because of the way the WebDriver API defines getting an elements text.

Because so much of this functionality is built in JavaScript, a browser that has a slow JavaScript engine like IE Will show poor performance when executing WebDriver code. Remember that the JavaScript engine in IE before version 9 was about ten times slower than the JavaScript engines in Firefox and Chrome. IE9 introduced a new JavaScript engine that was a lot closer in performance to that of Firefox and Chrome, but Microsoft only implemented the new JavaScript engine in the 32-bit version of IE. So the first thing you can do is run your tests against the 32-bit version of IE9.

IE also doesn’t have a native XPath engine for finding elements. So to be able to find elements by XPath in IE, we have to use a JavaScript XPath query engine. That’s going to be slower than doing the same thing in other browsers. This is the biggest reason why I recommend using CSS selectors instead of XPath for finding elements.

I would also recommend calling expensive methods as seldom as possible. The two most expensive methods are getText() and isDisplayed(), because they have to walk a substantial portion of the DOM tree before they can return the correct value.