WebSockets vs SSE vs Long Polling — Real-Time Tanpa Kepanasan

Sebagian besar pengembang memilih WebSockets secara default. Namun, itu biasanya salah.

Bukan karena WebSockets buruk — mereka sangat efektif dalam tugas yang mereka lakukan. Namun, mereka membawa beban infrastruktur nyata: sesi yang tetap di load balancer, logika heartbeat khusus, solusi autentikasi, dan konfigurasi proxy yang bekerja baik hingga seseorang membuka aplikasi Anda di kantor perusahaan. Untuk sebagian besar kebutuhan 'real-time', beban tersebut tidak perlu.

Versi pendeknya: jika data hanya mengalir dari server ke klien, gunakan Server-Sent Events (SSE). Jika klien perlu mengirim data kembali dengan latensi rendah, gunakan WebSockets. Jika frekuensi pembaruan diukur dalam detik dan Anda ingin penyebaran yang paling sederhana, long polling masih bekerja — dan tidak ada kekurangan dalam hal itu.

Perbandingan

Long Polling

Long polling adalah polling HTTP standar di mana server mempertahankan permintaan terbuka hingga ada data yang dapat dikembalikan — atau timeout terjadi. Klien mengirim permintaan, server menunggu, mengembalikan respons saat data tersedia, dan klien segera mengirim permintaan berikutnya. Ini adalah lingkaran yang disembunyikan sebagai panggilan jaringan.

Ini benar-benar cocok untuk berbagai kasus penggunaan:

• Badge notifikasi — jumlah tidak dibaca yang diperbarui setiap 30 detik tidak perlu koneksi tetap.
• Dashboard admin dengan kecepatan yang tidak ketat — metrik yang diperbarui setiap 15–60 detik bekerja dengan baik menggunakan polling.
• Aplikasi mobile di koneksi tidak stabil — koneksi tetap dapat dihentikan oleh manajemen jaringan yang agresif; polling dapat menghubungkan kembali secara bersih setiap permintaan.
• Di balik proxy perusahaan — banyak proxy perusahaan menunda atau menghentikan koneksi non-standard. Polling HTTP bekerja di mana saja, tanpa pengecualian.

Keterbatasan skalabilitas benar-benar ada. Setiap permintaan yang tetap terbuka mengambil slot koneksi. Di server berthread ini menjadi mahal; di server berbasis event loop (Node.js, Tornado, Go dengan goroutines) ini dapat dikelola tetapi tidak gratis. Pada jumlah pengguna serentak puluhan ribu, perhitungan terhadap sumber daya server mulai penting.

Server-Sent Events (SSE)

SSE adalah pilihan yang sering dilewatkan oleh pengembang saat mereka beralih ke WebSockets. Kesalahan ini terjadi untuk semua kasus penggunaan di mana data mengalir hanya dari server ke klien.

Ini berjalan di atas HTTP biasa. Server mengatur Content-Type: text/event-stream dan menulis pesan yang dipisahkan baris ke tubuh respons secara tak terbatas. API bawaan browser EventSource menangani reconnection secara otomatis — termasuk Last-Event-ID header agar server dapat melanjutkan aliran setelah terputus. Anda mendapatkan tipe peristiwa yang dinamakan, interval retry yang dapat dikonfigurasi, dan tidak perlu library tambahan.

const source = new EventSource('/api/events');

source.addEventListener('priceUpdate', (e) => {
  const { price, symbol } = JSON.parse(e.data);
  updateTicker(symbol, price);
});

source.onerror = () => {
  // EventSource reconnects automatically — nothing to do here
};

Apa yang SSE lakukan dengan benar:

• HTTP standar — bekerja melalui load balancer, reverse proxy, dan CDN tanpa konfigurasi tambahan. Tidak perlu sesi tetap.
• Reconnection otomatis — sudah ada dalam spesifikasi. Atur retry: field di aliran untuk mengatur interval; klien menangani sisanya.
• Multiplexing HTTP/2 — menghilangkan batas lama 6 koneksi per domain dari HTTP/1.1. Jika Anda menggunakan HTTP/2 (Anda seharusnya), ini bukan kekhawatiran.
• Implementasi server yang lebih sederhana — tetapkan koneksi terbuka dan tulis ke dalamnya. Tidak perlu handshake protokol, tidak perlu parsing frame, tidak perlu logika heartbeat.

Keterbatasan satu-satunya: SSE bersifat satu arah. Klien tidak dapat mengirim data melalui koneksi SSE. Dalam praktiknya ini jarang menjadi masalah — gunakan permintaan POST biasa untuk apa pun yang perlu dikirim oleh klien, bersama dengan aliran SSE untuk peristiwa server. Kedua hal ini dapat berjalan tanpa masalah.

Batasan koneksi HTTP/1.1 perlu diketahui. Browser membatasi hingga 6 koneksi bersamaan per domain di semua tab. Tiga tab browser masing-masing menggunakan dua aliran SSE = batas tercapai. HTTP/2 menghilangkan ini melalui multiplexing. Jika Anda tidak dapat memastikan pengiriman HTTP/2 (beberapa konfigurasi CDN lama, beberapa proxy perusahaan), pertimbangkan ini.

WebSockets

