Kebanyakan orang mengenal Crawlee saat lagi cari jawaban buat pertanyaan lain: “browser headless mana yang paling cocok saya pakai?” Padahal, pertanyaan itu sebenarnya kurang tepat, dan Crawlee justru ada untuk menjawab celah itu. Crawlee bukan browser. Ini framework Node/TypeScript yang akan membungkus browser saat memang dibutuhkan, dan melewatinya kalau tidak perlu.
Saya menghabiskan beberapa hari untuk menguji Crawlee 3.17.0 pada serangkaian fixture yang terkontrol dan beberapa situs demo publik, di Node v22.22.3 dan macOS. Janji utamanya — satu library, satu API, dengan HTTP crawler atau browser sungguhan di bawahnya — adalah bagian yang paling saya ingin uji, karena itulah klaim yang menentukan apakah Crawlee layak masuk ke stack Anda atau justru Anda lebih baik langsung memakai Playwright secara langsung. Singkatnya: cerita dua mesin ini memang benar, walau ada beberapa catatan yang nanti saya bahas.
Apa Sebenarnya Crawlee Itu (dan Bukan Itu)
Crawlee mendeskripsikan dirinya sebagai library web scraping dan automasi browser untuk Node.js, yang dibuat untuk membangun crawler yang andal. Posisi resminya cukup luas: mengekstrak data untuk AI, LLM, RAG, atau GPT; mengunduh HTML, PDF, JPG, PNG, dan file lain; mendukung Puppeteer, Playwright, Cheerio, JSDOM, dan HTTP mentah; mode headful atau headless; plus rotasi proxy bawaan. Cakupannya memang besar, jadi penting juga untuk menjelaskan apa yang bukan Crawlee.
Crawlee bukan mesin rendering. Ia tidak punya browser sendiri. Saat Anda ingin JavaScript dijalankan, Crawlee akan mengendalikan Playwright atau Puppeteer, lalu keduanya mengendalikan Chromium (atau browser lain). Crawlee juga bukan layanan hosted yang dipanggil lewat jaringan — melainkan dependensi yang Anda instal dan jalankan sendiri. Jadi, yang paling tepat disebut Crawlee adalah lapisan di atas pengambilan data: kelas crawler, request queue, storage, dan logika mengikuti tautan. Anggap saja ini framework untuk crawl, dengan slot mesin yang bisa dipasang di bawahnya.
Sebagai catatan, versi yang saya uji adalah 3.17.0 (rilis 2026-06-04), ditulis dengan TypeScript, berlisensi Apache-2.0, dan repo-nya berada di sekitar 24.6k bintang per 2026-07-09 di apify/crawlee. Jumlah bintang tentu bisa berubah — repo ini naik 53 dalam dua hari saat saya memantaunya — jadi anggap angka itu sebagai snapshot, bukan sesuatu yang statis.
Dua Mesin: CheerioCrawler vs PlaywrightCrawler
Di sinilah desainnya benar-benar terasa berguna, dan di sinilah saya paling banyak menghabiskan waktu.
CheerioCrawler adalah jalur HTTP. Ia mengambil HTML mentah lewat jaringan lalu mem-parse-nya dengan Cheerio — tanpa browser, tanpa eksekusi JavaScript, tanpa rendering. Cepat dan hemat. PlaywrightCrawler adalah jalur browser. Ia menjalankan Chromium sungguhan, merender halaman termasuk JavaScript yang membentuk DOM, dan bahkan bisa mengambil screenshot.
Dua mesin yang berbeda dengan kemampuan yang memang berbeda. Inti Crawlee adalah: keduanya memakai pola penggunaan yang sama. Keduanya menerima requestHandler. Keduanya punya run(). Keduanya bisa crawl tautan lewat enqueueLinks. Pindah dari satu mesin ke mesin lain cukup ganti kelas, bukan menulis ulang semuanya — saya memverifikasi ini dengan menjaga logika ekstraksi tetap identik byte-per-byte dan hanya mengganti kelas crawler yang membungkusnya.
Ada satu hal yang perlu diperhatikan karena di situlah kesetaraan itu berhenti: cara mengakses kontennya berbeda. Di handler CheerioCrawler, Anda mendapat $ — DOM statis yang sudah diparse dan bisa di-query seperti jQuery. Di handler browser, Anda mendapat objek page yang hidup. Jadi, queue, routing, dan mekanisme “kirim data ini, ikuti tautan itu” tetap sama, tapi bagian membaca isi halaman bentuknya beda. Dokumentasi Crawlee sendiri menjelaskan hal yang sama — interface bersama hanya mencakup operasi crawl, sementara akses kontennya memang berbeda.
| Mesin | Cara mengambil data | Menjalankan JavaScript? | Hasil uji saya (1 halaman dinamis) | Paling cocok untuk |
|---|---|---|---|---|
CheerioCrawler | HTTP mentah + parse Cheerio | Tidak | ~0.035 detik | HTML statis, JSON API, kecepatan |
PlaywrightCrawler | Chromium asli via Playwright | Ya | ~4.967 detik | Halaman hasil render JS, screenshot |
Timing di atas berasal dari satu mesin dan satu kali run — bukan benchmark, hanya gambaran komprominya. Jalur browser memakan waktu sekitar dua orde magnitudo lebih lama pada URL yang sama. Itulah harga rendering, dan itu juga alasan Anda tidak akan memakainya sebagai default.
Pengujian: URL Sama, 0 vs 8/8
Klaim itu murah. Alasan saya percaya pada cerita dua mesin ini adalah karena saya bisa membuatnya gagal, lalu memperbaikinya hanya dengan mengganti satu kelas.
Saya membuat fixture dinamis lokal — halaman katalog dengan kartu produk yang disuntikkan oleh JavaScript setelah load, tipe halaman yang sekarang umum di web modern. Saya arahkan CheerioCrawler ke sana. Hasilnya 0 kartu produk. Itu bukan bug; itu memang konsekuensinya. Cheerio tidak pernah menjalankan JavaScript, jadi kartu-kartu itu memang tidak pernah muncul di HTML yang diparse. Lalu saya arahkan PlaywrightCrawler ke URL yang sama, tanpa mengubah apa pun lagi, dan ia merender 8 dari 8 produk serta mengambil screenshot sebagai bukti.
Supaya ini bukan cuma kebetulan dari fixture buatan saya sendiri, saya menjalankan pola yang sama pada situs publik — halaman demo JavaScript Quotes to Scrape, yang membangun kutipannya di sisi klien. Hasilnya tetap sama: CheerioCrawler melihat 0 quote, sedangkan PlaywrightCrawler berhasil mengambil 10.
Saya ingin hati-hati soal apa yang benar-benar dibuktikan di sini. Ini adalah reproduksi yang rapi dari klaim yang memang sudah didokumentasikan Crawlee — framework ini memang sudah berbagi base class dan interface yang sama di berbagai tipe crawler sejak versi 3.0. Jadi ini lebih tepat disebut verifikasi, bukan penemuan baru. Tapi justru di situlah nilainya: slogan “satu interface, HTTP atau browser” ternyata benar, dan inilah bukti 0 → data penuh pada fixture yang saya kendalikan maupun situs yang tidak saya kendalikan.
Kapan Jalur HTTP Lebih Unggul
Mudah sekali membaca bagian di atas sebagai “selalu pakai browser.” Jangan. Justru inti desain dua mesin ini adalah browser menjadi opsi cadangan yang mahal, bukan pilihan default.
Pada konten statis, CheerioCrawler akurat dan cepat. Fixture katalog statis saya mengembalikan 12 dari 12 produk dengan recall penuh, mengikuti pagination lewat enqueueLinks({ selector: '.next-page' }), hanya dalam sekitar 0,155 detik. Satu halaman artikel juga memberi judul dan 3 dari 3 paragraf isi, sementara teks boilerplate login/subscribe/copyright terpisah rapi dari konten utama.
Yang paling penting untuk diingat: halaman yang datanya dimuat lewat JavaScript sering kali punya JSON API di baliknya. Data pada fixture dinamis saya sebenarnya tersedia di sebuah endpoint, dan saat saya arahkan CheerioCrawler langsung ke API itu, hasilnya 8 dari 8 produk kembali muncul — tanpa browser, hanya sekitar 0,035 detik. Data yang sama pada jalur browser butuh hampir lima detik untuk dirender. Pelajarannya sudah lama, tapi tetap benar: kalau Anda bisa mereproduksi request dasarnya, lakukan itu daripada menjalankan Chromium. Crawlee memberi Anda pilihan ini per crawler tanpa perlu ganti framework.
Bagian Framework Crawl-nya (alasan memilih Crawlee ketimbang browser library mentah)
Kalau yang Anda butuhkan cuma merender satu halaman, Anda sebenarnya tidak perlu Crawlee — Anda cukup pakai Playwright atau Puppeteer langsung. Yang tidak diberikan browser library mentah adalah proses crawl: queue, deduplikasi, kontrol kedalaman, retry. Inilah bagian Crawlee yang sama sekali tidak bergantung pada mesin.
Saya menjalankan crawl dengan hostname yang sama dari root fixture menggunakan enqueueLinks dan pelacakan depth. Crawlee menelusuri 11 halaman pada depth {0:1, 1:3, 2:7} — satu root, tiga halaman satu hop keluar, tujuh halaman dua hop keluar — dan mematuhi maxRequestsPerCrawl sebagai batas berhenti. RequestQueue menangani pencatatannya. Saat saya mengarahkan request ke halaman yang mengembalikan HTTP 500, Crawlee melakukan retry lalu menampilkan kegagalan lewat failedRequestHandler alih-alih diam-diam menelan error atau menjatuhkan proses run.
Ini adalah argumen terkuat untuk Crawlee dibanding alat browser standalone: orkestrasi crawl sudah ada di dalamnya, dan yang paling penting, orkestrasinya sama baik ketika mesin di bawahnya HTTP maupun browser. Anda menulis logika antre dan mengikuti tautan sekali. Lalu Anda putuskan secara terpisah apakah setiap crawler perlu merender JavaScript.
Instalasi dan Unduhan Browser yang Tersembunyi
Proses instalasi umumnya lancar, dengan satu jebakan yang bisa menjatuhkan pengguna baru.
npm install crawlee playwright berjalan bersih — dilaporkan 0 vulnerability. Namun PlaywrightCrawler tidak akan bisa dijalankan sebelum Anda juga menjalankan npx playwright install chromium, yang akan mengunduh binary Chromium sekitar 81,7 MiB. Menginstal paket crawlee saja tidak akan mengambil browser. Kalau Anda melewati langkah ini lalu langsung memakai browser crawler, Anda akan menemui error saat launch yang mungkin tidak jelas kalau belum paham model packaging Playwright. Ini perilaku bawaan Playwright, bukan cacat Crawlee, tapi tetap jadi friksi pertama kali yang patut dicatat.
Satu catatan operasional lagi: secara default Crawlee menulis ke direktori lokal storage/. Harness pengujian saya mengalihkan itu ke temp dir sementara dan mematikan persistence supaya tetap bersih, tetapi run biasa akan meninggalkan folder storage/ di proyek Anda. Bukan masalah, hanya sesuatu yang perlu diketahui sebelum muncul di git status.
Mesin Ketiga, Sekilas
Cerita kesetaraan Crawlee tidak berhenti di Cheerio dan Playwright. Ada juga PuppeteerCrawler, dan saya memeriksa seberapa jauh klaim “interface yang sama” berlaku untuknya — di level kelas dan permukaan API, bukan dengan crawl langsung.
Ketiga kelas crawler itu berakar pada base BasicCrawler yang sama. CheerioCrawler melewati HttpCrawler; PlaywrightCrawler dan PuppeteerCrawler sama-sama melewati BrowserCrawler yang dipakai bersama. Saat mengintrospeksi paket yang terpasang, ada 24 method publik yang dibagi bersama oleh ketiga mesin, termasuk operasi queue dan storage yang jadi fondasi desain ini — run, addRequests, pushData, getData, getDataset, exportData, getRequestQueue, useState, stop. Bahkan PuppeteerCrawler dan PlaywrightCrawler punya set method publik yang identik. Satu-satunya perbedaan lintas mesin ada di batas HTTP versus browser, persis seperti yang Anda harapkan.
Batas yang perlu disebutkan jelas: saya tidak menjalankan crawl langsung dengan PuppeteerCrawler. Peer dependency puppeteer bersifat opsional dan tidak terpasang di paket uji saya, dan mencobanya berarti harus mengunduh browser lagi. Jadi, kesetaraan Puppeteer di sini terverifikasi secara struktural — base class sama, method bersama sama, bentuk context handler sama — bukan lewat run eksekusi. Dan bahkan saat interface-nya cocok, perilaku di bawahnya tetap tidak persis sama: panduan resmi Crawlee menyebutkan bahwa Playwright melakukan auto-wait pada elemen, sementara Puppeteer mengharuskan Anda menunggu secara eksplisit. Itu karakter mesin, bukan kesalahan Crawlee, tapi artinya “API sama” tidak sama dengan “kode di setiap handler juga sama persis.”
Hal yang Tidak Saya Uji
Berikut hal-hal yang memang sengaja saya sisihkan, supaya hasil saya tidak dibaca lebih luas dari yang sebenarnya.
- Skala. Semua dijalankan pada fixture kecil dan crawl publik singkat. Tidak ada run 100–1.000 halaman, jadi saya tidak bisa bicara soal autoscaling atau stabilitas Crawlee di beban nyata.
- Persistensi queue dan resume. Saya tidak pernah sengaja menghentikan crawl di tengah jalan untuk melihat apakah
RequestQueuebisa melanjutkan dengan mulus setelah crash. Itu kemampuan penting untuk job panjang dan belum saya uji di sini. - Ekspor Dataset dan KeyValueStore. Saya menulis ekspor JSON/CSV secara manual di harness. Ergonomi ekspor bawaan
Dataset/KeyValueStoreCrawlee — yang bisa dibilang salah satu nilai praktis framework ini — tidak saya coba. - Proxy dan session pool. Crawlee memang menyertakan rotasi proxy dan fitur fingerprinting. Saya melihat ini murni sebagai topik kepatuhan dan operasional, bukan fitur “bypass anti-bot”, dan saya tidak menguji stresnya ke arah mana pun.
Dan semua angka timing di atas berasal dari satu mesin dan satu kali run. Angka itu menunjukkan bentuk biaya HTTP versus browser. Itu bukan benchmark, dan saya tidak akan mengutipnya sebagai benchmark.
Kelebihan dan Kekurangan
Kelebihan
- Satu permukaan API untuk crawling HTTP dan browser — pergantian mesin benar-benar cuma ganti kelas, terbukti dari 0 → data penuh pada fixture lokal dan situs publik.
- Framework crawl yang benar-benar lengkap:
RequestQueue,enqueueLinksdengan kontrol depth, retry, danfailedRequestHandler, bukan sekadar renderer halaman. - Ekstraksi HTTP yang akurat (12/12 statis, 3/3 paragraf artikel, 8/8 lewat JSON API) saat JavaScript bukan hambatan.
- Jalur browser bisa mengambil konten yang memang tidak bisa dilihat oleh jalur HTTP, plus screenshot.
- Apache-2.0, TypeScript, dan aktif dipelihara.
Kekurangan
- Browser crawler butuh
npx playwright install chromiumterpisah (~81,7 MiB) yang tidak ditangani olehnpm install crawlee— mudah kelupaan. - Rendering browser membawa biaya nyata per halaman (~5 detik vs di bawah satu detik pada uji satu halaman saya).
- Efek samping direktori
storage/secara default pada run biasa. - Skala, persistensi/resume queue, dan ergonomi ekspor Dataset belum terbukti dalam pengujian saya.
- Fitur proxy dan fingerprinting harus dipakai sesuai syarat situs dan hukum — tanggung jawab, bukan fitur untuk dipakai sembarangan.
Kapan Memilih Crawlee vs API Managed
Crawlee adalah alat yang Anda bangun sendiri, dan itu pilihan yang tepat untuk banyak tim. Pakai saat Anda ingin punya crawler di codebase Node Anda sendiri, menggabungkan crawling HTTP dan browser dalam satu proyek tanpa ganti framework, dan mengendalikan queue serta storage sendiri. Kalau Anda nyaman menjalankan — dan pada akhirnya menskalakan — armada browser sendiri, Crawlee memberi fondasi yang rapi dan dirancang dengan baik.
Jalur lainnya adalah tidak menjalankan infrastruktur itu sama sekali. Kalau Anda tidak mau menghabiskan waktu engineering untuk mengurus instance Chromium, rotasi proxy, dan penanganan anti-bot, maka API managed adalah alternatifnya — dan di situlah stack developer kami di Thunderbit cocok. Untuk pengguna teknis, Thunderbit bukan extension Chrome; melainkan API scraping AI, MCP server, dan CLI. Anda memanggil POST /distill untuk mengubah halaman menjadi Markdown yang bersih dan siap untuk LLM, atau POST /extract dengan JSON Schema untuk mendapatkan data terstruktur, dengan renderMode none, basic, atau full supaya Anda bisa menentukan kapan full browser render memang layak dipakai. MCP server memungkinkan AI agent (Claude, Cursor, dan klien MCP lain) melakukan scraping di tengah tugas, dan CLI bisa dijalankan dari terminal atau CI:
Coba Thunderbit untuk Ekstraksi Data Web
npx -y @thunderbit/thunderbit-cli distill "<url>" -f markdown > out.md
Perbedaan yang penting buat developer: Crawlee memberi Anda bahan mentah — HTML yang sudah dirender, node yang sudah diparse — dan Anda yang memegang pipeline-nya; managed API mengembalikan JSON terstruktur yang cocok dengan schema, dengan rendering JS, CAPTCHA, dan anti-bot ditangani di sisi server. Tugasnya memang berbeda. Kalau Anda ingin kontrol maksimal dan tidak keberatan dengan operasional, pilih Crawlee. Kalau Anda ingin datanya tanpa perlu mengelola armada browser, pilih jalur managed. Banyak tim akhirnya memakai keduanya: satu untuk crawl khusus, satu lagi untuk kasus “tolong berikan data terstruktur saja”. Anda bisa lihat trade-off biayanya di harga Thunderbit.
Kesimpulan
Jadi, apakah Anda sebaiknya memakai Crawlee? Ya — kalau Anda adalah developer Node atau TypeScript yang menginginkan satu framework yang mencakup crawling HTTP dan browser dengan queue crawl yang nyata di bawahnya. Janji dua mesin adalah alasan utama untuk memilihnya, dan itu terbukti rapi pada fixture saya: URL yang sama berubah dari 0 menjadi data penuh hanya dengan mengganti satu kelas, ekstraksi statis akurat dan cepat, dan crawling berbasis queue serta depth berjalan sesuai dokumentasi.
Masuklah dengan dua hal di pikiran. Sisihkan anggaran untuk unduhan browser tersembunyi saat pertama kali memakai PlaywrightCrawler, dan jangan mengira bagian yang tidak saya uji — skala, resume setelah crash, ekspor bawaan — akan bekerja sama baiknya dengan bagian yang saya uji sebelum Anda menjalankannya pada workload Anda sendiri. Sebagai fondasi untuk membangun crawler Anda sendiri, Crawlee adalah engineering yang kuat dan dirancang dengan baik. Sebagai pipeline data jadi yang sepenuhnya otomatis, Crawlee adalah titik awal, bukan tujuan akhir.
Coba Thunderbit untuk Ekstraksi Data Web Get Started Free
FAQ
Apakah Crawlee gratis, dan lisensinya apa?
Ya. Crawlee adalah open source dengan lisensi Apache-2.0 dan dipasang dari npm (npm install crawlee). Versi yang saya uji adalah 3.17.0. Menjalankan browser crawler butuh unduhan Chromium terpisah melalui Playwright, yang juga gratis tetapi menambah sekitar 81,7 MiB pada setup Anda.
CheerioCrawler vs PlaywrightCrawler — sebaiknya pakai yang mana?
Gunakan CheerioCrawler saat data sudah ada di HTML mentah atau JSON API di baliknya — jauh lebih cepat dan tidak pernah membuka browser. Gunakan PlaywrightCrawler saat konten dirender oleh JavaScript, yang bisa Anda kenali ketika jalur HTTP menghasilkan hasil kosong. Dalam pengujian saya, mesin HTTP mengembalikan 0 item pada halaman yang dirender JS, sedangkan mesin browser mengembalikan semuanya. Karena API-nya sama, perpindahannya cukup ganti kelas, bukan menulis ulang.
Apakah Crawlee membutuhkan browser untuk berjalan?
Hanya untuk browser crawler. CheerioCrawler sama sekali tidak membutuhkan browser. PlaywrightCrawler (dan PuppeteerCrawler) membutuhkan binary browser — instal dengan npx playwright install chromium. Perlu dicatat bahwa npm install crawlee saja tidak akan mengambil browser, dan itulah jebakan pertama yang paling sering terjadi.
Bisakah Crawlee menangani pagination dan crawl multi-halaman?
Bisa, dan ini salah satu alasan utama memilihnya dibanding library browser standalone. enqueueLinks mengikuti tautan (termasuk selector pagination seperti .next-page), RequestQueue melakukan deduplikasi dan mengelola crawl, serta Anda mendapat kontrol depth dan batas maxRequestsPerCrawl. Dalam pengujian, crawl pada hostname yang sama menelusuri 11 halaman pada depth 0–2, dan request yang gagal muncul lewat failedRequestHandler.
Bagaimana perbandingan Crawlee dengan API scraping hosted?
Crawlee bersifat self-hosted: Anda menulis dan menjalankan crawler, serta bertanggung jawab atas scaling, proxy, dan penanganan anti-bot. Managed API seperti endpoint distill/extract milik Thunderbit mengembalikan Markdown bersih atau JSON terstruktur yang cocok dengan schema, dengan rendering dan anti-bot ditangani di sisi server, dan tersedia melalui API, MCP server, serta CLI. Pilih Crawlee kalau Anda ingin kontrol maksimal atas pipeline Anda sendiri; pilih managed API kalau Anda tidak ingin menjalankan dan menskalakan infrastruktur browser sendiri.
