Server-Side Rendering vs Client-Side Rendering: 5 Perbedaan dan Mana yang Harus Dipilih

Server-side rendering dan client-side rendering adalah dua cara utama untuk menentukan di mana halaman web dibuat, apakah di server atau di browser. Pilihan ini terdengar teknis, tetapi dampaknya sangat nyata. Ia memengaruhi seberapa cepat halaman tampil, bagaimana mesin pencari membacanya, berapa besar beban server, dan bagaimana rasanya bagi pengguna di ponsel yang sederhana.

Banyak developer memilih salah satunya karena mengikuti tren atau kebiasaan tim. Padahal, tidak ada pendekatan yang selalu paling baik. Blog pribadi, dashboard internal, dan toko online punya kebutuhan yang berbeda, sehingga cara terbaik membuat halamannya pun berbeda.

Artikel ini menjelaskan apa itu server-side rendering dan client-side rendering, lima perbedaan pentingnya, kapan memilih masing-masing, serta contoh kode untuk halaman yang sama dengan kedua pendekatan. Selain itu, Anda akan mengenal pendekatan hybrid dan kesalahan umum yang sering terjadi.

Perbandingan server-side rendering dan client-side rendering pada pengembangan web — Perbedaan utamanya terletak pada tempat halaman dibuat: server atau browser.

Daftar Isi

Apa itu server-side rendering
Apa itu client-side rendering
5 perbedaan server-side rendering dan client-side rendering
Kapan memilih server-side rendering
Kapan memilih client-side rendering
Contoh kode kedua pendekatan
Pendekatan hybrid, static rendering, dan hydration
Kesalahan umum
Daftar periksa
Kesimpulan

Apa Itu Server-Side Rendering?

Server-side rendering (SSR) berarti server membuat HTML lengkap untuk sebuah halaman, lalu mengirimkannya ke browser. Menurut panduan Rendering on the Web dari web.dev, SSR adalah proses merender aplikasi di server untuk mengirim HTML, bukan JavaScript, ke klien. Browser menerima halaman yang sudah berisi konten, sehingga pengguna bisa langsung membacanya.

Bayangkan restoran yang menyajikan makanan yang sudah matang di meja. Dapur, yaitu server, melakukan semua pekerjaan. Pelanggan, yaitu browser, tinggal menikmatinya. Pendekatan ini adalah cara klasik web bekerja, dan sekarang dihidupkan kembali oleh framework modern seperti Next.js, Nuxt, dan SvelteKit.

Kelebihan utamanya adalah konten muncul lebih cepat dan tidak bergantung pada JavaScript di perangkat pengguna. Web.dev mencatat bahwa SSR umumnya menghasilkan First Contentful Paint (FCP) yang cepat, karena logika halaman dan proses rendering berjalan di server.

Apa Itu Client-Side Rendering?

Client-side rendering (CSR) berarti browser yang membuat halaman. Server mengirim kerangka HTML yang hampir kosong beserta berkas JavaScript. Browser lalu menjalankan JavaScript itu, mengambil data lewat API, dan menyusun tampilan di layar. Web.dev menyebut bahwa pada CSR, semua logika, pengambilan data, templating, dan routing ditangani di klien.

Jika SSR seperti makanan matang, CSR seperti paket bahan masak yang dikirim ke rumah. Pelanggan harus memasaknya sendiri. Dapurnya, yaitu perangkat pengguna, yang bekerja. Jika dapur itu cepat, hasilnya bagus. Jika lambat, pelanggan menunggu.

Kelebihan CSR adalah interaksi yang mulus setelah aplikasi termuat. Perpindahan antarhalaman terasa instan karena browser hanya mengganti bagian yang perlu. Karena itu, pendekatan ini umum dipakai pada aplikasi interaktif seperti dashboard dan editor.

5 Perbedaan Server-Side Rendering dan Client-Side Rendering

1. Kecepatan Tampil Awal

Dengan SSR, browser menerima HTML yang sudah berisi konten, sehingga halaman cepat terlihat. Namun, web.dev mengingatkan bahwa membuat halaman di server membutuhkan waktu, sehingga bisa menaikkan Time to First Byte (TTFB). Dengan CSR, server merespons cepat dengan kerangka kosong, tetapi pengguna harus menunggu JavaScript diunduh dan dijalankan sebelum melihat konten.

2. Interaktivitas dan Ukuran JavaScript

CSR biasanya mengirim banyak JavaScript, karena seluruh aplikasi berjalan di browser. Web.dev menyebut bahwa CSR sulit dijaga tetap cepat di perangkat seluler, kecuali Anda disiplin menjaga anggaran JavaScript. SSR bisa mengurangi JavaScript yang dikirim, tetapi sebagian besar solusi tetap memakai hydration agar halaman interaktif.

3. SEO dan Pratinjau Tautan

