Playwright vs Puppeteer vs Selenium: Panduan Memilih Tool Browser Automation

Memilih antara Playwright, Puppeteer, dan Selenium terasa seperti memilih kendaraan untuk perjalanan jauh: ketiganya bisa membawamu sampai tujuan, tapi pengalaman, biaya, dan kecepatannya beda jauh. Playwright vs Puppeteer vs Selenium adalah perbandingan yang paling sering dicari developer yang mengerjakan browser automation — entah untuk automated testing, web scraping, atau monitoring uptime.

Artikel ini membedah ketiganya dari sisi arsitektur, bukan sekadar daftar fitur. Kamu akan melihat cara masing-masing tool berbicara dengan browser, contoh kode yang mengerjakan tugas yang sama persis, dan matriks keputusan praktis supaya tidak salah pilih di awal proyek.

Ringkasan: Playwright adalah pilihan default untuk proyek baru di 2026 berkat auto-waiting, dukungan multi-browser, dan tooling test bawaan. Puppeteer unggul untuk pekerjaan spesifik Chromium dan ekosistem Node.js, terutama scraping. Selenium tetap relevan untuk tim dengan suite Java/Python yang besar, kebutuhan grid lintas OS, dan kompatibilitas enterprise. Salah pilih di awal biasanya terbayar mahal dalam bentuk test yang flaky dan maintenance berbulan-bulan.

Apa itu browser automation?

Browser automation adalah teknik mengendalikan browser web lewat kode: membuka halaman, mengklik tombol, mengisi formulir, membaca konten, sampai mengambil screenshot — semuanya tanpa tangan manusia. Tiga kegunaan dominannya adalah automated testing (memastikan aplikasi web tetap berfungsi setiap ada perubahan kode), web scraping (mengambil data dari situs), dan RPA ringan (mengotomatisasi tugas administratif berbasis web yang membosankan).

Ketiga tool dalam artikel ini menyelesaikan masalah yang sama, tapi lahir dari era dan filosofi berbeda. Memahami asal-usulnya membantu menjelaskan kenapa API mereka terasa berbeda saat dipakai.

Kenapa pilihan tool menentukan segalanya

Biaya tersembunyi dari pilihan yang salah

Tool browser automation bukan sekadar library — ia menjadi fondasi suite test atau pipeline scraping yang akan hidup bertahun-tahun. Pilihan yang keliru muncul sebagai gejala mahal: test yang gagal tanpa alasan jelas (flaky), waktu eksekusi CI yang membengkak, atau scraper yang tiba-tiba diblokir karena fingerprint browser yang ketinggalan zaman. Migrasi di tengah jalan hampir selalu berarti menulis ulang seluruh suite, karena API ketiganya tidak saling kompatibel.

Tiga pekerjaan yang mereka lakukan

Sebelum membandingkan, samakan dulu ekspektasinya. Semua tool browser automation melakukan tiga hal: meluncurkan dan mengendalikan browser, berinteraksi dengan halaman (klik, ketik, navigasi), dan mengamati hasilnya (assertion, screenshot, network log). Perbedaannya ada di bagaimana mereka melakukannya — protokol komunikasi dengan browser, bahasa pemrograman yang didukung, dan seberapa banyak pekerjaan rumah (menunggu elemen, retry, paralelisasi) yang ditanggung tool versus ditulis manual olehmu.

Playwright: pendatang yang merebut mahkota

Playwright dikembangkan Microsoft dan dirilis pertama kali tahun 2020. Versi terbarunya, Playwright 1.64, dirilis 7 Oktober 2026 dengan dukungan WebMCP dan API locator.within() — detail lengkapnya ada di dokumentasi resmi Playwright. Dalam enam tahun ia bergerak dari "alternatif baru" menjadi pilihan default untuk automated testing di banyak tim — pergeseran yang jarang terjadi secepat ini di dunia tooling.

