In Selenium Webdriver which is better in terms of performance Linktext or css?

Question

In Selenium it is always better to go locate the element with the Locator ID .

And the Least locator is XPath (Correct me if I'm wrong).

So is there any precedence or order in which a person should proceed with Locators to identify element ?

Answer 1

Here is a little benchmark of different methods to locate an element on https://stackoverflow.com/questions :

Chrome 52, driver 2.22

15 ms for execute_script("return [].find.call(document.getElementsByTagName('a'), function(e){return e.textContent.trim() == 'Physics'});")
15 ms for find_element_by_css_selector("#footer-sites > table > tbody > tr:nth-child(2) > td:nth-child(7) > ol > li:nth-child(2) > a")
15 ms for find_element_by_css_selector("[title='go to page 2']")
15 ms for find_element_by_xpath("//*[@id='footer-sites']/table/tbody/tr[2]/td[7]/ol/li[3]/a")
16 ms for find_element_by_class_name("top-footer-links")
16 ms for find_element_by_css_selector("a[href$='math.stackexchange.com']")
16 ms for find_element_by_id("footer-sites")
16 ms for find_element_by_name("q")
16 ms for find_element_by_xpath("//a[text()='Ask Ubuntu']")
31 ms for find_element_by_xpath("//*[normalize-space(.)='Game Development']")
311 ms for find_element_by_link_text("Area 51")
343 ms for find_element_by_partial_link_text("Stack Apps")

Firefox 2.47, driver 2.53.0

16 ms for find_element_by_class_name("top-footer-links")
16 ms for find_element_by_css_selector("#footer-sites > table > tbody > tr:nth-child(2) > td:nth-child(7) > ol > li:nth-child(2) > a")
16 ms for find_element_by_css_selector("a[href$='math.stackexchange.com']")
16 ms for find_element_by_id("footer-sites")
16 ms for find_element_by_name("q")
23 ms for execute_script("return [].find.call(document.getElementsByTagName('a'), function(e){return e.textContent.trim() == 'Physics'});")
23 ms for find_element_by_css_selector("[title='go to page 2']")
47 ms for find_element_by_xpath("//*[@id='footer-sites']/table/tbody/tr[2]/td[7]/ol/li[3]/a")
47 ms for find_element_by_xpath("//a[text()='Ask Ubuntu']")
62 ms for find_element_by_xpath("//*[normalize-space(.)='Game Development']")
1625 ms for find_element_by_link_text("Area 51")
1726 ms for find_element_by_partial_link_text("Stack Apps")

Internet Explorer 11, driver 2.53.1

77 ms for find_element_by_name("q")
78 ms for execute_script("return [].find.call(document.getElementsByTagName('a'), function(e){return e.textContent.trim() == 'Physics'});")
78 ms for find_element_by_class_name("top-footer-links")
78 ms for find_element_by_id("footer-sites")
93 ms for find_element_by_xpath("//*[@id='footer-sites']/table/tbody/tr[2]/td[7]/ol/li[3]/a")
108 ms for find_element_by_xpath("//a[text()='Ask Ubuntu']")
109 ms for find_element_by_css_selector("#footer-sites > table > tbody > tr:nth-child(2) > td:nth-child(7) > ol > li:nth-child(2) > a")
125 ms for find_element_by_css_selector("[title='go to page 2']")
125 ms for find_element_by_css_selector("a[href$='math.stackexchange.com']")
140 ms for find_element_by_xpath("//*[normalize-space(.)='Game Development']")
801 ms for find_element_by_link_text("Area 51")
812 ms for find_element_by_partial_link_text("Stack Apps")

Answer 2

I'm just writing some points from this reference which is already provided by GK27 in comments, The purpose of writing here is to be clear if page has not found some time, user can view from here.

So the better way of locating the element, Priority wise should be in the list [id, name, linkText, partialLinkText, tagName, className, cssSelector, xpath] here first value id in the list contains first priority and so on.

Locating an Element By ID:

The most efficient way and preferred way to locate an element on a web page is By ID . ID will be the unique on web page which can be easily identified. IDs are the safest and fastest locator option and should always be the first choice

Locating an Element By Name:

When there is no Id to use, the next worth seeing if the desired element has a name attribute. But make sure there the name cannot be unique all the times. If there are multiple names, Selenium will always perform action on the first matching element

Locating an Element By LinkText:

Finding an element with link text is very simple. But make sure, there is only one unique link on the web page. If there are multiple links with the same link text (such as repeated header and footer menu links), in such cases Selenium will perform action on the first matching element with link.

Locating an Element By Partial LinkText:

In the same way as LinkText , PartialLinkText also works in the same pattern, only difference is that it's match link with partial text means uses contains.

Locating an Element By TagName:

TagName can be used with Group elements like , Select and check-boxes / dropdowns.

Locating an Element By Class Name:

There may be multiple elements with the same class name, if we just use findElementByClassName , make sure it is only one. If not the you need to extend using the classname and its sub elements.

CSS Selector:

CSS mainly used to provide style rules for the web pages and we can use for identifying one or more elements in the web page using css. If you start using css selectors to identify elements, you will love the speed when compared with XPath . We can you use Css Selectors to make sure scripts run with the same speed in IE browser. CSS selector is always the best possible way to locate complex elements in the page. If you have a need to find an element using a complex selector, I usually recommend using CSS Selectors, if possible. It's not quite as flexible as XPath, but will cover many of the same cases, without exhibiting the extreme performance penalty on IE that XPath can.

XPath Selector:

Finding elements by XPath is useful for finding elements using very complex selectors, and is the most flexible selection strategy, but it has the potential to be very slow, particularly in IE . In IE 6, 7, or 8, finding by XPath can be an order of magnitude slower than doing the same in Firefox . IE provides no native XPath-over-HTML solution, so the project must use a JavaScript XPath implementation, and the JavaScript engine in legacy versions of IE really is that much slower.

There are two types of xpath

1. Native Xpath, it is like directing the xpath to go in direct way. like Example: html/head/body/table/tr/td

Here the advantage of specifying native path is, finding an element is very easy as we are mention the direct path. But if there is any change in the path (if some thing has been added/removed) then that xpath will break.

2. Relative Xpath. In relative xpath we will provide the relative path, it is like we will tell the xpath to find an element by telling the path in between. Advantage here is, if at all there is any change in the html that works fine, until unless that particular path has changed. Finding address will be quite difficult as it need to check each and every node to find that path.