Digital Transformation
Server-Side Rendering (SSR)
TL;DR: Server-Side Rendering (SSR) merender HTML di server tiap request lalu mengirim halaman jadi ke browser. Pendekatan ini mempercepat First Contentful Paint, mempermudah indexing mesin pencari, dan ideal untuk halaman dengan data dinamis seperti checkout, dashboard, dan halaman katalog yang sering berubah.
Apa itu Server-Side Rendering?
Server-Side Rendering adalah pola render di mana server menyusun HTML lengkap berdasarkan data terkini, kemudian browser hanya perlu menampilkan halaman jadi tanpa menunggu JavaScript besar dijalankan dulu. Berbeda dengan Client-Side Rendering yang menyerahkan render ke browser, SSR memindahkan beban itu ke server sehingga halaman terlihat lebih cepat dan robot perayap mendapatkan konten utuh sejak HTML pertama dikirim.
Pendekatan ini punya kemiripan dengan Static Site Generation, tapi berbeda di waktu eksekusi. SSG men-generate HTML saat build, SSR men-generate HTML saat request. Implikasinya, SSR cocok untuk data yang sering berubah per pengguna atau per waktu, sementara SSG ideal untuk konten yang stabil seperti glosarium dan artikel evergreen.
Cara Kerja SSR
Alur dasar SSR di Next.js dan framework modern lainnya umumnya melewati lima tahap berikut.
| Tahap | Aksi |
|---|---|
| 1. Request | Browser mengirim permintaan ke server |
| 2. Fetch data | Server memanggil database atau API yang dibutuhkan halaman |
| 3. Render HTML | Server menyusun HTML lengkap dengan data tersebut |
| 4. Kirim respons | Server mengirim HTML siap pakai ke browser |
| 5. Hydrate | JavaScript di browser mengikat event handler ke HTML statis |
Selama proses hydration, halaman sudah terlihat dan bisa dibaca, hanya interaksi yang menunggu JavaScript siap. Ini yang membuat metrik LCP dan INP biasanya lebih sehat di SSR dibanding SPA murni.
Kenapa Penting untuk Marketer Indonesia?
SSR menjawab tiga kebutuhan praktis sekaligus. Pertama, halaman terindeks lebih baik karena konten ada di HTML pertama, bukan menunggu eksekusi JavaScript yang kadang gagal di lingkungan crawler bandwidth rendah. Kedua, pengguna jaringan 4G menengah ke bawah, yang masih jadi mayoritas di Indonesia menurut riset Google Search Central, mendapat pengalaman lebih cepat karena tidak menunggu bundle besar. Ketiga, halaman dinamis seperti hasil pencarian dan halaman personalisasi tetap bisa di-cache di edge dengan strategi tepat.
Dalam beberapa proyek terakhir di Vetmo dan Nalesha, perpindahan halaman katalog dari SPA ke SSR Next.js menurunkan Largest Contentful Paint di mobile dari kisaran 3,8 detik ke 1,9 detik. Rentang ini bukan klaim absolut, hasil bervariasi tergantung ukuran asset dan kualitas hosting.
Pertanyaan Umum
Apakah SSR selalu lebih baik dari Static Site Generation?
Tidak. SSR menambah beban server tiap request, jadi untuk konten yang jarang berubah seperti glosarium atau halaman tentang, SSG lebih hemat sumber daya dan lebih cepat di-cache. SSR menonjol untuk halaman dengan data per-user atau per-waktu.
Apakah SSR butuh server khusus?
Tidak harus. Platform seperti Vercel dan Cloudflare menawarkan edge function yang menjalankan SSR di banyak lokasi tanpa perlu mengelola server sendiri. Untuk traffic besar, opsi serverless lebih ramping dibanding membangun server VPS dari nol.