「最速のPython HTMLパーサー」を名乗る記事では、だいたい selectolax が取り上げられます。そして多くの場合、話は「BeautifulSoupよりずっと速い」で締めくくられます。そこまでは事実です。ただ、selectolax を lxml と並べたときに何が起きるのかまでは、ほとんど語られません。そこでは「最速」に少し注釈が必要になります。
そこで今回は、ちゃんとベンチマークを取りました。selectolax の両バックエンド、lxml、BeautifulSoup（html.parser と lxml）、それから parsel を、1 KB から 10 MB までの5段階のページサイズで比較しています。各計測は3回の独立プロセス実行の中央値を採用しました。結果としては、selectolax は BeautifulSoup を圧倒し、raw の lxml とほぼ互角、ただし純粋なパース処理では lxml に一歩譲る、という形でした。以下の数値はすべて暫定で、しかも1台のマシン（macOS arm64、Python 3.14.2）での結果です。スクリプトは公開済みなので、引用する前にぜひ自分の環境でも試してみてください。
selectolax とは何か、そして何ではないのか
selectolax は、HTML5 を解析して CSS セレクタで検索できる2つの C エンジン、Modest と Lexbor に対する Python バインディングです。クローラーではありません。ブラウザでもありません。ボタンひとつで使える意味での「スクレイパー」でもありません。すでに取得済みの HTML の塊を渡して使うものです。メンテナー自身の説明をひとことで言うと、「Cython で書かれ、Modest と Lexbor エンジンを使う、高速な HTML5 パーサー」 です。
バックエンドは2種類あり、この違いはドキュメント以上に大事です。
LexborHTMLParser（Lexbor エンジン）— README が 2024 年時点で推奨しているのはこちら。HTMLParser（Modest エンジン）— 元祖版です。README によると、元の C ライブラリは「もはや保守されていない」とされています。
速度の話に入る前に、先に押さえておきたい事実があります。2026-07-10 時点の リポジトリのスナップショット では、selectolax は 1,653 スター、最新リリースは v0.4.10（2026年5月）でした。PyPI の対象 Python は >=3.9,<3.15 です。インストールは、このレビューでいちばん地味な部分でした。pip install selectolax で 2.3 MB の事前ビルド済み cp314 ホイールが入り、Python 3.14 ですぐ動きました。ブラウザのダウンロードも、doctor ステップも、コンパイルも不要です。ブラウザ依存のツールではなく純粋なパーサーであることの、静かな強みです。入れてしまえば、そのまま import して動きます。
もうひとつ、先に触れておくべきライセンス面の注意があります。Python バインディング自体は MIT ですが、実際に配布されるホイールにはエンジン本体が同梱されていて、それぞれ独自のライセンスが付いています。Modest は LGPL-2.1、Lexbor は Apache-2.0 です。つまり「selectolax は MIT」は Python コードについては正しいものの、実際に出荷するバイナリ全体としては不十分な説明です。配布コンポーネントの法務が気になるなら、この違いは必ず確認しておくべきです。
速度の実態を、数字で確認する
今回計測したタスクは、HTML 文字列を解析し、<h3 class="title"> のテキストを全部取り出し、<a> の href をすべて取得する、というものです。単位はミリ秒です。3回の独立プロセス実行の中央値を採用しており、C ベースのパーサーではサイズによって実行間のばらつきはだいたい5%未満に収まりました。各セルの計測前には、すべてのパーサー出力を content hash に落として、もし静かに処理量が少ないパーサーがあれば検出して除外するようにしています。このページ群では6つすべてが全サイズで一致したので、純粋な比較になっています。完全なデータはコミット済みの bench_parse.json にあります。
| ページサイズ | selectolax (Lexbor) | selectolax (Modest) | lxml | parsel | BS (lxml) | BS (html.parser) |
|---|---|---|---|---|---|---|
| 1 KB | 0.027 | 0.029 | 0.036 | 0.044 | 0.281 | 0.323 |
| 10 KB | 0.160 | 0.171 | 0.166 | 0.228 | 1.705 | 2.049 |
| 100 KB | 1.464 | 1.565 | 1.423 | 2.020 | 16.5 | 20.6 |
| 1 MB | 14.901 | 16.9 | 14.177 | 20.9 | 181.9 | 232.6 |
| 10 MB | 159.9 | 247.9 | 172.9 | 231.9 | 2261.6 | 2788.7 |
BeautifulSoup との比較：だいたい12〜17倍。よくある通説は控えめすぎる
この数値を比率にすると、selectolax-Lexbor は 1 KB ページで BeautifulSoup(html.parser) より約12倍速く、10 MB では約17倍。同じ範囲で BeautifulSoup(lxml) よりも約10〜14倍速い という結果でした。ネットでよく見る「selectolax は BeautifulSoup より4〜5倍速い」という話は、html.parser 相手にはかなり控えめで、lxml ベースの BeautifulSoup に対してのみだいたい妥当です。本当の倍率は、どの BeautifulSoup を指すか、そして1ページあたりどれだけ抽出するかで変わります。
これは README に載っているベンチマークとも整合しています。そこでは BeautifulSoup(html.parser) に対して 25.5 倍の差が示唆されています。どちらの数字も間違いではありません。README のタスクは、小さなホームページから title、リンク、script、meta を抜き出すもので、パースあたりの処理量が少ないため、BeautifulSoup のオーバーヘッドがより目立ちます。範囲を限定して言うなら、実務的な「解析して抽出する」作業に対して selectolax は BeautifulSoup よりおおむね10〜15倍速く、ページが小さいほど、抽出量が少ないほど差が広がります。
いま BeautifulSoup のコードがページ処理のボトルネックになっているなら、ここは移行コストに見合う場面です。ここまでは異論も少ないでしょう。問題は次です。
lxml との比較：ほぼ引き分け。ただし純パースでは lxml が先に出る
100 KB と 1 MB の行を見直してください。Lexbor と lxml の差は 5% 前後に収まり、1回ごとのばらつき区間も重なっています。私の基準ではこれは引き分けで、「どちらが速い」とは言いません。selectolax が本当に優位に立つのは 10 MB ページのときだけです（159.9 ms 対 172.9 ms、差は 8.1% で区間も重なっていません）。つまり、タスク全体では selectolax は lxml に並び、勝つのはかなり大きなドキュメントだけです。
そのあと、ツリー構築と CSS クエリを切り分けてみると、多くの解説記事が見落としている結果が出ました。クエリを一切しない純粋なパースでは、この環境では lxml が selectolax-Lexbor より一貫して約33〜34%高速でした。10 MB ページでは 77.9 ms 対 116.6 ms です。全体タスクでは両者は結局近づくので、私の仮説では（これは因果を実験で証明したわけではありません）、このページ群では CSS クエリが全体時間の中で小さな割合しか占めず、lxml のパース段階での優位性が薄まって、最終的に総時間が拮抗しているのだと思われます。
この主張は、このレビューでいちばん突っ込まれやすい部分です。なぜなら、一般的な定説をひっくり返しているからです。しかも、パースだけを切り出した公開ベンチマークのうち、私が見つけた aows.jpt.sh では逆の結果、つまり selectolax が約4倍速いと出ています。なので、ここはかなり慎重に囲いました。結果は単一プラットフォーム（macOS arm64、Python 3.14、事前ビルド済み cp314 ホイール。Linux x86_64 やソースビルドは未検証）、4つのページサイズで再確認され、すべてで同じ傾向でした。さらに、API 起因の偶然を排除するため、lxml の異なる2つの API でも再検証しています。どちらの lxml API でも、すべてのサイズで selectolax-Lexbor より速かったです。私は「lxml のほうが速い」と断定しているのではなく、公開されている多くの数値と比べても、私のベンチではこう出た、ということをスクリプト付きで示しています。ぜひ自分の環境でも実行してみてください。
もう1点だけ。フラットなページで <a> を100,000件クエリしたところ、lxml と selectolax-Modest は引き分けでした（33.30 ms 対 34.19 ms、区間は重複）。一方で selectolax-Lexbor は両者より約15%遅れます。3つの C エンジンに共通しているのは、parsel や BeautifulSoup より5〜7倍速く大量選択できることです。Python のオブジェクトをノードごとに作るモデルが本質的な足かせだからです。つまり、「大量の CSS セレクタ処理で selectolax が最速」とは言えません。Modest は lxml と並ぶだけで、Lexbor は lxml に負けます。
私が実際に自信を持って言える結論はこうです。selectolax が lxml に対して持つ優位性は、広い意味での全体速度ではありません。最も大きなページでだけ勝ちます。本当の価値は、API の使いやすさ、壊れた入力への強さ、そしてモダン CSS の扱いやすさにあります。そこがこのレビューの残りの部分です。
メモリとコールドスタート：プロファイラではなく RSS で見る
メモリについては、以前の私の数値を修正しなければなりません。そしてその修正こそが重要です。tracemalloc を切った状態で 10 MB ページの RSS 変化量を測ると、BeautifulSoup は selectolax や lxml の約1.5〜1.8倍のメモリを使います。範囲は、最小で 1.51 倍（BS-lxml の 218.4 MB に対し Lexbor は 144.6 MB）から、最大で 1.75 倍まででした。selectolax と lxml はどちらも軽量側に並び、RSS で最も軽いのは lxml です。
以前の試算では「約3倍」と書いていましたが、それは不正確でした。理由は明快で、tracemalloc を動かしたまま測っていたためです。tracemalloc は各アロケーションの管理コストを持つので、アロケーションの多いパーサーほど見かけの RSS を大きくします。パーサーのメモリ比較をするなら、プロファイラを切った状態で RSS を見て順位付けするべきです。tracemalloc のピークで比べると、特に C ベースのパーサーの順序が狂います。実際には近いのに、selectolax-Lexbor が Modest より重く見えてしまいました。ここで本当に重いのは BeautifulSoup です。ただし、汚れた計測器で見えたような「3倍重い」ほどではありません。
コールドスタートも小さいながら無視できません。selectolax の import は約14 msで、lxml とほぼ同程度、bs4 や parsel より約2.3倍速いです。CLI ツールやサーバーレス関数のように、起動時間が毎回の実行コストに含まれる環境では、見逃せない差です。
CSS セレクタの対応範囲：かなり強いが、いくつか本当の穴がある
CSS 対応範囲は41ケースのマトリクスで確認しました。各セレクタは、正解が既知の fixture に対して照合し、さらに Lexbor エンジンを壊すことを目的にした意地悪なテストも追加しています。各ケースは独立したサブプロセスで実行しました。というのも、そのうち1つはインタプリタごと落とすからです。結果は以下の通りです。
| エンジン | PASS | WRONG | UNSUPPORTED | PROCESS_ABORT |
|---|---|---|---|---|
| soupsieve | 41 | 0 | 0 | 0 |
| selectolax Lexbor | 39 | 0 | 2 | 0 |
| lxml (cssselect) | 37 | 1 | 3 | 0 |
| parsel (cssselect) | 37 | 1 | 3 | 0 |
| selectolax Modest | 35 | 3 | 2 | 1 |
意地悪なセレクタを混ぜると、Lexbor が圧勝というわけではありません。41/41 の soupsieve が最強で、Lexbor は 39/41 でした。Lexbor が落とした2つは :lang(en) と :dir(rtl) で、どちらも parse error になります。それ以外、:has()、:is()、:where()、大小文字を無視する属性指定まで含めて、全部ちゃんと動きます。
一方で、cssselect 系に対して Lexbor が優れている点ははっきりしています。README の代表的なセレクタ — div > :nth-child(2n+1):not(:has(a)) — は、selectolax の両エンジンと soupsieve では正しい結果を返しますが、lxml と parsel では誤った結果を返してもエラーになりません。Scrapy や parsel にそのまま持ち込むと、静かに間違った抽出結果になります。表現を正確にすると、cssselect は 1.2.0（2022年）から :has() を解析でき、私が試したのは 1.4.0 です。したがって、これは「未対応」ではなく「対応しているが複合条件の評価が誤る」という状態です。この複合セレクタでのサイレントな誤結果は、:has() の制限をエラーとして記録している cssselect のトラッカー には載っていません。Lexbor はまた、[data-role="LEAD" i] のような大文字小文字を無視する属性フラグも正しく扱えますが、cssselect はこれをそのまま拒否します。
ただし、移行を左右する大きな欠点が2つあります。selectolax は XPath を一切サポートしません。どちらのバックエンドにも xpath() はありません。また、::text / ::attr() 疑似要素もありません。これは実 CSS ではなく、parsel / Scrapy の拡張です。既存のスクレイパーが XPath に依存しているなら、ここが最大の壁になります。単にライブラリを差し替えるのではなく、セレクタを書き直す必要があるからです。逆に Lexbor には、他では使えないケース非依存のテキスト一致用疑似クラス :lexbor-contains("text" i) があり、これはドキュメントどおり動きます。
ぐちゃぐちゃな HTML に対する頑健性。selectolax が真価を発揮するところ
現実のスクレイピングでは、壊れた入力をパーサーに投げて、それでも落ちないことを期待します。そこで18種類の意地悪な入力を試しましたが、このカテゴリでは selectolax が lxml に対して最も強いです。
空文字列や空白だけを lxml.html.fromstring に渡すと、ParserError("Document is empty") が発生します。selectolax の両バックエンドは、どちらも有効な空ツリーを返します。 URL リストを回していて、そのうち一部のレスポンスが空で返るようなスクレイパーでは、try/except で全体を包む必要が1つ減ります。selectolax は 100,000 要素の入力もスタックオーバーフローなしで処理しました。
深いネストでは差がいちばんはっきり出ました。<div> の入れ子が 1,000 層、5,000 層になると、lxml は最深部の内容を静かに落としますが、selectolax は保持します。 libxml2 はパース深度をおおむね256層で打ち切り、エラーも出さずにツリーを切り詰めるため、最深部のテキストは届かなくなります。selectolax の両エンジンは完全なツリーを返します。これは後で触れる <template> の罠の反対です。あちらでは Lexbor が他のパーサーが保持する内容を落とし、こちらでは lxml が selectolax が保持する内容を落とします。
すべてが勝ちだったわけではありません。Modest バックエンドは :dir() に遭遇すると、例外を投げるのではなく Python インタプリタ全体を SIGABRT で終了させます。これは legacy バックエンドを今も使っている人にとって、見逃せない頑健性の問題です。しかも、本番ジョブが朝3時に落ちるまで気づきにくいタイプの不具合でもあります。
リリース前に知っておくべき、2つのサイレントなデータ損失ポイント
どちらも upstream では既知ですが、どちらも実データを静かに失います。そして README では大きくは触れられていません。
Lexbor は <template> 内の <a> を落とす
実際の MDN ページで試したところ、selectolax-Lexbor が見つけたリンクは 497 件でしたが、lxml、両方の BeautifulSoup バックエンド、そして selectolax の Modest バックエンドは 508 件を見つけました。 足りなかった11件は、<template> 要素の中にあった言語切り替えリンクと discussions へのリンクです（このページは Lit の Web Components を使っています）。
原因はちゃんとあります。HTML5 仕様では <template> の内容は通常の DOM ではなく、別の不活性なフラグメントとして解析されます。Lexbor はこれに厳密に従うため、tree.css("a") は template 内をたどりません。lxml、両方の BeautifulSoup バックエンド、そして Modest は template の内容をメインツリーに平坦化するので、そのリンクも拾います。これは既知の未解決 issue です (selectolax#146、エンジン側の根本原因は lexbor#170)。どちらの解釈にも理はあります。仕様に忠実なのは Lexbor のほうだと言えるでしょう。ただし、推奨バックエンド を使っている開発者がそのデータを静かに見落とすのは事実です。逆に言えば、他のパーサーはブラウザが実際には描画しない不活性な template 内容まで表面化するので、ユーザーには見えないはずの幻のデータを渡してくることがあります。このケースだけなら、頼れる逃げ道は Modest バックエンドか、別ライブラリです。
UTF-8 ではないバイト列は .text() を静かに壊す
selectolax に UTF-8 として不正な bytes を渡しても、パース自体は成功します。問題は後で表面化し、しかもきれいに落ちるより厄介です。"<p>café éè</p>".encode("latin-1") を渡すと、Lexbor の .text() は置換文字を返し、Modest の .text() は問題のバイトを静かに落とします。そしてどちらのエンジンも、.html に触れた瞬間にだけ UnicodeDecodeError を投げます。バインディングはパース時ではなく読み戻し時に strict UTF-8 としてデコードするのです。これは、エンコード/デコードの厳格さに関する 既知の selectolax issue と関係しています。
修正は1行で済み、しかも体に覚えさせるべきです。bytes は自分で先に decode してください。たとえば LexborHTMLParser(resp.content.decode("latin-1")) のようにすれば、どちらのエンジンでも 'café éè' を正しく返します。実務では、selectolax には必ず str を渡し、UTF-8 でない raw の bytes は渡さないのが鉄則です。README にはこの点がはっきり書かれていません。
本番運用の観点（1回測定なので、傾向として見る）
ここからの結果は3回ではなく1回だけ測っているので、確定値ではなくシグナルとして扱ってください。
いちばん面白いのはスレッドスケーリングです。1 MB ページを4スレッドで48回パースしたところ、selectolax は約3.5〜3.9倍の wall-clock 短縮を示しました。これは、C のパース中に GIL を解放しているライブラリに典型的な挙動です。一方 BeautifulSoup(lxml) はスレッド化すると数倍遅くなり、GIL 上で処理が直列化しているサインが出ました。lxml はその中間で、決定打にはなりませんでした。Python が向かっている free-threading 時代を考えると、BeautifulSoup とは違って selectolax のパースがスレッド間で並列化されるのは、暫定的ではあるものの、実際の強みです。ただし、これは1ページサイズでの1回のスレッド数に限った話で、機構についても C コードを計測して確かめたわけではなく仮説です。
メモリリークについては、1 MB の parse-extract-drop を 2,000 回繰り返しても、3つのパーサーのどれにもリーク特有の直線的な RSS 増加は見られず、各々が一定のワーキングセット帯に収まりました。この結果を信じているのは、同じ計測器に既知のリーク検証対象を通したところ、意図どおり +198 MB まで上がり、計測器がリークを見抜けることが証明されたからです。つまり、パーサーではリークが見つからなかっただけです。さらに、所有していたツリーがスコープ外に出た後でも、ノードハンドルは有効なままで、segfault も起きませんでした。いずれも単発観測で、長時間の soak テストではありません。
selectolax はどこに向いていて、どこで役割を終えるのか
ここまでの話はすべて、すでに手元にある HTML を高速に構造化データへ変える、という1つの仕事についてです。selectolax はこの仕事がとても得意です。逆に、ページの取得、JavaScript のレンダリング、プロキシの切り替え、CAPTCHA の解決、そして「どの要素が欲しいのか」を判断することはやりません。そこは今もあなたのコードの役目です。selectolax はパース層であり、それ以上を名乗りません。
だからこそ、パーサーの上に置くべきなのは、パーサーを置き換えるものではなく、管理された抽出サービスです。取得・レンダリング・アンチボット・抽出のスタックを自前で作って保守したくないなら、Thunderbit はそれを API、MCP サーバー、CLI として提供しています。POST /distill でページをきれいな Markdown に変換し、POST /extract でスキーマ一致の構造化 JSON を返します。JavaScript レンダリングやアンチボット処理は Thunderbit 側で面倒を見ます。問題のレイヤーが違うのです。すでに HTML を持っていて、その生のパース速度を自分でコントロールしたいなら selectolax。取得と抽出を任せて、構造化データだけ返してほしいなら、Thunderbit の API、MCP サーバー、または CLI のようなものを選ぶ、ということです。置き換えではなく、同じスタックの別の高度です。
長所・短所・そして本当に使うべき人
selectolax が強いところ:
- 現実的な解析＋抽出作業で BeautifulSoup より約12〜17倍高速。ページサイズが3桁変わっても安定。
- メモリが軽い（lxml 帯で、BeautifulSoup より約1.5〜1.8倍少ない）うえ、import も約14 ms。
- 空入力、空白、極端に深いネストなど、lxml が苦手な入力でも素直に動く。
:has()、:is()、:where()、大小文字無視属性、Lexbor 専用の:lexbor-contains()など、現代的な CSS に対応。- None 安全な DOM 操作：要素がなければ
Noneや[]が返り、例外を投げにくい。さらにツリーの変更と再シリアライズもできる。 - 現役でメンテされている（v0.4.10、2026年半ば）うえ、インストールも簡単。
selectolax が弱いところ:
- lxml より広い意味で速いわけではない。全体タスクでは引き分けで、純パースでは私の環境では lxml が勝った。
- XPath 非対応、
::text/::attr()もなし。XPath ベースのスクレイパーにとっては大きな移行壁。 - サイレントなデータ損失が2つある。Lexbor の
<template>内容と、.text()での非 UTF-8 bytes だ。 - Modest バックエンドは legacy で、
:dir()でインタプリタを SIGABRT させる。 - ここでの数値はすべて単一プラットフォーム（macOS arm64、Python 3.14）での暫定結果。
selectolax を使うべきか？ 使うべきです。lxml 級のパース速度を、より扱いやすくて None 安全な API で、空や壊れた入力にもかなり強い形で欲しいなら向いています。ただし CSS だけの世界でやっていく覚悟は必要です。もしコードベースが XPath に縛られているなら、書き換えコストは現実的に発生します。さらに「単純にいちばん速いパーサー」を追っているなら、このベンチからの正直な答えは、selectolax と lxml は十分近く、決め手は生速度ではなく、使い勝手と頑健性だということです。ツール選びの理由としては、そのほうがずっと健全です。
Webデータ抽出に Thunderbit を試す Get Started Free
よくある質問
selectolax は BeautifulSoup より速い？
はい、明確に速いです。現実的な parse-and-extract タスクでは、BeautifulSoup(html.parser) より約12〜17倍、BeautifulSoup(lxml) より約10〜14倍高速でした。1 KB から 10 MB まで一貫してこの差が出ています（macOS arm64、Python 3.14）。よく言われる「4〜5倍」は、html.parser との比較としては差を過小評価しています。
selectolax は lxml より速い？ 広い意味ではそうとは言えません。解析＋抽出の全体タスクでは 100 KB と 1 MB で引き分けで、selectolax が勝つのは 10 MB ページだけでした。クエリなしの純パースでは、私の環境では lxml のほうが約33〜34%速かったです。これは単一プラットフォームの結果なので、自分の環境でも確認してください。
Lexbor と Modest のどちらを使うべき？
ほとんどの場合は Lexbor です。README が推奨する現行の高機能エンジンで、CSS 対応範囲も優れています。例外は <template> の中にコンテンツを隠しているページで、その場合は Lexbor の仕様準拠の挙動により内容が見えなくなり、たまたま Modest のほうが拾えます。ただし Modest には :dir() でインタプリタを落とすなど、かなり鋭い欠点があります。
selectolax は XPath をサポートしている？
いいえ。どちらのバックエンドにも xpath() メソッドはありません。selectolax は CSS 専用です。XPath に依存したスクレイパーを移す場合は、セレクタの書き換えが必要で、これが lxml や parsel から移行する際の最大のコストです。
selectolax の出力が崩れる、または要素が欠けるのはなぜ？
よくある原因は2つです。テキストが置換文字になったりアクセントが消えたりするなら、UTF-8 ではない raw bytes をそのまま渡している可能性があります。パース前に resp.content.decode("latin-1") のように str に変換してください。モダンなサイトでリンクや要素が見つからないなら、それらは <template> タグの中にあり、Lexbor バックエンドが降りていない可能性があります。そのページだけ Modest や別のパーサーに切り替えてください。