Kekuatan utamanya ada tiga. Pertama, auto-waiting: setiap aksi seperti klik atau pengisian form otomatis menunggu elemen benar-benar siap (terlihat, stabil, aktif) sebelum dieksekusi. Ini menghilangkan sebagian besar sleep() manual yang menjadi sumber flaky test. Kedua, dukungan tiga engine browser — Chromium, Firefox, dan WebKit — lewat satu API yang sama, sehingga satu suite bisa memverifikasi perilaku lintas browser tanpa ditulis ulang. Ketiga, tooling test bawaan: test runner dengan paralelisasi, Trace Viewer untuk debugging kegagalan (rekaman langkah-demi-langkah lengkap dengan snapshot DOM), codegen untuk merekam interaksi menjadi kode, dan UI mode.

Playwright tersedia untuk JavaScript/TypeScript, Python, .NET, dan Java. Arsitekturnya khas: kode test berbicara dengan sebuah driver native lewat pipe, dan driver inilah yang menerjemahkan perintah ke protokol khusus tiap browser. Pendekatan ini memberi Playwright kontrol yang dalam tanpa bergantung pada satu protokol browser saja.

Kelemahannya? Ukuran instalasi besar (tiap engine browser diunduh terpisah, totalnya bisa ratusan MB), dan untuk scraping skala besar yang butuh fingerprint kustom tingkat lanjut, kontrolnya tidak sedalam tool yang memang dirancang untuk itu. Ia juga tidak punya jawaban bawaan untuk mobile native — itu ranahnya Appium atau device cloud.

Puppeteer: pisau bedah dari tim Chrome

Puppeteer lahir di tim Chrome DevTools Google dan sejak awal dirancang untuk satu hal: mengendalikan Chromium lewat Chrome DevTools Protocol (CDP) — protokol yang sama dipakai oleh panel DevTools di browser. Versi terbarunya, Puppeteer 25.15.0, dirilis 20 Oktober 2026, hanya sehari sebelum artikel ini ditulis, dengan Chrome 155 sebagai browser bawaannya — daftar perubahannya tercatat di changelog resmi Puppeteer.

Karena berbicara langsung lewat CDP, Puppeteer memberi akses yang sangat granular: intersepsi network, emulasi perangkat, manipulasi service worker, sampai emulasi Bluetooth di versi-versi terbaru. Untuk scraping, ini berarti kamu bisa memblokir resource yang tidak perlu (gambar, font, analytics), memutar proxy per halaman, dan meniru perilaku browser sungguhan dengan presisi tinggi.

Puppeteer adalah library Node.js murni — tanpa test runner bawaan, tanpa assertion library, tanpa paralelisasi bawaan. Kamu merakit sendiri stack-nya (misalnya dipadukan Jest atau Vitest untuk testing), yang memberi fleksibilitas sekaligus tanggung jawab penuh. Ekosistem puppeteer-extra beserta plugin stealth-nya sudah matang sejak 2018 dan masih jadi rujukan untuk pekerjaan yang harus menghindari deteksi bot.

Keterbatasan terbesarnya jelas: fokus ke Chromium. Dukungan Firefox tersedia tapi bukan prioritas utama, dan WebKit/Safari tidak didukung. Kalau kebutuhanmu adalah verifikasi lintas browser, Puppeteer bukan jawabannya.

Selenium: veteran yang menolak mati

Selenium sudah mengotomatisasi browser sejak 2004. Versi terbarunya, Selenium 4.51, dirilis 9 Oktober 2026. Umurnya yang panjang justru jadi aset: dokumentasi melimpah, jawaban komunitas untuk hampir semua error yang mungkin kamu temui, dan adopsi enterprise yang masif. Rilis terbarunya diumumkan di blog resmi Selenium.

Selenium berbicara dengan browser lewat protokol W3C WebDriver — sebuah standar web resmi, bukan protokol milik satu vendor. Artinya browser apa pun yang mengimplementasikan WebDriver bisa dikendalikan: Chrome, Firefox, Safari, Edge. Binding resminya tersedia untuk Java, Python, C#, Ruby, JavaScript, dan Kotlin — pilihan bahasa terluas di antara ketiganya.

