
Wicked Good XPath: Fast Jpath in Javascript
- Transfer
We are pleased to introduce a new library developed by Google - Wicked Good XPath , an implementation of the XPath specification for DOM Level 3 . We are sure that today this library is the fastest of all existing.
To start using it, just download the file
Then call the w method
Despite the growing popularity of CSS selectors, XPathstill remains a useful tool for fetching elements in an HTML document. It is especially often used in front-end testing applications such as Selenium and Web Puppeteer . Well, and sometimes there are times when Xpath is the only possible solution to access certain elements on a page.
If you've never met Xpath before, take a look at an example: on the Google search results page, the expression

The main difficulty in using XPath is the lack of native support in some browsers. For example, IE does not support XPath on HTML documents. As a result of this, many developers are forced to use Javascript solutions. Back in 2005, Google engineers released the AJAXSLT library , which implemented the correct, but not very fast, Xpath. Querying this library in IE was pretty long.
Later, in 2007, the Cybozu Labs group introduced another library, Javascript-XPath , which was 10 times faster than AJAXSLT. Many testing applications switched to it, and everything was wonderful, but not for long. The library quickly lost support, there was no one to fix bugs. Well, in view of the fact that it was not written inGoogle Closure , for us, Google, was not easy to implement it in their applications. The library needed to be rewritten.
But we didn’t just port it to Google Closure. We made some corrections that significantly affected the performance of the library - our version works 30% faster than the original. In addition, the Closure compiler was able to shrink it to 25K, which is 40% less than Javascript-XPath. Well, and finally, we are sure that the new structuring and documentation of the code will provide speed and ease in further supporting the library.
Separately, we want to thank our two Google interns, Michael Zhou and Evan Thomas, who did most of the work in this project.
Google engineers, Greg Dennis and Joon Lee.
To start using it, just download the file
wgxpath.install.js
and include it on your page. Then call the w method
gxpath.install()
in the page code, which will provide access to the document.evaluate
Xpath navigation function in the current window ( window
). If you need to add the library functionality in another window, just pass the pointer to this window into the method install()
. Despite the growing popularity of CSS selectors, XPathstill remains a useful tool for fetching elements in an HTML document. It is especially often used in front-end testing applications such as Selenium and Web Puppeteer . Well, and sometimes there are times when Xpath is the only possible solution to access certain elements on a page.
If you've never met Xpath before, take a look at an example: on the Google search results page, the expression
//li[@class=”g”][3]
will point to the third result in the list. This can be seen from the screenshot of the Xpath Viewer plugin for Chrome.
The main difficulty in using XPath is the lack of native support in some browsers. For example, IE does not support XPath on HTML documents. As a result of this, many developers are forced to use Javascript solutions. Back in 2005, Google engineers released the AJAXSLT library , which implemented the correct, but not very fast, Xpath. Querying this library in IE was pretty long.
Later, in 2007, the Cybozu Labs group introduced another library, Javascript-XPath , which was 10 times faster than AJAXSLT. Many testing applications switched to it, and everything was wonderful, but not for long. The library quickly lost support, there was no one to fix bugs. Well, in view of the fact that it was not written inGoogle Closure , for us, Google, was not easy to implement it in their applications. The library needed to be rewritten.
But we didn’t just port it to Google Closure. We made some corrections that significantly affected the performance of the library - our version works 30% faster than the original. In addition, the Closure compiler was able to shrink it to 25K, which is 40% less than Javascript-XPath. Well, and finally, we are sure that the new structuring and documentation of the code will provide speed and ease in further supporting the library.
Separately, we want to thank our two Google interns, Michael Zhou and Evan Thomas, who did most of the work in this project.
Google engineers, Greg Dennis and Joon Lee.