I’m going to hold the unpopular on SO Selenium tag opinion that an XPath selector is preferable to a CSS selector in the long run.

This long post has two sections - first I'll put a back-of-the-napkin proof the performance difference between the two is 0.1-0.3 milliseconds (yes; that's 100 microseconds), and then I'll share my opinion why XPath is more powerful.

Performance difference

Let's first tackle "the elephant in the room" – that XPath is slower than CSS.

With the current CPU power (read: anything x86 produced since 2013), even on BrowserStack, Sauce Labs, and AWS VMs, and the development of the browsers (read: all the popular ones in the last five years) that is hardly the case.

The browser's engines have developed, the support of XPath is uniform, and Internet Explorer is out of the picture (hopefully for most of us). This comparison in the other answer is being cited all over the place, but it is very contextual – how many are running – or care about – automation against Internet Explorer 8?

If there is a difference, it is in a fraction of a millisecond.

Yet, most higher-level frameworks add at least 1 ms of overhead over the raw selenium call anyway (wrappers, handlers, state storing, etc.); my personal weapon of choice – Robot Framework – adds at least 2 ms, which I am more than happy to sacrifice for what it provides. A network round trip from an AWS US-East-1 to BrowserStack's hub is usually 11 milliseconds.

So with remote browsers, if there is a difference between XPath and CSS, it is overshadowed by everything else, in orders of magnitude.

The measurements

There are not that many public comparisons (I've really seen only the cited one), so – here's a rough single-case, dummy and simple one.

It will locate an element by the two strategies X times, and compare the average time for that.

The target – BrowserStack's landing page, and its "Sign Up" button; a screenshot of the HTML content as writing this post:

Here's the test code (Python):

from selenium import webdriver
import timeit


if __name__ == '__main__':

    xpath_locator = '//div[@class="button-section col-xs-12 row"]'
    css_locator = 'div.button-section.col-xs-12.row'

    repetitions = 1000

    driver = webdriver.Chrome()
    driver.get('https://www.browserstack.com/')

    css_time = timeit.timeit("driver.find_element_by_css_selector(css_locator)",
                             number=repetitions, globals=globals())
    xpath_time = timeit.timeit('driver.find_element_by_xpath(xpath_locator)',
                               number=repetitions, globals=globals())

    driver.quit()

    print("CSS total time {} repeats: {:.2f} s, per find: {:.2f} ms".
          format(repetitions, css_time, (css_time/repetitions)*1000))
    print("XPATH total time for {} repeats: {:.2f} s, per find: {:.2f} ms".
          format(repetitions, xpath_time, (xpath_time/repetitions)*1000))

For those not familiar with Python – it opens the page, and finds the element – first with the CSS locator, then with the XPath locator; the find operation is repeated 1,000 times. The output is the total time in seconds for the 1,000 repetitions, and average time for one find in milliseconds.

The locators are:

• for XPath – "a div element having this exact class value, somewhere in the DOM";
• the CSS is similar – "a div element with this class, somewhere in the DOM".

It is deliberately chosen not to be over-tuned; also, the class selector is cited for the CSS as "the second fastest after an id".

The environment – Chrome v66.0.3359.139, ChromeDriver v2.38, CPU: ULV Core M-5Y10 usually running at 1.5 GHz (yes, a "word-processing" one, not even a regular Core i7 beast).

Here's the output:

CSS total time 1000 repeats: 8.84 s, per find: 8.84 ms

XPath total time for 1000 repeats: 8.52 s, per find: 8.52 ms

Obviously, the per find timings are pretty close; the difference is 0.32 milliseconds. Don't jump "the XPath selector is faster" – sometimes it is, but sometimes it's CSS.

Let's try with another set of locators. It is a tiny-bit more complicated—an attribute having a substring (common approach at least for me, going after an element's class when a part of it bears functional meaning):

xpath_locator = '//div[contains(@class, "button-section")]'
css_locator = 'div[class~=button-section]'

The two locators are again semantically the same – "find a div element having in its class attribute this substring".

Here are the results:

CSS total time 1000 repeats: 8.60 s, per find: 8.60 ms

XPath total time for 1000 repeats: 8.75 s, per find: 8.75 ms

A difference of 0.15 ms.

As an exercise—the same test as done in the linked blog in the comments/other answer—the test page is public, and so is the testing code.