Dua perkembangan modern membuatnya tetap relevan. Selenium Manager, yang dibundel sejak versi 4.6, otomatis mengunduh dan mengelola browser driver yang cocok — mengubur ritual lama mencocokkan versi ChromeDriver secara manual. WebDriver BiDi, protokol dua arah yang dibangun bersama para vendor browser, perlahan menggantikan akses CDP yang sifatnya sementara dengan standar lintas browser untuk intersepsi network, log, dan event browser.

Selenium juga satu-satunya yang punya Grid matang untuk menjalankan ribuan test paralel di banyak mesin dan kombinasi OS/browser — kebutuhan klasik enterprise dan QA skala besar. Kelemahannya: API-nya level rendah. Tidak ada auto-waiting bawaan (kamu menulis explicit wait sendiri), tidak ada test runner, dan pengalaman setup awal terasa kuno dibanding Playwright yang "langsung jalan". Detail arsitektur dan status terbarunya bisa dibaca di dokumentasi Selenium.

Cara kerja ketiganya di balik layar

Perbedaan arsitektur menjelaskan perbedaan perilaku. Playwright menempatkan sebuah driver native di antara kode dan browser — driver ini berbicara protokol khusus tiap engine, sehingga satu API bisa seragam di tiga browser. Puppeteer memangkas lapisan: kode Node.js berbicara langsung ke Chromium lewat CDP over WebSocket, tanpa perantara. Selenium mengambil jalur standar: binding bahasa mengubah perintah menjadi HTTP request sesuai spesifikasi W3C WebDriver, diterima oleh browser driver (misalnya ChromeDriver), lalu diteruskan ke browser.

Implikasinya praktis. Jalur Puppeteer yang langsung membuatnya gesit untuk operasi Chromium murni. Lapisan driver Playwright menambah sedikit overhead tapi membeli keseragaman lintas browser. Jalur HTTP Selenium paling "jauh" dari browser — dan di sinilah sebagian latensi serta kebutuhan explicit wait berasal.

Perbandingan head-to-head

Kode yang sama dalam tiga gaya

Untuk merasakan perbedaannya, berikut satu skenario identik — login ke sebuah form — ditulis di ketiganya.

Playwright (TypeScript)

import { test, expect } from '@playwright/test';

test('login berhasil menampilkan dasbor', async ({ page }) => {
  await page.goto('https://contoh.com/login');
  await page.getByLabel('Email').fill('[email protected]');
  await page.getByLabel('Kata sandi').fill('rahasia123');
  await page.getByRole('button', { name: 'Masuk' }).click();
  // Auto-waiting: assertion menunggu sendiri sampai kondisi terpenuhi
  await expect(page.getByText('Dasbor')).toBeVisible();
});

Perhatikan tidak ada satu pun perintah tunggu manual. getByRole dan getByLabel memakai locator yang tahan terhadap perubahan kecil pada struktur DOM — praktik yang lebih awet dibanding selector CSS yang rapuh.

Puppeteer (JavaScript)

import puppeteer from 'puppeteer';

const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.goto('https://contoh.com/login');
await page.locator('#email').fill('[email protected]');
await page.locator('#password').fill('rahasia123');
await page.locator('button[type="submit"]').click();
await page.waitForSelector('text/Dasbor');
await browser.close();

API page.locator di Puppeteer modern membawa pola tunggu otomatis yang mirip Playwright. Tanpa test runner bawaan, kamu membungkus skrip seperti ini dengan framework test pilihanmu sendiri.

Selenium (Python)

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