Halaman SSR berisi konten di HTML awal, sehingga mudah dibaca oleh mesin pencari dan pembuat pratinjau tautan. Pada CSR, konten baru muncul setelah JavaScript berjalan. Mesin pencari modern mampu menjalankan JavaScript, tetapi prosesnya lebih rumit dan tidak selalu secepat membaca HTML. Untuk situs yang mengandalkan pencarian organik, SSR atau static rendering lebih aman.

4. Beban Server dan Biaya

SSR membuat server bekerja untuk setiap permintaan. Web.dev menyebut bahwa sifat dinamisnya dapat memiliki biaya komputasi yang signifikan. Pada CSR, sebagian besar pekerjaan berpindah ke perangkat pengguna, sehingga beban server lebih ringan. Namun, beban itu berpindah ke ponsel dan laptop pengguna, yang spesifikasinya beragam.

5. Data Personal dan Kompleksitas

SSR memungkinkan pengambilan data terkini di server dan menanggapi permintaan yang lebih beragam dibanding static rendering. Namun, SSR menambah kerumitan, misalnya soal cache, memori, dan pengiriman cookie sesi ke server. CSR lebih sederhana untuk dipikirkan, tetapi pengambilan data dari klien perlu penanganan akses lintas domain. Untuk soal autentikasi, baca JWT vs Session: 5 Perbedaan dan Mana yang Harus Dipakai.

Tabel berikut merangkum perbandingannya.

Aspek	Server-Side Rendering	Client-Side Rendering
Tempat halaman dibuat	Server	Browser
Tampil awal (FCP)	Umumnya cepat	Menunggu JavaScript berjalan
TTFB	Bisa lebih lambat	Umumnya cepat
Ukuran JavaScript	Bisa lebih kecil	Cenderung besar
SEO	Konten ada di HTML awal	Bergantung pada eksekusi JavaScript
Beban server	Lebih tinggi	Lebih rendah
Cocok untuk	Situs konten dan toko online	Dashboard dan aplikasi interaktif

Kapan Memilih Server-Side Rendering?

Pertimbangkan SSR jika kondisi berikut berlaku:

SEO sangat penting. Blog, toko online, dan situs berita membutuhkan konten yang mudah dibaca mesin pencari.
Waktu tampil awal menentukan. Pengguna perlu melihat konten secepat mungkin, terutama di jaringan lambat.
Perangkat pengguna beragam. Anda tidak ingin menggantungkan pengalaman pada kekuatan perangkat.
Data harus selalu terbaru. Konten berubah sering dan tidak cocok dibuat statis.
Pratinjau tautan penting. Judul dan gambar harus muncul saat tautan dibagikan.

Kapan Memilih Client-Side Rendering?

Client-side rendering masuk akal jika:

Aplikasi sangat interaktif. Dashboard, editor, dan alat internal lebih banyak berinteraksi daripada dibaca.
Halaman di balik login. Mesin pencari tidak perlu membacanya, sehingga SEO tidak menjadi faktor.
Server ingin diringankan. Pekerjaan merender dipindahkan ke klien.
Perpindahan halaman perlu terasa instan. Setelah aplikasi termuat, navigasi berjalan tanpa memuat ulang.
Tim berpengalaman dengan single-page application. Alur kerja dan perkakasnya sudah dikuasai.

Contoh Kode Server-Side Rendering dan Client-Side Rendering

Berikut halaman artikel yang sama dibuat dengan dua pendekatan. Contoh ini sengaja sederhana agar perbedaannya mudah terlihat. Pertama, versi SSR memakai Express dan template EJS. Server mengambil data, mengisinya ke template, lalu mengirim HTML lengkap.

// server.js
import express from 'express';

const app = express();
app.set('view engine', 'ejs');

app.get('/artikel/:id', async (req, res) => {
  const artikel = await ambilArtikel(req.params.id); // data diambil di server
  res.render('artikel', { artikel });
});

app.listen(3000);

<!-- views/artikel.ejs -->
<!doctype html>
<html lang="id">
  <head>
    <title><%= artikel.judul %></title>
  </head>
  <body>
    <h1><%= artikel.judul %></h1>
    <p><%= artikel.ringkasan %></p>
  </body>
</html>

Tag <%= %> pada EJS menetralkan karakter khusus HTML, sehingga data tidak langsung dieksekusi sebagai kode. Hal ini penting untuk mencegah serangan XSS. Jika Anda menyusun HTML dengan menggabungkan teks sendiri, jangan lupa menetralkan data dari pengguna.

Kedua, versi CSR mengirim kerangka HTML sederhana. Browser lalu mengambil data lewat API dan mengisi halamannya.

<!-- index.html -->
<!doctype html>
<html lang="id">
  <head><title>Artikel</title></head>
  <body>
    <h1 id="judul">Memuat...</h1>
    <p id="ringkasan"></p>

    <script>
      async function muatArtikel() {
        const res = await fetch('/api/artikel/1');
        const artikel = await res.json();

        document.getElementById('judul').textContent = artikel.judul;
        document.getElementById('ringkasan').textContent = artikel.ringkasan;
      }

      muatArtikel();
    </script>
  </body>
