Scrapy sering dimasukkan ke kotak “tidak bisa menangani website modern” karena tidak menjalankan JavaScript. Anggapan itu justru kebalik. Tidak merender halaman memang inti dari pendekatannya, dan begitu Anda melihat cara kerjanya, itu berhenti terasa seperti fitur yang kurang.
Saya membuktikannya sendiri lewat satu percobaan. Saya membuat fixture katalog yang dirender dengan JavaScript, mengarahkan Scrapy ke halaman yang akan ditampilkan browser, dan hasilnya 0 kartu produk. Lalu saya arahkan spider yang sama ke endpoint JSON yang diam-diam dipanggil halaman itu di belakang layar, dan saya mendapat 8/8 item, bersih. Tool yang sama, sesi yang sama, hasil yang berlawanan — dan jarak antara dua angka itu adalah inti dari ulasan ini.
Apa sebenarnya Scrapy itu (dan bukan)
Scrapy adalah framework Python untuk merayapi situs dan mengekstrak data terstruktur. Itulah cara tim pengembangnya sendiri mendefinisikannya di dokumentasi ringkasan, dan setelah memakainya, definisi itu memang pas — tidak ada klaim marketing berlebihan yang perlu dibetulkan. Umurnya sudah cukup matang dan mapan sampai-sampai jadi jawaban spontan ketika developer Python bertanya tool apa yang dipakai orang serius untuk scraping, dan repo-nya mendukung itu: sekitar 62.981 bintang GitHub per 2026-07-07 (scrapy/scrapy), dengan 11.773 fork dan 590 issue terbuka pada hari yang sama. Lisensinya BSD-3-Clause, butuh Python 3.10 atau lebih baru, dan versi yang saya uji adalah 2.17.0, yang kebetulan rilis pagi saat saya menjalankan tes ini — jadi tidak ada tanda bintang untuk versi yang terlambat di sini.
Inilah pembeda utamanya dibanding gelombang crawler AI yang lebih baru: secara default, Scrapy hanya HTTP. Tidak ada browser. Tidak ada mesin rendering. Ia mengambil HTML lewat jaringan, menyerahkannya ke parser, lalu membiarkan Anda mengambil field lewat selector CSS atau XPath. Menyebut itu sebagai keterbatasan memang ada benarnya, tapi itu juga melewatkan inti desainnya. Premis Scrapy adalah bahwa menyalakan headless Chrome untuk scraping rutin biasanya bukan pilihan paling efisien — jalan yang lebih pintar adalah menemukan request data yang memang sudah dipanggil halaman, lalu mengambilnya langsung.
Premis itu bukan cuma saya yang memaksakan makna ke tool ini. Dokumentasi resmi tentang konten dinamis menyebutnya jelas: cari dan tiru request data yang mendasarinya dulu, dan pakai browser headless hanya sebagai cadangan kalau request itu memang tidak praktis untuk direproduksi. Kebanyakan scraper membuka browser dulu dan tidak pernah melirik API-nya. Scrapy membalik default itu.
Fitur utama, dan alasan desain di balik masing-masing
Di balik layar, Scrapy adalah kumpulan komponen yang masing-masing mengasumsikan satu hal tentang Anda: Anda developer yang ingin kontrol, bukan wizard sekali klik.
Spider. Anda menulis kelas, memberi daftar URL awal, dan mendefinisikan callback parse yang menghasilkan item atau mengikuti tautan lain. Itu memang lebih banyak ngetik dibanding extractor tanpa kode — aturan ekstraksinya Anda tulis sendiri — tapi sebagai gantinya Anda dapat kontrol presisi atas apa yang diambil dan ke mana crawl berikutnya berjalan.
Selector. Proses parsing berjalan di atas parsel, yang memakai lxml di bawahnya. CSS dan XPath sama-sama didukung penuh, bukan tempelan tambahan. Dukungan lxml inilah yang bikin seleksi tetap cepat dan kode ekstraksi terasa jelas, bukan rangkaian slicing string yang berantakan.
Feed export. Arahkan spider ke sebuah file, dan Scrapy akan menyerialkan item Anda ke JSON, JSON Lines, CSV, atau XML tanpa perlu plumbing tambahan. Dalam pengujian saya, satu spider katalog statis langsung menulis JSON dan CSV tanpa satu baris pun kode ekspor dari saya — cerita feed export itu nyata, dan memang bekerja seperti yang dijanjikan.
AutoThrottle dan kontrol crawl. Request dijadwalkan secara asinkron di atas Twisted, dan Anda mendapat batas concurrency, jeda unduhan, pembatasan kedalaman, AutoThrottle untuk rate limiting adaptif, serta kepatuhan terhadap robots.txt. Inilah kontrol yang mencegah crawl besar berubah jadi insiden yang membebani server.
Hanya HTTP, jika dilihat sebagai fitur. Tanpa browser berarti penggunaan memori rendah, throughput tinggi, dan tidak ada mesin rendering yang perlu dirawat — selama data yang Anda cari memang bisa dijangkau lewat HTTP biasa. Dan lebih sering dari yang diasumsikan kubu browser-first, memang begitu.
Instalasi: tumpukan dependensi yang jarang masuk screenshot
Instalasinya nyaris tanpa drama, dan untuk framework sebesar ini, itu layak disebut terang-terangan. pip install Scrapy==2.17.0 selesai mulus di virtual environment baru pada macOS arm64, mengambil binary wheel, tanpa kompilasi yang mentok di tengah jalan. Tidak ada hal dramatis untuk dilaporkan — dan justru itu poinnya.
Tapi lihat apa saja yang ikut terpasang. scrapy version -v menampilkan Scrapy 2.17.0 yang berjalan di atas lxml 6.1.1, Twisted 26.4.0, pyOpenSSL 26.3.0, dan cryptography 49.0.0, dengan parsel, cssselect, dan tldextract melengkapi paketnya. Itu footprint yang nyata — setara seluruh framework crawling, bukan parser HTML satu file. Di mesin ini, semua sudah tersedia dalam bentuk wheel dan instalasi tetap lancar. Di setup lain, dokumentasi resmi masih memperingatkan potensi gesekan dependensi yang spesifik platform, dan secara historis bagian yang sering bikin repot ada di cryptography dan Twisted, jadi siapkan ruang untuk itu kalau Anda memakai lingkungan yang tidak umum. Setup di sini mulus; tetapi besarnya paket yang terpasang tetap penting diketahui sebelum Anda memutuskan, karena Anda memang sedang mengambil sebuah framework dan bobotnya memang bobot framework.
Praktik langsung: apa yang bertahan
Begitu terpasang, jalur statis berjalan bersih. Recall penuh, tidak ada yang hilang.
| Pengujian | Hasil | Runtime |
|---|---|---|
| Katalog statis lokal + pagination | 12/12 produk | 0.557s |
| Ekspor CSV katalog statis | 12 baris ditulis | (run yang sama) |
| Ekstraksi artikel | judul + 3/3 paragraf isi | 0.416s |
| Grafik crawl, DEPTH_LIMIT=2 | 11 halaman pada kedalaman 0/1/2 | 0.904s |
| Halaman 500 lokal | status 500 tertangkap, tidak crash | 0.424s |
| Books to Scrape (publik) | 20 produk | 2.053s |
| Spider Quotes to Scrape (publik) | 12 item kutipan | 3.465s |
Spider katalog statis menelusuri pagination dari halaman satu ke halaman dua dan menangkap 12/12 rekaman yang diharapkan, lalu menulisnya sebagai JSON dan CSV dalam satu proses yang sama. Fixture artikel adalah yang paling menarik diperhatikan. Scrapy tidak mencoba membersihkan halaman secara otomatis menjadi Markdown yang rapi — sebagai gantinya, saya bisa menarget field article dengan selector yang eksplisit dan memisahkan teks navigasi serta footer ke field berbeda, sehingga saya mendapat 3/3 paragraf isi dan teks boilerplate tetap dikarantina, bukan tercampur di hasil. Itulah trade-off-nya: Anda menulis selector, dan Anda mendapat tepat apa yang Anda minta, tidak lebih dan tidak kurang.
Kontrol crawl juga terbukti di skala kecil. Dengan DEPTH_LIMIT=2, jeda download singkat, concurrency per domain, dan robots.txt aktif, grafik crawl melihat 11 halaman pada kedalaman 0, 1, dan 2, dan perhitungan depth berjalan semestinya. Penanganan error juga sama tenangnya. Halaman 500 yang sengaja dibuat mengembalikan item terstruktur dengan status 500 yang muncul lewat handle_httpstatus_list — tanpa exception, tanpa proses yang mendadak mati. Scrapy memperlakukan status error sebagai sesuatu yang Anda tangani di logika spider, bukan kejutan yang meruntuhkan crawl.
Praktik langsung: tembok JavaScript dan pintu di sebelahnya
Sekarang ke hasil yang jadi dasar ulasan ini.
Saya mengarahkan fetcher HTTP Scrapy ke fixture katalog yang dirender dengan JavaScript. Ia mengunduh HTML sumber, menemukan 0 node .product-card, lalu lanjut — karena ia tidak pernah menjalankan script yang seharusnya menggambar kartu-kartu itu. Halaman publik Quotes to Scrape JS menunjukkan cerita yang sama: 0 node kutipan yang dirender. Kalau tes berhenti di situ, Anda akan mengira Scrapy tidak layak dipakai untuk apa pun yang dibangun dalam satu dekade terakhir.
Jangan berhenti di situ. Katalog JS itu diisi oleh API JSON di latar belakang, seperti banyak kasus serupa. Saya mengarahkan spider Scrapy yang sama ke endpoint itu dan mendapatkan 8/8 produk dalam 0.416s — tanpa browser, tanpa rendering, hanya request ke URL yang memang sudah dipanggil halaman dan parsing JSON yang kembali.
Perbandingan berdampingan itu merangkum filosofi reproduksi request dalam bentuk paling sederhana. Halaman yang dirender adalah umpan; datanya sebenarnya sudah ada di balik API sejak awal, dan desain Scrapy mengarahkan Anda untuk memukul API itu langsung alih-alih membayar headless browser cuma untuk melihat halaman menyusun dirinya sendiri. Lebih cepat, lebih ringan, dan lebih jarang rusak — kontrak API biasanya jauh lebih stabil daripada tumpukan DOM sisi-klien. Kekurangannya: semuanya manual. Anda harus buka tab network, menemukan request-nya, lalu menyalin header dan parameternya sendiri. Scrapy tidak akan menemukan API itu untuk Anda; ia hanya membuat pemanggilannya jadi sangat mudah setelah Anda menemukannya.
Dua batasan, saya jelaskan terus terang. Kalau memang tidak ada request dasar yang bisa direproduksi — misalnya data dibangun murni lewat client-side rendering tanpa API di belakangnya — Scrapy memerlukan integrasi browser headless yang Anda pasang sendiri, dan saya tidak menguji jalur itu dalam penilaian ini. Lalu, semua tes di atas berjalan pada fixture kecil dan halaman demo publik. Saya tidak menjalankan crawl 100 sampai 1.000 halaman, jadi saya tidak membuat klaim apa pun tentang memori, throughput, atau perilaku retry pada skala besar — inti asinkron dan kontrol crawl memang sinyal yang kuat, tetapi sinyal bukan pengukuran.
Kelebihan dan kekurangan
Kelebihan:
- Desain hanya HTTP cepat dan ringan — recall 12/12 untuk data statis dalam sekitar setengah detik, 8/8 dari API JSON dalam 0.416s, tanpa overhead browser.
- Pendekatan reproduksi request benar-benar berhasil: halaman JS yang memberi 0 node menyerahkan seluruh 8 item lewat API pendukungnya.
- Selector CSS dan XPath berbasis
lxmlmembuat kode ekstraksi tetap mudah dibaca dan cepat. - Feed export ke JSON/CSV/XML tanpa perlu menulis plumbing ekspor.
- Penanganan error yang jelas — status 500 kembali sebagai status yang bisa Anda tangkap, bukan crash.
- Kontrol crawl yang matang: concurrency, delay, depth limit, AutoThrottle, robots.txt.
- Lisensi BSD-3-Clause yang permisif; instalasi bersih di mesin modern.
Kekurangan:
- Tidak merender JavaScript secara desain — 0 node pada halaman yang dirender client-side sampai Anda menemukan API-nya sendiri.
- Menemukan request dasarnya tetap manual; Scrapy tidak akan menunjuk endpoint untuk Anda.
- Tumpukan dependensi cukup besar (Twisted, lxml, cryptography, pyOpenSSL, parsel, tldextract) — mulus di sini, tetapi historisnya sering jadi titik gesekan di platform yang tidak umum.
- Butuh lebih banyak kode dibanding tool tanpa kode atau tool auto-extraction; spider harus Anda tulis dan rawat sendiri.
- Pengujian saya hanya mencakup fixture kecil dan situs demo, bukan crawl besar — keandalan pada skala besar belum terbukti dalam pengujian ini.
Cocok untuk siapa, dan siapa yang sebaiknya lewat
Scrapy cocok untuk developer yang ingin kontrol di level kode dan berpikir dalam request, bukan dalam halaman. Kalau reaksi alami Anda terhadap situs JavaScript yang lambat adalah “pasti ada API di balik sini,” tool ini memang dibuat untuk insting seperti itu. Ia memberi hasil terbaik bagi orang yang nyaman menulis selector, membaca tab network, dan memegang penuh logika ekstraksi dari awal sampai akhir. Untuk situs statis, katalog berhalaman, dan apa pun yang didukung endpoint JSON yang bisa ditemukan, Scrapy cepat dan presisi.
Lewati saja — atau setidaknya pasangkan dengan tool lain — kalau menulis dan memelihara kode spider bukan cara Anda ingin menghabiskan waktu, atau jika target Anda merender data sepenuhnya di sisi klien tanpa request yang bisa direproduksi dan Anda tidak ingin memasang browser headless sendiri. Dan kalau harapan Anda adalah menempelkan tool ke URL lalu mendapat output terstruktur yang bersih tanpa menulis aturan ekstraksi, itu memang bukan tugas Scrapy, dan ia tidak pernah berpura-pura sebaliknya.
Alternatif, dan posisi Thunderbit
Coba Thunderbit untuk Ekstraksi Data Web
Mulailah dari apa yang sebenarnya Anda pilih: framework gratis dan open-source yang Anda jalankan serta rawat sendiri. Anda memiliki spider-nya, tumpukan dependensinya, dan pekerjaan untuk menemukan request data tiap situs. Sebagai gantinya Anda tidak membayar per request, menjaga semuanya tetap internal, dan mendapat kontrol penuh. Untuk banyak tim, itu keputusan yang tepat, dan ulasan ini bukan untuk mengajak siapa pun keluar dari pilihan itu.
Trade-off-nya ada pada masalah rendering dan perubahan struktur, dan jawaban Scrapy adalah: Anda yang menyelesaikannya. Anda mencari API-nya, meniru request-nya, dan menangani kasus tanpa API dengan memasang browser sendiri. Managed AI scraping API justru menghapus lapisan itu dari beban Anda. Di situlah posisi Thunderbit untuk pembaca teknis — AI scraping API plus MCP server plus CLI, bukan extension browser yang dipakai tim sales dan operasional. POST /distill mengubah halaman menjadi Markdown yang bersih dan siap untuk LLM; POST /extract mengembalikan JSON terstruktur berdasarkan skema yang Anda definisikan; dan keduanya menangani rendering JavaScript, anti-bot, serta konten dinamis di sisi server — termasuk kasus client-rendered ketika Scrapy meminta Anda memakai browser. Ada MCP server untuk AI agent dan coding assistant (dengan thunderbit_suggest_fields gratis untuk memetakan halaman sebelum Anda mengeluarkan biaya), serta CLI lewat npx @thunderbit/thunderbit-cli untuk kerja di terminal, CI, atau cron.
Perbedaannya bukan kualitas, melainkan kepemilikan. Scrapy adalah framework engineering yang eksplisit: Anda memelihara spider, pipeline, dan strategi JavaScript, dan Anda mendapat kontrol penuh dengan biaya per-call nol. Stack Thunderbit menyerahkan lapisan render-dan-extract sebagai layanan terkelola, sehingga Anda tidak perlu lagi mengutak-atik tab network dan membayar per panggilan. Kecil, code-first, dan suka mengendalikan setiap langkah? Kontrol Scrapy lebih cocok. Ingin menskalakan ke seratus situs dan tidak mau meniru request satu per satu untuk tiap situs? Jalur terkelola menghapus seluruh kategori pekerjaan itu.
Untuk lanskap yang lebih luas, artikel benchmark ini membahas tetangganya: perbandingan lengkap scraper open-source, ulasan crawler Go Colly tanpa browser, dan ulasan selector adaptif Scrapling.
Putusan
Jadi, haruskah Anda memakai Scrapy? Ya — jika Anda seorang developer yang ingin kontrol dan setuju dengan cara pandang ini: jangan render halaman, temukan request di baliknya. Dalam pengujian, filosofi itu benar-benar menghasilkan sesuai janji. Katalog JavaScript memberi fetcher HTTP 0 kartu; API JSON yang menjadi sumber datanya menyerahkan seluruh 8 item ke spider yang sama. Ekstraksi statis mencapai 12/12, selector artikel menjaga 3/3 paragraf tetap bersih dari boilerplate, grafik crawl mematuhi batas kedalaman pada 11 halaman, dan status 500 kembali sebagai status yang tertangani, bukan crash.
Namun, ukuran klaimnya harus tepat. Scrapy tidak merender JavaScript, dan ia tidak akan menemukan API untuk Anda — naluri itu harus Anda bangun sendiri. Tumpukan dependensinya layak disebut sebuah framework dan bisa menyulitkan di platform aneh meski di sini instalasinya mulus. Dan saya menguji fixture serta halaman demo, bukan crawl seribu halaman, jadi anggap cerita skalanya menjanjikan tetapi belum terbukti. Di dalam batas itu, Scrapy adalah tool yang paling setia pada ide yang diam-diam radikal: cara tercepat melewati sebuah halaman web biasanya justru bukan lewat halamannya sama sekali.
Coba Thunderbit untuk Ekstraksi Data Web Get Started Free
FAQ
Bisakah Scrapy mengambil halaman yang dirender dengan JavaScript? Tidak dengan fetcher HTTP bawaannya — hasilnya 0 node pada fixture JS dan juga pada halaman publik Quotes JS, karena ia mengunduh HTML tanpa menjalankan browser. Jalur yang memang disarankan adalah menemukan request data yang mendasari halaman dan memanggilnya langsung; dalam pengujian saya, API JSON di balik katalog JS menyerahkan seluruh 8 item. Untuk halaman yang tidak punya request yang bisa direproduksi, Anda perlu memasang browser headless sendiri.
Apa arti “mereproduksi request” sebenarnya? Sebagian besar halaman dinamis mengambil data dari API JSON di latar belakang, lalu merendernya di sisi klien. Alih-alih menjalankan browser untuk menonton proses itu, Anda membuka tab network, menemukan panggilan API tersebut, lalu mengarahkan Scrapy langsung ke sana. Ini lebih cepat dan lebih stabil dibanding rendering — kontrak API lebih jarang rusak daripada DOM — tetapi tetap pekerjaan manual, dan Scrapy tidak akan mencarikan endpoint itu untuk Anda.
Apakah instalasi Scrapy sulit?
Bagi saya tidak — pip install Scrapy==2.17.0 selesai tanpa error kompilasi dalam venv baru di macOS dengan binary wheel. Namun, ia menarik stack yang cukup besar (Twisted, lxml, cryptography, pyOpenSSL, parsel, tldextract), dan dokumentasi resmi masih memperingatkan adanya gesekan dependensi yang spesifik platform pada beberapa sistem, jadi siapkan ruang ekstra jika Anda memakai lingkungan yang tidak umum.
Format output apa saja yang didukung Scrapy? Feed export mendukung JSON, JSON Lines, CSV, dan XML secara bawaan — arahkan spider ke file, lalu item Anda diserialkan tanpa kode tambahan. Dalam pengujian saya, satu spider menghasilkan JSON dan CSV dalam satu kali jalan. Perlu dicatat bahwa ia mengekspor field yang Anda pilih; ia tidak otomatis membersihkan halaman menjadi Markdown.
Apakah Scrapy gratis untuk penggunaan komersial? Ya, lisensinya BSD-3-Clause, yang bersifat permisif dan ramah untuk penggunaan komersial. Tetap cek lisensi terbaru di repo sebelum Anda membangunnya di atasnya, dan pastikan pilihan user-agent, proxy, dan rate limit Anda tetap bertanggung jawab — kemampuan bukan berarti izin.
