In the last tip I provided benchmarks that showed XPath and CSS performance across various browsers. Since then I've received feedback on some things that my test was missing -- most notably more browser coverage (e.g., Internet Explorer 9 and 10) and testing against a larger and deeper page.
In order to make sure these benchmarks are as thorough as possible I've put together an example that demonstrates a large and deep page, and retooled my test script accordingly. Otherwise, everything is pretty much the same as last time (e.g., dual runs to weed out anomalies, 100 test executions for time in seconds, etc.).
Let's dig into the results.
In Table Form
In Chart Form
What The Results Tell Us
Chrome and Firefox are clearly tuned for faster CSS performance. Internet Explorer 8 is a grab bag of CSS that won't work, an out of control XPath traversal that takes ~65 seconds, and a 38 second table traversal with no CSS result to compare it against.
In IE 9 and 10, XPath is faster overall. In Safari, it's a toss up, except for a couple of slower traversal runs with XPath. And across almost all browsers, the nested sibling traversal and table cell traversal done with XPath are an expensive operation.
That shouldn't be too surprising though since they are brittle and inefficient ways to write locators. Do try to avoid them.
So all in all there are two circumstances where XPath is markedly slower than CSS. But they are easily avoidable. Otherwise, the performance difference is slightly in favor of CSS for non-IE browsers and slightly in favor of XPath for IE browsers. Given that, I would recommend that you choose your locator strategy based on what works for you and your team. And really, it doesn't matter. If you can ensure that the primary elements on your page have unique IDs and Classes then that will always be faster than traversing across the DOM (regardless of which locator strategy you use).
If you want to do some benchmarking on your own, I wrapped up all the code I wrote into this library.