Python में जब लोग पहली बार किसी web page को scrape करते हैं, तो ज़्यादातर BeautifulSoup ही चुनते हैं, और सच यह है कि serious HTML parsers में यह सबसे धीमा भी है। ये दोनों बातें सही हैं, और इनमें से कोई भी आलोचना नहीं है। दिलचस्प बात यह है कि “सबसे धीमा” आखिरकार एक ठोस, मापी जा सकने वाली संख्या है — बस एक feeling नहीं।
मैंने bs4 (यानी beautifulsoup4, version 4.15.0, June 2026 में जारी, MIT-licensed) को capability tests के नए set और उसी benchmark rig के reused timing data के साथ परखा। नतीजा साफ़ है: आप लगभग 10x की speed penalty के बदले सबसे friendly API और field की सबसे मजबूत error tolerance पाते हैं। यह trade-off समझदारी भरा है या नहीं, यह पूरी तरह आपके workload पर निर्भर करता है — इसलिए यह review दोनों पहलुओं को साथ रखता है।
BeautifulSoup असल में क्या है — और क्या नहीं है
अधिकांश tutorials सबसे महत्वपूर्ण बात छोड़ देते हैं: BeautifulSoup HTML parse नहीं करता। यह एक wrapper है। अंदर से यह आपके document को तीन real parsers में से किसी एक के पास भेजता है — Python का built-in html.parser, lxml, या html5lib — और फिर उनके बनाए tree को एक ही, बहुत user-friendly navigation और search API में लपेट देता है। bs4 का काम parsing नहीं है। इसका काम result को आसानी से घूमने-फिरने लायक बनाना है।
इसके अपने author इसे “screen-scraping library” कहते हैं, और इसका मूल वादा हमेशा यही रहा है: HTML को ऐसे pages पर भी point करो जो browser को भी असहज कर दें, और यह फिर भी आपके माँगे हुए data को निकाल लेगा। यह reputation कमाई हुई है — एक छोटी-सी शर्त के साथ, जिस पर हम आगे आएँगे।
आगे बढ़ने से पहले कुछ महत्वपूर्ण तथ्य:
| Field | Value |
|---|---|
| Package | beautifulsoup4 (import as bs4) |
| Tested version | 4.15.0 (uploaded 2026-06-07) |
| Python requirement | >=3.7.0 |
| License | MIT |
| Canonical home | crummy.com/software/BeautifulSoup |
| Source + bug tracker | Launchpad — not GitHub |
| Maintenance | Active (4.15.0 in June 2026, six releases in the past year) |
यह “not GitHub” वाली बात जितनी दिखती है उससे ज़्यादा मायने रखती है। bs4 एक 20 साल पुरानी library है जो crummy.com और Launchpad पर रहती है, इसलिए सामान्य GitHub star-count वाली health check यहाँ लागू नहीं होती। इसकी health release cadence से आँकिए, और उस कसौटी पर यह बिल्कुल active और healthy है।
Licensing पर एक बारीक लेकिन ज़रूरी बात, खासकर अगर आपको compliance team को जवाब देना पड़ता है: wrapper तो MIT है, लेकिन bs4 इस्तेमाल करने पर आपकी dependency tree में क्या आएगा, यह इस बात पर निर्भर करता है कि आप कौन-सा backend install करते हैं। html.parser Python standard library का हिस्सा है (PSF license, कोई extra dependency नहीं)। lxml BSD है, लेकिन यह libxml2/libxslt पर टिकता है — एक external C dependency जिसे आप या तो compile करते हैं या prebuilt wheel के रूप में लेते हैं। html5lib pure Python है और MIT licensed है। अगर आपको सबसे साफ़ dependency footprint चाहिए, तो built-in html.parser वह सुविधा देता है — और यही, संयोग से, सबसे बड़ा catch भी है। आगे समझते हैं।
Speed Tax, मापी हुई
पहले सीधे number रख देते हैं, क्योंकि यही headline है और इसे छिपाना ईमानदारी नहीं होगी। एक realistic parse-then-extract task पर — string parse करना, हर <h3 class="title"> और हर <a href> निकालना — BeautifulSoup इस comparison में सबसे धीमा parser है, और काफ़ी पीछे।
ये timings selectolax benchmark rig से reused हैं (same machine, same 3-run methodology, as-of 2026-07-13); यह review CPU contention और duplicated work से बचने के लिए अपनी तरफ से कोई timing benchmark दोबारा नहीं चलाता। Median p50 latency, milliseconds में:
| Page size | bs4 (html.parser) | bs4 (lxml) | selectolax-Lexbor | lxml | bs4-hp slower | bs4-lxml slower |
|---|---|---|---|---|---|---|
| 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 |
इसलिए bs4(html.parser) selectolax-Lexbor जैसे C parser से लगभग 12–17x धीमा चलता है, और lxml backend लगाने पर भी यह सिर्फ 10.5–14x तक वापस आता है — यानी अब भी पूरे एक order of magnitude पीछे। वजह structural है, bug नहीं: backend कोई भी parsing करे, bs4 हर single node के लिए एक complete Python object (Tag या NavigableString) बनाता है। यही object-materialization layer वह tax है जो C parsers नहीं चुकाते।
ध्यान दें multiplier pages बड़े होने के साथ बढ़ता है — 1 KB पर 12.0x, 10 MB पर 17.4x। इसका मतलब यह fixed startup overhead नहीं है जिसे आप amortize कर सकें। यह per-node tax है जो nodes की संख्या के साथ linearly बढ़ता है।
अब इसे दूसरे नज़रिए से देखें, क्योंकि “10x slower” अक्सर जितना डरावना लगता है, उतना होता नहीं। 1 MB page पर बात 232 ms बनाम 15 ms की है। अगर आपका काम “कुछ सौ से लेकर कुछ हज़ार pages scrape करना है, और हर page कुछ सौ KB का है,” तो यह absolute फर्क practically महसूस नहीं होगा — इसे optimize करने से आपको कोई real फायदा नहीं मिलेगा। लेकिन अगर आपका काम million-page pipeline है, तो यही ratio job के पूरा होने और न होने का फर्क बन जाता है। एक ही number, लेकिन verdict बिल्कुल उल्टा। Benchmarks नहीं, अपनी actual volume के हिसाब से फैसला करें।
नहीं, backend बदलने से समस्या खत्म नहीं होती
एक आम myth है कि बस bs4 को lxml backend दे दीजिए और आपको lxml जैसी speed मिल जाएगी। ऐसा नहीं है, और वजह समझना ज़रूरी है। 100,000-node batch CSS query पर (हर <a> को select करके उसका href पढ़ना, tree पहले से बना हुआ है), throughput का अंतर साफ़ दिखता है:
| Parser | Query p50 | Nodes/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) लगभग 399,000 nodes/second तक पहुँचता है — यानी बाकी तीन C engines से लगभग 6.3–7.5x धीमा, जबकि उसका अपना backend lxml ही है। Backend tree building को तेज़ करता है। Querying और traversal फिर भी soupsieve और bs4 Tag objects के रास्ते से होते हैं, और हर matched node Python object में लपेटी जाती है। इसलिए यह सोचना गलत है कि “bs4 को lxml दो और यह lxml जितना तेज़ हो जाएगा।” Backend सिर्फ़ एक चरण तेज़ करता है, और सबसे धीमा चरण वह नहीं है।
Memory और cold start भी इस लागत को पूरा करते हैं। 10 MB document पर bs4, selectolax या lxml की तुलना में लगभग 1.5–1.75x अधिक resident memory इस्तेमाल करता है (218–226 MB बनाम 129–145 MB) — वही मूल वजह, हर node पर एक Python object। और bs4 import करने में लगभग 33.4 ms लगते हैं, जबकि lxml.html में 14.1 ms — यानी import 2.36x धीमा है। लंबे-running process में यह छोटी बात लग सकती है, लेकिन CLI tool या serverless function के लिए, जहाँ cold start बार-बार होता है, यह एक छोटा लेकिन असली cost है।
ज़्यादा threads मदद नहीं करेंगे
अगर धीमे CPU-bound task पर आपकी पहली सोच होती है “इसमें threads डाल दो,” तो bs4 उस आदत को punish करेगा। 1 MB page को 48 बार parse करने पर, single-threaded बनाम four threads:
| Parser | 1 thread | 4 threads | Speedup |
|---|---|---|---|
| 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 |
नीचे वाली row दो बार पढ़िए। चार threads ने bs4 को लगभग 3.9x धीमा कर दिया, तेज़ नहीं। Empirical signal यह है कि यह शायद GIL को hold करता है: bs4 की tree construction pure Python है, इसलिए यह Global Interpreter Lock के अंदर serialize हो जाती है, और threads जोड़ने से ऐसे काम में सिर्फ़ scheduling overhead बढ़ता है जो parallel चल ही नहीं सकता। selectolax अपने C core के कारण lock छोड़ देता है, इसलिए उसे लगभग 3.5x speedup मिलता है; bs4 के पास ऐसी गुंजाइश नहीं।
Free-threading युग के लिए व्यावहारिक takeaway यह है: अगर आपको BeautifulSoup को parallelize करना है, तो threads की जगह multiprocessing (ProcessPoolExecutor) लें। selectolax और lxml threads पर scale कर सकते हैं; bs4 नहीं। एक note on rigor — यह एक ही observation है, एक ही thread count (4) पर, एक ही page size (1 MB) के साथ, और “holds the GIL” वाला mechanism wall-clock behavior से निकाला गया hypothesis है, न कि किसी instrumented proof से। दिशा साफ़ है; exact mechanism अभी provisional है।
Default backend ही असली trap है — इसे पहले पढ़ें
इस review से एक ही बात लें, तो यह लें। बिना दूसरे argument के किया गया BeautifulSoup(html) default रूप से html.parser इस्तेमाल करता है, और html.parser HTML5 के optional-end-tag rules implement नहीं करता। यह academic सा लग सकता है, जब तक यह silently आपका data खराब न करने लगे।
मैंने 15 deliberately malformed HTML samples को तीनों backends पर चलाया, और हर sample के लिए पहले से backend-agnostic structural assertion तय किया था (ताकि बाद में कोई winner चुनने का मौका न रहे)। Scores यह रहे:
| Backend | Meets expectation / 15 |
|---|---|
| lxml | 15 |
| html5lib | 15 |
| html.parser | 12 |
तीनों failures का root cause एक ही है। एक unclosed table लें: <table><tr><td>a<td>b<tr><td>c<td>d</table>. html.parser के नीचे extracted cell text ['abcd','bcd','cd','d'] आता है — हर <td> अपने बाद का सब कुछ swallow कर लेता है, क्योंकि parser cells को बंद करने की जगह nested बना देता है। lxml और html5lib सही तरीके से ['a','b','c','d'] लौटाते हैं। Bare list items भी यही करते हैं: <li>a<li>b<li>c html.parser में nested ['abc','bc','c'] देता है, जबकि बाकी दो साफ़ ['a','b','c'] देते हैं। Duplicate attributes भी flip हो जाते हैं — <div id="first" id="second"> html.parser में "second" रखता है, जबकि lxml/html5lib "first" रखते हैं, और HTML5 spec पहले attribute को रखने को कहता है।
यह सिर्फ़ irritating नहीं, बल्कि dangerous क्यों है: क्योंकि यह बिना error उठाए होता है। जो scraper casually BeautifulSoup(html) इस्तेमाल करता है और unclosed table या list पर पहुँचता है — जो पुराने sites, hand-written HTML, और closing tag भूल जाने वाले templates में दुखद रूप से आम है — वह adjacent cell text को एक field में मिला देगा, dirty data देगा, और एक बार भी शिकायत नहीं करेगा। Fix सिर्फ़ एक argument है: BeautifulSoup(html, "lxml") या BeautifulSoup(html, "html5lib")।
html.parser के साथ निष्पक्षता यह है कि बाकी 12 में से 15 malformed samples तीनों backends पर एक जैसे निकले — mis-nested tags जैसे <b><i></b></i>, missing html/body skeletons, unquoted attributes, orphaned closing tags, unclosed comments, nested forms, mixed case, और भी बहुत कुछ। bs4 की tolerance वाकई बहुत मजबूत है; divergence लगभग पूरी तरह optional-end-tag family में केंद्रित है। और यह कोई नई खोज भी नहीं है — bs4 की अपनी “Differences between parsers” documentation पहले से साफ़ कहती है कि html.parser “less lenient” है। Malformed matrix जो जोड़ती है, वह हैं वे specific, reproducible cases जहाँ “less lenient” का मतलब गलत output बन जाता है।
आप क्या नहीं खोते: API और CSS, दोनों इसकी सबसे बड़ी ताकत हैं
तो bs4 धीमा है, single-threaded है, और default-backend trap है। इसके बावजूद लोग इसे चुनते हैं, क्योंकि इसका “friendly” हिस्सा पूरी तरह real है — और test में भी टिकता है।
मैंने search, CSS, tree navigation, text extraction, और DOM modification को कवर करने वाले 29 API probes चलाए। सभी 29 पास हुए, और हर result actual return value को expected value से compare करके तय किया गया — अंदाज़े से नहीं। इनमें से दो capabilities ऐसी हैं जो C parsers आम तौर पर नहीं देते:
find/find_allमें function predicates. आपsoup.find(lambda t: t.name == "a" and "btn" in t.get("class", []))जैसा code लिखकर एक ही Python line में complex condition express कर सकते हैं — “सब कुछ select करो, फिर filter करो” वाला दो-चरणीय झंझट नहीं।- Named, bidirectional tree navigation.
.parent,.next_sibling,.find_parent,.stripped_strings,.descendants— traversal अंग्रेज़ी की तरह पढ़ता है और दोनों directions में चलता है। selectolax इनमें से कुछ के लिए कई steps मांगता है, या देता ही नहीं।
यही वह हिस्सा है जो developer time बचाता है। Marketing नहीं, 29 green checks का नतीजा है।
दो traps भी ध्यान रखने लायक हैं, क्योंकि fair review दोनों तरफ़ देखता है। पहला, boolean attributes: <input disabled> bs4 में disabled के लिए empty string "" लौटाता है (selectolax None लौटाता है)। दोनों falsy हैं, इसलिए if node.get("disabled") logic silently उस boolean attribute को miss कर सकता है जो असल में मौजूद है — safe test है "disabled" in tag.attrs। दूसरा, get_text(strip=True) stripping के बाद node text को बिना separator के जोड़ देता है, इसलिए "...with " + "link1" मिलकर "withlink1" बन सकता है। शब्दों के बीच boundary चाहिए हो तो separator=" " दें। ये traps bs4-specific नहीं हैं; दोनों cross-library gotchas हैं।
और अब वह बात जो अक्सर लोगों को चौंकाती है: bs4 चुनने से आपकी CSS coverage कम नहीं होती। इसका CSS engine, soupsieve, इस पूरे comparison में सबसे complete implementation है। 41-case base matrix पर (selectolax rig से reused) soupsieve ने 41/41 score किया — field में अकेला perfect score, selectolax-Lexbor के 39/41 और cssselect (lxml/parsel) के 37/41 से आगे। फिर मैंने soupsieve docs में advertised 20 additional extended cases चलाए, और यह 20/20 निकला — उन selectors सहित जिन्हें Lexbor सीधा reject कर देता है: :lang(en), soupsieve-only :-soup-contains('featured'), :is(), :where(), और :has(> a)। असली gaps सिर्फ़ XPath हैं (soupsieve CSS-only है) और parsel के ::text / ::attr() pseudo-elements, जो Scrapy extensions हैं। अगर आपका workflow XPath पर टिका है, तो migration आपको चुभेगा।
इस section का verdict साफ़ है: BeautifulSoup चुनकर आप speed छोड़ते हैं। आप API ergonomics नहीं छोड़ते, और CSS coverage तो बिल्कुल नहीं।
Production में ध्यान रखने लायक दो और pitfalls
Default backend के अलावा, दो व्यवहार लंबे-running या non-UTF-8 workloads में खास तौर पर परेशानी देंगे।
Reference Cycles: लंबे loops में decompose() चलाइए
हर bs4 Tag अपने parent को भी reference करता है और children को भी, जिससे एक reference cycle बनती है। CPython का reference counting अकेले ऐसी cycle को reclaim नहीं कर सकता — यह generational garbage collector का काम है। यह समझने के लिए कि यह कितना मायने रखता है, मैंने GC बंद करके tree को 300 बार build और delete किया, फिर memory में बचे हुए Tag objects गिने:
| Scenario | Tags retained after del |
|---|---|
| GC off | 120,900 (300 cycles, nothing reclaimed) |
| GC on | 26,598 (generational GC fired mid-loop) |
After forced gc.collect() | 0 (all reclaimed) |
| No-cycle control (list of strings, GC off) | delta 0 |
GC off होने पर del soup ने कुछ भी reclaim नहीं किया — सभी 120,900 objects resident रहे, क्योंकि reference cycle reference counting को मात दे देती है। एक gc.collect() ने हर एक object साफ़ कर दिया। No-cycle control group (strings की plain list, जिसमें cycle नहीं होती) का delta zero रहा, जिससे साबित होता है कि buildup bs4 की cycle से आया, measurement noise से नहीं। bs4 की अपनी docs भी कहती हैं कि objects “densely interconnected ... exactly the sort a garbage collector would have trouble with” होते हैं — यानी यह documented behavior है; इस test ने retained-object count और collect() के zero-out करने का proof दिया है।
व्यावहारिक नियम यह है: अगर आप किसी pipeline में कई बड़े pages tight loop में parse कर रहे हैं, और आपका code (या कोई high-throughput setting) GC को disable कर देता है या पर्याप्त बार trigger नहीं करता, तो bs4 trees लटकते रहेंगे और memory बढ़ती जाएगी। हर page के बाद soup.decompose() चलाइए — bs4 ने इसे इसी cycle को तोड़कर early reclaim के लिए दिया है। selectolax और lxml के C trees में यह समस्या नहीं होती।
Encoding: bs4 का शांत लेकिन असली फायदा UnicodeDammit है
bs4 एक ऐसा component साथ लाता है जो तेज़ parsers नहीं देते: UnicodeDammit, जो document की encoding पहचानकर उसे automatically Unicode में बदल देता है। मैंने इसे “declared vs. actual charset” वाले 8-case matrix पर चलाया:
| Case | True encoding | UnicodeDammit guessed | Recovered? |
|---|---|---|---|
| utf8_no_decl | utf-8 | utf-8 | Yes |
| utf16_bom | utf-16 | utf-16le | Yes |
| gbk_chinese | gbk | gb18030 | Yes (superset) |
| shiftjis | shift_jis | cp932 | Yes (superset) |
| latin1_declared_utf8 | latin-1 (declared utf-8) | iso-8859-1 | Yes (ignored the lie) |
| latin1_no_decl | latin-1 | cp720 | No |
| cp1252_no_decl | cp1252 | cp862 | No |
| utf8_declared_latin1 | utf-8 (declared latin-1) | iso-8859-1 | No (followed the lie) |
आठ में से पाँच सही recovery हुई। UTF-8, UTF-16 with BOM, GBK, Shift-JIS, और यहाँ तक कि गलत label वाला latin-1 भी सही निकला, और superset guesses (GBK→gb18030, Shift-JIS→cp932) फिर भी ठीक decode हो गए। दो failure modes जानना ज़रूरी है: छोटे latin-1/cp1252 byte samples अक्सर DOS code pages के रूप में गलत पहचाने जाते हैं, क्योंकि short inputs पर statistical detector भरोसेमंद नहीं होता और DOS box-drawing characters Latin-1 के code points से overlap करते हैं; और जब <meta charset> declaration ही गलत हो, UnicodeDammit उसी declaration पर भरोसा कर लेता है। bs4 की docs दोनों बातों को बताती हैं — sample इतना छोटा हो सकता है कि Unicode, Dammit “can’t get a lock on it,” और ज़्यादा data better guess देती है।
selectolax के मुकाबले, जो non-UTF-8 bytes को silently corrupt कर सकता है और आपसे पहले ही decode करने की उम्मीद करता है, यह एक वास्तविक advantage है: bs4 कम-से-कम sniff करने की कोशिश करता है और अक्सर सफल भी होता है। लेकिन यह guarantee नहीं है। ज्ञात encoding हो, तो guess मत कीजिए — साफ़-साफ़ बताइए: BeautifulSoup(bytes, from_encoding="...")।
क्या real pages पर backends सच में अलग होते हैं?
Malformed matrix से पता चलता है कि deliberately broken input पर backends अलग व्यवहार कर सकते हैं। अगला obvious सवाल यह है कि क्या यह दुनिया में भी मायने रखता है, इसलिए मैंने तीनों backends को 11 real fetched pages — BBC, Wikipedia, Craigslist, MDN, old.reddit, Python docs, Hacker News, Books to Scrape, webscraper.io, whitehouse.gov, और एक JS-rendered quotes page — पर चलाया और link, heading, तथा image counts की तुलना की।
सभी 11 pages पर तीनों सहमत रहे। Zero divergence। इसका मतलब यह है कि trap section में दिखा backend disagreement केवल deliberately malformed HTML पर आता है; जब कोई modern production site पर्याप्त अच्छी तरह structured हो — भले थोड़ा messy ही क्यों न हो — backend का चुनाव आपके extracted data को नहीं बदलता। Practical मतलब: mainstream, well-formed sites के लिए html.parser बिल्कुल ठीक है और dependency बचाता है। लेकिन जब आप visibly non-standard, hand-written, या बहुत पुराने HTML को scrape कर रहे हों, तभी backend choice परिणाम बदलना शुरू करता है — और तब आपको lxml या html5lib की ओर जाना चाहिए।
उस run से एक और खास edge case: MDN page में <template> element है, और bs4 के सभी backends ने 508 links लौटाए — यानी bs4 <template> की contents को main tree में flatten कर देता है। इस मामले में bs4, lxml के साथ एक ही side पर है, और selectolax-Lexbor के विपरीत, जो HTML5 spec को सख्ती से follow करता है (<template> एक inert DocumentFragment है) और 497 links लौटाता है, template के अंदर की 11 links को silently drop कर देता है। इसलिए bs4 <template> के अंदर का data पकड़ लेगा — उपयोगी भी है, लेकिन इससे ऐसे “phantom” content भी आ सकते हैं जिन्हें browser कभी render ही नहीं करता। दोनों behaviors गलत नहीं हैं; वे अलग spec interpretations हैं, और आपको पता होना चाहिए कि आपको कौन-सा मिल रहा है।
BeautifulSoup कहाँ फिट बैठता है — और कहाँ नहीं
इन सब बातों को एक 0–100 score में समेट देने से (जो ठीक उन्हीं trade-offs को छिपा देगा जो सबसे ज़्यादा मायने रखते हैं), यहाँ dimension-level scorecard है, हर row के साथ एक caveat भी:
| Dimension | What the tests found | Reader caveat |
|---|---|---|
| Install / first run | Pure wrapper, no browser/setup; html.parser zero-dep; all prebuilt wheels | lxml backend needs a C dependency |
| Speed vs C parsers | 12–17x slower (html.parser) / 10.5–14x (lxml backend), all sizes | Single rig; reused selectolax data |
| CSS query throughput | ~6–7.5x slower on 100k nodes; lxml backend doesn't rescue it | Reused; pays the Python Tag tax |
| Memory | 1.5–1.75x selectolax/lxml; heaviest | Reused; measured by RSS |
| Import cold start | 2.36x slower (33.4 vs 14.1 ms) | Reused; small item |
| Thread scaling | bs4-lxml ~3.9x slower at 4 threads (holds GIL) | Single observation; use multiprocessing |
| API ergonomics | 29/29 probes; function-predicate find + bidirectional nav | Empty-string bool-attr and strip word-boundary traps |
| CSS coverage | soupsieve strongest: 41/41 base + 20/20 extended; supports :lang | No XPath, no ::text |
| 3-backend tolerance | lxml/html5lib 15/15; html.parser 12/15 | Divergence only on malformed HTML |
| Real-page consistency | 3 backends agree 11/11; all flatten <template> (508) | Well-formed sites: backend doesn't matter |
| Reference-cycle GC | Tree is a cycle; 300 loops retained 120,900 objects, collect zeroed it | Long loops need decompose() |
| Encoding | UnicodeDammit recovers 5/8; misjudges short samples, follows bad declarations | Single observation |
| Maintenance | Active (4.15.0, June 2026); MIT | Home on crummy/Launchpad, not GitHub |
तो BeautifulSoup किसके लिए है? उन लोगों के लिए जो raw throughput से ज़्यादा readable API और forgiving parsing को महत्व देते हैं, और moderate volume पर काम करते हैं — prototypes, one-off scrapes, internal tools, और वे teams जहाँ developer time runtime से महँगा है। किसे कहीं और देखना चाहिए? Million-page pipelines, जहाँ speed tax असली पैसे में बदल जाती है; वे workloads जिन्हें thread-level parallelism चाहिए; और वे लोग जो XPath से बँधे हुए हैं।
एक note यह भी कि यह real scraping stack में कहाँ फिट बैठता है, और हमारा अपना tool कहाँ आता है। BeautifulSoup मानकर चलता है कि आपके पास HTML पहले से है। यह pages fetch नहीं करता, JavaScript render नहीं करता, और anti-bot defenses या CAPTCHAs से निपटता नहीं है — वह बिलकुल अलग काम है, और modern web पर सचमुच कठिन भी। यहीं AI scraping API एक अलग layer पर बैठती है: Thunderbit का developer stack — एक REST API, एक MCP server, और एक CLI — fetch, JS rendering, और anti-bot problem को संभालता है, फिर बिना आपके selectors लिखे साफ़ Markdown (POST /distill) या schema-matched structured JSON (POST /extract) लौटाता है। ये दोनों competitors नहीं, complementary हैं। bs4 उस HTML को parse करता है जो आपके पास पहले से है; Thunderbit का API, MCP, और CLI वह HTML लाते हैं जिसे पहली बार हासिल करना आसान नहीं होता। अगर आपकी bottleneck parsing है, तो bs4 एक बढ़िया जवाब है। अगर bottleneck acquisition है, तो वह दूसरी layer है।
वेब डेटा extraction के लिए Thunderbit आज़माएँ
निष्कर्ष
BeautifulSoup आपको सबसे सहज API, सबसे मजबूत malformed-HTML tolerance, और इस comparison में सबसे complete CSS engine देता है — लेकिन कीमत है लगभग एक order-of-magnitude speed tax और सबसे भारी memory footprint। यही पूरा trade-off है, साफ़-साफ़ कहा जाए तो। Default html.parser backend ही असली trap है: यह unclosed tables और lists को silently बिगाड़ देता है, इसलिए जब भी input ugly हो सकता हो, "lxml" या "html5lib" pass करें। Threads इसे तेज़ नहीं करेंगे — multiprocessing करेगी। और लंबे loops में हर page के बाद decompose() चलाइए, ताकि reference cycles इकट्ठी न हों।
समापन पर दो सीमाएँ। यहाँ सब कुछ एक ही platform (macOS arm64, Python 3.14, prebuilt wheels) पर मापा गया, और timing multipliers selectolax rig से reused हैं (same bench, as-of 2026-07-13) — यानी वही single-platform limitation inherited है, और Linux x86_64 या source-compiled setup exact figures को थोड़ा बदल सकता है। और इन results में कोई नई खोज भी नहीं है: bs4 एक 20 साल पुरानी library है, इसलिए हर tested behavior या तो documented है या publicly recorded। Value कोई scoop नहीं है। Value यह है कि docs जिन trade-offs को सिर्फ़ qualitative तौर पर बताते हैं, उनके लिए एक वास्तविक number देना।
अक्सर पूछे जाने वाले सवाल
क्या BeautifulSoup धीमा है?
हाँ, और यह मापा जा सकता है। parse-plus-extract task पर यह default html.parser backend के साथ selectolax-Lexbor जैसे C parser से लगभग 12–17x धीमा चलता है, और lxml backend के साथ 10.5–14x, क्योंकि यह हर node के लिए Python object बनाता है। इसका महत्व आपके scale पर निर्भर है: 1 MB page पर यह 232 ms बनाम 15 ms है — कुछ हज़ार pages के लिए नगण्य, लेकिन million-page pipeline के लिए निर्णायक।
मुझे कौन-सा BeautifulSoup parser इस्तेमाल करना चाहिए — html.parser, lxml, या html5lib?
Well-formed, mainstream sites के लिए default html.parser ठीक है और कोई dependency नहीं जोड़ता। लेकिन यह HTML5 optional-end-tags implement नहीं करता, इसलिए unclosed tables या lists पर यह adjacent text को बिना error दिए मिला सकता है। जब input malformed, hand-written, या पुराना हो सकता है, तब "lxml" या "html5lib" explicitly दें — दोनों ने malformed-HTML matrix पर साफ़ 15/15 score किया, जबकि html.parser 12/15 पर रहा।
क्या BeautifulSoup threads के साथ parallel चल सकता है?
नहीं। bs4 की tree building pure Python है और GIL को hold करती है, इसलिए threads जोड़ने से यह तेज़ नहीं, बल्कि धीमा हो जाता है — testing में चार threads ने 1 MB parse को एक thread की तुलना में लगभग 3.9x धीमा किया। bs4 को parallel करने के लिए multiprocessing (ProcessPoolExecutor) इस्तेमाल करें। selectolax और lxml जैसे C core वाले libraries thread-level parallelism का फायदा उठाते हैं।
क्या BeautifulSoup broken HTML को अच्छी तरह संभालता है?
कुल मिलाकर हाँ — malformed samples की एक range (mis-nested tags, missing skeletons, unquoted attributes, और बहुत कुछ) में तीनों backends ने साफ़ recovery दिखाई। एक कमजोर जगह default html.parser और optional-end-tags हैं: unclosed <td>/<li> cells को बंद करने के बजाय nested कर देता है, जिससे extracted text खराब हो जाता है। lxml या html5lib backend पर जाएँ, और यह समस्या दूर हो जाती है।
BeautifulSoup बनाम lxml — कौन बेहतर है?
ये अलग tools हैं। lxml tree building और querying दोनों में बहुत तेज़ है, और XPath support करता है। BeautifulSoup, lxml सहित अन्य parsers को बहुत user-friendly API में लपेटता है और soupsieve के ज़रिए CSS coverage भी ज़्यादा broad देता है। बस यह उम्मीद न करें कि lxml backend bs4 को lxml-जैसा तेज़ बना देगा — backend सिर्फ़ parsing तेज़ करता है, जबकि queries और traversal अभी भी bs4 की per-node Python object cost चुकाते हैं, इसलिए बड़े batch selections पर यह लगभग 6–7.5x धीमा रहता है।
वेब डेटा extraction के लिए Thunderbit आज़माएँ Get Started Free
