Ulasan Browserless: Chrome sebagai Layanan yang Bisa Anda Atur Kuotanya

Browserless adalah Chrome headless yang dikemas sebagai layanan yang Anda host sendiri. Kontainer Docker-nya tetap berjalan, menerima pekerjaan lewat HTTP atau WebSocket, lalu menerapkan batas penerimaan bersama, alih-alih di-import ke tiap pemanggil. Dalam pengujian REST di sini, layanan ini punya 0 proses Chrome saat idle, membuat proses Chrome saat ada permintaan aktif, lalu kembali ke nol setelahnya. Yang dibagi bersama adalah kapasitas layanan dan antrean, bukan kumpulan proses browser yang sudah dipanaskan lebih dulu.

Saya menguji v2.55.0 pada fixture lokal yang terkontrol — startup dipecah ke beberapa tahap, kontrol penerimaan pada tiga konfigurasi, ketepatan endpoint dibandingkan dengan ground truth yang diketahui, soak 30 sesi, dan batas timeout. Hasil yang paling berguna bukan angka kecepatannya, melainkan perilaku operasional: batas penerimaan cocok dengan respons yang dilihat klien, dan sisi-sisi tajamnya terutama berkaitan dengan cara deployment.

Hasil yang paling berguna ternyata bukan angka latensi. Browserless tidak membuat Chrome mulai lebih cepat — ia memasang aturan akses di depan Chrome: sejumlah sesi tertentu boleh masuk, sisanya mengantre, dan semua yang kehabisan jatah kena HTTP 429. Batas itu bergeser dari 4 ke 8 ke 10 saat saya mengubah dua variabel lingkungan, dan pencatatan internal kontainer konsisten dengan status code klien pada setiap permintaan.

Apa sebenarnya Browserless itu

Di sini banyak orang sering keliru soal kategorinya. Browserless bukan library yang Anda import lalu panggil. Ini adalah image Docker — ghcr.io/browserless/chromium — yang dijalankan sebagai layanan jangka panjang. Browserless menjadi perantara pekerjaan browser dan mengeksposnya lewat dua cara: endpoint REST (/content, /scrape, /screenshot, /pdf, plus /function dan /unblock) serta permukaan CDP/WebSocket yang bisa di-connect() oleh Puppeteer dan Playwright.

Saya menguji permukaan REST. Jalur WebSocket itu nyata dan banyak dipakai, tetapi tidak saya ukur.

Versi yang diuji adalah v2.55.0, diperiksa pada 27 Juli 2026.

Jumlah bintang berubah-ubah; anggap saja itu sebagai pembacaan pada saat tertentu.

Gerbang lisensi: SSPL-1.0 atau komersial

Repositori ini menawarkan Browserless di bawah SSPL-1.0 atau lisensi komersial Browserless. Baca tepatnya file LICENSE repositori saat ini dan panduan resmi deployment open-source dari Browserless sebelum memilih jalur. Artikel ini tidak melakukan analisis hukum atas produk komersial, aplikasi closed-source, sistem CI, layanan terkelola, atau deployment internal, jadi tidak menetapkan skenario-skenario tersebut ke satu lisensi tertentu. Mintalah penasihat hukum atau pihak yang bertanggung jawab atas lisensi software untuk mengevaluasi model deployment dan distribusinya.

Browserless juga menjual paket hosted. Harga dan definisi unit penggunaan bisa berubah-ubah dan tidak menjadi bagian dari pengujian self-hosted ini, jadi verifikasikan langsung di situs resmi, jangan menganggap tabel usang di sini sebagai bukti pengadaan.

Cara kerja model sesi di balik layar

Jalur REST yang saya ukur berperilaku seperti pekerjaan browser per permintaan, tetapi harness ini tidak menelusuri internals Browserless cukup dalam untuk membedakan proses browser baru dari semua strategi penggunaan ulang konteks yang mungkin. Yang berhasil dibuktikan lebih sederhana: 0 proses Chrome saat idle, 11 proses keluarga Chrome saat ada permintaan aktif, dan 0 setelah run berurutan selesai. Tidak ada bukti adanya pool browser yang sudah dipanaskan sebelumnya pada konfigurasi ini.