</html>

Perhatikan penggunaan textContent pada versi CSR. Properti ini memperlakukan data sebagai teks biasa, bukan HTML, sehingga lebih aman. Jika API berada di domain berbeda, Anda mungkin bertemu masalah akses lintas domain. Penyebab dan solusinya dibahas di CORS Error: Penyebab dan 5 Cara Mengatasinya di Express.

Ada cara sederhana untuk mengenali perbedaannya. Buka halaman, lalu pilih “View Page Source”. Pada versi SSR, Anda melihat judul dan isi di HTML. Pada versi CSR, Anda hanya melihat kerangka kosong dengan tulisan “Memuat…”. Web.dev juga menyarankan menonaktifkan JavaScript untuk menguji apakah sebuah halaman benar-benar dirender sebelumnya.

Alur client-side rendering: browser membuat halaman dengan JavaScript — Pada CSR, browser mengunduh JavaScript lalu menyusun halaman sendiri.

Pendekatan Hybrid, Static Rendering, dan Hydration

Anda tidak harus memilih satu pendekatan untuk seluruh situs. Web.dev menyebut bahwa Anda dapat memakai server-side rendering untuk sebagian halaman dan tidak untuk halaman lain. Banyak framework modern memungkinkan pemilihan per halaman atau bahkan per komponen.

Ada tiga istilah yang perlu Anda kenal:

Static rendering. HTML dibuat saat build, satu berkas untuk tiap URL. TTFB konsisten cepat dan mudah dipasang di CDN. Namun, pendekatan ini sulit untuk halaman yang terlalu banyak atau butuh data personal.
Hydration. JavaScript dijalankan di atas HTML dari server agar halaman menjadi interaktif. Sebagian besar solusi SSR memakainya.
Hybrid. Gabungan beberapa pendekatan, misalnya halaman pemasaran dibuat statis, halaman produk memakai SSR, dan dashboard memakai CSR.

Hydration membawa tantangan tersendiri. Jika HTML dari server dan hasil render pertama di browser berbeda, muncul pesan error yang membingungkan. Penyebab dan cara memperbaikinya dijelaskan di Hydration Error: Mengapa Sering Muncul di Aplikasi Web Modern?.

Kesalahan Umum dalam Server-Side Rendering dan Client-Side Rendering

Memilih berdasarkan tren. Pilih berdasarkan kebutuhan halaman, bukan popularitas framework.
Memakai SSR untuk halaman yang tidak butuh SEO. Dashboard di balik login sering tidak memerlukannya, dan biaya server malah naik.
Mengirim terlalu banyak JavaScript pada CSR. Aplikasi menjadi lambat di ponsel sederhana.
Tidak mengukur performa. Pantau TTFB, FCP, dan INP, bukan hanya mengandalkan perasaan.
Menyimpan cache halaman personal secara bersama. Pada SSR, halaman yang berisi data pengguna tidak boleh disajikan ke pengguna lain.
Mengabaikan hydration. Perbedaan keluaran server dan browser menyebabkan error dan render ulang.
Tidak memikirkan data personal. Autentikasi dan sesi perlu dirancang untuk kedua lingkungan.

Daftar Periksa Memilih Metode Rendering

Apakah halaman ini perlu muncul di mesin pencari?
Apakah konten berubah sering, atau cukup dibuat saat build?
Apakah halaman memuat data personal pengguna?
Seberapa cepat waktu tampil awal harus tercapai?
Seberapa kuat perangkat pengguna Anda?
Apakah server mampu menangani beban rendering?
Apakah pendekatan hybrid lebih cocok daripada satu metode saja?
Apakah TTFB, FCP, dan INP sudah dipantau setelah rilis?

Kesimpulan: Pilih Server-Side Rendering atau Client-Side Rendering Sesuai Kebutuhan Halaman

Server-side rendering membuat halaman di server dan mengirim HTML siap tampil, sehingga konten cepat terlihat dan mudah dibaca mesin pencari. Client-side rendering membuat halaman di browser, sehingga interaksi terasa mulus tetapi bergantung pada JavaScript dan kekuatan perangkat. Keduanya punya kelebihan dan biaya yang berbeda.

Karena itu, jawaban terbaik bergantung pada halaman Anda. Gunakan SSR atau static rendering untuk konten yang perlu cepat dan terindeks, dan gunakan CSR untuk bagian yang sangat interaktif. Ukur hasilnya, lalu sesuaikan. Dengan begitu, Anda memilih berdasarkan data, bukan sekadar tren.

Artikel Lainnya di NgodingDaily

Lanjutkan belajar dengan topik lain yang saling melengkapi: