Hver eneste artikkel om den «raskeste Python HTML-parseren» nevner til slutt selectolax, og de fleste stopper historien ved «mye raskere enn BeautifulSoup». Det stemmer. Det som sjelden blir fullført, er hva som skjer når du setter selectolax opp mot lxml i stedet — for der får «raskest» en liten stjerne.
Så jeg benchmarket det skikkelig: selectolax (begge backend-variantene) mot lxml, BeautifulSoup med html.parser og med lxml, samt parsel, på fem sidestørrelser fra 1 KB til 10 MB. Hver måling er medianen av tre separate prosesskjøringer. selectolax slo BeautifulSoup klart og endte på nivå med ren lxml — og tapte deretter ren parse-delen mot lxml. Tallene under er foreløpige og kommer fra én maskin (macOS arm64, Python 3.14.2); skriptene er sjekket inn, så kjør dem gjerne på din egen maskin før du siterer meg.
Hva selectolax egentlig er – og hva det ikke er
selectolax er en Python-binding til to C-motorer — Modest og Lexbor — som parser HTML5 og lar deg spørre med CSS-selektorer. Det er ikke en crawler, ikke en nettleser og ikke en «scraper» i knapp-trykk-forstand. Det er verktøyet du gir en HTML-klump etter at du allerede har hentet siden. Vedlikeholderens egen kortversjon er: «A fast HTML5 parser with CSS selectors, written in Cython, using Modest and Lexbor engines.»
Det finnes to backends, og forskjellen betyr mer enn dokumentasjonen gir inntrykk av:
LexborHTMLParser(Lexbor-motoren) — den README-en anbefaler å bruke per 2024.HTMLParser(Modest-motoren) — den opprinnelige, hvis underliggende C-bibliotek «is not maintained anymore», ifølge samme README.
Noen fakta det er nyttig å ha før vi snakker om hastighet. Per repo-snapshoten tatt 2026-07-10, har selectolax 1 653 stjerner, og siste versjon er v0.4.10 (mai 2026). PyPI oppgir støtte for Python >=3.9,<3.15. Installasjon er det minst dramatiske med hele denne testen: pip install selectolax hentet en ferdigbygd 2,3 MB cp314-wheel og fungerte umiddelbart på Python 3.14 — ingen nettleserdownload, ingen doctor-steg, ingen kompilering. Det er den stille fordelen med en ren parser sammenlignet med et nettleserbasert verktøy. Den bare importeres og kjører.
Én lisensdetalj er verdt å nevne med en gang, i stedet for å gjemme den bort: Python-bindingen er MIT-lisensiert, men wheel-en pakker også motorene som kompileres inn, og de har egne lisenser — Modest er LGPL-2.1, Lexbor er Apache-2.0. Så «selectolax er MIT» er riktig for Python-koden, men ufullstendig for binæren du faktisk distribuerer. Hvis juristene dine bryr seg om redistribuerte komponenter, er det denne forskjellen du bør flagge.
Hastighetsspørsmålet, besvart med faktiske tall
Dette var oppgaven jeg målte: parse HTML-strengen, hent ut all <h3 class="title">-tekst og hent alle <a>-lenker. Latensen er oppgitt i millisekunder, som median av tre separate prosesskjøringer; variasjonen mellom kjøringene holdt seg under ca. 5 % for C-baserte parsere ved de fleste størrelser. Før noen celle ble timet, ble outputen til hver parser redusert til en content hash, slik at en parser som i stillhet gjorde mindre arbeid ville bli fanget opp og ekskludert — på disse sidene matchet alle seks ved alle størrelser, så dette er en reell sammenligning med like vilkår. Hele datasettet ligger i den sjekkte 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 |
Mot BeautifulSoup: rundt 12–17x, og myten undervurderer forskjellen
Gjør vi dette om til forholdstall, kommer selectolax-Lexbor ut som omtrent 12x raskere enn BeautifulSoup(html.parser) på en 1 KB-side, og opp mot 17x raskere ved 10 MB, og omtrent 10–14x raskere enn BeautifulSoup(lxml) i samme område. Tallet som ofte sirkulerer på nettet — «selectolax er omtrent 4–5x raskere enn BeautifulSoup» — er for lavt mot html.parser og bare omtrent riktig mot BeautifulSoup som bruker lxml-backend. Den faktiske multiplikatoren avhenger av hvilken BeautifulSoup-variant du mener, og hvor mye du ekstraherer per side.
Dette stemmer også med README-ens egen benchmark, som antyder en 25,5x fordel over BeautifulSoup(html.parser). Ingen av tallene er feil. README-oppgaven (tittel, lenker, scripts og meta fra små hjemmesider) gjør mindre ekstraksjon på mindre sider, noe som gjør BeautifulSoups overhead per parse mer dominerende. Innenfor samme begrensede område blir konklusjonen: selectolax er grovt sett 10–15x raskere enn BeautifulSoup på realistisk parse-og-ekstraher-arbeid, høyere på små sider og ved lett ekstraksjon.
Hvis dagens flaskehals er en haug med BeautifulSoup-kode som tygger gjennom sider, er dette en migrering som betaler seg selv. Det er ikke kontroversielt. Det neste tilfellet er.
Mot lxml: uavgjort — og lxml vinner delen alle glemmer å isolere
Se tilbake på radene for 100 KB og 1 MB. Lexbor og lxml ligger innenfor omtrent 5 % av hverandre, og intervallene per kjøring overlapper. Med metodikken min er det uavgjort — ingen vinner, ingen «raskere». Det eneste stedet selectolax faktisk drar fra, er på 10 MB-siden (159,9 ms mot 172,9 ms, altså et gap på 8,1 % uten overlappende intervaller). På hele oppgaven matcher altså selectolax lxml og slår den bare på de aller største dokumentene.
Deretter isolerte jeg trebygging fra CSS-spørring, og da snur resultatet på en måte de fleste omtaler overser. For ren parsing, uten noen query i det hele tatt, var lxml konsekvent omtrent 33–34 % raskere enn selectolax-Lexbor på denne maskinen — 77,9 ms mot 116,6 ms på 10 MB-siden. På hele oppgaven konvergerer de likevel, og arbeidshypotesen min (ikke noe jeg beviste med en egen attributt-test) er at CSS-spørringen på disse sidene utgjør en liten del av totalen, slik at lxmls fordel i parse-steget blir utvannet til totalsummene møtes.
Dette er den mest angrepsbare påstanden i hele gjennomgangen, og jeg vil være helt åpen om hvorfor. Den snur den vanlige visdommen, og den ene publiserte benchmarken jeg fant som isolerer ren parsing — aows.jpt.sh — rapporterer det motsatte, med selectolax omtrent 4x raskere. Derfor satte jeg gjerder rundt resultatet: det er fra én plattform (macOS arm64, Python 3.14, ferdigbygde cp314-wheels — Linux x86_64 eller kildebygging er ikke testet), det ble kryssjekket på fire sidestørrelser og holdt hele veien, og det ble verifisert på nytt med to ulike lxml-API-er for å utelukke et API-artefakt. Begge lxml-API-ene slo selectolax-Lexbor på alle størrelser. Jeg presenterer ikke «lxml parser raskere» som et endelig faktum — jeg presenterer det som det benchmarken min ga, med skriptet vedlagt, i motsetning til mye av det publiserte materialet. Kjør det på ditt eget oppsett.
Én ting til: ved å spørre etter 100 000 <a> på en flat side, ender lxml og selectolax-Modest helt likt (33,30 ms mot 34,19 ms, med overlappende intervaller), mens selectolax-Lexbor ligger omtrent 15 % bak begge. Det alle tre C-motorene har til felles, er at de er 5–7x raskere enn parsel eller BeautifulSoup ved masseutvelgelse, der Python-objekt-per-node-modellen er den egentlige bremseklossen. Så påstanden «selectolax er den raskeste for bulk CSS-utvelgelse» holder heller ikke — Modest matcher bare lxml, og Lexbor taper mot den.
Det jeg faktisk ville stått inne for, er dette: selectolaxs fordel over lxml er ikke bred, helhetlig hastighet. Den vinner bare på den største siden. Styrken ligger andre steder — API-ergonomi, oppførsel på søppeldata og moderne CSS — og det er der resten av testen hører hjemme.
Minne og kaldstart: ranger etter RSS, ikke etter profilereren din
Minne er området der jeg må korrigere mine egne tidligere tall, og nettopp derfor er det viktig. Målt som RSS-endring på 10 MB-siden med tracemalloc slått av, bruker BeautifulSoup omtrent 1,5–1,8x mer minne enn selectolax eller lxml — spennet går fra 1,51x (BS-lxml på 218,4 MB mot Lexbor på 144,6 MB) til 1,75x i toppen. selectolax og lxml ligger i samme lette kategori; lxml er den letteste målt i RSS.
En tidligere versjon av mine tall viste «ca. 3x», og det var feil av en lærerik grunn: målingen ble gjort mens tracemalloc kjørte, og tracemallocs bokføring per allokering omtrent dobler den tilsynelatende RSS-en til parseren som allokerer mest. Så et råd til alle som benchmarker minnebruk i parserer: ranger etter RSS med profilereren avslått. Å rangere parsere etter topp i tracemalloc gjør spesielt de C-baserte variantene feilplassert — det fikk selectolax-Lexbor til å se tyngre ut enn Modest, selv om de i faktisk RSS ligger nær hverandre. BeautifulSoup er faktisk tyngst her; den er bare ikke 3x tyngre slik et forurenset måleinstrument fikk den til å se ut.
Kaldstart er mindre, men reell: selectolax importeres på rundt 14 ms, omtrent på nivå med lxml og omtrent 2,3x raskere enn bs4 eller parsel. Hvis du shipper et CLI-verktøy eller en serverless-funksjon der importtid inngår i hver kjøring, er det et gap som er verdt å merke seg.
Dekning av CSS-selektorer: sterk, men med et par reelle hull
CSS-dekningen fikk en matrise med 41 tilfeller, der hver selektor ble testet mot en fixture med kjent korrekt svarsett, pluss en bevisst feiljakt for å prøve å knekke Lexbor-motoren. Hver test kjørte i sin egen subprocess, noe som viste seg å være nødvendig — én av dem krasjer hele tolken. Resultatet:
| Motor | PASS | FEIL | IKKE STØ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 mest fiendtlige selektorene er med, er Lexbor ikke den udiskutable vinneren — soupsieve er det, med rene 41/41 mot Lexbors 39/41. Lexbors to bommer er :lang(en) og :dir(rtl), som den avviser med parse-feil. Den er perfekt på alt annet, inkludert :has(), :is(), :where() og attributter uten hensyn til store og små bokstaver.
Der Lexbor virkelig skinner, er mot cssselect-stacken. README-ens flaggskip-selektor — div > :nth-child(2n+1):not(:has(a)) — gir korrekt resultat på begge selectolax-motorene og på soupsieve, men feil mengde på lxml og parsel, uten at det kastes noen feil. En scraper som kopierer den selektoren inn i Scrapy eller parsel får stille og rolig feil resultater. For å være presis: cssselect har støttet :has() siden versjon 1.2.0 (2022), og jeg testet 1.4.0, så dette er «støttet, men evalueres feil i kombinasjonen», ikke «ikke støttet». At denne kombinasjonen gir feil sett uten å si fra, er ikke omtalt i cssselect-trackerens sak, som beskriver :has()-begrensningene som eksplisitte feil. Lexbor håndterer også den case-insensitive attributtflaggen [data-role="LEAD" i], som cssselect avviser helt.
Det er likevel to hull som avgjør migreringer. selectolax støtter ingen XPath i det hele tatt — ingen av backendene eksponerer xpath() — og heller ingen ::text / ::attr()-pseudoelementer, siden det er en utvidelse fra parsel/Scrapy og ikke ekte CSS. Hvis de eksisterende scraperne dine er bygget rundt XPath, er det dette du møter først; du må skrive om selektorer, ikke bare bytte bibliotek. På den andre siden leverer Lexbor en :lexbor-contains("text" i)-pseudoklasse for case-insensitiv tekstmatching som verken lxml, parsel eller standard CSS tilbyr, og den fungerer som dokumentert.
Robusthet på stygg HTML, som er der selectolax fortjener plassen sin
I reell scraping mater du parseren med søppel og håper den ikke kollapser. Jeg kjørte 18 adversariske input-varianter, og dette er kategorien der selectolax har sterkest sak mot lxml.
Gir du lxml.html.fromstring en tom streng eller bare whitespace, kaster den ParserError("Document is empty"). Begge selectolax-backendene returnerer i stedet et gyldig, tomt tre. For en scraper som går gjennom en liste med URL-er der noen svar kommer tilbake tomme, er det én mindre try/except-innpakking du trenger. selectolax håndterte også 100 000 elementer uten stack overflow.
Dyp nesting ga den tydeligste forskjellen. Ved 1 000 og 5 000 nivåer med nestede <div>-er dropper lxml innholdet lengst ned uten å si fra, mens selectolax beholder det. libxml2 setter en maksdybde på rundt 256 nivåer og kapper treet uten feilmelding, så den dypeste teksten blir rett og slett utilgjengelig. Begge selectolax-backendene returnerer hele treet. Det er speilbildet av <template>-fellen jeg kommer til straks: der mister Lexbor innhold de andre beholder; her mister lxml innhold selectolax beholder.
Ikke alle cellene var en seier. Modest-backenden avslutter hele Python-tolken med SIGABRT når den møter :dir() — ikke et unntak du kan fange, men en hard prosessdød. Det er en reell robusthetsadvarsel for alle som fortsatt bruker den eldre backend-en, og akkurat den typen ting som forblir usynlig helt til den velter en produksjonsjobb kl. 03.00.
To feller for stille datatap du bør kjenne til før du shipper
Ingen av disse er nye oppdagelser — begge er dokumentert oppstrøms — men begge koster reell data, stille, og ingen av dem er tydelig omtalt i README-en.
Lexbor dropper <a> inne i <template>
På den live MDN-siden jeg testet, fant selectolax-Lexbor 497 lenker, mens lxml, begge BeautifulSoup-backendene og til og med selectolaxs egen Modest-backend fant 508. De 11 som manglet, var en språkvelger og en diskusjonslenke som lå inne i <template>-elementer (siden bruker Lit web components).
Rotårsaken er legitim: ifølge HTML5-spesifikasjonen parses <template>-innhold inn i et eget inaktivt fragment, ikke i den vanlige DOM-en, og Lexbor følger dette strengt — tree.css("a") går ikke ned i template-innhold. lxml, begge BeautifulSoup-backendene og Modest flater ut template-innholdet i hovedtreet, og finner derfor disse lenkene. Dette er en dokumentert åpen sak (selectolax#146, med rotårsaken i motoren hos lexbor#170), og begge tolkningene kan forsvares — Lexbor er kanskje til og med mer spesifikasjonsriktig. Men en utvikler på den anbefalte backend-en mister likevel disse dataene uten varsel. Det motsatte er også verdt å si: de andre parserne eksponerer inert template-innhold som en nettleser aldri viser, så de kan gi deg spøkelsesdata brukeren ikke ser. Den mest pålitelige nødløsningen for akkurat den siden er Modest-backenden, eller et annet bibliotek.
Ikke-UTF-8-bytes ødelegger .text() uten varsel
Gir du selectolax bytes som ikke er gyldig UTF-8, lykkes parsing — men korrupsjonen dukker opp senere, og det er verre enn en ren krasj. På "<p>café éè</p>".encode("latin-1") returnerer Lexbors .text() erstatningstegn, Modests .text() dropper de problematiske bytene stille, og begge motorene kaster bare UnicodeDecodeError når du berører .html. Bindingen dekoder som streng UTF-8 ved lesing tilbake, ikke ved parsing. Dette henger sammen med en kjent selectolax-sak om strenghet i encode/decode.
Fiksen er én linje og bør sitte i ryggmargen: dekod bytes selv først — LexborHTMLParser(resp.content.decode("latin-1")) — så returnerer begge motorene riktig 'café éè'. I praksis bør du alltid gi selectolax en str, aldri rå ikke-UTF-8 bytes. README-en sier ikke dette eksplisitt.
Produksjonsdimensjoner (én observasjon, så se dem som signaler)
De neste resultatene målte jeg én gang, ikke over tre kjøringer, så jeg markerer dem som signaler heller enn endelige tall.
Trådskalering er den interessante. Når jeg parser en 1 MB-side 48 ganger fordelt over fire tråder, viste selectolax en ~3,5–3,9x reduksjon i veggklokketid — det empiriske kjennetegnet på et bibliotek som slipper GIL under C-parsing — mens BeautifulSoup(lxml) ble flere ganger saktere med tråder, noe som tyder på arbeid som serialiseres på GIL-en. lxml havnet midt imellom og var uavgjort. I den flertrådede epoken Python er på vei inn i, er selectolax-parsing som paralleliserer over tråder der BeautifulSoup ikke gjør det, en reell, om enn foreløpig, fordel. Dette er én trådkonfigurasjon på én sidestørrelse, og mekanismen er en hypotese, ikke noe jeg har bekreftet ved å instrumentere C-koden.
Om minnelekkasjer: over 2 000 iterasjoner med parse-ekstraher-slipp på 1 MB-siden viste ingen av de tre parserne den lineære RSS-stigningen som kjennetegner en lekkasje — hver av dem stabiliserte seg i et avgrenset arbeidssett. Jeg stoler på akkurat det resultatet fordi jeg kjørte en kjent lekkasje-kalibreringskandidat gjennom samme instrument, og den steg til +198 MB slik den skulle, noe som beviser at instrumentet faktisk kunne se en lekkasje og bare ikke fant noen i parserne. Og en node-handle som ble holdt i live etter at treet den tilhørte hadde gått ut av scope, forble brukbar uten segfault. Alt er én observasjon, og ingen av dem er en timeslang soak-test.
Hvor selectolax passer inn – og hvor den overlater jobben
Alt over handler om én jobb: å gjøre HTML du allerede har om til strukturert data, raskt. selectolax er veldig god på nettopp den jobben. Det den bevisst ikke gjør, er å hente siden, rendere JavaScript, rotere proxyer, løse CAPTCHA-er eller finne ut hvilke elementer du vil ha. Alt dette er fortsatt din kode. selectolax er parse-laget, og later ikke som om den er noe mer.
Det er grensen der en administrert ekstraksjonstjeneste ligger over en parser i stedet for å erstatte den. Hvis du helst ikke vil bygge og vedlikeholde hele fetch-render-anti-bot-extract-stacken selv, tilbyr Thunderbit dette som API, MCP-server og CLI — POST /distill gjør en side om til ren Markdown, og POST /extract returnerer strukturert JSON som matcher schemaet, med JS-rendering og anti-bot håndtert for deg. Det er et annet nivå av problemet: du velger selectolax når du allerede har HTML-en og vil ha rå parse-hastighet under egen kontroll, og noe som Thunderbit sitt API, MCP-server eller CLI når du vil at henting og ekstraksjon skal tas hånd om og bare ønsker strukturert data tilbake. Ikke et bytte — et annet nivå i samme stack.
Prøv Thunderbit for webdata-ekstraksjon
Fordeler, ulemper og hvem som faktisk bør bruke det
Der selectolax vinner:
- Omtrent 12–17x raskere enn BeautifulSoup på realistisk parse-og-ekstraher-arbeid, stabilt over tre størrelsesordener i sidestørrelse.
- Lett på minne (lxml-nivået, omtrent 1,5–1,8x lettere enn BeautifulSoup) og importerer på rundt 14 ms.
- Tåler input som knekker lxml — tomt innhold, whitespace og patologisk dyp nesting.
- Moderne CSS, inkludert
:has(),:is(),:where(), attributter uten hensyn til store og små bokstaver, og Lexbor-spesifikke:lexbor-contains(). - En None-sikker DOM for lesing og skriving: manglende elementer returnerer
Noneeller[]i stedet for å kaste, og du kan faktisk mutere og serialisere treet på nytt. - Aktiv vedlikehold (v0.4.10, midten av 2026) og enkel installasjon.
Der den ikke gjør det:
- Ikke bredt raskere enn lxml — uavgjort på hele oppgaven, og taper ren parse-delen i mitt oppsett.
- Ingen XPath og ingen
::text/::attr()— en hard migreringsvegg for XPath-baserte scrapers. - To feller for stille datatap:
<template>-innhold på Lexbor og ikke-UTF-8-bytes via.text(). - Modest-backenden er gammel og vil SIGABRT på
:dir(). - Alle tallene her er fra én plattform (macOS arm64, Python 3.14) og foreløpige.
Bør du bruke selectolax? Ja, hvis du vil ha lxml-klasse parsehastighet med et mer behagelig, None-sikkert API og merkbart bedre oppførsel på tom og ødelagt input — og du er villig til å holde deg til CSS-only. Hvis kodebasen din er bygget på XPath, er omskrivingskostnaden reell, og den bør vurderes ærlig. Og hvis du jakter på «den absolutt raskeste parseren», er det riktige svaret fra denne testen at selectolax og lxml er såpass like at utslagsgivende faktor er ergonomi og robusthet, ikke ren hastighet. Det er egentlig en bedre grunn til å velge verktøy uansett.
Prøv Thunderbit for webdata-ekstraksjon Get Started Free
Ofte stilte spørsmål
Er selectolax raskere enn BeautifulSoup?
Ja, klart — omtrent 12–17x raskere enn BeautifulSoup(html.parser) og 10–14x raskere enn BeautifulSoup(lxml) på en realistisk parse-og-ekstraher-oppgave, stabilt fra 1 KB til 10 MB sider (macOS arm64, Python 3.14). Den ofte siterte «4–5x» undervurderer gapet mot html.parser.
Er selectolax raskere enn lxml? Ikke generelt. På hele parse-og-ekstraher-oppgaven er de uavgjort ved 100 KB og 1 MB, og selectolax vinner bare 10 MB-siden. På ren parsing uten query var lxml faktisk omtrent 33–34 % raskere på min maskin — et resultat som går mot konsensus, og som derfor er markert som plattformspesifikt, så verifiser det på din egen maskinvare.
Bør jeg bruke Lexbor- eller Modest-backenden?
Lexbor, i nesten alle tilfeller — det er den vedlikeholdte, fullverdige motoren README-en anbefaler, med bedre CSS-dekning. Unntaket er sider som skjuler innhold i <template>-elementer, der Lexbors spesifikasjonsriktige oppførsel dropper innholdet mens Modest tilfeldigvis beholder det. Modest har også skarpe kanter, inkludert hard tolkekrasj på :dir().
Støtter selectolax XPath?
Nei. Ingen av backendene eksponerer en xpath()-metode — selectolax er CSS-only. Hvis scraperne dine er avhengige av XPath, betyr migrering at du må skrive om selektorene dine, og det er den største enkeltkostnaden ved å gå fra en lxml- eller parsel-basert stack til selectolax.
Hvorfor blir selectolax-resultatet mitt ødelagt eller mangler elementer?
To vanlige syndere. Hvis tekst kommer tilbake med erstatningstegn eller manglende aksenter, har du sannsynligvis sendt rå ikke-UTF-8-bytes — dekod dem til en str først (resp.content.decode("latin-1")) før parsing. Hvis lenker eller elementer mangler på en moderne side, kan de ligge i <template>-tagger som Lexbor-backenden ikke går ned i; bruk Modest eller en annen parser for akkurat den siden.