Layanan Node yang berjalan terus-menerus menerima sejumlah pekerjaan browser yang terbatas, mengantrekan sejumlah lain yang juga terbatas, lalu menolak sisanya. Anggap model penerimaan itu sebagai kontrak arsitektural yang diukur di bawah ini. Jangan menyimpulkan adanya reuse proses atau konteks hanya dari kata “pool”; harness timing tidak bisa membuktikannya.

Kontrol penerimaan punya dua pengaturan:

• CONCURRENT — berapa banyak sesi yang berjalan sekaligus.
• QUEUED — berapa banyak permintaan tambahan yang boleh menunggu slot.

Endpoint /config pada kontainer melaporkan default CONCURRENT=10, QUEUED=10, TIMEOUT=30000. Apa pun di luar CONCURRENT + QUEUED langsung ditolak.

Autentikasi bukan opsi. Browserless v2 selalu memerlukan token — kalau Anda tidak menetapkan TOKEN, sistem akan membuat token acak dan mencetaknya ke stdout saat startup. Setiap panggilan REST membawa ?token=.

Untuk observabilitas, Anda mendapat /pressure (running, queued, CPU, memory, recently rejected), /sessions, dan /config. Ada juga ekspor JSON /metrics, tetapi perlu METRICS_JSON_PATH diatur dan saya tidak memakainya. Image ini juga menjalankan dumb-init sebagai PID 1, yang merupakan jawaban terdokumentasi atas keluhan zombie-process yang sudah bertahun-tahun mengikuti Chrome di dalam kontainer.

Realita setup: satu perintah, dan empat hal yang tidak ada di dalam satu perintah itu

Perintah instalasi yang sering dikutip memang hanya satu docker run. Tapi hal-hal di sekitarnya tetap harus Anda rencanakan.

Ukuran image-nya 4,34 GB. Itu angka yang seharusnya membentuk ekspektasi Anda, bukan latensi startup. Manifest-nya memuat linux/arm64 dan linux/amd64; di host arm64 saya, Docker mengambil varian arm64 native. (User-agent Chrome di dalam kontainer tetap membaca X11; Linux x86_64 — itu hanya UA kosmetik Chrome di Linux, bukan emulasi. uname -m menunjukkan aarch64. Orang sering mengira ini bug.)

Saya memakai --shm-size=2g untuk semua pengukuran. Harness ini tidak menyertakan run pembanding pada /dev/shm default milik Docker, jadi artikel ini tidak bisa menyatakan 2 GiB wajib secara universal atau mengukur titik gagalnya. Sesuaikan ukuran dengan jumlah browser dan beban kerja Anda.

Token adalah urusan deployment, bukan formalitas. Tanpanya, siapa pun yang bisa menjangkau port 3000 dapat menguasai browser di jaringan Anda.

Networking kontainer adalah tanggung jawab Anda. Fixture saya berjalan di host, jadi kontainer menjangkaunya lewat host.docker.internal (colima memetakannya dengan --add-host host.docker.internal:host-gateway). Saya memverifikasi bahwa kontainer benar-benar bisa mencapai fixture itu dengan curl mentah sebelum mempercayai pengukuran apa pun.

Lingkungan saya: colima 0.10.3 (6 CPU / 11.6 GiB) dengan Docker 29.2.1 di macOS 26.5.2 arm64. Harness ini hanya memakai Python 3 stdlib. Untuk PNG dan PDF, yang diperiksa hanya tanda tangan file, bukan validitas decoder, dimensi, jumlah halaman, kelengkapan, atau fidelitas visual.

Peluncuran minimal yang setara memakai image yang dipin, token eksplisit, dan alokasi shared-memory yang dipakai di sini:

docker run --rm -p 3000:3000 --shm-size=2g \
  -e TOKEN=replace-with-a-secret \
  ghcr.io/browserless/chromium:v2.55.0

Setelah /pressure?token=... merespons, POST /content?token=... yang terautentikasi dengan body JSON berisi URL target akan menguji jalur REST. Pemanggil produksi juga perlu retry terbatas dengan jitter untuk respons 429; retry seketika cuma akan berlomba lagi dengan antrean yang sama-sama penuh.

Biaya startup, dipecah per tahap

Tiga boot docker run baru, median dengan min–maks:

