Hvert indlæg om den "hurtigste Python HTML-parser" ender før eller siden med at nævne selectolax, og næsten alle stopper historien ved "meget hurtigere end BeautifulSoup." Det er sandt. Det, ingen plejer at gøre færdigt, er at se på, hvad der sker, når man sætter selectolax op mod lxml i stedet — for dér får ordet "hurtigst" pludselig en lille fodnote.
Så jeg benchmarkede det ordentligt: selectolax (begge backends) mod lxml, BeautifulSoup med både html.parser og lxml, samt parsel, på fem sidestørrelser fra 1 KB til 10 MB. Hver måling er medianen af tre separate proceskørsler. selectolax slog BeautifulSoup klart og matchede rå lxml — og tabte derefter den rene parse-del til lxml. Alle tal herunder er foreløbige og taget på én maskine (macOS arm64, Python 3.14.2); scripts er committet, så test selv på din egen opsætning, før du citerer mig.
Hvad selectolax faktisk er — og ikke er
selectolax er en Python-binding til to C-motorer — Modest og Lexbor — som parser HTML5 og kan forespørge den med CSS-selectorer. Det er ikke en crawler, ikke en browser og ikke en "scraper" i klik-på-knap-forstand. Det er værktøjet, du giver en HTML-klump til, efter du allerede har hentet den. Vedligeholderens egen one-liner er "A fast HTML5 parser with CSS selectors, written in Cython, using Modest and Lexbor engines."
Der er to backends, og forskellen betyder mere, end dokumentationen umiddelbart får frem:
LexborHTMLParser(Lexbor-motoren) — den som README anbefaler at bruge fra 2024.HTMLParser(Modest-motoren) — den oprindelige, hvor den bagvedliggende C-bibliotek ifølge samme README "ikke længere vedligeholdes".
Et par ting er værd at vide, før vi taler fart. Ifølge repo-snapshotten taget 2026-07-10 ligger selectolax på 1.653 stjerner, og seneste release er v0.4.10 (maj 2026). PyPI angiver understøttelse for Python >=3.9,<3.15. Installationen er det mindst dramatiske ved hele testen: pip install selectolax hentede en 2,3 MB forudbygget cp314-wheel og virkede med det samme på Python 3.14 — ingen browser-download, intet doctor-trin, ingen compilation. Det er den stille fordel ved en ren parser frem for et browserbaseret værktøj. Den importerer bare og kører.
Der er også en licensdetalje, man bør nævne med det samme: Python-bindingen er MIT, men wheel'en pakker motorerne med, og de har deres egne licenser — Modest er LGPL-2.1, Lexbor er Apache-2.0. Så "selectolax er MIT" er sandt for Python-koden, men ufuldstændigt for den binære pakke, du faktisk sender ud. Hvis jura-afdelingen går op i redistribuerede komponenter, er det den forskel, man skal notere.
Hastighedsspørgsmålet, besvaret med rigtige tal
Her er opgaven, jeg målte: parse HTML-strengen, træk al tekst fra <h3 class="title">, og hent alle <a>-hrefs. Median-latens i millisekunder, målt som medianen på tværs af tre separate proceskørsler; spredningen mellem kørslerne holdt sig under ca. 5% for de C-baserede parsere i de fleste størrelser. Før nogen celle blev timet, blev hvert parsers output reduceret til en content hash, så en parser, der stille gjorde mindre arbejde, ville blive opdaget og sorteret fra — på disse sider matchede alle seks ved alle størrelser, så det her er en reel æble-til-æble-sammenligning. De fulde data ligger i den committede bench_parse.json.
| Side | 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 |
Mod BeautifulSoup: omkring 12-17x, og myten undervurderer forskellen
Omsat til forhold kommer selectolax-Lexbor ud som ca. 12x hurtigere end BeautifulSoup(html.parser) på en 1 KB-side, stigende til ca. 17x på 10 MB, og ca. 10-14x hurtigere end BeautifulSoup(lxml) på samme spænd. Det tal, man ofte ser online — "selectolax er cirka 4-5x hurtigere end BeautifulSoup" — er for lavt i forhold til html.parser og nogenlunde rigtigt kun i forhold til lxml-baseret BeautifulSoup. Den reelle faktor afhænger af, hvilken BeautifulSoup du mener, og hvor meget du ekstraherer pr. side.
Det stemmer også med README’s egen benchmark, som antyder en fordel på 25,5x over BeautifulSoup(html.parser). Ingen af tallene er forkerte. README’s opgave (titler, links, scripts og meta fra små hjemmesider) laver mindre udtræk på små sider, hvilket vægter BeautifulSoups overhead pr. parse tungere. I praksis lander det her som: selectolax er cirka 10-15x hurtigere end BeautifulSoup på realistisk parse-og-udtræk-arbejde, og endnu mere på små sider og let udtræk.
Hvis dit nuværende flaskehalsproblem er en bunke BeautifulSoup-kode, der tygger sig gennem sider, er det her en migration, der betaler sig selv hjem. Det er ikke kontroversielt. Det næste er.
Mod lxml: uafgjort — og lxml vinder den del, alle glemmer at isolere
Kig tilbage på 100 KB- og 1 MB-rækkerne. Lexbor og lxml ligger inden for ca. 5% af hinanden, deres intervaller overlapper, og efter min metode er det uafgjort — ingen vinder, ingen "hurtigere". Det eneste sted, selectolax reelt trækker fra, er 10 MB-siden (159,9 ms mod 172,9 ms, en forskel på 8,1% med ikke-overlappende intervaller). På den samlede opgave matcher selectolax altså lxml og slår det kun på de allerstørste dokumenter.
Derefter isolerede jeg træbygning fra CSS-forespørgsler, og resultatet vender på en måde, som de fleste gennemgange overser. For ren parsing uden nogen forespørgsel var lxml konsekvent ca. 33-34% hurtigere end selectolax-Lexbor på min maskine — 77,9 ms mod 116,6 ms på 10 MB-siden. På den samlede opgave konvergerer de to alligevel, og min arbejdshypotese (ikke noget, jeg beviste med et særskilt attributionseksperiment) er, at CSS-forespørgslen på disse sider kun fylder en lille del af den samlede tid, så lxml’s fordel i parse-trinnet bliver udvandet, indtil totalerne mødes.
Det er den mest angrebsflade-venlige påstand i hele testen, og jeg vil være helt åben om hvorfor. Den vender den gængse visdom på hovedet, og den ene publicerede benchmark, jeg fandt, som isolerer ren parsing — aows.jpt.sh — rapporterer det modsatte, med selectolax cirka 4x hurtigere. Derfor afgrænsede jeg den: resultatet er enkelt-platform (macOS arm64, Python 3.14, forudbyggede cp314-wheels — Linux x86_64 eller source build er ikke testet), det er krydstjekket på tværs af fire sidestørrelser og holdt hele vejen, og det er efterprøvet med to forskellige lxml-API’er for at udelukke et API-artefakt. Begge lxml-API’er slog selectolax-Lexbor ved alle størrelser. Jeg præsenterer ikke "lxml parser hurtigere" som en endelig sandhed — jeg præsenterer det som det, min benchmark gav, med scriptet vedlagt, imod det meste af det publicerede materiale. Kør det på din egen maskine.
Et ekstra snit: ved forespørgsel på 100.000 <a>-elementer på en flad side er lxml og selectolax-Modest uafgjort (33,30 ms mod 34,19 ms, intervallerne overlapper), mens selectolax-Lexbor ligger ca. 15% efter begge. Det, alle tre C-motorer har til fælles, er at være 5-7x hurtigere end parsel eller BeautifulSoup ved masseudvælgelse, hvor modellen med et Python-objekt pr. node er den egentlige bremseklods. Så påstanden om, at "selectolax er den hurtigste til bulk CSS selection", holder heller ikke — Modest matcher blot lxml, og Lexbor taber til det.
Det takeaway, jeg faktisk vil stå inde for, er: selectolax’ fordel over lxml er ikke bred, samlet hastighed. Den vinder kun på den største side. Dens styrke ligger i andre ting — API-venlighed, adfærd på dårligt input og moderne CSS — og det er dér resten af testen hører hjemme.
Hukommelse og cold start: rangér efter RSS, ikke efter din profiler
Hukommelse er dér, hvor jeg må rette mine egne tidligere tal, og rettelsen er pointen. Målt som RSS-ændring på 10 MB-siden med tracemalloc slået fra bruger BeautifulSoup omkring 1,5-1,8x mere hukommelse end selectolax eller lxml — spændet går fra 1,51x (BS-lxml ved 218,4 MB mod Lexbor ved 144,6 MB) til 1,75x i den øverste ende. selectolax og lxml ligger i samme lette kategori; lxml er den letteste målt på RSS.
En tidligere version af mine tal sagde "ca. 3x", og det var forkert af en lærerig grund: den blev målt med tracemalloc kørende, og tracemallocs bogføring pr. allokering fordobler omtrent den synlige RSS for den parser, der allokerer mest. Så en klar advarsel til alle, der benchmarker parser-hukommelse: rangér efter RSS med din profiler slået fra. At rangere parsere efter tracemalloc-peak skubber især C-baserede parsere forkert — det fik selectolax-Lexbor til at se tungere ud end Modest, selv om de i reel RSS ligger tæt. BeautifulSoup er oprigtigt den tungeste her; den er bare ikke tung med den 3x-margin, et forurenet måleværktøj viste.
Cold start er en lille, men reel ting: selectolax importerer på omkring 14 ms, cirka på niveau med lxml og ca. 2,3x hurtigere end bs4 eller parsel. Hvis du sender et CLI-værktøj eller en serverless funktion, hvor importtid er en del af hver eneste kørsel, er den forskel værd at notere.
CSS-selector-dækning: stærk, med et par reelle huller
CSS-dækningen fik en matrix med 41 cases, hvor hver selector blev testet mod et fixture med en kendt korrekt svarmængde, plus en målrettet fejlfindingsrunde designet til at knække Lexbor-motoren. Hver case kørte i sin egen subprocess, hvilket viste sig nødvendigt — én af dem får hele interpreter’en til at crashe. Resultaterne:
| Motor | PASS | FORKERT | IKKE UNDERSTØTTET | 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 |
Når de fjendtlige selectors først kommer i spil, er Lexbor ikke den klare vinder — soupsieve er, med 41/41 mod Lexbors 39/41. Lexbors to miss er :lang(en) og :dir(rtl), som den afviser med parse-fejl. Den er perfekt på alt andet, inklusive :has(), :is(), :where() og case-insensitive attributter.
Hvor Lexbor virkelig skinner, er mod cssselect-stakken. README’s flagskib-selector — div > :nth-child(2n+1):not(:has(a)) — returnerer den korrekte mængde på begge selectolax-motorer og på soupsieve, men den forkerte mængde på lxml og parsel, uden at der kastes en fejl. En scraper, der kopierer den selector ind i Scrapy eller parsel, får stille og roligt forkerte resultater. For at være helt præcis: cssselect har understøttet :has() siden version 1.2.0 (2022), og jeg testede 1.4.0, så det her er "understøttet men beregner den sammensatte selector forkert" — ikke "ikke understøttet". Den stille-forkerte adfærd på netop denne kombination står ikke i cssselect-issue-tracker, som ellers beskriver :has()-begrænsninger som fejl, der bliver kastet. Lexbor håndterer også det case-insensitive attributflag [data-role="LEAD" i], som cssselect afviser direkte.
Der er dog to huller, der kan afgøre migrationer. selectolax understøtter slet ikke XPath — ingen af backends eksponerer xpath() — og heller ingen ::text / ::attr() pseudo-elementer, fordi det er en parsel/Scrapy-udvidelse og ikke rigtig CSS. Hvis dine eksisterende scrapers bygger på XPath, er det den største mur, du støder på; du skal omskrive selectors, ikke bare skifte bibliotek. Omvendt leverer Lexbor en :lexbor-contains("text" i) pseudo-klasse til case-insensitive tekstmatch, som hverken lxml, parsel eller standard CSS tilbyder, og den virker som dokumenteret.
Robusthed på grim HTML, hvor selectolax virkelig tjener sit keep
Ægte scraping betyder at fodre en parser med skrald og håbe, at den ikke vælter. Jeg kørte 18 fjendtlige input, og det er den kategori, hvor selectolax’ sag mod lxml er stærkest.
Giver du lxml.html.fromstring en tom streng eller whitespace, kaster den ParserError("Document is empty"). Begge selectolax-motorer returnerer derimod et gyldigt, tomt træ. For en scraper, der loop’er over en liste URLs, hvor nogle svar kommer tilbage blanke, er det én try/except mindre, du skal vikle hele koden ind i. selectolax klarede også 100.000 elementer uden stack overflow.
Dybt nestede tags gav den skarpeste forskel. Ved 1.000 og 5.000 niveauer af nestede <div>-elementer smider lxml stille det dybeste indhold væk, mens selectolax bevarer det. libxml2 cap’er parse-dybden omkring 256 niveauer og trunkerer træet uden fejl, så den dybeste tekst bliver simpelthen utilgængelig. Begge selectolax-motorer returnerer hele træet. Det er spejlbilledet af <template>-fælden, jeg kommer til om lidt: dér mister Lexbor indhold, de andre bevarer; her mister lxml indhold, selectolax bevarer.
Ikke alle celler var en sejr. Modest-backenden aborts hele Python-interpreteren med SIGABRT, når den rammer :dir() — ikke en fangbar exception, men et hårdt process-kill. Det er en reel robusthedsadvarsel for alle, der stadig bruger den gamle backend, og præcis den slags ting, der bliver usynlig, indtil den vælter et produktionsjob klokken 3 om natten.
To fælder med stille datatab, du skal kende før release
Ingen af dem er en ny opdagelse — begge er dokumenteret upstream — men begge koster rigtig data, helt stille, og ingen af dem larmer i README’en.
Lexbor dropper <a> inde i <template>
På den live MDN-side, jeg testede, fandt selectolax-Lexbor 497 links, mens lxml, begge BeautifulSoup-backends og endda selectolax’ egen Modest-backend fandt 508. De manglende elleve var en sprogomskifter og et discussions-link inde i <template>-elementer (siden bruger Lit web components).
Årsagen er legitim: ifølge HTML5-specifikationen parses <template>-indhold ind i et separat, inert fragment og ikke i den normale DOM, og Lexbor følger det strengt — tree.css("a") går ikke ned i template-indhold. lxml, begge BeautifulSoup-backends og Modest flader template-indhold ud i hovedtræet, så de finder linksene. Det er et dokumenteret åbent issue (selectolax#146, med motorårsagen i lexbor#170), og begge fortolkninger kan forsvares — Lexbor er faktisk den mest specifikationstro. Men en udvikler på den anbefalede backend mister bare de data uden fejl. Det modsatte er også værd at sige højt: de andre parsere viser inert template-indhold, som en browser aldrig renderer, så de kan give dig fantomdata, som en bruger ikke kan se. Den pålidelige udvej for netop den side er Modest-backenden eller et andet bibliotek.
Ikke-UTF-8 bytes korrumperer .text() uden advarsel
Hvis du giver selectolax bytes, der ikke er gyldig UTF-8, lykkes parsing fint — korruptionen viser sig først senere, og det er værre end et rent crash. På "<p>café éè</p>".encode("latin-1") returnerer Lexbors .text() erstatningstegn, Modests .text() dropper de problematiske bytes stille og roligt, og begge motorer kaster først UnicodeDecodeError, når du rører .html. Bindingen dekoder som strict UTF-8 ved læsning tilbage, ikke ved parsing. Det hænger sammen med et kendt selectolax-issue om strenghed i encode/decode.
Løsningen er én linje og bør sidde på rygraden: dekod selv bytes først — LexborHTMLParser(resp.content.decode("latin-1")) — så returnerer begge motorer 'café éè' korrekt. I praksis: giv altid selectolax en str, aldrig rå ikke-UTF-8 bytes. README’en siger det ikke direkte.
Produktionsdimensioner (enkelt-observation, så tag dem som signaler)
De næste resultater målte jeg én gang, ikke over tre kørsler, så jeg markerer dem som signaler snarere end endelige tal.
Trådskalering er den interessante. Ved at parse en 1 MB-side 48 gange fordelt over fire tråde viste selectolax en ca. 3,5-3,9x forbedring i wall-clock-tid — det empiriske tegn på et bibliotek, der frigiver GIL under C-parsing — mens BeautifulSoup(lxml) blev flere gange langsommere i tråde, hvilket tyder på arbejde, der serialiseres på GIL’en. lxml landede midt imellem, men resultatet var ikke entydigt. For den free-threading-æra, Python bevæger sig ind i, er selectolax’ paralleliserende parsing på tværs af tråde, hvor BeautifulSoup ikke kan følge med, en reel, om end foreløbig, fordel. Det er én trådtælling på én sidestørrelse, og mekanismen er en hypotese, ikke noget, jeg bekræftede ved at instrumentere C-koden.
Om leaks: over 2.000 parse-extract-drop-iterationer på 1 MB viste ingen af de tre parsere den lineære RSS-stigning, man forbinder med et memory leak — hver af dem stabiliserede sig i et begrænset arbejdsområde. Jeg stoler især på den konklusion, fordi jeg kørte et kendt leak-calibration-subject gennem samme instrument, og det steg til +198 MB som forventet, hvilket beviser, at instrumentet kunne se et leak og bare ikke fandt et i parserne. Og et node-handle, der blev holdt i live efter at dets ejende træ var gået out of scope, forblev brugbart uden segfault. Alt er enkelt-observationer, intet er en flere timers soak-test.
Hvor selectolax passer ind — og hvor den giver stafetten videre
Alt ovenstående handler om én opgave: at gøre HTML, du allerede har, til strukturerede data hurtigt. selectolax er rigtig god til netop det. Det, den bevidst ikke gør, er at hente siden, rendere JavaScript, rotere proxies, løse CAPTCHAs eller finde ud af hvilke elementer du vil have. Det er stadig din kode. selectolax er parse-laget og foregiver ikke at være mere end det.
Det er dér, hvor en managed extraction service ligger oven på en parser i stedet for at erstatte den. Hvis du helst vil undgå selv at bygge og vedligeholde hele fetch-render-anti-bot-extract-stakken, tilbyder Thunderbit det som API, MCP-server og CLI — POST /distill omdanner en side til ren Markdown, og POST /extract returnerer skemamatchende struktureret JSON, mens JS-rendering og anti-bot håndteres for dig. Det er et andet lag i problemet: du vælger selectolax, når du allerede har HTML’en og vil have rå parse-hastighed under egen kontrol, og noget i stil med Thunderbit’s API, MCP-server eller CLI, når du vil have hentning og udtræk håndteret og bare have strukturerede data tilbage. Ikke et skift — bare en anden højde i samme stack.
Prøv Thunderbit til webdataudtræk
Fordele, ulemper og hvem der faktisk bør bruge det
Hvor selectolax vinder:
- Ca. 12-17x hurtigere end BeautifulSoup på realistisk parse-og-udtræk-arbejde, stabilt over tre størrelsesordener af sidestørrelse.
- Let hukommelsesforbrug (lxml-niveau, ca. 1,5-1,8x mindre end BeautifulSoup) og omkring 14 ms import.
- Robust på input, der får lxml til at fejle — tomt, whitespace og ekstremt dyb nesting.
- Moderne CSS inklusive
:has(),:is(),:where(), case-insensitive attributter og den Lexbor-only:lexbor-contains(). - En None-sikker DOM til læsning og skrivning: manglende elementer returnerer
Noneeller[]i stedet for at kaste fejl, og du kan faktisk mutere og reserialisere træet. - Aktiv vedligeholdelse (v0.4.10, midt-2026) og en triviel installation.
Hvor den ikke gør:
- Ikke generelt hurtigere end lxml — uafgjort på den samlede opgave, og den taber den rene parse-del i min benchmark.
- Ingen XPath og ingen
::text/::attr()— en hård migrationsmur for XPath-baserede scrapers. - To fælder med stille datatab:
<template>-indhold i Lexbor og ikke-UTF-8 bytes via.text(). - Modest-backenden er legacy og giver SIGABRT på
:dir(). - Alle tal her er enkelt-platform (macOS arm64, Python 3.14) og foreløbige.
Skal du bruge selectolax? Ja, hvis du vil have lxml-klasse parsehastighed med en mere venlig, None-sikker API og markant bedre adfærd på tomt og fejlformet input — og du kan leve i CSS-only-land. Hvis din kodebase er bygget på XPath, er omskrivningen reel, og det bør du tage seriøst. Og hvis du jagter "den ene hurtigste parser", er det korrekte svar fra denne benchmark, at selectolax og lxml ligger så tæt, at tiebreakeren er ergonomi og robusthed, ikke rå speed. Det er faktisk en bedre grund til at vælge et værktøj.
Prøv Thunderbit til webdataudtræk Get Started Free
Ofte stillede spørgsmål
Er selectolax hurtigere end BeautifulSoup?
Ja, helt klart — omkring 12-17x hurtigere end BeautifulSoup(html.parser) og 10-14x hurtigere end BeautifulSoup(lxml) i en realistisk parse-og-udtræk-opgave, stabilt fra 1 KB til 10 MB sider (macOS arm64, Python 3.14). De ofte citerede "4-5x" undervurderer forskellen mod html.parser.
Er selectolax hurtigere end lxml? Ikke generelt. På den fulde parse-og-udtræk-opgave er de uafgjort ved 100 KB og 1 MB, og selectolax vinder kun på 10 MB-siden. Ved ren parsing uden forespørgsel var lxml faktisk ca. 33-34% hurtigere på min maskine — et resultat, der går imod den gængse opfattelse, og som derfor skal verificeres på din egen hardware.
Skal jeg bruge Lexbor- eller Modest-backenden?
Lexbor i næsten alle tilfælde — det er den vedligeholdte, funktionsrige motor, som README anbefaler, og den har bedre CSS-dækning. Den eneste undtagelse er en side, der gemmer indhold i <template>-elementer, hvor Lexbors spec-korrekte adfærd dropper indholdet, mens Modest tilfældigvis bevarer det. Modest har også skarpe kanter, herunder et hårdt interpreter-crash på :dir().
Understøtter selectolax XPath?
Nej. Ingen af backends eksponerer en xpath()-metode — selectolax er CSS-only. Hvis dine scrapers afhænger af XPath, betyder migrationen, at du skal omskrive selectors, og det er den største enkeltomkostning ved at flytte fra en lxml- eller parsel-baseret stack.
Hvorfor er mit selectolax-output forvrænget eller mangler elementer?
To sædvanlige syndere. Hvis teksten kommer tilbage med erstatningstegn eller manglende accenter, har du sandsynligvis givet rå ikke-UTF-8 bytes — dekod dem først til en str (resp.content.decode("latin-1")) før parsing. Hvis links eller elementer mangler på en moderne side, ligger de måske inde i <template>-tags, som Lexbor-backenden ikke går ned i; skift til Modest eller en anden parser for den side.
