Polling, SSE, atau WebSocket? Cara Memilih Komunikasi Real-Time untuk Website

Ketika sebuah halaman harus menampilkan status pesanan, progres pekerjaan, notifikasi, atau harga yang berubah tanpa menunggu pengguna menekan tombol refresh, kita membutuhkan komunikasi yang lebih dinamis antara browser dan server. Namun, solusi real-time tidak selalu berarti WebSocket.

Banyak aplikasi justru menjadi lebih sulit dirawat karena memilih teknologi yang terlalu rumit untuk kebutuhan sederhana. Dashboard yang hanya perlu menerima pembaruan dari server, misalnya, belum tentu membutuhkan komunikasi dua arah penuh. Sebaliknya, aplikasi kolaborasi atau chat akan cepat menemui batas jika hanya mengandalkan permintaan HTTP biasa.

Tiga pendekatan yang paling sering dibandingkan adalah polling, Server-Sent Events atau SSE, dan WebSocket. Memahami cara kerja masing-masing akan membantu kita mengambil keputusan berdasarkan pola komunikasi, bukan sekadar tren teknologi.

Polling: sederhana, tetapi bisa boros

Polling berarti browser mengirim permintaan ke server secara berkala. Misalnya, JavaScript memanggil endpoint /api/status setiap lima detik untuk menanyakan apakah ada perubahan.

setInterval(async () => {
  const response = await fetch('/api/status');
  const data = await response.json();
  renderStatus(data);
}, 5000);

Keunggulan polling adalah implementasinya mudah. Hampir semua server, framework PHP, dan infrastruktur HTTP sudah siap memakainya. Tidak ada koneksi khusus yang harus dipertahankan, sehingga debugging juga relatif familiar: kita cukup melihat request dan response di tab Network pada browser.

Masalahnya, sebagian besar request mungkin tidak menghasilkan perubahan. Jika 1.000 pengguna membuka dashboard dan masing-masing mengirim request setiap lima detik, server harus menangani sekitar 200 request per detik meskipun data hanya berubah sesekali. Interval yang terlalu pendek membebani server, sedangkan interval yang terlalu panjang membuat informasi terasa terlambat.

Polling cocok untuk data yang tidak harus muncul seketika, seperti status sinkronisasi, statistik sederhana, atau halaman admin dengan perubahan yang jarang.

SSE: pilihan praktis untuk pembaruan satu arah

Server-Sent Events atau SSE memungkinkan server mengirim data ke browser melalui koneksi HTTP yang tetap terbuka. Browser menggunakan API EventSource untuk menerima aliran event dari endpoint tertentu.

const source = new EventSource('/events.php');

source.addEventListener('order-updated', (event) => {
  const order = JSON.parse(event.data);
  renderOrder(order);
});

Berbeda dari WebSocket, SSE dirancang untuk komunikasi satu arah: server mengirim pembaruan kepada client. Jika browser perlu mengirim aksi, misalnya mengubah status pesanan, aksi tersebut tetap bisa memakai fetch() atau form HTTP biasa.

Model ini cocok untuk notifikasi, feed aktivitas, progres ekspor laporan, pemantauan proses background, atau dashboard monitoring. Server bisa mengirim event seperti berikut:

event: order-updated
data: {"id":123,"status":"dikemas"}

Format SSE menggunakan MIME type text/event-stream. Browser juga memiliki mekanisme koneksi ulang bawaan ketika koneksi terputus. Event dapat diberi ID sehingga server dan client bisa membantu melanjutkan aliran dari posisi tertentu setelah reconnect. Namun, fitur pemulihan ini bukan alasan untuk mengabaikan desain event yang idempoten dan pemeriksaan otorisasi.

SSE memiliki batasan. Ia tidak cocok jika client harus mengirim banyak pesan secara terus-menerus melalui koneksi yang sama. Dukungan terhadap pengiriman data biner juga tidak sefleksibel WebSocket. Selain itu, server, reverse proxy, dan platform hosting harus dikonfigurasi agar tidak mem-buffer response terlalu lama.

WebSocket: untuk komunikasi dua arah yang intensif

WebSocket menyediakan koneksi dua arah yang memungkinkan browser dan server saling mengirim pesan melalui koneksi yang sama. Setelah proses handshake, aplikasi dapat mengirim dan menerima pesan tanpa membuat request HTTP baru untuk setiap komunikasi.

