Selenium: Is there a performance difference between By.Id("myelement") and By.Css("#myelement")?

Question

I was writing some helper methods for our testers around the IWebDriver in .NET, and started wondering whether there was any point in have a method to get an element by ID when you can use a CSS selector to also get the element by ID.

I would assume that, in the end, a request for CSS "#myelement" will be optimised away to document.getElementById("myelement") anyway.

Is there a performance difference? Should we bother using By.Id and By.Name when we can use CSS selectors to accomplish the same thing?

I think the only difference is that By.Id is showing that you searching through id, but when using By.Css("#"), you need to write more and to know CSS syntax, it's easier to read and understand By.Id then By.Css("#") IMHO — Andrian Durlestean, Jan 16 '14 at 11:37
Google Chrome (we do have the web driver set up for FireFox as well, but we rarely run it). — Richiban, Jan 16 '14 at 18:00

score 3 · Accepted Answer · answered Jan 16 '14 at 15:39

3

By.cssSelector() is faster than By.id().

The method to find elements using By.id() actually utilizes xpath:

    @Override
    public List<WebElement> findElements(SearchContext context) {
      if (context instanceof FindsById)
        return ((FindsById) context).findElementsById(id);
      return ((FindsByXPath) context).findElementsByXPath(".//*[@id = '" + id
          + "']");
    }

    @Override
    public WebElement findElement(SearchContext context) {
      if (context instanceof FindsById)
        return ((FindsById) context).findElementById(id);
      return ((FindsByXPath) context).findElementByXPath(".//*[@id = '" + id
          + "']");
    }

Where as By.cssSelector uses the CSS engine. CSS is faster than xpath, ergo, By.cssSelector will operate faster than By.id

answered Jan 16 '14 at 15:39

ddavison

28,221
15
85
110

That is not actually correct: "The method to find elements using By.id() actually utilizes xpath:". The first if is actually directing you to `((FindsById) context).findElementsById(id);`. That is a construct that I do not understand as `context instanceof FindsBy*` (where * is any (id, css..)) returns true. They are probably handling some weird edge case here. Anyway, my current tests with FF do not show XPath being slower than CSS. – Erki M. Aug 22 '14 at 13:39
so I want to see numbers. – Erki M. Aug 22 '14 at 13:44
unfortunately - SauceLabs has taken down my citation. A resource used to exist at: https://saucelabs.com/resources/selenium/css-selectors That actually had statistics and reasons to use CSS over XPath (Speed being one of them. ). They had since taken the page down and replaced it with what you see now. I don't think you'll notice any speed differences unless you have extreme-case selectors. As in, using xpath's `//` descendent hierarchy multiple times, combined with dynamic searching like `contains(@attr, '')` – ddavison Aug 22 '14 at 13:57
Also, with FF - they have a better engine than IE. If you use some complicated XPath, IE will slow down. Nowaday's, it's sort of irrelvant which one will do the best. CSS though, IS simpler. Take a [look at this](http://stackoverflow.com/questions/13975595/why-one-should-prefer-using-css-over-xpath-in-ie/14139380#answer-14165197) These are the statistics i was talking about – ddavison Aug 22 '14 at 13:59

Selenium: Is there a performance difference between By.Id("myelement") and By.Css("#myelement")?

1 Answers1