They are doing a couple of things in the code - clicking on a column to sort by it, then getting the values, and checking the UI sort is correct.

I'll cut it - just get the locators, after all - this is the root test, right?

The same code as above, with these changes in:

• The URL is now http://the-internet.herokuapp.com/tables; there are two tests.

• The locators for the first one - "Finding Elements By ID and Class" - are:

css_locator = '#table2 tbody .dues'
xpath_locator = "//table[@id='table2']//tr/td[contains(@class,'dues')]"

And here is the outcome:

CSS total time 1000 repeats: 8.24 s, per find: 8.24 ms

XPath total time for 1000 repeats: 8.45 s, per find: 8.45 ms

A difference of 0.2 milliseconds.

The "Finding Elements By Traversing":

css_locator = '#table1 tbody tr td:nth-of-type(4)'
xpath_locator = "//table[@id='table1']//tr/td[4]"

The result:

CSS total time 1000 repeats: 9.29 s, per find: 9.29 ms

XPath total time for 1000 repeats: 8.79 s, per find: 8.79 ms

This time it is 0.5 ms (in reverse, XPath turned out "faster" here).

So five years later (better browsers engines) and focusing only on the locators performance (no actions like sorting in the UI, etc), the same testbed - there is practically no difference between CSS and XPath.

The Best/Fastest/Hip Strategy?

So, out of XPath and CSS, which of the two to choose for performance? The answer is simple – choose locating by id.

Long story short, if the id of an element is unique (as it's supposed to be according to the specifications), its value plays an important role in the browser's internal representation of the DOM, and thus is usually the fastest.

Fun fact - the webdriver protocol actually does not support locator strategy "by id". When one uses By.ID in selenium, what it actually does is to transform it to a css selector in the form "any element having an id attribute with the requested value". Still, the browsers optimize the css engines heavily, and it ends up in the advantage section of the DOM representation.

Yet, unique and constant (e.g. not auto-generated) ids are not always available, which brings us to "why XPath if there's CSS?"

The XPath advantage

With the performance out of the picture, why do I think XPath is better? Simple – versatility, and power.

XPath is a language developed for working with XML documents; as such, it allows for much more powerful constructs than CSS.

For example, navigation in every direction in the tree—find an element, then go to its grandparent and search for a child of it having certain properties. It allows embedded boolean conditions—cond1 and not(cond2 or not(cond3 and cond4)); embedded selectors —"find a div having these children with these attributes, and then navigate according to it".

XPath allows searching based on a node's value (its text)—however frowned upon this practice is. It does come in handy especially in badly structured documents (no definite attributes to step on, like dynamic ids and classes - locate the element by its text content).

The stepping in CSS is definitely easier—one can start writing selectors in a matter of minutes; but after a couple of days of usage, the power and possibilities XPath has quickly overcomes CSS.

And purely subjective – a complex CSS expression is much harder to read than a complex XPath expression.

Outro ;)

Finally, again very subjective - which one should we chose?

IMO, there isn’t any right or wrong choice—they are different solutions to the same problem, and whatever is more suitable for the job should be picked.

Being "a fan" of XPath I'm not shy to use in my projects a mix of both - heck, sometimes it is much faster to just throw a CSS one, if I know it will do the work just fine.

The debate between cssSelector vs XPath still now remains as one of the most heated and subjective conversation in the Selenium Community. A quick recap on what we had already known so far can be summarized as:

• People in favor of cssSelector say that it is more readable and faster (specifically when running against Internet Explorer).
• While those in favor of XPath tout it's ability to transverse the page (while cssSelector cannot).
• Traversing the DOM in older browsers like IE8 does not work with cssSelector but is fine with XPath.
• XPath can walk up the DOM (e.g. from child to parent), whereas cssSelector can only traverse down the DOM (e.g. from parent to child)
• However not being able to traverse the DOM with cssSelector in older browsers isn't necessarily a bad thing as it is more of an indicator that your page has poor design and could benefit from some helpful markup.

Dave Haeffner carried out a test on a page with two HTML data tables, one table is written without helpful attributes (ID and Class), and the other with them. I have analyzed the test procedure and the outcome of this experiment in details in the discussion Why should I ever use CSS selectors as opposed to XPath for automated testing?. While this experiment demonstrated that each Locator Strategy is reasonably equivalent across browsers, it didn't adequately paint the whole picture for us.

cssSelector vs XPath, Under a Microscope