Baris tengah ini mudah disalahartikan. Ini tidak mengukur startup browser secara terpisah dan tidak menunjukkan bahwa Browserless memulai Chrome lebih cepat daripada library dalam proses. Ini adalah round trip HTTP ke dalam kontainer ditambah kerja browser, navigasi, dan transfer respons. Selisih sekitar 0,17 detik antara request pertama dan berikutnya bisa saja mencakup efek filesystem, OS, Chrome, Node, atau cache kontainer. Karena saat idle proses Chrome bernilai nol dan harness tidak menangkap trace CDP atau timeline proses untuk panggilan-panggilan ini, selisih itu tidak bisa diatributkan pada reuse browser atau biaya startup yang “diamortisasi”.

Juga: angka ini berasal dari colima VM di macOS. Linux bare-metal akan berbeda. Jangan mengutip 0,78 dtk ke tim SRE Anda seolah-olah itu portabel.

Praktik langsung: mencari batas, dari dua sisi

Kontrak CONCURRENT + QUEUED → 429 diulang di banyak tempat, tetapi jarang benar-benar diperlihatkan.

Setup-nya: sebuah route fixture yang sleep 5 detik di sisi server, sehingga setiap permintaan pasti menempati satu sesi selama durasi yang diketahui. Lalu kirim CONCURRENT + QUEUED + 4 permintaan secara bersamaan dan lihat apa yang kembali — sementara sebuah thread sampler terpisah melakukan polling /pressure untuk membaca pencatatan internal kontainer.

Ada tiga hal yang bisa disimpulkan dari sini.

Batasnya persis CONCURRENT + QUEUED, setiap saat. Respons sukses masing-masing jadi 4, 8, dan 10 — sesuai jumlah konfigurasi di tiap kasus. Penolakan sama dengan kelebihan permintaan, yakni 4 dalam ketiga run.

Batas itu bisa berubah. Ini bukan angka tetap yang tertanam di image; angka itu mengikuti konfigurasi Anda. Berpindah dari 4 → 8 → 10 hanya dengan mengubah variabel lingkungan adalah bagian yang membuatnya berguna, bukan sekadar trivia.

Dan dua sinyal itu independen. Status code klien saya berasal dari respons HTTP nyata; /pressure berasal dari pencatatan internal kontainer sendiri, dipolling oleh thread lain. Keduanya selaras dalam tiga run singkat ini. Itu membuat /pressure layak dipertimbangkan sebagai sinyal produksi, tetapi bukan kontrak autoscaling yang lengkap: frekuensi scraping, semantik reset, agregasi multi-replika, dan perilaku pada beban campuran yang lebih lama masih perlu divalidasi.

Satu nuansa yang tersembunyi di balik hitung sukses/gagal. Permintaan yang masuk antrean tidak gagal — ia menunggu, dan bisa menunggu cukup lama. Pada (2, 2) dengan pekerjaan 5 detik, respons sukses datang antara 5,7 dtk sampai 11,0 dtk, median 8,3 dtk. Jadi latensi end-to-end mencapai kira-kira dua durasi sesi. Harness ini tidak menangkap timestamp terpisah untuk admission dan execution, jadi tidak bisa menisbahkan seluruh delay ke waktu tunggu antrean.

Seperti apa ini pada pekerjaan nyata

Bayangkan Anda merender 4.000 halaman produk ke PDF setiap malam, dan tiap halaman memakan waktu sekitar 5 detik. Anda menetapkan CONCURRENT=5, QUEUED=5. Batas throughput Anda adalah 5 halaman per 5 detik — satu halaman per detik — jadi pekerjaan selesai sekitar 67 menit kalau aliran selalu penuh tepat. Itu aritmetika berdasarkan perilaku terukur, bukan benchmark, tetapi itulah aritmetika yang seharusnya Anda lakukan sebelum deploy.

Permintaan apa pun yang datang setelah semua slot running dan queued terpakai bisa langsung mendapat 429; pengiriman simultan tidak menjamin urutan permintaan mana yang kalah balapan. Job runner harus memperlakukan respons itu sebagai backpressure dan memakai retry terbatas dengan jitter. Kalau tidak, halaman bisa hilang sementara akuntansi pekerjaan tingkat atas tetap berjalan — sebuah risiko operasional, bukan skenario kegagalan yang dibuktikan oleh harness ini.

Praktik langsung: apa yang benar-benar dilihat endpoint

Untuk menguji fidelitas render secara jujur, halaman fixture menyembunyikan teks penandanya dari siapa pun yang tidak menjalankan browser sungguhan. String yang terlihat Runtime Injected Marker 88 dirangkai dari fragmen JavaScript saat load, jadi tidak ada literal utuhnya dalam byte apa pun yang dikirim server. Fetch statis biasa atas halaman itu hanya mengembalikan 702 byte tanpa penanda tersebut.

/content yang mengembalikan 811 byte dengan penanda yang diinjeksi berarti Chromium sungguhan merender halaman sebelum HTML dikembalikan. /scrape mengambil nilai dari node yang tidak ada sampai JavaScript berjalan. Keduanya bekerja tanpa kode automasi sisi klien sama sekali — cukup satu POST terautentikasi.

Itulah pitch sebenarnya. Pada putaran pengujian yang sama, crawler statis melewatkan kelas konten ini sepenuhnya, dan library browser dalam proses (chromedp, rod, Selenium) baru menangkapnya setelah saya menulis explicit wait. Browserless menangkapnya dengan request berbentuk curl. Anda menukar kode automasi dengan bobot deployment.

Ada dua batas untuk klaim itu. Bukti di sini mencakup kelas konten fixture saya, bukan survei atas web modern. Dan /unblock, endpoint anti-detection, sengaja tidak disentuh — hasil-hasil ini tidak boleh dibaca sebagai klaim kemampuan anti-bot. /function, /download, dan /performance juga tidak diuji.

Praktik langsung: cek residu singkat

Chrome di dalam kontainer punya reputasi meninggalkan bangkai proses, jadi saya menjalankan 30 sesi berurutan dengan CONCURRENT=3 dan menghitung proses di dalam kontainer.

Sebelum mempercayai apa pun, saya mengkalibrasi detektornya. Saat sebuah sesi masih berjalan, enumerator /proc membaca 11 proses keluarga Chrome (browser, zygote, GPU, renderer, utility). Itu penting: ini membuktikan instrumen benar-benar bisa melihat Chrome, sehingga nilai nol setelah run selesai adalah hasil pengukuran, bukan karena buta. Tes kebocoran yang melaporkan "0 proses" tanpa membuktikan bahwa ia bisa menghitung adalah tidak berguna.

Setelah 30 sesi: 0 proses chrome, 0 zombie. Satu-satunya yang bertahan adalah dumb-init, node, Xvfb, start.sh, dan sh. /sessions membaca 0 saat idle.

Memori kontainer, dari docker stats (angka yang terlihat oleh operator, bukan RSS satu proses):

Pertumbuhan bersih selama 30 sesi: sekitar 9,5 MB, dan kurva sampel mendatar setelah sesi ke-10. Itu tidak konsisten dengan kebocoran linear sederhana per sesi dalam jendela pendek ini. Warmup Node adalah salah satu penjelasan yang masuk akal, bukan sesuatu yang bisa dibuktikan oleh jumlah proses dan deret memori ini.

Cakupan: 30 sesi berurutan adalah soak kecil, bukan uji ketahanan atau konkurensi. Peringatan listener EventEmitter yang sudah lama ada di tracker isu adalah jenis hal yang bisa muncul setelah berjam-jam dan ribuan sesi, dan saya tidak menjalankannya. Kesimpulan yang didukung hanyalah bahwa tidak ada penumpukan proses Chrome atau zombie yang teramati dalam jendela ini pada v2.55.0.

Batas timeout

TIMEOUT didokumentasikan sebagai sebuah pengaturan. Saya ingin melihatnya benar-benar bekerja.

Dengan TIMEOUT=5000, sesi yang mencoba menahan halaman selama 15 detik mengembalikan HTTP 408 pada 5,007 dtk alih-alih menggantung. Satu observasi ini mengonfirmasi penegakan di dekat batas yang dikonfigurasi. Ini belum mengungkap implementasi timer atau membuktikan pembersihan slot; pengujian yang lebih kuat adalah mengulang percobaan, mengamati /sessions dan /pressure kembali idle, lalu memastikan bahwa permintaan berikutnya memperoleh slot yang sudah bebas.

Jebakan migrasi: PREBOOT tidak aktif, dan ia tidak memberi tahu Anda

Dari semua yang saya ukur, inilah hasil yang paling ingin saya dapatkan sebelum melakukan upgrade.

Browserless 2.0.0 menghapus PREBOOT dan KEEP_ALIVE — changelog menyebut keduanya dibuang karena membingungkan, hampir tidak berguna, dan menimbulkan bug. Keputusan yang masuk akal. Masalahnya muncul saat konfigurasi v1 disalin begitu saja ke v2, karena itulah cara upgrade yang paling umum dilakukan.

