Setiap panduan “Scrapy vs. Selenium” di internet rasanya bunyinya selalu sama: Scrapy lebih ngebut, Selenium bisa menangani JavaScript, tinggal pilih mau pakai yang mana. Arah besarnya memang tidak keliru, tapi klaim universal soal berapa halaman per menit itu hampir tidak pernah benar-benar presisi. Throughput sangat tergantung pada target, jaringan, concurrency, siklus hidup browser, wait, dan kontrol anti-bot.
Panduan ini membandingkan arsitektur dan kompromi operasional yang memang relevan dari satu proyek ke proyek berikutnya. Di sini juga dibahas hal yang sering luput dari perbandingan lain: bagaimana browser automation mengubah model resource, kenapa selective rendering sering lebih efektif daripada crawling penuh dengan browser, dan kapan managed extraction API justru lebih pas daripada kedua framework ini.
Putusan Singkat: Scrapy vs. Selenium di 2026
Kalau mau versi pendeknya: Scrapy unggul untuk kecepatan, skala, dan efisiensi resource pada halaman server-rendered. Selenium unggul saat Anda butuh browser sungguhan untuk melakukan aksi sungguhan — klik, mengetik, atau menunggu modal selesai animasi. Tidak ada yang benar-benar jago menghadapi pertahanan anti-bot modern secara bawaan, dan Playwright diam-diam sudah mengambil alih banyak use case yang dulu biasanya memakai Selenium.
Berikut matriks keputusan yang benar-benar saya pakai:
| Situasi Anda | Pilihan yang Tepat |
|---|---|
| Halaman statis atau server-rendered, volume tinggi | Scrapy |
| SPA berat JavaScript dengan login, klik, flow bertahap | Selenium atau Playwright |
| Situs campuran — mayoritas statis, sebagian kecil khusus JS | Hybrid Scrapy-Playwright |
| URL sudah diketahui, hanya perlu data terstruktur, minim perawatan | AI extraction API (Thunderbit dan sejenisnya) |
Per pertengahan 2026, Scrapy 2.17.0 sudah tersedia, Selenium 4 terus memperluas dukungan WebDriver BiDi, dan scrapy-playwright menyediakan cara yang rapi untuk mengarahkan request tertentu dari Scrapy ke browser. Simpan matriks keputusan itu — sisanya artikel ini akan menjelaskan kenapa pilihan itu masuk akal.
Apa Itu Scrapy dan Selenium (dan Kenapa Developer Masih Perdebatkannya)
Membandingkan Scrapy dengan Selenium itu mirip seperti membandingkan truk pengiriman dengan mobil. Keduanya sama-sama bisa memindahkan sesuatu dari A ke B, tetapi yang satu dibuat untuk membawa beban besar secara efisien, sedangkan yang satu lagi dirancang untuk dikendarai langsung oleh manusia yang perlu berinteraksi dengan jalan. Perdebatan ini terus hidup karena keduanya bisa dipakai untuk scraping — hanya saja memang ditujukan untuk pekerjaan yang berbeda, dan banyak tim terlanjur memilih yang kurang pas sebelum sadar sendiri.
Scrapy: Mesin Crawling Asinkron
Scrapy adalah framework Python-only yang dibangun di atas model I/O Twisted yang event-driven dan non-blocking. Ini bukan browser — sejak awal memang bukan — melainkan hanya mengirim HTTP request dan mem-parsing HTML yang balik. Itu inti keunggulannya. Karena tidak perlu menunggu browser merender apa pun, Scrapy bisa mengirim puluhan request sekaligus tanpa blocking.
Secara bawaan, Scrapy sudah membawa spiders, item pipelines, feed exporters, retry middleware, dan rate limiting. Ini bukan framework yang membuat Anda harus membangun semuanya dari nol — banyak kebutuhan production sudah ditangani. Dokumentasi arsitektur Scrapy menunjukkan Engine, Scheduler, Downloader, dan Item Pipeline sebagai komponen terpisah yang bisa ditukar, itulah salah satu alasan framework ini tetap relevan: Anda bisa menambahkan kemampuan baru tanpa menulis ulang inti sistem.
Kekurangannya jelas: tanpa browser berarti tanpa eksekusi JavaScript. Kalau data Anda dimuat lewat fetch call di sisi klien setelah halaman dirender, Scrapy tidak akan melihatnya. Ia hanya membaca HTML awal, titik.
Selenium: Browser yang Bisa Diprogram
Selenium mengontrol browser sungguhan — Chrome, Firefox, Edge — lewat protokol W3C WebDriver, spesifikasi standar yang membuat Selenium tidak terikat pada bahasa atau browser tertentu, bukan sekadar trik khusus Chrome. Selenium bisa merender JavaScript, menjalankan AJAX, dan mengklik, scroll, serta mengetik persis seperti manusia.
Itulah kenapa Selenium cocok untuk hal yang bergantung pada interaksi: login bertahap, wizard, infinite scroll, menu dropdown yang memicu API call. Tapi setiap sesi browser itu berat. Panduan sizing Selenium Grid sendiri menyarankan kira-kira 1 GB RAM per sesi browser hanya untuk perencanaan — dan itu belum termasuk beban CPU saat halaman benar-benar dirender.
Satu hal yang sering menjebak orang: halaman selesai dimuat bukan berarti UI siap dipakai. Dokumentasi Selenium sendiri memperingatkan agar tidak mencampur implicit dan explicit wait karena timeout yang dihasilkan bisa jadi cepat sekali tidak terduga. Kalau script Selenium Anda sering flaky, biasanya ini penyebabnya.
Scrapy vs. Selenium: Performa Tanpa Angka Universal Palsu
Benchmark yang bisa dipercaya harus mempublikasikan halaman target, status cache, kondisi jaringan, concurrency, strategi reuse browser, kondisi wait, dan kode lengkap. Tanpa konteks itu, angka halaman per menit cuma marketing, bukan bukti. Perbandingan arsitektur tetap berguna:
| Karakteristik workload | Scrapy | Selenium | Scrapy-Playwright |
|---|---|---|---|
| HTML server-rendered | Jalur HTTP langsung | Jalur browser penuh | Gunakan jalur langsung Scrapy |
| Konten yang dirender JavaScript | Butuh renderer tambahan | Eksekusi browser native | Selective browser rendering |
| Model concurrency | Asynchronous request scheduler | Sesi browser yang dikelola kode Anda atau Grid | Scheduler Scrapy plus browser contexts |
| Profil resource | Tanpa overhead rendering browser | Overhead CPU dan memori browser | Biaya browser hanya untuk request yang ditandai |
| Metrik terbaik | Item per menit pada error rate yang aman | Flow selesai per menit pada error rate yang aman | Throughput request statis dan rendered dipisah |
Pengaturan concurrent request default pada Scrapy adalah batas atas, bukan angka throughput yang dijanjikan. Kecepatan aktual ditentukan oleh latency, limit per domain, throttling, retry, ukuran response, pekerjaan parsing, dan laju request yang masih diterima target. Selenium bisa memakai ulang sesi browser, jadi tidak otomatis berarti satu browser baru per halaman, tetapi setiap sesi aktif tetap menjalankan dan merender lingkungan browser.
Model hybrid menarik karena request biasa tetap lewat jalur HTTP Scrapy, sedangkan hanya halaman yang memang perlu rendering yang dikirim ke browser. Itu biasanya mengurangi kerja browser, tetapi tidak otomatis lebih cepat: ukur jalur statis dan rendered secara terpisah, masukkan failure dan retry rate, lalu sesuaikan concurrency dengan keamanan situs target dan kapasitas memori yang tersedia.
Perbedaan Inti yang Mempengaruhi Keputusan Anda
Kecepatan bukan satu-satunya variabel. Beberapa faktor praktis sama pentingnya begitu Anda mulai menjalankannya di production.
Rendering JavaScript dan Konten Dinamis
Scrapy sendiri tidak bisa melihat konten yang dirender di sisi klien. Selenium melihat semuanya karena memang browser asli. Jalan tengahnya — Scrapy-Splash (lebih lama, berbasis Lua) dan scrapy-playwright (lebih modern, direkomendasikan) — memungkinkan Anda merender JS secara selektif di dalam crawl loop Scrapy, tanpa harus memakai browser penuh untuk semua request. Kalau 80–90% halaman target Anda berupa HTML statis dan hanya segelintir yang butuh JS, selective rendering adalah arsitektur yang paling masuk akal. Merender semuanya lewat browser hanya karena sebagian halaman membutuhkannya adalah pemborosan komputasi.
Skalabilitas dan Concurrency
Menskalakan Scrapy dari 1.000 halaman ke 1.000.000 halaman sebagian besar soal provisioning — tambah concurrent request, mungkin distribusikan ke beberapa worker dengan Redis. Menskalakan Selenium berarti menambah instance browser secara linear, yang berarti RAM dan CPU juga naik linear, dan sekarang Anda mengelola browser farm dengan Selenium Grid serta menghadapi pemulihan saat crash. Bukan berarti Selenium tidak bisa scale — hanya saja scaling-nya adalah proyek infrastruktur, bukan sekadar ubah konfigurasi.
Pipeline Data dan Ekspor
Item pipeline milik Scrapy menangani validasi, deduplikasi, dan ekspor ke JSON, CSV, atau database sebagai fitur bawaan. Selenium tidak memberi Anda semua itu — Anda harus menulis sendiri logika serialisasi dan penyimpanan dari awal. Kalau kualitas data dan integrasi downstream penting bagi Anda (dan seharusnya memang penting), ini adalah head start yang sangat berarti dari Scrapy.
Maintenance dan Keandalan Jangka Panjang
Ada pola yang sering saya lihat: spider Scrapy cenderung lebih tahan lama seiring waktu karena arsitektur berbasis middleware memberi struktur yang cukup rapi. Script Selenium lebih mudah rapuh — update browser merusak driver, masalah timing menyebabkan run yang flaky, dan setiap perubahan DOM berarti selector harus diperbarui. Saya pernah melihat developer di forum terang-terangan bilang bahwa scraper berbasis Selenium “sepertinya bukan pilihan terbaik untuk sesuatu yang akan kita jual ke klien,” dan jujur saja, insting itu tepat kalau proyek harus bertahan lebih dari beberapa bulan tanpa disentuh.
Realitas Anti-Bot: Bagaimana Masing-Masing Tool Tahan terhadap Pertahanan 2026
Ini bagian yang sering dilewatkan di perbandingan lain, padahal inilah yang menentukan apakah scraper Anda benar-benar jalan atau tidak. Baik Scrapy maupun Selenium tidak dirancang dengan infrastruktur anti-bot modern di dalam benak mereka, dan berpura-pura sebaliknya cuma akan menyiapkan kejutan buruk di production.
| Lapisan Pertahanan | Scrapy | Selenium | Scrapy-Playwright | Thunderbit API |
|---|---|---|---|---|
| Rendering JS | ❌ Butuh middleware | ✅ | ✅ | ✅ Bawaan |
| TLS fingerprint | ⚠️ Bisa terdeteksi | ⚠️ Bisa terdeteksi | ⚠️ Lebih baik, belum tuntas | ✅ Ditangani |
| CAPTCHA solving | ❌ Manual | ❌ Manual | ❌ Manual | ✅ Bawaan |
| Rate-limit rotation | ⚠️ Proxy DIY | ⚠️ Proxy DIY | ⚠️ Proxy DIY | ✅ Dikelola |
Scrapy gagal dalam pemeriksaan browser fingerprint secara langsung karena memang tidak ada browser untuk di-fingerprint — ia hanya HTTP client, dan banyak vendor anti-bot menandai traffic yang tidak tampak berasal dari browser nyata. Selenium lolos dari pemeriksaan JS dasar karena memang browser sungguhan, tetapi masih bisa dideteksi lewat sinyal seperti navigator.webdriver, flag standar yang bernilai true saat automation. Patch seperti undetected-chromedriver mencoba menutupi hal ini, tetapi mereka seperti main pukul tikus dalam permainan melawan vendor deteksi yang terus memperbarui signature mereka.
Perlombaan Stealth (dan Kenapa DIY Itu Rapuh)
Inilah kenyataan yang tidak enak soal patch anti-detection: itu bukan solusi, melainkan treadmill maintenance. undetected-chromedriver dan playwright-stealth bekerja sampai Cloudflare Turnstile atau DataDome merilis update yang mengenali teknik yang mereka pakai. Lalu Anda harus patch lagi. Saya pernah melihat tim menghabiskan lebih banyak waktu engineering untuk menjaga lapisan stealth tetap hidup daripada waktu yang mereka habiskan membangun scraper itu sendiri.
Rate limiting juga perlu dibahas secara khusus. Saat server mengembalikan 429 Too Many Requests, header Retry-After hanyalah saran, bukan perintah mutlak — banyak situs bahkan tidak mengirimkannya sama sekali, dan sebagian membatasi Anda lewat sinyal lain. AutoThrottle milik Scrapy membantu dengan menyesuaikan delay berdasarkan latency yang teramati, tetapi sifatnya reaktif, bukan pencegahan.
Di sinilah managed extraction API menunjukkan nilainya — penanganan anti-bot menjadi masalah engineering milik orang lain, bukan milik Anda. Kita bahas itu sebentar lagi.
Faktor Playwright: Kenapa “Scrapy vs. Selenium” Bukan Lagi Gambaran Lengkap
Membingkai ini sebagai debat dua tool saja melewatkan apa yang sebenarnya terjadi di komunitas scraping dalam beberapa tahun terakhir. Forum developer penuh dengan orang yang bilang versi kalimat seperti “saya pindah dari Selenium ke Playwright dan sangat puas” — namun sebagian besar artikel perbandingan hanya menyebut Playwright sekilas, kalaupun menyebut sama sekali.
Playwright, buatan Microsoft, mengontrol Chromium, Firefox, dan WebKit lewat satu API. Model actionability-nya menunggu elemen benar-benar terlihat, stabil, dan bisa diinteraksikan sebelum menjalankan aksi — ini mengurangi flaky timing yang sering menghantui banyak script Selenium. Playwright juga menangani browser contexts dengan lebih efisien, sehingga Anda bisa membuat sesi terisolasi tanpa harus meluncurkan browser baru penuh setiap kali.
Kapan Playwright Menggantikan Selenium Sepenuhnya
Untuk scraping — bukan browser testing dengan infrastruktur Selenium yang sudah ada — Playwright sering kali memang tool yang lebih baik di 2026. Pembuatan context lebih cepat, footprint resource per halaman lebih ringan, dukungan async native, dan network interception bawaan. Kalau Anda memulai proyek scraping dari nol tanpa suite test Selenium yang harus dipertahankan, kecil sekali alasan untuk memilih Selenium terlebih dahulu.
Pengecualiannya: jika tim Anda sudah punya infrastruktur test Selenium, atau Anda butuh kustomisasi profile browser yang sangat spesifik dan Playwright tidak mendukungnya sebaik itu, Selenium masih layak dipakai.
Cara Kerja scrapy-playwright
scrapy-playwright adalah download handler untuk Scrapy yang hanya mengarahkan request yang diberi tag meta={"playwright": True} lewat browser sungguhan — sisanya tetap berada di jalur HTTP asinkron Scrapy yang cepat. Berikut spider sederhana yang melakukan crawl katalog paginasi di mana kartu produk dirender lewat JS sisi klien:
import scrapy
class CatalogSpider(scrapy.Spider):
name = "catalog"
def start_requests(self):
yield scrapy.Request(
"https://example.com/products?page=1",
meta={"playwright": True, "playwright_include_page": True},
)
async def parse(self, response):
page = response.meta["playwright_page"]
products = response.css("div.product-card")
for product in products:
yield {
"title": product.css("h3::text").get(),
"price": product.css(".price::text").get(),
}
next_page = response.css("a.next::attr(href)").get()
if next_page:
yield scrapy.Request(
response.urljoin(next_page),
meta={"playwright": True, "playwright_include_page": True},
)
await page.close()
Hanya halaman yang benar-benar perlu rendering yang melewati browser. Inilah inti pendekatan hybrid — Anda tidak membayar “pajak browser” untuk setiap request, hanya untuk yang memang membutuhkannya.
Scrapy-Splash vs. Scrapy-Playwright: Middleware Mana yang Dipakai
Scrapy-Splash mengharuskan Anda menyiapkan layanan Docker Splash terpisah dan menulis skrip Lua untuk interaksi — bisa dipakai, tetapi setup-nya lebih berat dan lebih tua. scrapy-playwright terintegrasi langsung ke event loop async Scrapy, mendukung ketiga mesin browser utama, dan menangani interaksi kompleks tanpa bahasa scripting kedua yang ditempelkan. Kalau Anda memulai proyek baru di 2026, praktis tidak ada alasan lagi untuk memilih Splash.
Arsitektur Hybrid yang Siap Production
Banyak artikel cuma bilang “Scrapy dan Selenium bisa digabung” lalu berhenti di situ. Itu bukan arsitektur. Itu saran. Berikut seperti apa setup production yang benar.
Alurnya: scheduler Scrapy mengarahkan request lewat URL router yang memeriksa apakah halaman statis atau dinamis. Request statis langsung lewat downloader standar Scrapy. Request dinamis diberi tag dan diarahkan ke middleware Playwright, yang mengelola pool browser context. Kedua jalur bertemu kembali di item pipeline yang sama untuk validasi, deduplikasi, dan ekspor — entah data berasal dari HTML mentah atau DOM hasil rendering, ujungnya tetap sama: output JSON, CSV, atau database.
Beberapa catatan deployment kalau Anda membawa ini ke production: containerize dengan Docker supaya binary browser Playwright konsisten di semua environment, batasi concurrent Playwright context sesuai RAM yang tersedia (saya tidak akan lewat 8–10 context di mesin 4 GB standar), dan jalankan job terjadwal lewat cron atau pipeline CI/CD, bukan membiarkan satu proses berjalan tanpa henti.
Setup seperti ini memberi Anda kontrol maksimal. Tapi artinya Anda juga bertanggung jawab atas update browser binary, bug lifecycle context (page yang tidak ditutup akan menahan crawl), rotasi proxy, dan patch anti-bot apa pun yang perlu Anda pasang. Itu komitmen engineering yang nyata, dan sebaiknya jujur pada diri sendiri sebelum masuk ke sana.
Untuk tim yang ingin output terstruktur tanpa harus memiliki infrastruktur itu sendiri, CLI Thunderbit mengambil pendekatan berbeda terhadap masalah yang sama:
thunderbit batch extract --schema schema.json --file urls.txt
Output JSON terstruktur tetap sama. Tidak ada spider code, tidak ada browser pool, tidak ada plumbing anti-bot yang harus dipelihara. Anda menukar sedikit fleksibilitas demi kecepatan menuju production — itu kompromi yang sah, bukan peningkatan universal, dan semuanya tergantung pada seberapa besar kontrol yang benar-benar dibutuhkan proyek Anda.
Jalur “Lewati Framework”: Kapan AI Scraping API Mengalahkan Keduanya
Pada titik tertentu, seorang developer sadar bahwa mereka sebenarnya tidak butuh framework crawling. Mereka butuh data terstruktur dari 500 URL yang sudah diketahui, dan membangun spider, browser pool, dan lapisan anti-bot untuk itu terasa berlebihan — karena memang biasanya begitu.
Inilah celah yang ingin diisi oleh Thunderbit, dan saya tegaskan dari awal: ini bukan pengganti Scrapy untuk crawl kompleks, rekursif, dan penuh logika kustom. Ini alat berbeda untuk masalah yang berbeda dan lebih sempit.
Open API: POST /extract menerima JSON Schema dan mengembalikan data terstruktur yang sesuai — bukan HTML mentah, bukan tumpukan Markdown yang harus Anda parse sendiri. POST /distill melakukan kebalikannya, menghasilkan Markdown bersih yang siap dipakai ke pipeline RAG atau LLM. Managed service ini mendukung rendering JavaScript dan penanganan anti-bot, jadi Anda tidak perlu mengelola infrastruktur itu sendiri. Panduan Distill vs. Extract saat ini mencantumkan 1 credit per halaman Distill dan 20 per halaman Extract; cek dokumentasi live sebelum menghitung anggaran karena ketentuan produk bisa berubah.
MCP Server: untuk AI agent seperti Claude atau Cursor, MCP server milik Thunderbit mengekspos distillation, structured extraction, field suggestion, dan batch jobs sebagai tool, sehingga agent bisa mengambil data web terbaru di tengah tugas tanpa meninggalkan lingkungannya.
CLI: Thunderbit CLI yang terdokumentasi mendukung perintah seperti thunderbit extract <url> --schema schema.json dan cocok untuk workflow terminal maupun job terjadwal. Anda juga bisa mengalirkan Markdown hasil distill ke tool lain untuk riset sekali pakai yang cepat.
Kalau Anda lebih suka tidak menulis kode sama sekali, Thunderbit Chrome Extension menyediakan cara yang sama lewat antarmuka klik-klik, dan ini layak dicoba kalau tim Anda punya non-developer yang butuh data tanpa menyentuh terminal. Saya juga menulis lebih banyak tentang lanskap AI web scraping dan web scraping tanpa coding kalau Anda ingin gambaran yang lebih lengkap.
Jujurlah pada diri sendiri soal posisi Anda: Scrapy masih pilihan tepat untuk crawl multi-site yang kompleks dengan logika kustom dan recursive link-following. Selenium atau Playwright untuk flow yang sangat interaktif. Tapi “saya butuh data terstruktur dari URL yang sudah diketahui” adalah masalah yang lebih sempit daripada yang dirancang oleh kedua tool itu, dan API benar-benar bisa menghapus spider code, plumbing anti-bot, serta maintenance berkelanjutan yang muncul saat Anda memiliki infrastruktur itu sendiri.
Scrapy vs. Selenium vs. Playwright vs. AI API: Perbandingan Langsung
| Fitur | Scrapy | Selenium | Scrapy-Playwright | Thunderbit API |
|---|---|---|---|---|
| Dukungan bahasa | Hanya Python | Python, Java, C#, JS, Ruby | Python | REST (bahasa apa pun) |
| Rendering JS | Tidak (butuh middleware) | Ya | Ya | Ya, bawaan |
| Async/concurrency | Native, tinggi | Terbatas per instance | Native lewat Scrapy | Dikelola di server |
| Penanganan anti-bot | DIY | DIY | Sebagian | Bawaan |
| Pipeline/ekspor data | Bawaan | DIY | Bawaan | Output JSON terstruktur |
| Kompleksitas setup | Sedang | Rendah untuk awal, tinggi saat scale | Sedang hingga tinggi | Minimal |
| Beban maintenance | Rendah-sedang | Tinggi | Sedang | Hampir nol |
| Paling cocok untuk | Crawl statis volume besar | Flow yang sangat interaktif | Situs campuran statis/dinamis | URL yang sudah diketahui, output terstruktur |
Kalau Anda sedang menimbang opsi scraper lain di luar empat ini, ada baiknya juga melihat bagaimana alternatif Instant Data Scraper dan best AI web scrapers dibandingkan — lanskapnya sudah ramai, dan tidak semua tool menyelesaikan masalah yang sama.
Catatan Legal dan Etika untuk Web Scraping di 2026
Saya singkat saja karena ini bukan fokus utama, tapi tetap penting. Setting ROBOTSTXT_OBEY di Scrapy akan membuat spider Anda mematuhi aturan robots.txt — praktik yang baik, walau perlu diketahui bahwa Robots Exclusion Protocol sendiri secara eksplisit menyatakan bahwa aturannya bukan izin akses secara hukum. Selenium dan Playwright tidak punya kepatuhan robots.txt bawaan sama sekali — itu sepenuhnya tanggung jawab Anda untuk diimplementasikan. Apa pun tool-nya, cek terms of service situs dan hukum yang berlaku di yurisdiksi Anda sebelum scraping dan menggunakan ulang data; “data itu terlihat publik” tidak otomatis berarti legal di semua tempat.
Memilih Tool yang Tepat untuk Proyek Scraping Anda di 2026
Keputusannya sebenarnya kembali ke empat pertanyaan: jenis kontennya apa, skalanya seberapa besar, seberapa banyak interaksi yang dibutuhkan, dan seberapa besar maintenance berkelanjutan yang siap Anda tanggung. Untuk halaman statis dalam skala besar, pilih Scrapy. Untuk halaman berat JavaScript dengan interaksi nyata, pilih Selenium atau Playwright. Kalau campur-aduk, bangun arsitektur hybrid. Kalau URL sudah diketahui dan Anda hanya perlu output terstruktur dengan perawatan minimal, API seperti milik Thunderbit kemungkinan besar menghemat lebih banyak waktu daripada biayanya.
“Scrapy vs. Selenium” memang tidak pernah sepenuhnya jadi pertanyaan yang lengkap — dulu itu cuma satu-satunya bingkai yang tersedia. Playwright mengubah area tengah, dan AI extraction API membuka jalur baru bagi orang-orang yang sadar bahwa mereka sebenarnya sedang membangun infrastruktur, bukan menyelesaikan masalah bisnis. Coba dulu tier gratis sebelum komit ke salah satu jalur — suggest-fields gratis dan distill hanya memakai satu credit, jadi Anda bisa cek kecocokan API sebelum menulis satu baris pun spider code.
FAQ
Apakah Scrapy lebih cepat daripada Selenium untuk web scraping? Menurut pengujian saya, ya — sering kali jauh lebih cepat pada halaman statis, karena arsitektur async Scrapy melewati overhead browser sepenuhnya. Selisih itu mengecil ketika Scrapy memakai middleware Playwright untuk halaman berat JavaScript, tetapi Scrapy tetap unggul dalam throughput total untuk workload campuran karena halaman non-JS tetap berada di jalur cepat.
Bisakah Scrapy menangani halaman yang dirender JavaScript?
Tidak sendirian — Scrapy hanya melihat HTML awal. Menambahkan scrapy-playwright atau Scrapy-Splash yang lebih lama sebagai middleware memungkinkan Anda merender request tertentu lewat browser sungguhan sambil menjaga sisa crawl tetap di jalur native Scrapy yang lebih cepat.
Kapan saya harus memakai Selenium daripada Scrapy? Saat Anda butuh interaksi browser penuh — login bertahap, klik wizard, mengisi form — dan jumlah halamannya sedang, bukan sangat besar. Ini juga pilihan yang masuk akal kalau Anda sudah punya infrastruktur test berbasis Selenium yang ingin Anda pakai ulang untuk scraping.
Apakah Playwright lebih baik daripada Selenium untuk scraping di 2026? Untuk scraping secara khusus, umumnya ya — Playwright biasanya menawarkan performa lebih baik, auto-wait bawaan, dan footprint resource yang lebih ringan per browser context. Selenium masih punya keunggulan untuk tim yang sudah memiliki suite testing lintas-browser yang mapan dan tidak dirancang Playwright untuk menggantikannya.
Apa itu AI scraping API dan kapan ia menggantikan Scrapy atau Selenium? AI scraping API, seperti Open API milik Thunderbit, menangani rendering JS, pertahanan anti-bot, dan ekstraksi data di sisi server, lalu mengembalikan JSON terstruktur yang sesuai schema yang Anda tentukan. Ini pilihan yang tepat ketika Anda sudah tahu URL-nya dan butuh output terstruktur tanpa membangun atau memelihara infrastruktur crawl — ini bukan pengganti Scrapy untuk crawl kompleks, rekursif, dan penuh logika kustom.
Pelajari Lebih Lanjut
