Elke blogpost over de “snelste Python HTML-parser” noemt uiteindelijk selectolax, en bijna altijd blijft het verhaal steken bij “veel sneller dan BeautifulSoup.” Dat klopt ook. Wat zelden helemaal wordt uitgewerkt, is wat er gebeurt als je selectolax naast lxml zet — want dan krijgt “snelste” ineens een sterretje.
Dus heb ik het grondig doorgemeten: selectolax (beide backends), lxml, BeautifulSoup op html.parser en op lxml, en parsel, over vijf paginagroottes van 1 KB tot 10 MB. Elke meting is genomen als de mediaan van drie losse procesrondes. selectolax liet BeautifulSoup ver achter zich en eindigde gelijk met ruwe lxml — maar verloor op de pure parse-stap van lxml. Alle cijfers hieronder zijn voorlopig en komen van één machine (macOS arm64, Python 3.14.2); de scripts staan gecommit, dus draai ze gerust zelf voordat je me citeert.
Wat selectolax eigenlijk is (en wat niet)
selectolax is een Python-binding voor twee C-engines — Modest en Lexbor — die HTML5 parsen en via CSS-selectors doorzoeken. Het is geen crawler, geen browser en geen “scraper” in de zin van een knop indrukken en klaar. Het is juist het onderdeel waar je al opgehaalde HTML aan doorgeeft. De eigen one-liner van de maintainer is: “A fast HTML5 parser with CSS selectors, written in Cython, using Modest and Lexbor engines.”
Er zijn twee backends, en dat verschil doet meer ter zake dan de documentatie laat zien:
LexborHTMLParser(Lexbor-engine) — de backend die de README sinds 2024 aanbeveelt.HTMLParser(Modest-engine) — de originele backend; de onderliggende C-bibliotheek “is no longer maintained,” aldus dezelfde README.
Een paar feiten die handig zijn voordat we naar snelheid kijken. Volgens de repo-snapshot van 2026-07-10 staat selectolax op 1.653 sterren, met de nieuwste release v0.4.10 (mei 2026), en PyPI ondersteunt Python >=3.9,<3.15. Installeren is het minst spannende deel van deze review: pip install selectolax haalde direct een prebuilt cp314-wheel van 2,3 MB binnen en werkte meteen op Python 3.14 — geen browserdownload, geen doctor-stap, geen compilatie. Dat is het stille voordeel van een pure parser tegenover een browser-gedreven tool. Je importeert hem gewoon en hij draait.
Eén licentiedetail moet je meteen meenemen, niet ergens wegmoffelen: de Python-binding is MIT, maar het wheel bundelt de meegecompileerde engines en die hebben hun eigen licenties — Modest is LGPL-2.1, Lexbor is Apache-2.0. Dus “selectolax is MIT” klopt voor de Python-code, maar niet volledig voor de binaire component die je daadwerkelijk verspreidt. Als je juridische team om herverdeling van componenten geeft, is dát het punt om te markeren.
De snelheidsvraag, beantwoord met echte cijfers
Dit is de taak die ik heb getimed: de HTML-string parsen, alle <h3 class="title">-teksten ophalen en alle <a>-hrefs verzamelen. Latency in milliseconden, genomen als mediaan over drie losse procesrondes; de spreiding tussen runs bleef bij de meeste groottes onder ongeveer 5% voor de C-gedreven parsers. Voor elke meting werd eerst de output van elke parser teruggebracht tot een content-hash, zodat een parser die stilletjes minder werk deed eruit gefilterd zou worden — op deze pagina’s kwamen alle zes exact overeen op elke grootte, dus dit is echt een eerlijke vergelijking. De volledige data staat in de gecommitte bench_parse.json.
| Pagina | 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 |
Tegenover BeautifulSoup: ongeveer 12-17x, en de folklore doet het tekort
Als je daar verhoudingen van maakt, komt selectolax-Lexbor uit op ongeveer 12x sneller dan BeautifulSoup(html.parser) op een 1 KB-pagina, oplopend tot ongeveer 17x op 10 MB, en ongeveer 10-14x sneller dan BeautifulSoup(lxml) over hetzelfde bereik. Het getal dat online rondzingt — “selectolax is ongeveer 4-5x sneller dan BeautifulSoup” — is te laag als je het vergelijkt met html.parser, en ongeveer alleen in de buurt als je de lxml-variant van BeautifulSoup bedoelt. De echte factor hangt af van welke BeautifulSoup je gebruikt en hoeveel je per pagina extraheert.
Dat sluit ook aan op de benchmark in de README zelf, die een 25,5x voorsprong op BeautifulSoup(html.parser) suggereert. Geen van beide cijfers is fout. De taak in de README (titels, links, scripts en meta van kleine homepages) doet minder extractiewerk op kleinere pagina’s, waardoor de overhead per parse van BeautifulSoup zwaarder meetelt. Binnen een realistische bandbreedte kun je het zo samenvatten: selectolax is grofweg 10-15x sneller dan BeautifulSoup bij echte parse-en-extract-workloads, hoger bij kleine pagina’s en lichtere extractie.
Als jouw huidige knelpunt een berg BeautifulSoup-code is die pagina’s doorploegt, dan is dit precies de migratie die zichzelf terugverdient. Daar valt weinig op af te dingen. De volgende casus wel.
Tegenover lxml: gelijkspel — en lxml wint het deel dat iedereen vergeet te isoleren
Kijk nog eens naar de rijen van 100 KB en 1 MB. Lexbor en lxml zitten binnen ongeveer 5% van elkaar, de per-run bandbreedtes overlappen, en volgens mijn eigen methode is dat een gelijkspel — geen winnaar, geen “sneller.” Het enige moment waarop selectolax echt uitloopt, is op de 10 MB-pagina (159,9 ms versus 172,9 ms, een verschil van 8,1% met niet-overlappende intervallen). Op de volledige taak is selectolax dus gelijk aan lxml en alleen duidelijk sneller op de allergrootste documenten.
Daarna heb ik tree-construction losgekoppeld van CSS-querying, en dan slaat de balans om op een manier die veel artikelen missen. Voor pure parsing, zonder enige query, was lxml op deze machine consequent ongeveer 33-34% sneller dan selectolax-Lexbor — 77,9 ms tegenover 116,6 ms op de 10 MB-pagina. Op de volledige taak komen de twee toch dicht bij elkaar, en mijn werkhypothese (niet iets dat ik met een attributie-experiment bewezen heb) is dat op deze pagina’s de CSS-query slechts een klein deel van de totale tijd uitmaakt, waardoor het parse-voordeel van lxml wordt afgevlakt totdat de totalen gelijk worden.
Dit is de meest aanvechtbare claim in deze hele review, en ik wil daar eerlijk over zijn. Hij botst met de gangbare wijsheid, en de enige gepubliceerde benchmark die ik vond en die alleen parse-werk isoleert — aows.jpt.sh — rapporteert juist het tegenovergestelde, met selectolax ongeveer 4x sneller. Daarom heb ik het afgebakend: het resultaat komt van één platform (macOS arm64, Python 3.14, prebuilt cp314-wheels — Linux x86_64 of een source build is niet getest), het is gecheckt op vier paginagroottes en bleef overal consistent, en het is opnieuw geverifieerd met twee verschillende lxml-API’s om een API-effect uit te sluiten. Beide lxml-API’s waren op elke grootte sneller dan selectolax-Lexbor. Ik presenteer “lxml parseert sneller” dus niet als definitief feit — ik presenteer het als wat mijn bench opleverde, mét script erbij, tegen de meeste gepubliceerde cijfers in. Draai het op je eigen hardware.
Nog een uitsplitsing: bij het queryen van 100.000 <a>-elementen op een vlakke pagina eindigen lxml en selectolax-Modest gelijk (33,30 ms versus 34,19 ms, overlappende bandbreedtes), terwijl selectolax-Lexbor beide met ongeveer 15% achter zich laat. Wat alle drie de C-engines gemeen hebben, is dat ze 5-7x sneller zijn dan parsel of BeautifulSoup bij bulkselectie, waar het Python-object-per-node-model de echte rem is. Dus “selectolax is de snelste bij bulk CSS-selectie” klopt ook niet — Modest komt alleen gelijk uit met lxml, en Lexbor verliest ervan.
De conclusie die ik wél zou verdedigen: het voordeel van selectolax ten opzichte van lxml zit niet in brede, totale snelheid. Het wint alleen op de allerzwaarste pagina. De echte sterke punten zitten elders — in API-ergonomie, gedrag bij rommelige input en moderne CSS — en daar gaat de rest van deze review over.
Geheugen en cold start: rangschik op RSS, niet op je profiler
Geheugen is waar ik mezelf moet corrigeren, en die correctie is meteen de kern van het verhaal. Gemeten als RSS-delta op de 10 MB-pagina met tracemalloc uitgeschakeld, gebruikt BeautifulSoup ongeveer 1,5-1,8x zoveel geheugen als selectolax of lxml — de band loopt van 1,51x (BS-lxml op 218,4 MB versus Lexbor op 144,6 MB) tot 1,75x aan de bovenzijde. selectolax en lxml zitten in dezelfde zuinige klasse; lxml is op RSS de zuinigste.
Een eerdere ronde van mij meldde “ongeveer 3x”, en dat bleek onjuist om een leerzame reden: die meting draaide met tracemalloc aan, en de per-allocatie bookkeeping van tracemalloc verdubbelt grofweg de schijnbare RSS van de parser die het meeste allocates doet. Dus een waarschuwing voor iedereen die parsergeheugen benchmarkt: rangschik op RSS met je profiler uit. Parsers sorteren op tracemalloc-peak zet vooral de C-gedreven varianten verkeerd neer — selectolax-Lexbor leek daardoor zwaarder dan Modest, terwijl ze qua echte RSS juist dicht bij elkaar zitten. BeautifulSoup is hier echt het zwaarst; alleen niet met de 3x-marge die een vervuild meetinstrument liet zien.
Cold start is klein maar echt: selectolax importeert in ongeveer 14 ms, ongeveer gelijk aan lxml en ongeveer 2,3x sneller dan bs4 of parsel. Als je een CLI-tool of serverless functie bouwt waarbij importtijd in elke run meetelt, is dat een verschil dat de moeite waard is.
CSS-selector-ondersteuning: sterk, met een paar echte gaten
De CSS-coverage bestond uit een matrix van 41 cases, waarbij elke selector werd vergeleken met een fixture met een correct antwoordenbestand, plus een opzettelijke fault-finding run om de Lexbor-engine te breken. Elke case draaide in een apart subprocess, wat nodig bleek — één ervan laat de hele interpreter crashen. De resultaten:
| Engine | 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 |
Als je de vijandige selectors meeneemt, is Lexbor niet de onbetwiste winnaar — soupsieve is dat wel, met een zuivere 41/41 tegenover Lexbor’s 39/41. De twee misses van Lexbor zijn :lang(en) en :dir(rtl), die het afwijst met een parse error. Verder is het perfect op alles, inclusief :has(), :is(), :where() en hoofdletterongevoelige attributen.
Waar Lexbor juist uitblinkt, is vergeleken met de cssselect-stack. De vlaggenschip-selector uit de README — div > :nth-child(2n+1):not(:has(a)) — geeft de juiste set terug in beide selectolax-engines en in soupsieve, maar de verkeerde set in lxml en parsel, zonder foutmelding. Een scraper die die selector letterlijk overneemt naar Scrapy of parsel krijgt dus stilletjes verkeerde resultaten. Om precies te zijn: cssselect ondersteunt :has() sinds versie 1.2.0 (2022), en ik testte 1.4.0, dus dit is “ondersteund maar verkeerd geëvalueerd in de samengestelde selector,” niet “niet ondersteund.” Het stilletjes foutieve resultaat bij precies deze samengestelde selector staat niet in de cssselect tracker, die de :has()-beperkingen als expliciete fouten documenteert. Lexbor verwerkt ook de case-insensitive attribuutvlag [data-role="LEAD" i], die cssselect volledig afwijst.
Er zijn wel twee gaten die migraties gaan bepalen. selectolax ondersteunt helemaal geen XPath — geen van beide backends biedt xpath() aan — en ook geen ::text / ::attr() pseudo-elementen, omdat dat een parsel/Scrapy-uitbreiding is en geen echte CSS. Als je bestaande scrapers op XPath leunen, is dat de grootste muur waar je tegenaan loopt; je herschrijft dan selectors in plaats van alleen een library te vervangen. Aan de andere kant levert Lexbor wel een :lexbor-contains("text" i)-pseudo-class voor hoofdletterongevoelige tekstreeksvergelijking, iets wat noch lxml, noch parsel, noch standaard CSS biedt, en dat werkt zoals gedocumenteerd.
Robuustheid op lelijke HTML, en daar verdient selectolax zijn geld
Echte scraping betekent rommelige input geven aan een parser en hopen dat hij niet omvalt. Ik heb 18 adversariële inputs getest, en dit is de categorie waarin selectolax zich het sterkst tegen lxml verdedigt.
Geef lxml.html.fromstring een lege string of alleen whitespace en je krijgt ParserError("Document is empty"). Beide selectolax-engines geven daarentegen gewoon een geldige, lege tree terug. Voor een scraper die door een lijst URL’s loopt waar sommige responses leeg terugkomen, scheelt dat weer een try/except-laag om alles heen. selectolax verwerkte ook 100.000 elementen zonder stack overflow.
Diep geneste HTML leverde het scherpste verschil op. Bij 1.000 en 5.000 niveaus van geneste <div>-tags laat lxml stilletjes de diepste content vallen, terwijl selectolax die behoudt. libxml2 beperkt de parse-diepte tot ongeveer 256 niveaus en kapt de tree af zonder foutmelding, waardoor de diepste tekst simpelweg onbereikbaar wordt. Beide selectolax-engines geven de volledige tree terug. Het is de spiegelafbeelding van de <template>-valkuil die hierna komt: daar laat Lexbor content vallen die de anderen behouden; hier laat lxml content vallen die selectolax behoudt.
Niet elk vakje was een overwinning. De Modest-backend laat de hele Python-interpreter aborteren met een SIGABRT zodra hij :dir() tegenkomt — geen opgeworpen exception die je kunt vangen, maar een harde procesdood. Dat is een serieuze robuustheidswaarschuwing voor iedereen die nog op de legacy-backend zit, en precies het soort probleem dat je pas ziet als een productiejob om 03:00 uur omvalt.
Twee stille dataverlies-valkuilen die je moet kennen vóór je live gaat
Geen van beide ontdekkingen is nieuw — ze zijn upstream al gedocumenteerd — maar beide kosten echt data, zonder waarschuwing, en geen van beide springt in de README in het oog.
Lexbor mist <a> binnen <template>
Op de live MDN-pagina die ik testte, vond selectolax-Lexbor 497 links, terwijl lxml, beide BeautifulSoup-backends en zelfs selectolax’ eigen Modest-backend er 508 vonden. De elf ontbrekende links waren een taalwisselaar en een discussielink binnen <template>-elementen (de pagina gebruikt Lit-webcomponenten).
De oorzaak is legitiem: volgens de HTML5-specificatie wordt inhoud binnen <template> in een apart inert fragment geparsed, niet in de normale DOM, en Lexbor volgt dat strikt — tree.css("a") daalt niet af in template-inhoud. lxml, beide BeautifulSoup-backends en Modest flattenen template-inhoud juist in de hoofd-tree, waardoor ze die links wél vinden. Dit is een gedocumenteerde open issue (selectolax#146, met de onderliggende engine-oorzaak bij lexbor#170), en beide interpretaties zijn verdedigbaar — Lexbor is hier waarschijnlijk zelfs meer spec-correct. Maar een ontwikkelaar op de aanbevolen backend mist die data stilletjes, zonder foutmelding. Het omgekeerde is ook belangrijk: de andere parsers tonen inert template-materiaal dat een browser nooit rendert, en kunnen je dus spookdata geven die een gebruiker niet ziet. De betrouwbare uitweg voor precies die pagina is de Modest-backend, of een andere library.
Niet-UTF-8 bytes corrumperen .text() stilletjes
Geef selectolax bytes die geen geldige UTF-8 zijn, en parsen lukt gewoon — de schade verschijnt pas later, en die is erger dan een nette crash. Op "<p>café éè</p>".encode("latin-1") geeft Lexbor’s .text() vervangtekens terug, Modest’s .text() laat de probleembytes stilletjes weg, en beide engines gooien pas UnicodeDecodeError op het moment dat je .html aanraakt. De binding decodeert dus strikt als UTF-8 bij het uitlezen, niet bij het parsen. Dit hangt samen met een bekend selectolax-probleem rond encode/decode-striktheid.
De oplossing is één regel en moet in je spiergeheugen zitten: decodeer de bytes eerst zelf — LexborHTMLParser(resp.content.decode("latin-1")) — en beide engines geven weer correct 'café éè' terug. In de praktijk: geef selectolax altijd een str, nooit ruwe non-UTF-8 bytes. De README zegt dat er niet expliciet bij.
Productiedimensies (één meting per punt, dus behandel dit als richtinggevend)
De volgende resultaten heb ik één keer gemeten, niet drie keer, dus ik beschouw ze als signalen en niet als definitieve waarden.
Thread-scaling is de interessante. Bij het 48 keer parsen van een 1 MB-pagina over vier threads liet selectolax een wall-clock versnelling van ongeveer 3,5-3,9x zien — het empirische patroon van een library die de GIL loslaat tijdens C-parsing — terwijl BeautifulSoup(lxml) threaded juist meerdere keren trager werd, wat past bij werk dat serialiseert op de GIL. lxml zat ertussenin en was niet overtuigend. Voor het tijdperk van free-threading waar Python naartoe beweegt, is selectolax dat over threads paralleliseert waar BeautifulSoup dat niet doet een echt, zij het voorlopig, voordeel. Het is één thread-aantal op één paginagrootte, en het mechanisme is een hypothese, niet iets dat ik met instrumentatie in de C-code heb bevestigd.
Over leaks: na 2.000 iteraties van parse-extract-drop op 1 MB liet geen van de drie parsers de lineaire RSS-stijging van een leak zien — elk stabiliseerde binnen een begrensde working-set-band. Ik vertrouw dat resultaat juist omdat ik dezelfde meting ook op een bekende-leak test liet los, en die steeg naar +198 MB zoals bedoeld, wat bewijst dat de instrumentatie een leak kon zien en er in de parsers gewoon geen vond. En een node-handle die in leven bleef nadat de bijbehorende tree buiten scope was geraakt, bleef bruikbaar zonder segfault. Ook dit is één meting, geen urenlange soak-test.
Waar selectolax past — en waar het afhandelt
Alles hierboven gaat over één taak: HTML die je al hebt omzetten naar gestructureerde data, snel. selectolax is daar erg goed in. Wat het bewust niet doet, is de pagina ophalen, JavaScript renderen, proxies roteren, CAPTCHA’s oplossen of bepalen welke elementen je nodig hebt. Dat blijft allemaal jouw code. selectolax is de parse-laag, en doet niet alsof het meer is.
Daar ligt de grens waar een managed extraction-service bovenop een parser zit in plaats van die te vervangen. Als je liever niet zelf de fetch-render-anti-bot-extract-stack bouwt en onderhoudt, biedt Thunderbit dat aan via een API, MCP-server en CLI — POST /distill zet een pagina om in schone Markdown en POST /extract levert schema-gestructureerde JSON, inclusief JS-rendering en anti-bot-afhandeling. Dat is een andere laag van hetzelfde probleem: je kiest selectolax als je de HTML al hebt en raw parsing-snelheid onder eigen controle wilt, en iets als Thunderbit’s API, MCP-server of CLI als je het ophalen en extraheren wilt uitbesteden en gewoon gestructureerde data terug wilt. Geen vervanging, maar een andere hoogte in dezelfde stack.
Probeer Thunderbit voor webdata-extractie
Plus- en minpunten, en wie het echt zou moeten gebruiken
Waar selectolax wint:
- Ongeveer 12-17x sneller dan BeautifulSoup bij realistisch parse-en-extractwerk, stabiel over drie ordes van paginagrootte.
- Zuinig geheugen (het lxml-niveau, ongeveer 1,5-1,8x lichter dan BeautifulSoup) en een import van ongeveer 14 ms.
- Vergevingsgezind op input waar lxml op stukloopt — lege input, whitespace en extreem diepe nesting.
- Moderne CSS, inclusief
:has(),:is(),:where(), case-insensitive attributes en de Lexbor-only:lexbor-contains(). - Een None-veilige DOM voor lezen en schrijven: ontbrekende elementen geven
Noneof[]terug in plaats van een exception, en je kunt de tree echt muteren en opnieuw serialiseren. - Actief onderhoud (v0.4.10, midden 2026) en een triviale installatie.
Waar het niet wint:
- Niet structureel sneller dan lxml — gelijk op de volledige taak, en op mijn bench verliest het de pure parse-stap.
- Geen XPath en geen
::text/::attr()— een harde migratiemuur voor XPath-gebaseerde scrapers. - Twee stille dataverlies-valkuilen:
<template>-inhoud in Lexbor en non-UTF-8 bytes via.text(). - De Modest-backend is legacy en kan SIGABRT geven op
:dir(). - Elk cijfer hier komt van één platform (macOS arm64, Python 3.14) en is voorlopig.
Moet je selectolax gebruiken? Ja, als je lxml-achtige parsesnelheid wilt met een vriendelijkere, None-veilige API en duidelijk beter gedrag op lege en foutieve input — en als je bereid bent om in CSS-only-territorium te leven. Als je codebase op XPath leunt, is de ombouw reëel en moet je dat eerlijk meewegen. En als je achter “de absolute snelste parser” aan zit, dan is het juiste antwoord op basis van deze bench dat selectolax en lxml dicht genoeg bij elkaar liggen dat de doorslag gaat over ergonomie en robuustheid, niet over pure snelheid. Dat is eigenlijk al een betere reden om een tool te kiezen.
Probeer Thunderbit voor webdata-extractie Get Started Free
Veelgestelde vragen
Is selectolax sneller dan BeautifulSoup?
Ja, duidelijk — ongeveer 12-17x sneller dan BeautifulSoup(html.parser) en 10-14x sneller dan BeautifulSoup(lxml) bij een realistische parse-en-extract-taak, consistent van 1 KB tot 10 MB (macOS arm64, Python 3.14). De vaak aangehaalde “4-5x” onderschat het verschil met html.parser.
Is selectolax sneller dan lxml? Niet breed genomen. Op de volledige parse-en-extract-taak staan ze gelijk bij 100 KB en 1 MB, en wint selectolax alleen op de 10 MB-pagina. Bij pure parsing zonder query was lxml op mijn machine zelfs ongeveer 33-34% sneller — een resultaat dat tegen de consensus ingaat en daarom enkel als platformgebonden is afgebakend; controleer het dus op je eigen hardware.
Moet ik de Lexbor- of Modest-backend gebruiken?
Lexbor, in bijna alle gevallen — het is de onderhouden, compleetste engine die de README aanbeveelt, met betere CSS-dekking. De uitzondering is een pagina die content verbergt in <template>-elementen, waar Lexbor volgens de spec die content niet meeneemt en Modest die toevallig wel behoudt. Modest heeft bovendien scherpe randjes, waaronder een harde interpreter-crash op :dir().
Ondersteunt selectolax XPath?
Nee. Geen van beide backends biedt een xpath()-methode aan — selectolax is CSS-only. Als je scrapers op XPath leunen, betekent migreren dat je selectors herschrijft, en dat is de grootste enkele kostenpost bij de overstap van een lxml- of parsel-stack naar selectolax.
Waarom is mijn selectolax-output corrupt of ontbreken er elementen?
Twee gebruikelijke oorzaken. Als tekst terugkomt met vervangtekens of ontbrekende accenten, heb je waarschijnlijk ruwe non-UTF-8 bytes doorgegeven — decodeer die eerst naar een str (resp.content.decode("latin-1")) vóór het parsen. Als links of elementen ontbreken op een moderne site, kunnen ze in <template>-tags zitten waar de Lexbor-backend niet in afdaalt; schakel voor die pagina over naar Modest of een andere parser.