Saya menjalankan kontainer dengan -e PREBOOT=true dan membandingkannya dengan default:

Semua timing berada di dalam rentang min–maks arm default itu sendiri — itu noise, bukan efek. Dan tidak ada yang dipanaskan sebelumnya: kontainer PREBOOT=true saat idle tetap tidak memegang browser apa pun, identik dengan kontainer tanpa flag tersebut. Dua sinyal lagi, dan keduanya bukan angka:

• /config tidak menampilkan key preboot sama sekali. Key yang ada adalah concurrent, queued, timeout, token, maxCPU, maxMemory, retries, dan lain-lain.
• Tidak ada error. Tidak ada peringatan. Tidak ada apa pun di log kontainer.

Jadi konfigurasi PREBOOT v1 pada v2 menjadi no-op yang diam dalam startup normal dan pengecekan log. Key /config yang hilang plus perilaku yang tidak berubah adalah sinyal yang bisa dideteksi; Browserless tidak mengeluarkan penolakan atau peringatan eksplisit. Pemeriksaan migrasi perlu meninjau konfigurasi yang benar-benar diterapkan, bukan menganggap startup yang hijau sebagai bukti bahwa semua variabel lingkungan berjalan.

KEEP_ALIVE adalah kasus yang kebalikannya, dan keduanya tidak boleh disamakan. Fitur itu dihapus pada rilis yang sama, tetapi tidak diam — pemeriksaan spot pada kontainer menunjukkan ia menulis Environment variable of "KEEP_ALIVE" is deprecated and ignored. langsung ke stdout. Itu peringatan yang layak untuk operator. Saya tidak menjalankan KEEP_ALIVE melalui harness terukur yang sama seperti PREBOOT, jadi saya melaporkannya sebagai pengecekan, bukan sebagai pengukuran. Namun arahnya cukup jelas untuk berarti: hanya PREBOOT yang merupakan jebakan diam-diam. Browserless lebih jujur soal KEEP_ALIVE daripada yang akan diberikan oleh ringkasan umum "v2 mengabaikan flag v1 Anda".

Kelebihan dan kekurangan

Kelebihan

• Kontrol penerimaan yang bekerja persis seperti dokumentasi dan berubah mengikuti konfigurasi — dibuktikan pada tiga batas berbeda, baik pada status code klien maupun pada pencatatan internal server secara bersamaan.
• /pressure cocok dengan hitungan running, queued, dan rejected yang terlihat klien dalam tiga run singkat; pertimbangkan ini sebagai salah satu masukan untuk autoscaling dan alerting.
• Rendering Chromium sungguhan tanpa kode automasi sisi klien: satu POST terautentikasi menampilkan DOM yang diinjeksi JS dan tidak bisa dilihat oleh fetch statis pada halaman yang sama.
• Tidak ada penumpukan proses Chrome pada run berurutan 30 sesi; jumlah akhir adalah 0 proses Chrome dan 0 zombie.
• Satu percobaan TIMEOUT mengembalikan 408 pada 5,007 dtk terhadap anggaran 5,000 dtk; pembersihan dan pelepasan slot tidak diverifikasi terpisah.
• Autentikasi aktif secara default: keempat endpoint REST mengembalikan 401 tanpa token.
• Satu docker run menuju layanan siap pakai dalam sekitar 0,78 dtk, dan render pertama 0,32 dtk setelah itu.

Kekurangan

• Image 4,34 GB. Itu biaya utama yang jujur, dan muncul di registry Anda, cache CI Anda, serta waktu cold-deploy Anda.
• Lisensi SSPL-1.0 atau lisensi komersial Browserless. Evaluasi syarat saat ini terhadap model deployment dan distribusi Anda.
• PREBOOT dari v1 diterima dan diabaikan tanpa suara pada v2 — tanpa error, tanpa peringatan, tanpa key /config.
• Anda mengoperasikan sebuah layanan, bukan sekadar menambah dependency: ada kontainer, token, jalur jaringan, batas penerimaan, dan tanggung jawab upgrade.
• Permintaan yang masuk antrean mendorong latensi end-to-end menjadi kira-kira dua durasi sesi dalam run (2, 2); waktu tunggu antrean terpisah tidak diukur.
• Timing REST yang diukur mencakup satu hop HTTP dan tidak memisahkan biaya startup browser atau membuktikan reuse browser.

