Почти в каждом материале про «самый быстрый Python HTML-парсер» в итоге всплывает selectolax, и почти везде история заканчивается на фразе «намного быстрее BeautifulSoup». Это правда. Но обычно умалчивают о том, что происходит, если поставить selectolax рядом с lxml — потому что там у слова «самый быстрый» появляется звёздочка.
Поэтому я проверил всё как следует: сравнил selectolax (оба его backend’а) с lxml, BeautifulSoup на html.parser и на lxml, а также с parsel — на пяти размерах страниц от 1 КБ до 10 МБ, причём каждое значение брал как медиану трёх отдельных запусков процесса. selectolax разгромил BeautifulSoup и сравнялся с чистым lxml — а потом проиграл lxml на этапе собственно парсинга. Все цифры ниже предварительные и получены на одной машине (macOS arm64, Python 3.14.2); скрипты выложены в репозиторий, так что прежде чем цитировать меня, проверьте на своей системе.
Что такое selectolax на самом деле — и чем он не является
selectolax — это Python-обёртка над двумя C-движками, Modest и Lexbor, которые разбирают HTML5 и позволяют работать с ним через CSS-селекторы. Это не краулер, не браузер и не «scraper» в смысле кнопки «нажать и получить данные». Это инструмент, которому вы передаёте уже загруженный HTML. Сам автор описывает его одной строкой: «Быстрый HTML5-парсер с CSS-селекторами, написанный на Cython и использующий движки Modest и Lexbor».
Есть два backend’а, и разница между ними важнее, чем это может показаться по документации:
LexborHTMLParser(движок Lexbor) — именно его README рекомендует использовать с 2024 года.HTMLParser(движок Modest) — оригинальная версия, при этом сам README честно предупреждает, что лежащая под ней C-библиотека «больше не поддерживается».
Перед разговором о скорости полезно знать ещё несколько фактов. На момент снимка репозитория, сделанного 2026-07-10, у selectolax 1 653 звезды, а последний релиз — v0.4.10 (май 2026). В PyPI заявлена поддержка Python >=3.9,<3.15. Установка — самая беспроблемная часть обзора: pip install selectolax скачал готовое wheel-собрание cp314 размером 2.3 МБ и сразу заработал на Python 3.14 — без загрузки браузера, без шага doctor, без компиляции. В этом и есть тихое преимущество чистого парсера перед инструментом на базе браузера: он просто импортируется и работает.
Есть и нюанс по лицензии, о котором лучше сказать сразу. Python-обвязка распространяется под MIT, но в wheel уже встроены сами движки, а у них свои лицензии: Modest — LGPL-2.1, Lexbor — Apache-2.0. Поэтому фраза «selectolax — это MIT» верна только для Python-кода и не полностью описывает бинарный пакет, который вы фактически распространяете. Если ваш отдел юристов смотрит на включённые компоненты, это как раз тот момент, на который стоит обратить внимание.
Вопрос скорости, подтверждённый цифрами
Вот что я измерял: парсинг HTML-строки, извлечение текста у всех <h3 class="title"> и сбор всех href у <a>. Латентность в миллисекундах брал как медиану трёх отдельных запусков процесса; разброс между запусками для C-бэкендов на большинстве размеров держался в пределах примерно 5%. До измерения каждой ячейки вывод каждого парсера сводился к хэшу содержимого, чтобы не пропустить парсер, который молча делает меньше работы; на этих страницах все шесть вариантов совпали на каждом размере, так что сравнение действительно «яблоко к яблоку». Полные данные лежат в 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 оказывается примерно в 12 раз быстрее BeautifulSoup(html.parser) на странице 1 КБ и доходит примерно до 17 раз на 10 МБ, а также примерно в 10–14 раз быстрее BeautifulSoup(lxml) в том же диапазоне. Часто повторяемая в интернете цифра — «selectolax примерно в 4–5 раз быстрее BeautifulSoup» — слишком скромная, если сравнивать с html.parser, и лишь приблизительно верна для BeautifulSoup на базе lxml. Реальный множитель зависит от того, какой именно вариант BeautifulSoup вы имеете в виду и сколько данных извлекаете со страницы.
Это согласуется и с собственным benchmark’ом README, где заявлен отрыв в 25.5 раза от BeautifulSoup(html.parser). И там, и тут цифры не противоречат друг другу. Задача в README — заголовки, ссылки, скрипты и meta-теги со сравнительно небольших главных страниц — даёт меньше объёма извлечения на маленьких страницах, поэтому накладные расходы BeautifulSoup на сам парсинг выглядят тяжелее. Если ограничиться реальным диапазоном, получается так: selectolax в целом примерно в 10–15 раз быстрее BeautifulSoup на обычной задаче «распарсить и вытащить данные», а на крошечных страницах и при лёгкой экстракции отрыв ещё больше.
Если ваш текущий узкий участок — это код на BeautifulSoup, который переваривает страницы одну за другой, переход на selectolax действительно окупается. С этим спорить сложно. А вот следующий случай уже не такой очевидный.
Против lxml: ничья — и lxml выигрывает ту часть, которую обычно забывают выделять отдельно
Посмотрите на строки для 100 КБ и 1 МБ. Lexbor и lxml идут почти вровень — разница около 5%, интервалы по отдельным прогонам перекрываются, а по моей методике это значит ничья: без победителя и без утверждения «быстрее». Единственное место, где selectolax действительно уходит вперёд, — это страница 10 МБ (159.9 мс против 172.9 мс, то есть преимущество 8.1% без перекрытия интервалов). То есть на всей задаче selectolax сопоставим с lxml и обгоняет его только на самых больших документах.
Затем я отделил построение дерева от CSS-запросов — и картина перевернулась так, как это часто упускают в обзорах. Для чистого парсинга, без какого-либо запроса, lxml стабильно был примерно на 33–34% быстрее selectolax-Lexbor на этой машине — 77.9 мс против 116.6 мс на странице 10 МБ. На полной задаче эти различия всё равно сходятся, и моя рабочая гипотеза (подчеркну: не доказанная отдельным экспериментом на причинность) состоит в том, что на таких страницах CSS-запрос занимает лишь небольшую долю общего времени, поэтому преимущество lxml на этапе парсинга «размывается», пока итоги не сравняются.
Это, пожалуй, самая уязвимая часть всего обзора, и я хочу объяснить почему заранее. Результат идёт против общепринятого мнения, а единственный опубликованный benchmark, который я нашёл и который отдельно меряет только парсинг, — aows.jpt.sh — показывает обратное, то есть selectolax примерно в 4 раза быстрее. Поэтому я максимально ограничил выводы: это один набор условий (macOS arm64, Python 3.14, готовые cp314 wheels; Linux x86_64 и сборка из исходников не проверялись), результат подтверждён на четырёх размерах страниц и совпал на каждом из них, а также был перепроверен на двух разных API lxml, чтобы исключить артефакт конкретного вызова. Оба API lxml обошли selectolax-Lexbor на каждом размере. Я не утверждаю, что «lxml парсит быстрее» как окончательный и универсальный факт — я показываю, что именно выдал мой тест, со скриптом в приложении, в противовес большинству опубликованных цифр. Проверяйте на своём железе.
Ещё один срез: при выборке 100 000 <a> на плоской странице lxml и selectolax-Modest идут вничью (33.30 мс против 34.19 мс, интервалы перекрываются), тогда как selectolax-Lexbor отстаёт от обоих примерно на 15%. Общее у всех трёх C-движков — они в 5–7 раз быстрее, чем parsel или BeautifulSoup при массовом выборе, потому что модель «по Python-объекту на каждый узел» у последних и есть главный тормоз. Поэтому и утверждение «selectolax — самый быстрый для массового CSS-выбора» тоже не выдерживает проверки: Modest лишь сравнивается с lxml, а Lexbor ему уступает.
Практический вывод, который я готов отстаивать: преимущество selectolax над lxml — не в общей скорости на всей задаче. Он выигрывает только на самых больших страницах. Его сильные стороны — в другом: удобство API, поведение на мусорном HTML и современная поддержка CSS. Именно там и находится остальная часть обзора.
Память и холодный старт: смотрите на RSS, а не на вывод профайлера
С памятью я вынужден поправить собственные ранние цифры, и именно в этом суть. Если мерить по RSS-delta на странице 10 МБ при выключенном tracemalloc, BeautifulSoup потребляет примерно в 1.5–1.8 раза больше памяти, чем selectolax или lxml — диапазон от 1.51x (BS-lxml: 218.4 МБ против Lexbor: 144.6 МБ) до 1.75x на верхней границе. selectolax и lxml находятся в одном «лёгком» классе; по RSS самым экономным оказывается lxml.
В предыдущей версии я писал про «примерно 3x», и это было неверно по показательной причине: измерение шло с включённым tracemalloc, а его учёт каждой аллокации примерно удваивает видимый RSS у парсера, который делает больше всего выделений. Поэтому совет всем, кто бенчмаркит память парсеров: сравнивайте RSS при выключенном профайлере. Если ориентироваться на tracemalloc peak, C-бэкенды легко перепутать местами — у меня так selectolax-Lexbor выглядел тяжелее Modest, хотя по реальному RSS они близки. BeautifulSoup здесь действительно самый прожорливый, но не в 3 раза, как показал испорченный инструмент.
Холодный старт не критичен, но заметен: selectolax импортируется примерно за 14 мс — почти на уровне lxml и примерно в 2.3 раза быстрее, чем bs4 или parsel. Если вы выпускаете CLI-утилиту или serverless-функцию, где время импорта считается в каждом вызове, это уже имеет значение.
Покрытие CSS-селекторов: сильное, но с несколькими реальными пробелами
Покрытие CSS я проверял на матрице из 41 случая: каждый селектор сверялся с fixture, для которого заранее известно правильное множество результатов, плюс был отдельный стресс-тест, специально собранный, чтобы сломать движок Lexbor. Каждый случай запускался в отдельном subprocess’е — и это оказалось необходимо, потому что один из тестов валит весь интерпретатор. Результаты такие:
| Движок | 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 уже не абсолютный лидер — им становится soupsieve с чистым результатом 41/41 против 39/41 у Lexbor. Два промаха Lexbor — это :lang(en) и :dir(rtl), которые он отвергает как ошибку разбора. Во всём остальном он идеален, включая :has(), :is(), :where() и нечувствительные к регистру атрибуты.
Где Lexbor действительно хорош — так это в сравнении со стеком cssselect. Фирменный селектор из README — div > :nth-child(2n+1):not(:has(a)) — даёт правильный результат и в обоих selectolax-движках, и в soupsieve, но неправильный результат в lxml и parsel, причём без каких-либо ошибок. Если scraper просто перенесёт этот селектор в Scrapy или parsel, он получит тихо неверные данные. Чтобы точно сформулировать: cssselect умеет парсить :has() начиная с версии 1.2.0 (2022), а я тестировал 1.4.0, так что это не «не поддерживается», а «поддерживается, но неправильно вычисляется в сочетании с другими частями селектора». Поведение «молча возвращает неверный набор» для этого конкретного выражения не описано в трекере cssselect, где ограничения :has() отражены как явные ошибки. Lexbor также умеет работать с флагом нечувствительности к регистру у атрибутов [data-role="LEAD" i], который cssselect вообще отвергает.
Но есть и два пробела, которые могут решить вопрос миграции. selectolax вообще не поддерживает XPath — ни один backend не даёт метода xpath() — и не поддерживает псевдоэлементы ::text / ::attr(), потому что это расширение parsel/Scrapy, а не настоящий CSS. Если ваши текущие scraper’ы завязаны на XPath, это будет самая большая стена, в которую вы упрётесь: вам придётся переписывать селекторы, а не просто менять библиотеку. С другой стороны, в Lexbor есть псевдокласс :lexbor-contains("text" i) для поиска текста без учёта регистра — чего нет ни в lxml, ни в parsel, ни в стандартном CSS — и он работает ровно так, как обещано.
Устойчивость на кривом HTML — именно здесь selectolax зарабатывает очки
Настоящий web scraping — это когда вы кормите парсер мусором и надеетесь, что он не развалится. Я прогнал 18 вредоносных входов, и именно в этой категории у selectolax самый сильный аргумент против lxml.
Если передать lxml.html.fromstring пустую строку или одни пробелы, он выбросит ParserError("Document is empty"). Оба backend’а selectolax в такой ситуации возвращают валидное, но пустое дерево. Для scraper’а, который проходит по списку URL и иногда получает пустой ответ, это означает на один try/except меньше. Кроме того, selectolax спокойно переварил 100 000 элементов без переполнения стека.
Самое заметное расхождение проявилось в глубокой вложенности. На уровнях в 1 000 и 5 000 вложенных <div> lxml молча отбрасывает самый глубокий контент, а selectolax его сохраняет. libxml2 ограничивает глубину разбора примерно 256 уровнями и просто обрезает дерево без ошибки, поэтому самый глубокий текст становится недостижимым. Оба backend’а selectolax возвращают полное дерево. Это зеркальное отражение ловушки с <template>, к которой я вернусь ниже: там Lexbor отбрасывает то, что сохраняют другие; здесь lxml отбрасывает то, что сохраняет selectolax.
Не всё оказалось удачным. Backend Modest завершает весь Python-интерпретатор через SIGABRT, когда встречает :dir() — не выбрасывает исключение, которое можно поймать, а просто убивает процесс. Это реальное предупреждение по надёжности для тех, кто ещё сидит на старом backend’е, и как раз тот тип проблемы, который не видно, пока он не уронит production-задачу в три часа ночи.
Две ловушки тихой потери данных, о которых нужно знать до продакшена
Ни одна из них не является открытием — обе проблемы уже описаны upstream — но обе могут тихо стоить вам реальных данных, и в README это не подано как серьёзный риск.
Lexbor не видит <a> внутри <template>
На живой странице MDN, которую я тестировал, selectolax-Lexbor нашёл 497 ссылок, тогда как lxml, оба backend’а BeautifulSoup и даже собственный backend Modest нашли 508. Недостающие 11 ссылок — это переключатель языка и ссылка на обсуждения, которые находились внутри элементов <template> (на странице используются web components Lit).
Причина вполне корректная: по спецификации HTML5 содержимое <template> парсится в отдельный инертный фрагмент, а не в обычный DOM, и Lexbor следует этому буквально — tree.css("a") не проваливается внутрь template-контента. lxml, оба backend’а BeautifulSoup и Modest просто «расплющивают» template-контент в основное дерево, поэтому и находят эти ссылки. Это задокументированная открытая проблема (selectolax#146, с корневой причиной в lexbor#170), и оба подхода можно защитить: Lexbor, пожалуй, ближе к спецификации. Но разработчик, выбравший рекомендуемый backend, тихо теряет данные без какой-либо ошибки. Важно и обратное: остальные парсеры показывают инертный template-контент, который браузер никогда не рендерит, так что они могут вернуть вам «фантомные» данные, которых пользователь не видит. Надёжный обходной путь для такого случая — backend Modest или другой парсер.
Байты не в UTF-8 тихо портят .text()
Если передать selectolax байты, невалидные для UTF-8, парсинг пройдёт успешно — а искажение всплывёт позже, и это хуже, чем честный крах. На "<p>café éè</p>".encode("latin-1") .text() у Lexbor возвращает символы-заполнители, .text() у Modest молча отбрасывает проблемные байты, а оба движка выбросят UnicodeDecodeError только тогда, когда вы обратитесь к .html. Обвязка декодирует данные в строгом UTF-8 уже на чтении обратно, а не на этапе парсинга. Это связано с известной проблемой selectolax о strictness при encode/decode.
Исправление занимает одну строку и должно стать привычкой: сначала декодируйте bytes сами — LexborHTMLParser(resp.content.decode("latin-1")) — и тогда оба движка корректно вернут 'café éè'. На практике всегда передавайте selectolax str, а не сырые non-UTF-8 bytes. В README это не прописано явно.
Производственные аспекты (одна выборка, так что воспринимайте как направление)
Следующие результаты я измерял один раз, а не через три прогона, поэтому это скорее сигналы, чем окончательные цифры.
Самое интересное — масштабирование по потокам. Если парсить страницу 1 МБ 48 раз в четырёх потоках, selectolax показал ускорение примерно в 3.5–3.9 раза по wall-clock — характерный признак того, что библиотека освобождает GIL во время C-парсинга, — тогда как BeautifulSoup(lxml) в потоках стал заметно медленнее, что типично для сериализации работы через GIL. lxml оказался между ними, и вывод там неочевиден. Для эпохи free-threading, в которую движется Python, selectolax, который реально распараллеливается по потокам там, где BeautifulSoup этого не делает, — это настоящее, пусть и предварительное, преимущество. Но это один размер, один тест, и механизм здесь — гипотеза, а не результат инструментации C-кода.
По утечкам памяти: за 2 000 циклов parse-extract-drop на 1 МБ ни у одного из трёх парсеров не было линейного роста RSS, похожего на leak — каждый стабилизировался в ограниченном диапазоне рабочего набора. Я доверяю этому выводу ещё и потому, что прогнал через тот же инструмент заведомо «текущий» объект, и он вырос до +198 МБ именно так, как и должен был, то есть измеритель мог увидеть утечку, но не нашёл её у парсеров. А сохранённый живым node handle после выхода дерева из области видимости продолжал работать без segfault. Но повторю: всё это одна выборка, а не многочасовой soak-тест.
Где место selectolax — и где нужно передавать эстафету дальше
Всё выше — об одной задаче: быстро превратить уже имеющийся HTML в структурированные данные. В этом selectolax очень хорош. Чего он сознательно не делает — так это не загружает страницу, не рендерит JavaScript, не вращает прокси, не решает CAPTCHA и не угадывает, какие именно элементы вам нужны. Всё это по-прежнему ваша логика. selectolax — это только слой парсинга, и он не притворяется чем-то большим.
Именно здесь на сцену выходит управляемый сервис извлечения данных: он стоит над парсером, а не заменяет его. Если вам не хочется самим строить и поддерживать весь стек fetch-render-anti-bot-extract, Thunderbit предлагает это через API, MCP server и CLI — POST /distill превращает страницу в чистый Markdown, а POST /extract возвращает структурированный JSON, соответствующий схеме, при этом JS-рендеринг и антибот-защита уже встроены. Это другой уровень решения: selectolax вы берёте, когда HTML уже у вас на руках и вам нужна чистая скорость парсинга под полным контролем; Thunderbit’s API, MCP server или CLI — когда вы хотите, чтобы загрузка и извлечение были уже решены за вас, а на выходе нужны только структурированные данные. Это не замена — это другая высота в том же стеке.
Попробовать Thunderbit для извлечения веб-данных
Плюсы, минусы и кому вообще стоит его использовать
Где selectolax выигрывает:
- Примерно в 12–17 раз быстрее BeautifulSoup на реалистичной задаче «распарсить и извлечь данные», и это стабильно на трёх порядках размера страницы.
- Экономное потребление памяти (уровень lxml, примерно в 1.5–1.8 раза легче BeautifulSoup) и импорт около 14 мс.
- Корректное поведение на входах, которые ломают lxml: пустой HTML, пробелы и патологически глубокая вложенность.
- Современный CSS, включая
:has(),:is(),:where(), нечувствительные к регистру атрибуты и только у Lexbor —:lexbor-contains(). - DOM с безопасными значениями
None: отсутствующие элементы возвращаютNoneили[]вместо ошибки, и дерево можно реально изменять и сериализовать обратно. - Активное сопровождение (v0.4.10, середина 2026 года) и очень простая установка.
Где он не выигрывает:
- Не быстрее lxml в общем случае — на полной задаче ничья, а на чистом парсинге в моём тесте lxml даже оказался быстрее.
- Нет XPath и нет
::text/::attr()— это жёсткий барьер для XPath-ориентированных scraper’ов. - Две тихие ловушки потери данных: контент
<template>в Lexbor и не-UTF-8 байты через.text(). - Backend Modest устаревший и может завершить процесс через SIGABRT на
:dir(). - Все цифры здесь получены на одной платформе (macOS arm64, Python 3.14) и пока предварительные.
Стоит ли использовать selectolax? Да — если вам нужна скорость парсинга уровня lxml, более дружелюбный API без падений на None и заметно лучшее поведение на пустом и повреждённом HTML, и при этом вы готовы жить в мире только CSS-селекторов. Если ваша кодовая база построена на XPath, стоимость переписывания реальна, и это нужно учитывать честно. А если вы гонитесь именно за «единственным самым быстрым парсером», корректный ответ по этому тесту такой: selectolax и lxml достаточно близки, чтобы решающим фактором стали удобство и надёжность, а не голая скорость. И, честно говоря, это уже очень хороший критерий выбора инструмента.
Попробовать Thunderbit для извлечения веб-данных Get Started Free
FAQ
Быстрее ли selectolax, чем BeautifulSoup?
Да, однозначно — примерно в 12–17 раз быстрее BeautifulSoup(html.parser) и в 10–14 раз быстрее BeautifulSoup(lxml) на реалистичной задаче парсинга и извлечения данных, причём результат держится от страниц 1 КБ до 10 МБ (macOS arm64, Python 3.14). Часто цитируемое «4–5 раз» заметно занижает разницу по сравнению с html.parser.
Быстрее ли selectolax, чем lxml? Не в широком смысле. На полной задаче «распарсить и извлечь» они сравнялись на 100 КБ и 1 МБ, а selectolax выиграл только на странице 10 МБ. На чистом парсинге без запросов lxml у меня оказался примерно на 33–34% быстрее — это результат, противоречащий распространённому мнению, и я специально пометил его как полученный в одном окружении, так что лучше проверьте на своём железе.
Что выбрать — backend Lexbor или Modest?
Почти всегда Lexbor — это поддерживаемый, более полный движок, который рекомендует README, и у него лучшее покрытие CSS. Исключение — страницы, где контент спрятан внутри <template>: там Lexbor ведёт себя по спецификации и этот контент не видит, а Modest его, наоборот, сохраняет. Но у Modest есть и острые края, включая жёсткое падение интерпретатора на :dir().
Поддерживает ли selectolax XPath?
Нет. Ни один backend не предоставляет xpath() — selectolax работает только с CSS. Если ваши scraper’ы завязаны на XPath, миграция потребует переписывания селекторов, и это самый большой единичный расход при переходе с lxml- или parsel-стека.
Почему вывод selectolax искажён или почему пропадают элементы?
Обычно виноваты две вещи. Если в тексте появляются символы замены или пропадают акценты, скорее всего, вы передали сырые байты не в UTF-8 — сначала декодируйте их в str (resp.content.decode("latin-1")), а уже потом парсите. Если на современном сайте не хватает ссылок или элементов, они могут находиться внутри тегов <template>, куда backend Lexbor не заглядывает; для такой страницы переключитесь на Modest или другой парсер.
