BeautifulSoup este biblioteca la care ajunge aproape toată lumea prima dată când extrage o pagină web în Python, iar într-adevăr este cel mai lent dintre parser-ele HTML serioase. Ambele afirmații sunt adevărate și niciuna nu este o critică. Partea interesantă este că „cel mai lent” se dovedește a fi un număr precis, pe care îl poți plăti, nu doar o impresie.
Am testat bs4 (adică beautifulsoup4, versiunea 4.15.0, lansată în iunie 2026, sub licență MIT) printr-o combinație de teste noi de capabilități și date de timp reutilizate din același rig de benchmark, iar imaginea este consecventă: plătești o penalizare de viteză de aproximativ un ordin de mărime pentru cea mai prietenoasă API și cea mai bună toleranță la erori din domeniu. Dacă acest schimb este inteligent sau nu depinde integral de tipul de sarcină, așa că analiza de față păstrează ambele fețe pe masă.
Ce este, de fapt, BeautifulSoup — și ce nu este
Cele mai multe tutoriale sar peste partea care contează cel mai mult: BeautifulSoup nu parsează HTML. Este un wrapper. În spate, trimite documentul tău către unul dintre trei parsere reale — html.parser inclus în Python, lxml sau html5lib — apoi învelește arborele rezultat într-o singură API de navigare și căutare, foarte ușor de folosit. Rolul bs4 nu este să parseze. Rolul lui este să facă rezultatul plăcut de explorat.
Autorul său îl numește chiar „screen-scraping library”, iar promisiunea a fost mereu aceeași: pune-l peste un HTML atât de stricat încât ar face un browser să strâmbe din nas, iar el tot va scoate datele pe care le vrei. Reputația asta este câștigată, cu o notă de subsol la care ajungem imediat.
Câteva lucruri care merită fixate înainte de orice altceva:
| Câmp | Valoare |
|---|---|
| Pachet | beautifulsoup4 (import ca bs4) |
| Versiune testată | 4.15.0 (încărcată 2026-06-07) |
| Cerință Python | >=3.7.0 |
| Licență | MIT |
| Pagina oficială | crummy.com/software/BeautifulSoup |
| Sursă + tracker de bug-uri | Launchpad — nu GitHub |
| Mentenanță | Activă (4.15.0 în iunie 2026, șase versiuni în ultimul an) |
Faptul că „nu GitHub” contează mai mult decât pare. bs4 este o bibliotecă veche de 20 de ani, găzduită pe crummy.com și Launchpad, deci verificarea obișnuită a popularității după numărul de stele GitHub nu se aplică. Evaluează-i sănătatea după ritmul lansărilor și, din acest punct de vedere, este foarte vie.
Un detaliu subtil legat de licențiere, pentru oricine trebuie să dea explicații unei echipe de compliance: wrapper-ul este MIT, dar ce înseamnă concret „folosirea bs4” în dependențele tale depinde de backend-ul instalat. html.parser vine din biblioteca standard Python (licență PSF, fără dependențe suplimentare). lxml este BSD, dar se bazează pe libxml2/libxslt — o dependență C externă pe care fie o compilezi, fie o iei sub formă de wheel precompilat. html5lib este pur Python și MIT. Dacă vrei cea mai curată amprentă de dependențe, parser-ul inclus html.parser ți-o oferă — ceea ce, întâmplător, este și backend-ul cu cea mai mare capcană. Revenim imediat.
Taxa de viteză, cuantificată
Să punem numărul pe masă de la început, pentru că este titlul principal și ar fi necinstit să-l ascundem. Pentru o sarcină realistă de tip parse-then-extract — parsezi șirul, extragi fiecare <h3 class="title"> și fiecare <a href> — BeautifulSoup este cel mai lent parser din această comparație, și nu cu puțin.
Aceste timpi sunt preluați din rig-ul de benchmark selectolax (același calculator, aceeași metodologie cu 3 rulări, la data de 2026-07-13); review-ul de față nu rerulează niciun benchmark de timp, pentru a evita contendența pe CPU și munca duplicată. Mediana latenței p50, în milisecunde:
| Dimensiune pagină | bs4 (html.parser) | bs4 (lxml) | selectolax-Lexbor | lxml | bs4-hp mai lent | bs4-lxml mai lent |
|---|---|---|---|---|---|---|
| 1 KB | 0.323 | 0.281 | 0.027 | 0.036 | 12.0x | 10.5x |
| 10 KB | 2.049 | 1.705 | 0.160 | 0.166 | 12.8x | 10.7x |
| 100 KB | 20.599 | 16.540 | 1.464 | 1.423 | 14.1x | 11.3x |
| 1 MB | 232.558 | 181.855 | 14.901 | 14.177 | 15.6x | 12.2x |
| 10 MB | 2788.746 | 2261.557 | 159.935 | 172.933 | 17.4x | 14.1x |
Așadar, bs4(html.parser) rulează cam de 12–17x mai lent decât un parser C precum selectolax-Lexbor, iar trecerea la backend-ul lxml îl aduce doar la 10.5–14x — tot rămâne în urmă cu un ordin de mărime. Motivul este structural, nu un bug: indiferent ce backend face parsarea, bs4 construiește un obiect Python complet (un Tag sau un NavigableString) pentru fiecare nod. Stratul acela de materializare a obiectelor este o taxă pe care parser-ele C pur și simplu nu o plătesc.
Observă că multiplicatorul crește pe măsură ce paginile devin mai mari — 12.0x la 1 KB, 17.4x la 10 MB. Asta îți spune că nu este un cost fix de pornire pe care îl poți dilua. Este o taxă per nod, care crește liniar cu numărul de noduri construite.
Acum reformularea, pentru că „de 10x mai lent” sună mai alarmant decât este în practică. La o pagină de 1 MB, asta înseamnă 232 ms versus 15 ms. Dacă jobul tău este „extrage câteva sute sau câteva mii de pagini, fiecare de câteva sute de KB”, diferența absolută este invizibilă — nici nu o vei simți, iar optimizarea ei nu-ți aduce nimic. Dacă însă ai un pipeline de un milion de pagini, același raport face diferența dintre un job care se termină și unul care nu. Același număr, verdict opus. Evaluează-l în raport cu volumul real, nu cu benchmark-ul.
Nu, schimbarea backend-ului nu rezolvă problema
Există un mit persistent conform căruia poți să-i dai lui bs4 backend-ul lxml și să obții viteza lui lxml. Nu poți, și merită să înțelegi de ce. La o interogare CSS pe un lot de 100.000 de noduri (selectezi fiecare <a> și îi citești href-ul, arborele fiind deja construit), diferența de throughput este clară:
| Parser | Query p50 | Noduri/sec |
|---|---|---|
| lxml | 33.30 ms | 3,002,646 |
| selectolax-Modest | 34.19 ms | 2,924,550 |
| selectolax-Lexbor | 39.46 ms | 2,534,027 |
| bs4 (lxml) | 250.56 ms | 399,111 |
bs4(lxml) ajunge la aproximativ 399.000 de noduri/secundă — cam de 6.3–7.5x mai lent decât cele trei motoare C, deși backend-ul său este chiar lxml. Backend-ul accelerează construirea arborelui. Interogarea și parcurgerea tot trec prin soupsieve în obiecte bs4 Tag, iar fiecare nod potrivit ajunge în continuare împachetat în Python. Așa că modelul mental „dă-i lui bs4 lxml și devine la fel de rapid ca lxml” este greșit: backend-ul accelerează o singură etapă, iar etapa cea mai lentă nu este aceea.
Memoria și cold start-ul completează costul. La un document de 10 MB, bs4 folosește cam 1.5–1.75x memoria rezidentă a selectolax sau lxml (218–226 MB versus 129–145 MB) — aceeași cauză de bază, un obiect Python per nod. Iar importul lui bs4 durează aproximativ 33.4 ms față de 14.1 ms pentru lxml.html, deci este de 2.36x mai lent de importat. Ultimul aspect este aproape neglijabil într-un proces de lungă durată, dar pentru un CLI sau o funcție serverless care pornește mereu „la rece”, este un cost mic, dar real, pe care merită să-l cunoști.
De ce mai multe thread-uri nu te salvează
Dacă instinctul tău pentru o sarcină lentă, CPU-bound, este „aruncă thread-uri peste ea”, bs4 îți va pedepsi acel instinct. Pe o pagină de 1 MB parsată de 48 de ori, comparând un thread cu patru thread-uri:
| Parser | 1 thread | 4 thread-uri | Accelerație |
|---|---|---|---|
| selectolax-Lexbor | 0.563 s | 0.159 s | 3.54x |
| lxml | 0.459 s | 0.378 s | 1.21x |
| bs4 (lxml) | 6.945 s | 26.842 s | 0.26x |
Citește din nou ultimul rând. Patru thread-uri au făcut bs4 de aproximativ 3.9x mai lent, nu mai rapid. Semnalul empiric este „probabil ține GIL-ul”: construirea arborelui în bs4 este pur Python, deci se serializează sub Global Interpreter Lock, iar adăugarea de thread-uri nu face decât să aducă overhead de scheduling peste o sarcină care nu poate rula cu adevărat în paralel. selectolax obține acea accelerare de ~3.5x pentru că nucleul său C eliberează lock-ul; bs4 nu are acel spațiu.
Pentru era free-threading, concluzia practică este aceasta: dacă trebuie să paralelizezi BeautifulSoup, folosește multiprocessing (ProcessPoolExecutor), nu thread-uri. selectolax și lxml pot scala pe thread-uri; bs4 nu. O precizare de rigoare: aceasta este o singură observație, la un singur număr de thread-uri (4) și o singură dimensiune de pagină (1 MB), iar mecanismul „ține GIL-ul” este o ipoteză dedusă din comportamentul wall-clock, nu ceva confirmat prin instrumentarea exactă a căii de cod care blochează lock-ul. Direcția este clară; mecanismul exact rămâne provizoriu.
Backend-ul implicit este capcana. Citește asta primul.
Dacă reții un singur lucru din acest review, reține-l pe acesta. Un BeautifulSoup(html) simplu, fără al doilea argument, folosește html.parser, iar html.parser nu implementează regulile HTML5 pentru tag-urile de închidere opționale. Sună academic până când îți corupe datele fără să-ți dai seama.
Am rulat 15 mostre HTML intenționat stricate prin toate cele trei backend-uri, cu o afirmație structurală agnostică față de backend, preînregistrată pentru fiecare înainte de rulare (ca nimeni să nu poată alege câștigătorul după fapt). Rezultatele:
| Backend | Îndeplinește așteptarea / 15 |
|---|---|
| lxml | 15 |
| html5lib | 15 |
| html.parser | 12 |
Cele trei eșecuri au aceeași cauză de bază. Ia un tabel neînchis: <table><tr><td>a<td>b<tr><td>c<td>d</table>. În html.parser, textul celulelor extrase apare ca ['abcd','bcd','cd','d'] — fiecare <td> înghite tot ce urmează după el, pentru că parser-ul imbrică celulele în loc să le închidă. lxml și html5lib returnează corect ['a','b','c','d']. La fel se întâmplă și cu elementele de listă fără închidere: <li>a<li>b<li>c produce ['abc','bc','c'] în html.parser, iar în celelalte două obții curat ['a','b','c']. Și atributele duplicate se comportă diferit — <div id="first" id="second"> păstrează "second" în html.parser, dar "first" în lxml/html5lib, iar specificația HTML5 spune să fie păstrat primul.
De ce este asta periculos, nu doar enervant: se întâmplă fără să ridice eroare. Un scraper care face simplu BeautifulSoup(html) și întâlnește un tabel sau o listă neînchise — lucru deprimant de comun pe site-uri vechi, HTML scris manual și template-uri care au uitat un tag de închidere — va lipi textul din celulele vecine într-un singur câmp, îți va livra date murdare și nu se va plânge niciodată. Remediul este un singur argument: BeautifulSoup(html, "lxml") sau BeautifulSoup(html, "html5lib").
Ca să fim corecți față de html.parser, celelalte 12 din 15 mostre stricate au ieșit identic pe toate cele trei backend-uri — tag-uri imbricate greșit precum <b><i></b></i>, lipsa scheletului html/body, atribute fără ghilimele, tag-uri de închidere rămase singure, comentarii neînchise, formulare imbricate, litere mari/mici amestecate și altele. Toleranța bs4 este într-adevăr foarte bună peste tot; divergența este concentrată aproape exclusiv pe familia tag-urilor cu închidere opțională. Și nimic din toate acestea nu este o descoperire — documentația bs4 despre „Differences between parsers” spune deja, pe scurt, că html.parser este „less lenient”. Ce adaugă matricea de HTML stricat este setul specific, repetabil, de cazuri în care „mai puțin tolerant” devine ieșire greșită.
Ce nu pierzi: API-ul și CSS-ul sunt partea cea mai bună
Așadar, bs4 este lent, single-threaded și are o capcană în backend-ul implicit. Oamenii tot îl aleg, pentru că jumătatea „prietenoasă” a compromisului este cât se poate de reală — și rezistă la testare.
Am rulat 29 de verificări API care acoperă căutarea, CSS, navigarea în arbore, extragerea de text și modificarea DOM-ului. Toate 29 au trecut, iar rezultatul fiecărei probe a fost calculat comparând valoarea returnată cu o valoare așteptată, nu „din ochi”. Două dintre aceste capabilități sunt avantaje de ergonomie pe care parser-ele C pur și simplu nu le oferă:
- Predicat funcțional în
find/find_all. Poți scriesoup.find(lambda t: t.name == "a" and "btn" in t.get("class", []))și exprimi o condiție complexă într-o singură linie de Python — fără pasul în doi timpi „selectează tot, apoi filtrează”. - Navigare bidirecțională, cu nume clare.
.parent,.next_sibling,.find_parent,.stripped_strings,.descendants— parcurgerile se citesc aproape ca limba engleză și merg în ambele direcții. selectolax are nevoie de mai mulți pași pentru unele dintre acestea sau nu le oferă deloc.
Aceasta este partea care îți „cumpără timp de dezvoltare”, concret. Nu e marketing; sunt 29 de bifări verzi.
Două capcane de notat, pentru că un review corect le menționează pe ambele. Prima: atributele booleene — <input disabled> întoarce șirul gol "" pentru disabled în bs4 (selectolax întoarce None). Ambele valori sunt falsey, deci if node.get("disabled") ratează în tăcere un atribut boolean care există de fapt în ambele biblioteci — testul sigur este "disabled" in tag.attrs. A doua: get_text(strip=True) concatenează textul nodurilor fără separator după stripping, așa că "...with " + "link1" devine "withlink1". Când ai nevoie de limite între cuvinte, treci separator=" ". Niciuna dintre capcane nu este specifică bs4; ambele sunt probleme valabile în mai multe biblioteci.
Și acum partea care îi surprinde pe oameni: alegerea bs4 nu te costă acoperire CSS. Motorul său CSS, soupsieve, este cea mai completă implementare din întreaga comparație. Pe matricea de bază cu 41 de cazuri (reutilizată din rig-ul selectolax), soupsieve a obținut 41/41 — singurul scor perfect din test, peste 39/41 la selectolax-Lexbor și 37/41 la cssselect (lxml/parsel). Apoi am rulat încă 20 de cazuri extinse, pe care documentația soupsieve le promovează, și a obținut 20/20, inclusiv selectori pe care Lexbor îi refuză direct: :lang(en), pseudo-clasa specifică soupsieve :-soup-contains('featured'), :is(), :where() și :has(> a). Singurele lipsuri reale sunt XPath (soupsieve este doar CSS) și pseudo-elementele ::text / ::attr() din parsel, extensii Scrapy. Dacă trăiești în XPath, migrarea aceea te va durea.
Verdictul pentru această secțiune este clar: ceea ce sacrifici alegând BeautifulSoup este viteza. Nu este ergonomia API-ului și cu siguranță nu este acoperirea CSS.
Două probleme de producție pentru care merită să bugetezi
Dincolo de backend-ul implicit, două comportamente te vor lovi mai ales în workload-uri de lungă durată sau în cele care nu sunt UTF-8.
Cicluri de referință: apelează decompose() în bucle lungi
Fiecare Tag bs4 ține o referință către părinte și către copii, ceea ce creează un ciclu de referință. Numărarea prin referințe din CPython nu poate recupera singură un ciclu — asta este treaba garbage collector-ului generațional. Ca să văd cât contează asta, am construit și șters un arbore de 300 de ori cu GC dezactivat, apoi am numărat obiectele Tag rămase încă în memorie:
| Scenariu | Tag-uri reținute după del |
|---|---|
| GC oprit | 120,900 (300 cicluri, nimic recuperat) |
| GC pornit | 26,598 (GC-ul generațional a rulat în timpul buclei) |
După gc.collect() forțat | 0 (totul recuperat) |
| Grup de control fără ciclu (listă de șiruri, GC oprit) | delta 0 |
Cu GC oprit, del soup nu a recuperat nimic — toate cele 120.900 de obiecte au rămas în memorie, deoarece ciclul de referință învinge numărarea referințelor. Un singur gc.collect() le-a curățat pe toate. Grupul de control fără ciclu (o simplă listă de șiruri, despre care știm că nu are ciclu) a avut un delta de zero, ceea ce dovedește că acumularea a venit din ciclul bs4, nu din zgomotul măsurătorii. Propria documentație bs4 spune că obiectele sunt „densely interconnected ... exactly the sort a garbage collector would have trouble with”, deci acesta este un comportament documentat; testul adaugă numărul de obiecte reținute și dovada că collect() îl aduce la zero.
Regula practică: într-un pipeline care parsează multe pagini mari într-o buclă strânsă, dacă aplicația ta (sau vreun set de performanță mare) dezactivează GC-ul ori nu îl declanșează suficient de des, arborii bs4 vor rămâne agățați și memoria va crește. Apelează soup.decompose() după fiecare pagină — bs4 îl oferă exact pentru a rupe ciclul și a elibera memoria mai devreme. Arborii C din selectolax și lxml nu au deloc această problemă.
Codare: UnicodeDammit este avantajul tăcut al bs4
bs4 include o componentă pe care parser-ele rapide nu o au: UnicodeDammit, care detectează codarea unui document și îl convertește automat în Unicode. I-am dat o matrice de 8 cazuri „declared vs. actual charset”:
| Caz | Codare reală | UnicodeDammit a ghicit | Recuperat? |
|---|---|---|---|
| utf8_no_decl | utf-8 | utf-8 | Da |
| utf16_bom | utf-16 | utf-16le | Da |
| gbk_chinese | gbk | gb18030 | Da (superset) |
| shiftjis | shift_jis | cp932 | Da (superset) |
| latin1_declared_utf8 | latin-1 (declarat utf-8) | iso-8859-1 | Da (a ignorat minciuna) |
| latin1_no_decl | latin-1 | cp720 | Nu |
| cp1252_no_decl | cp1252 | cp862 | Nu |
| utf8_declared_latin1 | utf-8 (declarat latin-1) | iso-8859-1 | Nu (a urmat minciuna) |
Cinci din opt au fost recuperate. UTF-8, UTF-16 cu BOM, GBK, Shift-JIS și chiar latin-1 etichetat greșit au fost identificate corect, iar estimările de tip superset (GBK→gb18030, Shift-JIS→cp932) se decodează în continuare fără probleme. Cele două moduri de eșec merită cunoscute: eșantioanele scurte de bytes latin-1/cp1252 sunt confundate cu code page-uri DOS, pentru că detectorul statistic nu este fiabil pe intrări scurte, iar caracterele de tip box-drawing din DOS se suprapun cu punctele de cod din Latin-1; iar când o declarație <meta charset> este pur și simplu greșită, UnicodeDammit are încredere în acea declarație. Documentația bs4 indică ambele situații — o mostră poate fi „so short that Unicode, Dammit can't get a lock on it”, iar mai multe date înseamnă o estimare mai bună.
Față de selectolax, care corupe în tăcere bytes non-UTF-8 și se așteaptă să-i decodezi tu, acesta este un avantaj real: bs4 măcar încearcă să detecteze și de multe ori reușește. Dar nu este o garanție. Pentru o codare cunoscută, sari peste ghicit și fii explicit: BeautifulSoup(bytes, from_encoding="...").
Chiar diferă backend-urile pe pagini reale?
Matricea de HTML stricat arată că backend-urile diverg pe intrări intenționat corupte. Întrebarea firească este dacă asta contează în lumea reală, așa că am rulat toate cele trei backend-uri pe 11 pagini reale preluate — BBC, Wikipedia, Craigslist, MDN, old.reddit, documentația Python, Hacker News, Books to Scrape, webscraper.io, whitehouse.gov și o pagină de citate randată cu JS — comparând numărul de linkuri, headere și imagini.
Toate trei au fost de acord pe toate cele 11 pagini. Nicio divergență. Asta înseamnă că dezacordul dintre backend-uri din secțiunea capcană apare doar pe HTML intenționat stricat; când un site modern de producție este suficient de bine structurat — chiar și unul „dezordonat” — alegerea backend-ului nu schimbă ce extragi. Lecția practică: pentru site-uri mainstream, bine formate, html.parser este perfect acceptabil și îți economisește dependența. Doar când extragi HTML evident non-standard, scris manual sau foarte vechi, alegerea backend-ului începe să-ți modifice rezultatele, iar atunci treci la lxml sau html5lib.
Un detaliu interesant din acel test, fiindcă este un caz real de margine. Pagina MDN conține un element <template>, iar toate backend-urile bs4 au returnat 508 linkuri — ceea ce înseamnă că bs4 aplatizează conținutul din <template> în arborele principal. Asta îl pune pe bs4 de aceeași parte cu lxml și în opoziție cu selectolax-Lexbor, care respectă strict specificația HTML5 (un <template> este un DocumentFragment inert) și returnează 497, omițând în tăcere cele 11 linkuri din interiorul template-ului. Deci bs4 va captura date dintr-un <template> — util, dar și o modalitate de a prelua conținut „fantomă” pe care un browser nu l-ar afișa niciodată. Niciun comportament nu este greșit; sunt interpretări diferite ale specificației și trebuie să știi pe care o primești.
Unde se potrivește BeautifulSoup — și unde nu
În loc să comprimăm totul într-un singur scor 0–100 (ceea ce ar ascunde exact compromisurile care contează), iată un scor pe dimensiuni, cu o notă de precauție pe fiecare rând:
| Dimensiune | Ce au arătat testele | Precauție pentru cititor |
|---|---|---|
| Instalare / prima rulare | Doar wrapper, fără browser/setup; html.parser fără dependențe; toate wheel-urile sunt precompilate | Backend-ul lxml are nevoie de o dependență C |
| Viteză vs parser-ele C | de 12–17x mai lent (html.parser) / de 10.5–14x (backend lxml), pe toate dimensiunile | Un singur rig; date selectolax reutilizate |
| Throughput pentru interogări CSS | ~de 6–7.5x mai lent la 100k noduri; backend-ul lxml nu îl salvează | Date reutilizate; plătește taxa Python Tag |
| Memorie | 1.5–1.75x selectolax/lxml; cea mai mare | Date reutilizate; măsurată prin RSS |
| Cold start la import | de 2.36x mai lent (33.4 vs 14.1 ms) | Date reutilizate; componentă mică |
| Scalare cu thread-uri | bs4-lxml ~de 3.9x mai lent cu 4 thread-uri (ține GIL-ul) | O singură observație; folosește multiprocessing |
| Ergonomie API | 29/29 verificări; find cu predicat funcțional + navigare bidirecțională | Capcane: atribut boolean ca șir gol și granițe de cuvinte la strip |
| Acoperire CSS | soupsieve este cel mai bun: 41/41 bază + 20/20 extins; suportă :lang | Fără XPath, fără ::text |
| Toleranță pe 3 backend-uri | lxml/html5lib 15/15; html.parser 12/15 | Divergența apare doar pe HTML stricat |
| Consistență pe pagini reale | 3 backend-uri de acord 11/11; toate aplatizează <template> (508) | Pe site-uri bine formate, backend-ul nu contează |
| GC pe cicluri de referință | Arborele este un ciclu; 300 de bucle au reținut 120.900 de obiecte, iar collect le-a zeroat | Bucle lungi au nevoie de decompose() |
| Codare | UnicodeDammit recuperează 5/8; confundă mostre scurte, urmează declarații greșite | O singură observație |
| Mentenanță | Activă (4.15.0, iunie 2026); MIT | Găzduit pe crummy/Launchpad, nu pe GitHub |
Așadar, pentru cine este BeautifulSoup? Pentru oricine prețuiește o API lizibilă și parsarea tolerantă în locul throughput-ului brut, lucrând la volum moderat — prototipuri, scraping ocazional, tool-uri interne, echipe în care timpul de dezvoltare costă mai mult decât timpul de execuție. Cine ar trebui să caute altceva? Pipeline-uri de milioane de pagini, unde taxa de viteză se adună în cost real, workload-uri care au nevoie de paralelism la nivel de thread și oricine depinde de XPath.
O notă despre locul său într-un stack real de scraping și despre unde intervine propriul nostru tool. BeautifulSoup presupune că tu ai deja HTML-ul. Nu descarcă pagini, nu randază JavaScript și nu rezolvă apărarea anti-bot sau CAPTCHAs — asta este o altă sarcină, și una cu adevărat grea pe web-ul modern. Aici se află un API de scraping AI la un alt nivel: Thunderbit — stack-ul nostru pentru dezvoltatori, cu REST API, server MCP și CLI — se ocupă de fetch, randare JS și problema anti-bot, apoi returnează fie Markdown curat (POST /distill), fie JSON structurat conform schemei (POST /extract), fără să scrii deloc selectori. Cele două nu sunt concurente; sunt complementare. bs4 parsează HTML-ul pe care îl ai deja; API-ul, MCP-ul și CLI-ul Thunderbit îți obțin HTML-ul pe care nu-l poți ajunge ușor în primul rând. Dacă blocajul tău este parsarea, bs4 este un răspuns foarte bun. Dacă blocajul tău este obținerea datelor, atunci e vorba de un alt strat.
Încearcă Thunderbit pentru extragerea datelor web
Concluzia
BeautifulSoup îți oferă cea mai prietenoasă API, cea mai bună toleranță la HTML stricat și cel mai complet motor CSS din această comparație — cumpărate cu o taxă de viteză de aproximativ un ordin de mărime și cu cea mai mare amprentă de memorie. Acesta este întregul schimb, spus pe șleau. Backend-ul implicit html.parser este adevărata capcană: strică în tăcere tabelele și listele neînchise, așa că treci explicit "lxml" sau "html5lib" ori de câte ori intrarea ar putea fi urâtă. Thread-urile nu-l vor accelera — multiprocessing îl va accelera. Și în buclele de lungă durată, apelează decompose() pe fiecare pagină ca să nu se adune ciclurile de referință.
Două limitări de încheiere. Tot ce apare aici a fost măsurat pe o singură platformă (macOS arm64, Python 3.14, wheel-uri precompilate), iar multiplicatorii de timp sunt preluați din rig-ul selectolax (același benchmark, la data de 2026-07-13), nu rerulați — deci moștenesc limitarea acelei singure platforme, iar o configurație Linux x86_64 sau compilată din sursă ar putea schimba cifrele exacte. Și nimic din rezultate nu este o descoperire nouă: bs4 este o bibliotecă veche de 20 de ani, așa că orice comportament testat este fie documentat, fie deja public. Valoarea nu stă într-un „scoop”. Stă în a pune un număr real peste compromisuri pe care documentația le descrie doar calitativ.
Întrebări frecvente
Este BeautifulSoup lent?
Da, și se poate măsura. La o sarcină de tip parse-plus-extract rulează cam de 12–17x mai lent decât un parser C precum selectolax-Lexbor cu backend-ul implicit html.parser, și de 10.5–14x mai lent cu backend-ul lxml, pentru că construiește un obiect Python pentru fiecare nod. Dacă asta contează sau nu depinde de scară: la o pagină de 1 MB sunt 232 ms versus 15 ms, invizibil pentru câteva mii de pagini, dar decisiv pentru un pipeline de un milion de pagini.
Ce parser BeautifulSoup ar trebui să folosesc — html.parser, lxml sau html5lib?
Pentru site-uri bine formate și mainstream, parser-ul implicit html.parser este în regulă și nu adaugă dependențe. Dar nu implementează tag-urile de închidere opționale din HTML5, așa că pe tabele sau liste neînchise combină textul adiacent fără să dea eroare. Când intrarea poate fi stricată, scrisă manual sau veche, treci explicit "lxml" sau "html5lib" — ambele au obținut un 15/15 curat pe o matrice de HTML stricat, unde html.parser a obținut 12/15.
Poate BeautifulSoup să parseze în paralel cu thread-uri?
Nu. Construirea arborelui în bs4 este pur Python și ține GIL-ul, deci adăugarea de thread-uri îl face mai lent, nu mai rapid — în testare, patru thread-uri au rulat un parse de 1 MB cam de 3.9x mai lent decât un singur thread. Pentru paralelizarea bs4, folosește multiprocessing (ProcessPoolExecutor). Bibliotecile cu nucleu C, precum selectolax și lxml, sunt cele care beneficiază de paralelism la nivel de thread.
Se descurcă bine BeautifulSoup cu HTML stricat?
În linii mari, da — pe o gamă largă de mostre stricate (tag-uri imbricate greșit, lipsa scheletului, atribute fără ghilimele și altele), toate cele trei backend-uri s-au recuperat curat. Singurul punct slab este html.parser implicit și tag-urile cu închidere opțională: <td>/<li> neînchise sunt imbricate în loc să fie închise, corupând textul extras. Treci la backend-ul lxml sau html5lib, iar acea clasă de problemă dispare.
BeautifulSoup vs lxml — care e mai bun?
Sunt instrumente diferite. lxml este mult mai rapid atât la construirea arborelui, cât și la interogare, și suportă XPath. BeautifulSoup învelește lxml (printre altele) într-o API mult mai prietenoasă și are, de fapt, acoperire CSS mai largă prin soupsieve. Doar să nu te aștepți ca backend-ul lxml să facă bs4 la fel de rapid ca lxml — backend-ul accelerează doar parsarea, în timp ce interogările și traversarea continuă să plătească costul obiectelor Python per nod din bs4, ceea ce îl lasă cam de 6–7.5x mai lent la selecții mari în lot.
Încearcă Thunderbit pentru extragerea datelor web Get Started Free