Siapa yang sebaiknya menjalankannya, dan siapa yang sebaiknya tidak

Browserless memang layak dipakai ketika lebih dari satu hal membutuhkan browser. Layanan rendering yang dipakai bersama beberapa aplikasi, tim yang ingin screenshot dan PDF lewat endpoint HTTP alih-alih dependency Chrome di tiap service, pipeline kerja yang benar-benar membutuhkan batas kapasitas dengan backpressure yang bisa diukur — itulah bentuk yang cocok. Kalau Anda sudah menjalankan Docker dan ada pihak yang mengelola deploy, ceritanya jelas: penerimaan yang bisa diprediksi, backpressure yang terlihat, dan tidak ada penumpukan proses Chrome atau zombie yang teramati pada pemeriksaan 30 sesi berurutan.

Ini juga pilihan yang tepat kalau alternatifnya adalah setiap service di stack Anda memasang Chromium sendiri. Menyatukan semuanya ke satu kontainer dengan token dan batas kapasitas adalah trade arsitektural yang memang masuk akal.

Lewatkan kalau Anda cuma menulis satu skrip. Menarik 4,3 GB lalu menjalankan kontainer hanya supaya satu file Python bisa mengambil halaman yang sudah dirender adalah terlalu banyak seremoni untuk pekerjaan kecil — library browser di dalam proses Anda melakukannya tanpa layanan terpisah. Lewatkan kalau syarat SSPL tidak cocok untuk produk komersial Anda dan tidak bisa diselesaikan. Lewatkan kalau yang sebenarnya Anda butuhkan adalah browser yang langsung datang dalam keadaan hangat tanpa biaya dingin, karena PREBOOT tidak akan memberi itu di v2. Dan lewatkan kalau masalah Anda sebenarnya adalah penanganan anti-bot, karena itu ada di endpoint yang sengaja tidak saya uji dan tidak akan saya jamin.

Alternatif, termasuk posisi Thunderbit

Perbandingan yang layak dibuat bukan Browserless melawan kontainer lain. Yang penting adalah browsernya hidup di mana, dan siapa yang bertanggung jawab menjaganya tetap hidup.

Ulasan terkait: ulasan Browsertrix Crawler.

Ulasan terkait: ulasan chromedp.

Kalau Anda ingin browser di dalam proses sendiri dan tidak keberatan menulis wait, library memang lebih ringan dan tidak ada deployment terpisah. Saya sudah menulis sisi itu dalam perbandingan Playwright versus Puppeteer dan roundup proyek scraping open-source yang lebih luas.

Kalau Anda tidak ingin mengoperasikan browser sama sekali, Thunderbit kami sendiri adalah salah satu alternatif terkelola. Browserless mengembalikan material hasil render yang kemudian diinterpretasikan kode Anda; Thunderbit bisa mengembalikan Markdown atau data yang cocok dengan schema sementara penyedia yang memegang infrastruktur rendering. Artikel ini tidak membenchmark latensi, kapasitas, perilaku kegagalan, kualitas ekstraksi, atau biaya Thunderbit, jadi tabel di atas menjelaskan batas tanggung jawab, bukan perbandingan performa.

Bacaan terkait dari putaran pengujian yang sama: ulasan Crawl4AI membahas pipeline Markdown berbasis browser yang Anda jalankan sendiri, dan ikhtisar web scraping tools memetakan kategori yang lebih luas.

Coba Thunderbit untuk Ekstraksi Data Web

Putusan akhir

Perlukah Anda menjalankan Browserless? Ya, kalau beberapa pemanggil membutuhkan kerja browser, ada pihak yang bisa mengoperasikan kontainernya, dan tinjauan lisensi Anda menyetujui model deployment tersebut. Dalam tiga run penerimaan sintetis, jumlah yang diterima cocok dengan CONCURRENT + QUEUED, kelebihan permintaan kena 429, dan /pressure cocok dengan hitungan yang terlihat klien. Dalam pemeriksaan berurutan 30 sesi terpisah, tidak ada proses Chrome atau zombie yang menumpuk. Satu percobaan timeout mengembalikan 408 di dekat batas yang dikonfigurasi. Itu semua observasi terbatas yang berguna, bukan jaminan universal.

