Performance of different location strategies with Selenium WebDriver

Questions
#1

One of the questions that came during the UI Automation Week was related to performance on using different locators. I remember this arise during the session/experience report of @mwinteringham.
The question, if I remember it correctly, focused on finding elements by “id” vs “css selectors”.
Well, this question in particular kept alive in my head and I want to share with you my findings.

So, I looked at WebDriver specification and also at client side code.

As you can see, basically if you try to find web UI elements by their “id” attribute, the webdriver client library basically changes it to the css selector locator strategy.
Therefore, their performance is essentialy the same.

image
image2108×1132 195 KB

The same happens with other strategies that are available on client side and that do exist just to make our live easier. However, they will be mapped to the official supported location strategies of the WebDriver specification.

XPath locator strategy is known for being slower and prone to errors (as UI can easily break them).

3 Likes
#2

XPath locators nowadays are slower, yes (although it wasn’t always that way), but for the most part, are identical to CSS selectors in terms of how error-prone they are (there are some very niche scenarios where the XPath may loop internally forever, but failure rates are identical when using comparable locators). Xpath technically covers everything that CSS selectors do, with a little more (i.e., traversing up the tree, and locating based on text). So it really comes down, much like with CSS selectors, to what the locator is.

If an Xpath-based locator is built to describe every step in the tree to get to an element, then it will be just as error-prone as a CSS selector that does the same. But both are capable of making an “any descendent” step (i.e., a space in a CSS selector, and // in Xpath) as well as an “immediate child” step (i.e., > in CSS selectors, and / in XPath).

That said, I always advocate for the use of CSS selectors over Xpath wherever possible, because Xpath locators tend to be way more verbose than CSS selectors and fewer people understand them.

5 Likes
#3

I for one am less worried about their performance even though I am making calls over the wire, and am also forced to use a mix especially when accessing Complex controls of lists and trees where I need to make ancestor and child find() calls. Lists (with controls in them) and trees are a bigger part of my UI work than forms, so even though most of the locators in my code are CSS, the ones that run more often are relative XPATH’s to pull out elements in 2D lists where the devs often change the child control depth for example. My biggest cost is remembering how to write these as accurately as possible and quickly debug them.

Sergio’s question was about “speed”, which must only be measurable for a grid/remote. Not locally.

3 Likes
#4

For me whilst this example shows theres no performance advantage, the advantage I’d argue for is that IDs should always be unique and so make finding and interacting with elements using selenium easier. It also comes down to readability and maintainability. Whilst you might know what the xpath is doing somebody new may not. Yes you could add a comment to explain but if you need to do that then the code probably isnt the best. Using an Id it’s pretty clear which unique element its interacting with in the page.

I think many issues with finding correct selectors etc comes down to a team collaboration and communication problem. People often look to use tools or xpath to solve a problem rather than work with their team to influence a change or use the tests to drive the development. Often people just accept what’s been implemented and implement in my opinion rather ugly and hard to maintain tests.

3 Likes
#5

I find the execution speed is order’s of magnitude less important then the speed of writing and maintaining.

Use what works, what will keep working and what will be easy to update. For that there isn’t one answer, it’s whatever works for you, your app and your team.

2 Likes