driver = webdriver.Chrome()  # Selenium Manager mengurus driver otomatis
driver.get("https://contoh.com/login")
driver.find_element(By.ID, "email").send_keys("[email protected]")
driver.find_element(By.ID, "password").send_keys("rahasia123")
driver.find_element(By.CSS_SELECTOR, "button[type='submit']").click()
WebDriverWait(driver, 10).until(
    EC.visibility_of_element_located(
        (By.XPATH, "//*[contains(text(), 'Dasbor')]"))
)
driver.quit()

Versi Selenium paling panjang karena setiap penantian ditulis eksplisit. Sejak versi 4.6 kamu tidak perlu lagi mengurus ChromeDriver manual — webdriver.Chrome() memanggil Selenium Manager di belakang layar.

Studi kasus: tool mana untuk proyekmu?

Startup SaaS dengan tim kecil, stack TypeScript. Pilih Playwright. Setup lima menit, test paralel bawaan, dan Trace Viewer menghemat jam debugging setiap minggu. Ini skenario di mana Playwright paling bersinar — dan alasan ia menjadi default baru.

Pipeline scraping harga kompetitor, 50 ribu halaman per hari, stack Node.js. Pilih Puppeteer. Kontrol CDP memungkinkan pemblokiran resource berat dan rotasi proxy per konteks browser, yang memangkas bandwidth dan biaya. Ekosistem plugin stealth membantu di situs yang agresif mendeteksi bot.

Bank dengan 3.000 test Selenium Java yang sudah berjalan lima tahun. Tetap di Selenium. Biaya migrasi — menulis ulang ribuan test, melatih tim QA, memvalidasi ulang pipeline kepatuhan — jauh melampaui keuntungan pindah. Modernisasi bertahap (adopsi Selenium Manager, pindah ke Grid 4) memberi sebagian besar manfaat dengan sebagian kecil usaha.

Tim QA yang harus memverifikasi Safari di macOS dan Edge di Windows. Selenium atau Playwright. WebKit bawaan Playwright mendekati Safari meski bukan Safari asli; untuk Safari sungguhan tetap butuh WebDriver dari Apple. Puppeteer gugur di skenario ini.

Monitoring uptime sintetis dari banyak region. Playwright atau Puppeteer — keduanya ringan dijalankan headless di container. Pasangkan dengan pipeline CI/CD dan image Docker resmi yang sudah disediakan Playwright.

Kesalahan umum dan cara menghindarinya

Mengandalkan sleep() tetap. Ini biang flaky test nomor satu di semua tool. Ganti dengan penantian berbasis kondisi: auto-waiting di Playwright, waitForSelector/waitForFunction di Puppeteer, WebDriverWait dengan expected conditions di Selenium.

Selector yang rapuh. Selector seperti div > div:nth-child(3) > button pecah setiap ada perubahan layout kecil. Urutan prioritas yang aman: role/label yang aksesibel dulu, lalu data-testid yang memang disiapkan untuk test, terakhir CSS/XPath.

Menjalankan semua test secara serial. Suite 500 test yang butuh dua jam tidak akan dijalankan siapa pun. Playwright punya paralelisasi bawaan; untuk Puppeteer dan Selenium, pecah suite dan jalankan paralel di CI atau Selenium Grid.

Mengabaikan isolasi antar test. Test yang berbagi state (login sekali untuk semua test, database tidak di-reset) gagal secara misterius dan berurutan. Setiap test harus bisa berjalan sendiri — prinsip yang berlaku umum, sama seperti best practice penulisan kode lainnya.

Scraping tanpa menghormati target. Terlalu agresif mengirim request, mengabaikan robots.txt, atau memalsukan identitas secara berlebihan bukan cuma bermasalah secara etika — praktisnya IP-mu akan diblokir permanen. Batasi rate, manfaatkan cache, dan baca syarat layanan situs target.

Best practice lintas tool