Tetap ukur komitmennya dengan jujur. Ini image 4,34 GB dan sebuah layanan yang Anda operasikan, bukan dependency yang Anda tambahkan; pengujian ini tidak membuktikan perbandingan kecepatan dengan library browser dalam proses. Yang didapat adalah browser yang bisa Anda ration: batas yang diketahui dan backpressure yang terukur. Dalam pemeriksaan berurutan 30 sesi, tidak ada penumpukan proses Chrome atau zombie yang teramati. Biayanya adalah bobot deployment dan lisensi yang perlu Anda baca. Kalau Anda hanya merender beberapa halaman dari satu skrip, trade-off itu tidak sepadan. Kalau Anda menjalankan lapisan rendering yang dipakai beberapa service, maka iya — hanya saja cek variabel lingkungan v1 Anda saat masuk, karena PREBOOT akan terlihat seperti sedang bekerja padahal sama sekali tidak melakukan apa-apa.

Coba Thunderbit untuk Ekstraksi Data Web Get Started Free

FAQ

Apakah Browserless membuat headless Chrome lebih cepat? Pengujian ini tidak bisa menjawab itu. Endpoint HTTP menjadi responsif 0,78 dtk setelah docker run; panggilan /content pertama kemudian memakan 0,32 dtk dan panggilan berikutnya di kontainer yang sama sekitar 0,15 dtk. Angka-angka ini menggabungkan round trip HTTP, kerja browser, navigasi, dan transfer respons. Harness ini tidak mengisolasi waktu peluncuran, tidak menelusuri reuse proses, dan tidak menerbitkan benchmark in-process yang sebanding. Pakai Browserless sebagai batas layanan bersama dan kontrol penerimaan, lalu ukur sendiri jalur latensi Anda.

Apa yang terjadi kalau Anda melewati batas konkurensi Browserless? Anda langsung mendapat HTTP 429. Batasnya persis CONCURRENT + QUEUED, dan saya mengonfirmasinya pada tiga konfigurasi: (2,2) menerima 4 dan menolak 4, (3,5) menerima 8 dan menolak 4, (5,5) menerima 10 dan menolak 4. Endpoint /pressure pada server melaporkan jumlah running, queued, dan recentlyRejected yang cocok setiap kali. Perlu dicatat: permintaan yang antre tidak gagal, mereka menunggu — pada (2,2) dengan pekerjaan 5 detik, respons sukses memakan waktu antara 5,7 dtk dan 11,0 dtk. Bangun klien Anda agar memperlakukan 429 sebagai backpressure dengan retry dan backoff.

Apakah PREBOOT masih bekerja di Browserless v2? Tidak. PREBOOT dihapus pada 2.0.0, dan v2 menerima -e PREBOOT=true tanpa error atau peringatan sambil tidak melakukan apa pun dengannya. Saya mengonfirmasi sifat inert ini dengan tiga cara: latensinya tak bisa dibedakan dari default, kontainer PREBOOT=true yang idle memiliki 0 proses chrome yang menunggu, dan /config tidak menampilkan key preboot sama sekali. Kalau Anda memigrasikan konfigurasi v1, instance Anda tidak dipanaskan sebelumnya. Perhatikan bahwa KEEP_ALIVE, yang dihapus pada rilis yang sama, memang menulis peringatan "deprecated and ignored" — jadi masalah kegagalan diam-diam itu spesifik pada PREBOOT.

Apakah Browserless gratis untuk penggunaan komersial? Repositori menawarkan SSPL-1.0 atau lisensi komersial Browserless, tetapi artikel ini tidak memetakan skenario komersial atau closed-source tertentu ke salah satu opsi. Tinjau LICENSE dan panduan deployment resmi saat ini, lalu minta pihak yang bertanggung jawab atas lisensi software mengevaluasi model deployment dan distribusi Anda.

Apakah Browserless meninggalkan proses Chrome zombie? Tidak ada yang menumpuk dalam jendela pendek yang diuji. Setelah 30 sesi berurutan, kontainer memiliki 0 proses Chrome dan 0 zombie, dengan hanya dumb-init, node, Xvfb, start.sh, dan sh yang bertahan. Detektor menghitung 11 proses keluarga Chrome saat sesi sedang berjalan, jadi ia tidak buta. Memori kontainer naik dari 294 MiB ke 303 MiB lalu mendatar dalam sampel. Ini bukan hasil endurance multi-jam, konkurensi, atau ribuan sesi.