Dave Haeffner in the discussion Css Vs. X Path, Under a Microscope mentioned, in an an end-to-end test there were a lot of other variables at play Sauce startup, Browser start up, and latency to and from the application under test. The unfortunate takeaway from that experiment could be that one driver may be faster than the other (e.g. IE vs Firefox), when in fact, that's wasn't the case at all. To get a real taste of what the performance difference is between cssSelector and XPath, we need to dig deeper. This can be achieved by running everything from a local machine while using a performance bench-marking utility. The focus was on a specific Selenium action rather than the entire test run, and run things numerous times.

To demonstrate this detailed example, a Windows XP virtual machine was setup and Ruby (1.9.3) was installed. All the available browsers and their equivalent browser drivers for Selenium was also installed. For bench-marking, Ruby's standard lib benchmark was used.

The Test

In order to get an adequate sample set of data, the same test was ran against each browser 100 times. And to weed out anomalies in the data the rehearsal feature of benchmark was used so that it would run the full test sequence, perform garbage collection, and then run it again. To make things comparable, a few of the locators were updated to make for better matches in comparison to each other. And the specific action we measured is find_element.

Test Code

require_relative 'base'
require 'benchmark'

class SmallDOM < Base

  LOCATORS = {
    :id => {
      id: 'table2'
    },
    :table_header_class => {
      class: 'dues'
    },
    :table_header_id_and_class => {
      :css => "#table2 thead .dues",
      :xpath => "//table[@id='table2']//thead//*[@class='dues']"
    },
    :table_header_id_class_and_direct_desc => {
      :css => "#table2 > thead .dues",
      :xpath => "//table[@id='table2']/thead//*[@class='dues']"
    },
    :table_header_traversing => {
      :css => "#table2 thead tr th:nth-of-type(4)",
      :xpath => "//table[@id='table2']//thead//tr//th[4]"
    },
    :table_header_traversing_and_direct_desc => {
      :css => "#table2 > thead > tr > th:nth-of-type(4)",
      :xpath => "//table[@id='table2']/thead/tr/th[4]"
    },
    :table_cell_id_and_class => {
      :css => "#table2 tbody .dues",
      :xpath => "//table[@id='table2']//tbody//*[@class='dues']"
    },
    :table_cell_id_class_and_direct_desc => {
      :css => "#table2 > tbody .dues",
      :xpath => "//table[@id='table2']/tbody//*[@class='dues']"
    },
    :table_cell_traversing => {
      :css => "#table2 tbody tr td:nth-of-type(4)",
      :xpath => "//table[@id='table2']//tbody//tr//td[4]"
    },
    :table_cell_traversing_and_direct_desc => {
      :css => "#table2 > tbody > tr > td:nth-of-type(4)",
      :xpath => "//table[@id='table2']/tbody/tr/td[4]"
    }
  }

  attr_reader :driver

  def initialize(driver)
    @driver = driver
    visit '/tables'
    super
  end

  # The benchmarking approach was borrowed from
  # http://rubylearning.com/blog/2013/06/19/how-do-i-benchmark-ruby-code/
  def benchmark
    Benchmark.bmbm(27) do |bm|
      LOCATORS.each do |example, data|
    data.each do |strategy, locator|
      bm.report(example.to_s + " using " + strategy.to_s) do
        begin
          ENV['iterations'].to_i.times do
         find(strategy => locator)
          end
        rescue Selenium::WebDriver::Error::NoSuchElementError
          puts "( 0.0 )"
        end
      end
    end
      end
    end
  end

end

Results

NOTE: The output is in seconds, and the results are for the total run time of 100 executions.

Analyzing the Results

• On a whole, Internet Explorer is slower than the other drivers, but between CSS and XPath it looks like XPath is actually faster than CSS.
• Chrome and Opera have some differences, albeit much smaller, but they sway in both directions.
• In some cases CSS is faster, and in others, XPath.
• Firefox looks to be a bit more optimized for CSS since it's mostly faster across the board.

Outro

Even with these speed differences they are only a few seconds (or fractions of seconds) apart -- and that's for 100 executions. When you think about how it takes 30 seconds or more to complete a test run, this kind of difference is negligible. So, the choice between css-selectors and xpath can be a tough one to make. But now you are armed with more than enough data to make the choice for yourself. It's really just a matter of finding what works for you and your team and to not get weighed down by the hype and opinions around which one is better.