Googleが開発した新しいライブラリ、
Wicked Good XPathを紹介
します 。これは
、DOMレベル3のXPath仕様の実装です。 今日、このライブラリは既存のすべてのライブラリの中で最も高速であると確信しています。
使用を開始するには、
wgxpath.install.jsファイルをダウンロードして、ページで有効にしてください。
次に、現在のウィンドウで
document.evaluate 、Xpathナビゲーション関数へのアクセスを提供するページコードでw
gxpath.install()メソッドを呼び出します。 ライブラリ機能を別のウィンドウに追加する必要がある場合は、
install()メソッドでこのウィンドウにポインタを渡すだけです。
CSSセレクターの人気が高まっているにもかかわらず、
XPathはHTMLドキュメントの要素を取得するための便利なツールです。
Seleniumや
Web Puppeteerなどのフロントエンドテストアプリケーションで特によく使用されます。 さて、時には、Xpathがページ上の特定の要素にアクセスするための唯一の可能なソリューションである場合があります。
Xpathに出会ったことがない場合は、例を見てください。Google検索結果ページで、式
//li[@class=”g”][3]はリストの3番目の結果を指します。 これは、Chromeの
Xpath Viewerプラグインの
スクリーンショットから確認できます。
XPathを使用する際の主な問題は、一部のブラウザーでネイティブサポートが不足していることです。 たとえば、IEはHTMLドキュメントのXPathをサポートしていません。 この結果、多くの開発者はJavascriptソリューションの使用を余儀なくされています。 2005年に、Googleのエンジニアは
AJAXSLTライブラリをリリースし
ました 。これは、正しい
Xpathを実装しましたが、それほど高速ではありません。 IEでこのライブラリを照会するのはかなり時間がかかりました。
その後、2007年にサイボウズラボグループは別のライブラリである
Javascript-XPathを導入しました。これはAJAXSLTの10倍の速度でした。 多くのテストアプリケーションがそれに切り替え、すべてが素晴らしかったが、長くは続かなかった。 ライブラリはすぐにサポートを失い、バグを修正する人はいませんでした。 それは、
Google Closureに書かれていなかったという事実を考えると、Googleチームである私たちのアプリケーションに統合するのは簡単ではありませんでした。 ライブラリを書き換える必要がありました。
しかし、Google Closureに移植しただけではありません。 ライブラリのパフォーマンスに大きな影響を与えるいくつかの修正を行いました。このバージョンは元のバージョンよりも30％高速に動作します。 さらに、クロージャーコンパイラは25Kに縮小することができました。これはJavascript-XPathよりも40％少ないです。 最後に、新しいコードの構造化とドキュメント化により、ライブラリをさらにサポートするスピードと容易さが確実に得られると確信しています。
それとは別に、このプロジェクトでほとんどの作業を行った2人のGoogleインターン、Michael ZhouとEvan Thomasに感謝します。
GoogleのエンジニアであるGreg DennisとJoon Lee。