Setiap artikel tentang "parser HTML Python tercepat" hampir selalu menyebut selectolax, dan biasanya cerita itu ditutup dengan kesimpulan "jauh lebih cepat daripada BeautifulSoup." Bagian itu memang benar. Yang sering tidak dijelaskan sampai tuntas adalah apa yang terjadi saat selectolax dibandingkan langsung dengan lxml — karena di situ, label "tercepat" perlu diberi tanda bintang.
Jadi saya mengujinya dengan benar: selectolax (kedua backend-nya) melawan lxml, BeautifulSoup dengan html.parser dan lxml, serta parsel, pada lima ukuran halaman dari 1 KB sampai 10 MB, dengan setiap hasil diambil sebagai median dari tiga kali eksekusi proses terpisah. Hasilnya: selectolax jauh mengungguli BeautifulSoup dan setara dengan lxml dalam skenario penuh — tetapi kalah pada langkah parsing murni dari lxml. Semua angka di bawah ini masih bersifat sementara dan berasal dari satu mesin saja (macOS arm64, Python 3.14.2); skripnya sudah saya commit, jadi jalankan di mesin Anda sendiri sebelum mengutip hasil saya.
Apa sebenarnya selectolax itu (dan apa yang bukan)
selectolax adalah binding Python untuk dua mesin C — Modest dan Lexbor — yang mem-parse HTML5 lalu memungkinkan kita melakukan query dengan CSS selector. Ini bukan crawler, bukan browser, dan bukan "scraper" dalam arti klik tombol lalu beres. Ini adalah komponen yang Anda berikan blob HTML setelah halaman berhasil diambil. Satu kalimat dari maintainer-nya adalah: "A fast HTML5 parser with CSS selectors, written in Cython, using Modest and Lexbor engines."
Ada dua backend, dan perbedaannya lebih penting daripada yang terlihat di dokumentasi:
LexborHTMLParser(engine Lexbor) — yang direkomendasikan README untuk dipakai mulai 2024.HTMLParser(engine Modest) — backend awal, dengan pustaka C di bawahnya yang menurut README tersebut "sudah tidak dipelihara lagi."
Ada beberapa hal yang patut diketahui sebelum bicara soal kecepatan. Berdasarkan snapshot repo per 2026-07-10, selectolax memiliki 1.653 bintang dengan rilis terbaru v0.4.10 (Mei 2026), dan PyPI menetapkan dukungan Python >=3.9,<3.15. Instalasinya adalah bagian paling tidak dramatis dari seluruh review ini: pip install selectolax mengunduh wheel prebuilt cp314 berukuran 2,3 MB dan langsung berjalan di Python 3.14 — tanpa download browser, tanpa langkah doctor, tanpa kompilasi. Itulah keunggulan tenang dari parser murni dibanding alat berbasis browser. Cukup di-import, lalu langsung jalan.
Ada satu catatan lisensi yang perlu disampaikan sejak awal: binding Python-nya MIT, tetapi wheel tersebut membawa engine yang sudah dibundel, dan masing-masing punya lisensi sendiri — Modest menggunakan LGPL-2.1, Lexbor menggunakan Apache-2.0. Jadi, kalimat "selectolax itu MIT" benar untuk kode Python-nya, tetapi belum lengkap untuk binary yang benar-benar Anda distribusikan. Kalau tim legal Anda peduli pada komponen yang ikut didistribusikan, inilah detail yang perlu ditandai.
Pertanyaan soal kecepatan, dijawab dengan angka nyata
Tugas yang saya ukur adalah: parse string HTML, ambil semua teks <h3 class="title">, lalu ambil semua href dari <a>. Latensi median dalam milidetik, diambil dari median tiga proses terpisah; variasi antarrun tetap di bawah ~5% untuk parser berbasis C pada sebagian besar ukuran. Sebelum setiap sel diukur, output tiap parser saya reduksi menjadi content hash agar parser yang diam-diam mengerjakan lebih sedikit bisa ketahuan dan dikeluarkan — pada halaman-halaman ini, keenamnya cocok di semua ukuran, jadi ini benar-benar perbandingan yang adil. Data lengkap ada di bench_parse.json yang sudah dikomit.
| Halaman | 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 |
Dibanding BeautifulSoup: sekitar 12-17x, dan angka yang beredar justru meremehkannya
Kalau angka itu diubah menjadi rasio, selectolax-Lexbor terlihat ~12x lebih cepat daripada BeautifulSoup(html.parser) pada halaman 1 KB, lalu naik menjadi ~17x di 10 MB, serta ~10-14x lebih cepat daripada BeautifulSoup(lxml) pada rentang yang sama. Angka yang sering beredar di internet — "selectolax sekitar 4-5x lebih cepat daripada BeautifulSoup" — terlalu rendah jika dibandingkan dengan html.parser, dan hanya mendekati benar jika BeautifulSoup-nya berbasis lxml. Jadi, kelipatan yang tepat tergantung Anda membandingkan dengan varian BeautifulSoup yang mana dan seberapa banyak data yang diekstrak per halaman.
Hal ini juga selaras dengan benchmark di README mereka sendiri, yang mengindikasikan keunggulan 25,5x atas BeautifulSoup(html.parser). Jadi, tidak ada angka yang salah. Tugas pada README tersebut (judul, link, script, dan meta dari homepage kecil) mengekstrak lebih sedikit data pada halaman yang kecil, sehingga overhead per-parse BeautifulSoup terasa lebih berat. Kalau dibatasi pada rentang yang realistis, kesimpulannya kira-kira begini: selectolax sekitar 10-15x lebih cepat daripada BeautifulSoup untuk pekerjaan parse-dan-ekstrak yang masuk akal, lebih tinggi pada halaman kecil dan ekstraksi yang lebih ringan.
Kalau bottleneck Anda saat ini adalah kode BeautifulSoup yang menelusuri banyak halaman, ini adalah migrasi yang sangat layak. Kasus itu tidak kontroversial. Kasus berikutnya lebih menarik.
Melawan lxml: seri — dan lxml unggul di bagian yang sering dilupakan untuk dipisahkan
Lihat kembali baris 100 KB dan 1 MB. Lexbor dan lxml berada dalam jarak ~5% satu sama lain, rentang per-run mereka saling tumpang tindih, dan menurut metodologi saya itu berarti seri — tidak ada pemenang, tidak ada klaim "lebih cepat." Satu-satunya momen selectolax benar-benar unggul adalah pada halaman 10 MB (159,9 ms vs 172,9 ms, selisih 8,1% dengan interval yang tidak saling overlap). Jadi pada tugas penuh, selectolax menyamai lxml dan hanya mengunggulinya pada dokumen yang sangat besar.
Lalu saya pisahkan pembangunan tree dari query CSS, dan hasilnya berbalik dengan cara yang sering luput dalam tulisan lain. Untuk parsing murni, tanpa query sama sekali, lxml secara konsisten ~33-34% lebih cepat daripada selectolax-Lexbor di mesin ini — 77,9 ms vs 116,6 ms pada halaman 10 MB. Pada tugas penuh, keduanya memang mendekat, dan dugaan kerja saya (bukan sesuatu yang sudah saya buktikan lewat eksperimen atribusi) adalah bahwa pada halaman-halaman ini, query CSS hanya mengambil porsi kecil dari total waktu, sehingga keunggulan parsing lxml menjadi tersebar sampai total akhirnya terlihat sama.
Ini adalah klaim paling mudah diperdebatkan di seluruh review ini, dan saya ingin jujur soal alasannya. Hasil ini berlawanan dengan kebijaksanaan umum, dan satu benchmark publik yang saya temukan dan benar-benar mengisolasi parse-only — aows.jpt.sh — justru menunjukkan kebalikannya, dengan selectolax sekitar 4x lebih cepat. Karena itu saya membatasinya: hasil ini hanya satu platform (macOS arm64, Python 3.14, wheel cp314 prebuilt — Linux x86_64 atau build dari source belum diuji), sudah saya cek lintas empat ukuran halaman dan konsisten di semuanya, serta diverifikasi ulang dengan dua API lxml yang berbeda untuk menyingkirkan artefak API. Kedua API lxml mengalahkan selectolax-Lexbor di semua ukuran. Saya tidak menyajikan "lxml lebih cepat dalam parsing" sebagai fakta final — saya menyajikannya sebagai hasil benchmark saya, dengan skrip terlampir, yang berbeda dari sebagian besar angka publik. Silakan uji di mesin Anda sendiri.
Satu potongan lagi: saat meng-query 100.000 <a> pada halaman datar, lxml dan selectolax-Modest setara (33,30 ms vs 34,19 ms, rentang saling overlap), sedangkan selectolax-Lexbor tertinggal sekitar 15% dari keduanya. Yang sama-sama dimiliki ketiga engine C adalah kecepatan yang 5-7x lebih tinggi daripada parsel atau BeautifulSoup saat selection massal, karena model Python-object-per-node memang menjadi beban utama. Jadi, klaim "selectolax adalah yang tercepat untuk bulk CSS selection" juga tidak sepenuhnya benar — Modest hanya setara dengan lxml, dan Lexbor kalah dari keduanya.
Kesimpulan yang benar-benar saya berani pertahankan: keunggulan selectolax atas lxml bukan pada kecepatan total yang luas. Ia hanya unggul di halaman terbesar. Nilai utamanya ada pada hal lain — kemudahan API, perilaku pada input rusak, dan CSS modern — dan itulah yang dibahas di sisa review ini.
Memori dan cold start: lihat RSS, bukan hasil profiler Anda
Bagian memori adalah tempat saya harus mengoreksi angka saya sendiri sebelumnya, dan koreksi itu justru poin pentingnya. Diukur sebagai delta RSS pada halaman 10 MB dengan tracemalloc dimatikan, BeautifulSoup memakai sekitar 1,5-1,8x lebih banyak memori daripada selectolax atau lxml — rentangnya dari 1,51x (BS-lxml pada 218,4 MB vs Lexbor pada 144,6 MB) hingga 1,75x di ujung atas. selectolax dan lxml berada di kelas yang hemat; lxml adalah yang paling ringan berdasarkan RSS.
Di pengukuran saya sebelumnya, saya sempat menulis "~3x", dan angka itu salah karena alasan yang cukup edukatif: pengukuran dilakukan saat tracemalloc aktif, dan bookkeeping per-alokasi milik tracemalloc kira-kira menggandakan RSS semu dari parser yang melakukan banyak alokasi. Jadi, satu pesan penting untuk siapa pun yang membenchmark memori parser: urutkan berdasarkan RSS dengan profiler dimatikan. Mengurutkan parser berdasarkan puncak tracemalloc justru salah khususnya untuk engine berbasis C — itu membuat selectolax-Lexbor tampak lebih berat daripada Modest, padahal menurut RSS nyata keduanya dekat. BeautifulSoup memang yang paling berat di sini; hanya saja bukan berat sampai 3x seperti yang tampak dari instrumen yang tercemar.
Cold start memang kecil, tetapi nyata: import selectolax sekitar 14 ms, kira-kira setara dengan lxml dan ~2,3x lebih cepat daripada bs4 atau parsel. Kalau Anda membangun CLI atau serverless function, di mana waktu import ikut dihitung setiap kali eksekusi, selisih ini layak diperhatikan.
Cakupan CSS selector: kuat, tetapi ada beberapa lubang nyata
Cakupan CSS diuji dengan matriks 41 kasus, masing-masing selector dibandingkan dengan fixture yang sudah diketahui jawaban benarnya, plus satu pengujian sengaja dibuat untuk mematahkan engine Lexbor. Setiap kasus dijalankan di subprocess sendiri, dan itu ternyata perlu — salah satunya bisa menjatuhkan seluruh interpreter. Hasilnya:
| 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 |
Begitu selector yang agresif ikut dimasukkan, Lexbor bukan lagi pemenang mutlak — soupsieve-lah pemenangnya, dengan hasil bersih 41/41 dibanding 39/41 milik Lexbor. Dua kegagalan Lexbor adalah :lang(en) dan :dir(rtl), yang ditolak sebagai parse error. Di luar itu, hasilnya sempurna, termasuk :has(), :is(), :where(), dan atribut yang case-insensitive.
Yang benar-benar menonjol dari Lexbor adalah perbandingannya dengan stack cssselect. Selector andalan dari README — div > :nth-child(2n+1):not(:has(a)) — menghasilkan set yang benar pada kedua engine selectolax dan pada soupsieve, tetapi menghasilkan set yang salah pada lxml dan parsel, tanpa error apa pun. Scraper yang menyalin selector ini ke Scrapy atau parsel akan mendapatkan hasil yang diam-diam salah. Agar framing-nya presisi: cssselect sudah mem-parse :has() sejak versi 1.2.0 (2022), dan saya menguji 1.4.0, jadi ini adalah kasus "didukung tetapi evaluasi gabungannya salah," bukan "tidak didukung." Perilaku set salah yang diam-diam pada kombinasi ini memang belum ada di tracker cssselect, yang hanya mencatat batasan :has() sebagai error yang dilempar. Lexbor juga menangani flag atribut case-insensitive [data-role="LEAD" i] yang ditolak mentah-mentah oleh cssselect.
Namun ada dua celah yang sangat menentukan migrasi. selectolax tidak mendukung XPath sama sekali — tidak ada backend yang mengekspos xpath() — dan juga tidak ada pseudo-element ::text / ::attr(), karena itu merupakan ekstensi parsel/Scrapy, bukan CSS asli. Jika scraper Anda saat ini bergantung pada XPath, itu adalah tembok terbesar yang akan Anda temui; Anda harus menulis ulang selector, bukan sekadar mengganti library. Di sisi lain, Lexbor menyediakan pseudo-class :lexbor-contains("text" i) untuk pencocokan teks yang case-insensitive, sesuatu yang tidak dimiliki lxml, parsel, maupun CSS standar, dan ini bekerja sesuai dokumentasi.
Ketahanan terhadap HTML berantakan, dan di sinilah selectolax benar-benar berguna
Scraping di dunia nyata berarti memberi parser data sampah dan berharap ia tidak ambruk. Saya menjalankan 18 input adversarial, dan inilah kategori di mana kasus selectolax melawan lxml paling kuat.
Kalau Anda memberi lxml.html.fromstring string kosong atau whitespace, ia akan melempar ParserError("Document is empty"). Kedua engine selectolax justru mengembalikan tree kosong yang valid. Untuk scraper yang memproses daftar URL dan kadang mendapat respons kosong, itu berarti satu lapis try/except lebih sedikit untuk membungkus semuanya. selectolax juga berhasil memproses 100.000 elemen tanpa stack overflow.
Nesting yang terlalu dalam memberikan perbedaan paling tajam. Pada 1.000 dan 5.000 level <div> bertumpuk, lxml diam-diam membuang konten terdalam, sementara selectolax tetap menyimpannya. libxml2 membatasi kedalaman parse sekitar 256 level dan memotong tree tanpa error, sehingga teks terdalam tidak bisa dijangkau lagi. Kedua engine selectolax mengembalikan tree utuh. Ini adalah kebalikan dari jebakan <template> yang akan saya bahas berikutnya: di sana Lexbor membuang konten yang dipertahankan engine lain; di sini lxml yang membuang konten yang disimpan selectolax.
Tidak semua sel menang. Backend Modest menghentikan seluruh interpreter Python dengan SIGABRT ketika bertemu :dir() — bukan exception yang bisa ditangkap, melainkan kematian proses secara langsung. Ini adalah catatan ketahanan yang serius bagi siapa pun yang masih memakai backend lama, dan justru jenis masalah yang baru terlihat setelah menjatuhkan job produksi pada jam 3 pagi.
Dua jebakan silent-data-loss yang perlu Anda tahu sebelum rilis
Kedua hal berikut bukan temuan baru — keduanya sudah didokumentasikan di upstream — tetapi keduanya bisa menghilangkan data sungguhan secara diam-diam, dan tidak terlalu disorot di README.
Lexbor mengabaikan <a> di dalam <template>
Pada halaman MDN yang saya uji, selectolax-Lexbor menemukan 497 link, sementara lxml, kedua backend BeautifulSoup, dan bahkan backend Modest milik selectolax menemukan 508. Sebelas link yang hilang itu adalah language switcher dan link discussion yang berada di dalam elemen <template> (halaman itu memakai Lit web components).
Penyebab dasarnya memang valid: sesuai spesifikasi HTML5, konten <template> di-parse ke fragment inert terpisah, bukan ke DOM utama, dan Lexbor mengikuti aturan itu secara ketat — tree.css("a") tidak turun ke konten template. lxml, kedua backend BeautifulSoup, dan Modest meratakan konten template ke tree utama, sehingga mereka menemukan link tersebut. Ini adalah isu terbuka yang terdokumentasi (selectolax#146, dengan akar masalah engine di lexbor#170), dan dua interpretasi itu sama-sama bisa dibela — Lexbor bisa dibilang lebih patuh pada spesifikasi. Namun, developer yang memakai backend yang direkomendasikan bisa diam-diam kehilangan data itu tanpa error apa pun. Kebalikannya juga penting untuk disebutkan: parser lain mengekspos konten inert dari template yang tidak pernah dirender browser, jadi mereka bisa memberi Anda data hantu yang sebenarnya tidak terlihat oleh pengguna. Jalan keluar yang paling aman adalah memakai backend Modest, atau library lain, untuk halaman seperti itu.
Byte non-UTF-8 bisa merusak .text() tanpa peringatan
Kalau Anda memberi selectolax bytes yang bukan UTF-8 valid, parsing tetap berhasil — kerusakannya muncul belakangan, dan itu lebih buruk daripada crash yang jelas. Pada "<p>café éè</p>".encode("latin-1"), .text() pada Lexbor mengembalikan replacement character, .text() pada Modest diam-diam membuang byte yang bermasalah, dan kedua engine baru melempar UnicodeDecodeError saat Anda menyentuh .html. Binding ini mendekode secara strict UTF-8 saat pembacaan ulang, bukan saat parse. Masalah ini terkait dengan issue selectolax yang sudah dikenal mengenai strictness encode/decode.
Solusinya cuma satu baris dan sebaiknya jadi kebiasaan: decode dulu bytes-nya sendiri — LexborHTMLParser(resp.content.decode("latin-1")) — lalu kedua engine akan mengembalikan 'café éè' dengan benar. Praktiknya, selalu berikan str ke selectolax, bukan raw bytes non-UTF-8. README tidak menjelaskan hal ini secara tegas.
Dimensi produksi (hanya satu observasi, jadi anggap sebagai sinyal, bukan angka final)
Hasil berikut saya ukur sekali saja, bukan tiga kali, jadi saya tandai sebagai sinyal, bukan angka final.
Skalabilitas thread adalah yang paling menarik. Saat mem-parse halaman 1 MB sebanyak 48 kali melalui empat thread, selectolax menunjukkan percepatan wall-clock sekitar ~3,5-3,9x — tanda empiris bahwa library ini melepaskan GIL selama parsing C — sementara BeautifulSoup(lxml) justru menjadi beberapa kali lebih lambat saat di-thread, tanda bahwa pekerjaan justru terserialisasi di GIL. lxml berada di tengah dan hasilnya belum meyakinkan. Untuk era free-threading yang sedang dituju Python, kemampuan selectolax untuk mem-parallel-kan parsing antar thread saat BeautifulSoup tidak bisa adalah keunggulan nyata, meskipun masih sementara. Ini hanya satu jumlah thread pada satu ukuran halaman, dan mekanismenya masih hipotesis, belum saya verifikasi dengan menginstrumentasi kode C.
Soal memory leak: selama 2.000 iterasi parse-ekstrak-buang pada ukuran 1 MB, tidak ada satu pun dari ketiga parser yang menunjukkan kenaikan RSS linear seperti kebocoran — semuanya menetap dalam band working set yang terbatas. Saya percaya hasil itu karena saya menjalankan subjek kalibrasi yang memang sengaja bocor melalui instrumen yang sama, dan ia naik sampai +198 MB sesuai rancangan, yang membuktikan instrumennya memang mampu melihat leak dan hanya saja tidak menemukannya pada parser-parser tersebut. Selain itu, node handle yang tetap disimpan setelah tree asalnya keluar dari scope masih bisa dipakai tanpa segfault. Lagi-lagi, semuanya satu observasi, bukan soak test berjam-jam.
Posisi selectolax — dan kapan harus menyerahkannya ke alat lain
Semua yang dibahas di atas berpusat pada satu tugas: mengubah HTML yang sudah Anda miliki menjadi data terstruktur dengan cepat. selectolax sangat bagus untuk tugas itu. Yang memang tidak ia lakukan adalah mengambil halaman, merender JavaScript, mengganti proxy, menyelesaikan CAPTCHA, atau menentukan elemen mana yang Anda inginkan. Semua itu masih tugas kode Anda. selectolax adalah lapisan parsing, dan ia tidak berpura-pura menjadi lebih dari itu.
Di situlah layanan ekstraksi terkelola berada di atas parser, bukan menggantikannya. Kalau Anda tidak ingin membangun dan memelihara tumpukan fetch-render-anti-bot-extract sendiri, Thunderbit menyediakannya sebagai API, MCP server, dan CLI — POST /distill mengubah halaman menjadi Markdown bersih, dan POST /extract mengembalikan JSON terstruktur yang sesuai skema, lengkap dengan rendering JS dan penanganan anti-bot. Ini adalah lapisan masalah yang berbeda: gunakan selectolax saat Anda sudah punya HTML dan ingin kecepatan parsing mentah dengan kontrol penuh, dan gunakan sesuatu seperti API, MCP server, atau CLI Thunderbit saat Anda ingin fetching dan ekstraksi ditangani, lalu hanya menerima data terstruktur kembali. Bukan pengganti — hanya berada di ketinggian stack yang berbeda.
Coba Thunderbit untuk Ekstraksi Data Web
Kelebihan, kekurangan, dan siapa yang sebaiknya memakainya
Kapan selectolax unggul:
- ~12-17x lebih cepat daripada BeautifulSoup untuk tugas parse-dan-ekstrak yang realistis, stabil pada rentang ukuran halaman yang sangat lebar.
- Memori hemat (kelas lxml, ~1,5-1,8x lebih ringan daripada BeautifulSoup) dan waktu import sekitar ~14 ms.
- Tahan terhadap input yang membuat lxml gagal — kosong, whitespace, dan nesting yang sangat dalam.
- CSS modern termasuk
:has(),:is(),:where(), atribut case-insensitive, dan:lexbor-contains()khusus Lexbor. - DOM read/write yang aman terhadap
None: elemen yang hilang mengembalikanNoneatau[]alih-alih error, dan tree bisa dimodifikasi lalu diserialisasi ulang. - Pemeliharaan aktif (v0.4.10, pertengahan 2026) dan instalasi yang sangat mudah.
Kapan ia tidak unggul:
- Tidak secara umum lebih cepat daripada lxml — hasilnya seri pada tugas penuh, dan kalah pada parsing murni di benchmark saya.
- Tidak ada XPath dan tidak ada
::text/::attr()— ini tembok migrasi yang besar untuk scraper berbasis XPath. - Ada dua jebakan silent-data-loss: konten
<template>pada Lexbor, dan bytes non-UTF-8 lewat.text(). - Backend Modest sudah legacy dan bisa SIGABRT pada
:dir(). - Semua angka di sini berasal dari satu platform (macOS arm64, Python 3.14) dan masih bersifat sementara.
Jadi, apakah Anda sebaiknya memakai selectolax? Ya, kalau Anda menginginkan kecepatan parsing setara lxml dengan API yang lebih ramah, aman terhadap None, dan perilaku yang jauh lebih baik pada input kosong dan rusak — serta Anda rela bekerja dalam wilayah CSS saja. Kalau basis kode Anda dibangun di atas XPath, biaya rewrite-nya nyata dan perlu dipertimbangkan dengan jujur. Dan jika Anda mengejar "parser paling cepat yang satu-satunya", jawaban paling akurat dari benchmark ini adalah bahwa selectolax dan lxml cukup dekat sehingga pembeda utamanya adalah ergonomi dan ketahanan, bukan speed mentah. Dan jujur saja, itu alasan yang lebih baik untuk memilih tool.
Coba Thunderbit untuk Ekstraksi Data Web Get Started Free
FAQ
Apakah selectolax lebih cepat daripada BeautifulSoup?
Ya, jelas — sekitar 12-17x lebih cepat daripada BeautifulSoup(html.parser) dan 10-14x lebih cepat daripada BeautifulSoup(lxml) pada tugas parse-dan-ekstrak yang realistis, dan hasilnya stabil dari halaman 1 KB sampai 10 MB (macOS arm64, Python 3.14). Angka yang sering disebut "4-5x" meremehkan jaraknya terhadap html.parser.
Apakah selectolax lebih cepat daripada lxml? Tidak secara luas. Pada tugas parse-dan-ekstrak penuh, keduanya seri di 100 KB dan 1 MB, dan selectolax hanya unggul pada halaman 10 MB. Pada parsing murni tanpa query, lxml justru ~33-34% lebih cepat di mesin saya — hasil yang berbeda dari konsensus umum, jadi sebaiknya Anda verifikasi sendiri pada hardware Anda.
Haruskah saya memakai backend Lexbor atau Modest?
Lexbor, hampir dalam semua kasus — ini engine yang dipelihara, paling lengkap, dan direkomendasikan README, dengan cakupan CSS yang lebih baik. Satu pengecualian adalah halaman yang menyembunyikan konten di dalam <template>, di mana perilaku Lexbor yang sesuai spesifikasi justru melewatkan konten itu sementara Modest kebetulan masih menyimpannya. Modest juga punya sisi tajam, termasuk crash interpreter secara langsung pada :dir().
Apakah selectolax mendukung XPath?
Tidak. Tidak ada backend yang menyediakan metode xpath() — selectolax hanya CSS. Jika scraper Anda bergantung pada XPath, migrasi berarti menulis ulang selector, dan itu adalah biaya terbesar saat pindah dari stack berbasis lxml atau parsel ke selectolax.
Kenapa output selectolax saya berantakan atau ada elemen yang hilang?
Ada dua tersangka umum. Jika teks kembali dengan replacement character atau aksen hilang, kemungkinan Anda mengirim raw bytes non-UTF-8 — decode dulu menjadi str (resp.content.decode("latin-1")) sebelum parsing. Jika link atau elemen hilang di situs modern, bisa jadi mereka berada di dalam tag <template> yang tidak ditelusuri oleh backend Lexbor; gunakan Modest atau parser lain untuk halaman itu.