const socket = new WebSocket('wss://example.com/socket');

socket.addEventListener('message', (event) => {
  const message = JSON.parse(event.data);
  renderMessage(message);
});

socket.addEventListener('open', () => {
  socket.send(JSON.stringify({ type: 'join-room', room: 'general' }));
});

WebSocket lebih tepat untuk chat, permainan multiplayer, kolaborasi dokumen, papan kerja bersama, atau aplikasi yang membutuhkan respons cepat dari kedua arah. Client dapat mengirim aksi, server dapat menyebarkan perubahan, dan keduanya tidak perlu terus-menerus membuat request baru.

Fleksibilitas ini datang bersama tanggung jawab tambahan. Koneksi yang bertahan lama perlu dikelola ketika pengguna logout, sesi kedaluwarsa, jaringan berpindah, atau server melakukan deployment. Server juga harus membatasi ukuran pesan, jumlah koneksi, frekuensi pengiriman, dan waktu tunggu.

Untuk produksi, gunakan wss://, bukan ws://. Validasi autentikasi dan otorisasi pada saat handshake maupun saat memproses pesan. Jangan menganggap koneksi WebSocket otomatis aman hanya karena berasal dari browser yang sudah login. Origin, session, payload, dan hak akses tetap perlu diperiksa.

Cara memilih tanpa menebak

• Pilih polling jika data tidak perlu muncul seketika, perubahan jarang, dan kesederhanaan lebih penting daripada latensi rendah.
• Pilih SSE jika sebagian besar komunikasi bergerak dari server ke browser, seperti notifikasi, progress bar proses panjang, dan feed aktivitas.
• Pilih WebSocket jika browser dan server sama-sama perlu mengirim pesan secara aktif dengan latensi rendah.
• Tetap gunakan HTTP biasa untuk operasi CRUD, pengiriman form, dan permintaan yang tidak membutuhkan koneksi panjang.

Satu aplikasi juga boleh memakai lebih dari satu pendekatan. Contohnya, halaman admin dapat menggunakan HTTP untuk menyimpan perubahan, SSE untuk menerima notifikasi status terbaru, dan polling sebagai fallback ketika koneksi streaming tidak tersedia.

Yang perlu diperiksa sebelum masuk produksi

1. Ukur kebutuhan latensi. Apakah keterlambatan lima detik masih bisa diterima? Jika iya, polling mungkin sudah cukup.
2. Hitung jumlah koneksi. SSE dan WebSocket mempertahankan koneksi lebih lama, sehingga kapasitas worker, proxy, dan load balancer perlu diuji.
3. Rancang reconnect. Tentukan jeda percobaan ulang, kondisi berhenti, dan cara mencegah ribuan client menyambung kembali secara bersamaan.
4. Buat event yang aman diulang. Client bisa menerima pesan lebih dari sekali. Gunakan ID event atau kunci idempotensi agar pembaruan tidak menggandakan data.
5. Siapkan observabilitas. Catat koneksi dibuka, ditutup, gagal autentikasi, pesan ditolak, serta alasan pemutusan tanpa menyimpan token atau data sensitif.

Kesimpulan

Polling, SSE, dan WebSocket bukan urutan tingkat kecanggihan. Ketiganya adalah alat untuk pola kebutuhan yang berbeda. Mulailah dari pertanyaan sederhana: siapa yang lebih sering mengirim data, seberapa cepat pembaruan harus diterima, dan berapa banyak koneksi yang sanggup ditangani infrastruktur?

Jika server hanya perlu memberi tahu browser, SSE sering menjadi jalan tengah yang rapi. Jika komunikasi harus aktif dari kedua arah, WebSocket layak dipertimbangkan. Jika kebutuhan real-time masih ringan, polling yang dirancang dengan interval masuk akal bisa menjadi pilihan paling mudah dirawat.

Rujukan teknis

• Dokumentasi MDN tentang penggunaan Server-Sent Events
• Spesifikasi WHATWG untuk Server-Sent Events
• OWASP WebSocket Security Cheat Sheet

Sumber & bacaan lebih lanjut

• Using server-sent events - Web APIs | MDN
• HTML Standard — Server-sent events
• WebSocket Security Cheat Sheet — OWASP

– Rio Yotto @rioyotto