cssSelector vs XPath for selenium

Question

As per my understanding, CSS selector traverses through the DOM. Because CSS files will not have any info about element position then why cssSelector is faster then XPath (theoretically).

Theoretically cssSelector taking less time then XPath as XPath need to traverse through HTML DOM. XPath we can search elements backward or forward in the DOM hierarchy while CSS works only in a forward direction.

But if cssSelector also traverse through HTML DOM then how it make cssSelector faster.

In other words how cssSelector actually works internally and reason why it always preferable/recommended to use by everyone then xpath

Also please share other benefit of using cssSelector over XPath.

And vice versa in which area XPath are better then cssSelector

Answer 1

I've read a lot of articles and I've seen some like this and this that have data that show that CSS selectors are faster and I've done a little testing and have come to the same conclusion. I talked to Dave Haeffner, author of elementalselenium.com, in Dec 2016 and asked him about the perf numbers on his site (in the post I linked above) since they were pretty old. He linked me a presentation (see pp18-23) where he updated the tests and CSS selectors are still faster but XPath is catching up in a few configs.

So we can see evidence that it's true but I've never seen anyone talk about the technical details of why. If I were to guess, it would be because a lot of work has gone into the different browsers to optimize the speed of page rendering. Having CSS selectors work quickly makes the page render faster and since the browser drivers take advantage of the browser's ability to locate elements, that means CSS selectors generally win. I've read that some browsers have improved their XPath locator speed but I think it will likely always lag behind CSS selectors because it's just much less common than CSS selectors.

Both CSS selectors and XPath have to traverse through the DOM so there's no real difference there other than the speed of the engine that does the traversing. The CSS selector engine is likely a fine tuned machine by this point vs the XPath engine because of the wide spread use of CSS selectors.

My general locator strategy is ID first, CSS selector for everything else. When nothing else works I use XPath. It will vary from site to site but in my experience, IDs are maybe ~10% of my locators. CSS selectors are probably ~80% and the last 10% is XPath. I generally use XPath for when I need to locate an element by the contained text and very rarely DOM traversal. An example of my XPath usage might be I need to find an element in a TABLE relative to a row label, e.g. the price of cheese in a table row where the first cell contains "cheese" and the third cell contains the price.

I think XPath is seen a lot on sites like SO and many blogs because of its easy access. All I have to do is right-click an element in the devtools and Copy XPath. The problem is many times that generates a bad, brittle XPath. A handcrafted XPath is better but it takes time and experience to handcraft a good XPath or CSS selector. Time that many aren't willing to put in. A badly crafted CSS selector or XPath will make things slower also. Many times there are any number of ways that an element could be located, some are way more efficient than others... it comes down to the efficiency of the locator and how you use it. A badly formed CSS selector isn't automatically going to be faster than a well formed XPath,.