WebSockets adalah alat yang tepat ketika Anda benar-benar membutuhkan komunikasi dua arah dengan latensi rendah. Kasus penggunaan yang memerlukan kompleksitas ini:

• Chat — pesan dari setiap pengguna harus mencapai orang lain dalam waktu hampir real-time. WebSockets adalah standar di sini karena alasan yang baik.
• Permainan multiplayer — keadaan permainan sinkronisasi antar klien secara konstan, sering kali 20–60 kali per detik. Tidak ada pendekatan lain yang mendekati efisiensi per-frame yang sama.
• Pengeditan bersama — pengeditan real-time berbasis CRDT atau OT (Notion, Figma, gaya Google Docs) membutuhkan setiap ketukan untuk menyebar dengan latensi minimal.
• Terminal perdagangan — feed harga di bawah 100ms dengan pengiriman pesanan pada koneksi yang sama. WebSockets dibangun untuk hal ini.

Biaya infrastruktur yang dihindari oleh SSE dan polling:

• Sesi tetap — koneksi WebSocket bersifat berbasis status dan terikat pada proses server tunggal. Load balancer membutuhkan afiliasi sesi (hash IP atau berbasis cookie) untuk mengarahkan koneksi ulang secara benar. Tanpa itu, klien yang menghubungkan kembali mungkin jatuh ke server yang tidak mengetahui sesi mereka.
• Konfigurasi proxy dan CDN — Nginx, HAProxy, dan Cloudflare semua mendukung WebSockets tetapi membutuhkan konfigurasi eksplisit (Upgrade dan Connection header, proxy_http_version 1.1 di Nginx). Beberapa firewall perusahaan memblokir 101 Switching Protocols. Anda akan mengetahui hal ini dalam tiket dukungan dari pengguna di kantor tertentu.
• Kompleksitas autentikasi — WebSockets tidak dapat mengatur header khusus setelah handshake awal. Autentikasi token biasanya berarti mengirimkan token di baris query (tidak menarik, umum) atau di pesan pertama setelah koneksi (lebih bersih, tetapi membutuhkan logika pengawasan di sisi server).
• Heartbeat — spesifikasi tidak memerlukan keepalive. Tanpa logika ping/pong khusus, Anda tidak akan mendeteksi koneksi mati sampai pesan berikutnya gagal. Atau implementasikan heartbeat atau terima koneksi yang kadaluwarsa secara diam-diam.

Tidak ada yang menjadi penghalang — semua ini dapat diatasi. Ini adalah kompleksitas yang tidak ada pada SSE atau polling HTTP. Jika Anda memilih WebSockets untuk feed notifikasi atau dashboard langsung, Anda membayar biaya itu tanpa alasan.

Cara Memilih

Lakukan ini secara berurutan:

1. Apakah klien perlu mengirimkan data ke server dengan frekuensi tinggi, atau apakah latensi di bawah 200ms penting? Tidak → lewatkan WebSockets.
2. Apakah data hanya mengalir dari server ke klien? Ya → SSE hampir pasti adalah pilihan yang tepat.
3. Apakah Anda menggunakan HTTP/2? Jika ya, SSE tidak memiliki batasan yang berarti untuk kebanyakan kasus. Jika tidak, pertimbangkan batas 6 koneksi.
4. Apakah pengaturan Anda berbasis serverless atau di balik infrastruktur yang tidak mendukung koneksi tetap? SSE bekerja di sebagian besar platform serverless (Vercel, Cloudflare Workers melalui API Streams); WebSockets di serverless membutuhkan plumbing tambahan.
5. Apakah frekuensi pembaruan Anda 15 detik atau lebih? Long polling. Tetapkan sesuatu yang sederhana.

Jika Anda telah memperiksa ini dan jawabannya masih WebSockets — bagus. Sekarang Anda menggunakan mereka untuk alasan yang benar, bukan alasan default.

Pengaturan Payload Peristiwa

SSE data: field dan pesan WebSocket hampir selalu berisi JSON. Saat Anda memperbaiki aliran yang tidak berfungsi, menempelkan payload mentah ke IO Tools’ JSON Formatter adalah cara tercepat untuk melihat struktur secara langsung — terutama untuk objek peristiwa yang terkandung di dalamnya di mana kurangnya tanda kurung atau koma ekstra menghancurkan parsing secara diam-diam.

Anda mungkin juga menyukai

Baru

Pemvalidan Spesifikasi OpenAPI: Menangkap Kesalahan di File Swagger Anda Sebelum Klien Tersesat

Baca selengkapnya "

Diperbarui pada 9 Jun 2026

Baru

Log Akses Server — Cerita Setiap Permintaan yang Diterima Aplikasi Anda

Baca selengkapnya "

Diperbarui pada 9 Jun 2026

Baru

Kode Status HTTP yang Sebenarnya Menyerang Anda — 301 vs 302, 401 vs 403, dan Area 5xx yang Berbahaya

Baca selengkapnya "

Diterbitkan pada 8 Jun 2026

Baru

Pengaturan Batas Penggunaan: Cara Menghentikan Diterima 429 oleh Setiap API yang Anda Gunakan

Baca selengkapnya "

Diterbitkan pada 8 Jun 2026