1. Tulis test dari sudut pandang pengguna, bukan implementasi. Uji "pengguna bisa checkout", bukan "tombol dengan class X bisa diklik".
2. Pisahkan Page Object atau fixture dari logika assertion, agar perubahan UI hanya menyentuh satu tempat.
3. Jalankan subset kritis di setiap pull request, suite penuh di jadwal malam hari. Strategi ini dibahas lebih jauh di panduan pipeline CI/CD.
4. Simpan artefak kegagalan — screenshot, video, trace — otomatis di CI. Debugging tanpa artefak sama dengan menebak.
5. Pin versi browser dan tool di CI. Rilis minor Playwright atau Puppeteer kadang mengubah perilaku; versi yang mengambang membuat kegagalan sulit direproduksi.
6. Untuk scraping Python yang async, pola concurrency di panduan asyncio cocok dipadukan dengan Playwright Python yang sepenuhnya async-native.

FAQ

Apakah Playwright lebih cepat dari Selenium?

Untuk skenario yang setara, umumnya ya — auto-waiting menghilangkan jeda berlebih dan arsitektur driver-nya lebih dekat ke browser dibanding round-trip HTTP WebDriver. Tapi faktor "lebih cepat" yang paling menentukan biasanya bukan tool-nya, melainkan seberapa paralel test dijalankan dan seberapa efisien selector-nya.

Bisakah Puppeteer mengendalikan Firefox atau Safari?

Puppeteer mendukung Firefox secara eksperimental, tapi Chromium tetap fokus utamanya. Safari/WebKit tidak didukung. Kalau butuh keduanya, Playwright atau Selenium adalah pilihan yang tepat.

Apakah Selenium sudah ketinggalan zaman di 2026?

Tidak — Selenium 4.51 aktif dikembangkan, protokol WebDriver BiDi mengejar ketertinggalan fitur dua arah, dan Selenium Manager menghilangkan keluhan klasik soal driver. Ia memang bukan pilihan paling ergonomis untuk proyek baru, tapi untuk ekosistem enterprise yang sudah berjalan, ia tetap fondasi yang solid.

Tool mana yang terbaik untuk web scraping?

Puppeteer untuk scraping berat berbasis Node.js yang butuh kontrol browser mendalam. Playwright Python untuk scraping yang butuh concurrency async dan multi-browser. Selenium jarang jadi pilihan pertama untuk scraping baru kecuali tim sudah menguasainya. Ketiganya kalah efisien dibanding HTTP client biasa untuk situs yang tidak butuh JavaScript — jangan memakai browser automation untuk pekerjaan yang bisa diselesaikan curl.

Bisakah ketiga tool berjalan di CI seperti GitHub Actions?

Bisa semuanya. Playwright menyediakan image Docker resmi dan GitHub Action; Puppeteer butuh instalasi dependensi sistem Chrome di runner; Selenium paling nyaman lewat Selenium Grid atau image Docker standalone. Detail pola pipeline-nya ada di panduan CI/CD.

Kesimpulan

Tidak ada pemenang mutlak — yang ada hanyalah tool yang paling cocok untuk konteksmu. Playwright adalah titik awal yang aman untuk hampir semua proyek baru di 2026: ergonomi terbaik, multi-browser, tooling lengkap. Puppeteer adalah pilihan presisi untuk pekerjaan Chromium/Node.js, terutama scraping. Selenium adalah investasi jangka panjang yang terbukti untuk organisasi dengan kebutuhan multi-bahasa, multi-OS, dan skala Grid.

Aturan praktisnya: kalau memulai dari nol, mulai dari Playwright dan pindah hanya jika ada alasan konkret. Kalau sudah punya suite yang berjalan baik, modernisasi di tempat hampir selalu lebih murah daripada migrasi. Dan apa pun pilihanmu, disiplin selector dan isolasi test menentukan keberhasilan jauh lebih besar daripada logo di dokumentasi tool-nya.

Langkah berikutnya: pilih satu skenario kecil dari aplikasimu — misalnya alur login — tulis dalam tool pilihanmu, jalankan di CI, dan rasakan sendiri perbedaannya sebelum berkomitmen ke ratusan test.