Selecting an element with unique ID say "sign", which is the preferred method:

  1. By.id("sign");
  2. By.xpath("//[@id="sign"]");
  3. By.css('[id="sign"]');

Lets filter out xpath because By.id uses document.getElementById() under the hood and it can be faster. But when we compare with css and id what is the difference and how exactly does document.getElementById() works

Does the choice of locator have any relationship with the web technology eg : angularjs

  • 2
    Please provide an helpful comment before downvoting
    – PDHide
    Nov 20, 2019 at 12:38

2 Answers 2


Here is the specification for how a webdriver conform implementation should handle element retrieval https://www.w3.org/TR/webdriver/#xpath. XPath is incredibly slow because every layer of your path is basically a loop over all children within the current scope.

id and css selector leverage the fact that browsers are already really good at using those identifiers since they must be evaluated while rendering the page. How exactly they're implemented depends on the specific browser but the outlines are defined here https://www.w3.org/TR/selectors-api2/ (and I'd really encourage working through it since it helps understanding browsers and by extension web applications). The short version comes down to the fact that your browser, when it has rendered the page, has already a mapping for important subspaces in your page from which it can work off to find your specific selector with much less effort as it would need if you were to bruteforce your way through it using an xpath.

Between id and css selectors ids tend to be a little bit faster since the lookup is basically the same for both but css selectors have to be parsed beforehand but in the end where talking differences of one digit milliseconds here.

  • Hi Daniel , thank you so much for commenting. Does the speed of id and css depends on type of application ? does even an angularjs application has id as the faster locator?
    – PDHide
    Nov 20, 2019 at 16:35
  • 1
    Well, first of all, at the point where you weigh ids vs. css selectors you're definitely in purely academic territory. Pretty much every other factor will have more influence on your runtime than the decision which selector strategy to use but usually the fastest lookups happen on selectors already known to the system. So it depends on the application since if you reuse selectors already used by your styling it will be slightly (almost immeasurably) faster. But since the differences for every selector other than xpath is very small readability should be a much higher priority than speed.
    – Daniel
    Nov 22, 2019 at 2:08

This comes up repeatedly.

My answer is that all the studies I have seen have shown that the difference is trivial in comparison to the actual UI test suite run time.

For example when the run time is 5 minutes for a UI test, the fact that one selector approach over another is more efficient is still usually on the order of differences under 1 second.

So really, it's the age old problem #2 (of 2) in computer science - Avoid Premature Optimization

If the speed of locator is an actual, real demonstrable and significant problem then use an approach to address it.

Again, don't compare x to y without considering the bigger picture (in this case overall run time). It probably doesn't matter if x is 300% faster than y if both add up to less than a second on a suite that runs for minutes.
The need for code to be readable - and css is usually more readable by humans in my experience - outweighs minor differences in performance.

See also:



Difference Between CSS and XPATH

  • True , I don't know if there is already an implementation where we use css for everything , does it really worth the effort of migrating to id
    – PDHide
    Nov 22, 2019 at 7:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.