Belajar Svelte - Server-side Rendering & SvelteKit

#Pendahuluan

Halaman web bisa dirender di banyak tempat: di server, di browser, atau tidak dirender sama sekali dan hanya disimpan sebagai HTML statis. Pilihan strategi menentukan kecepatan, SEO, dan interaktivitas.

Episode ini membahas SSG, SSR, dan hybrid rendering di SvelteKit, load functions dan data server, islands architecture dan partial hydration, serta kapan menggunakan SSR versus SSG.

Setelah selesai, kalian tahu mengapa satu halaman bisa jadi statis sementara halaman lain butuh server, dan bagaimana SvelteKit mengabungkan keduanya dengan mulus.

Strategi rendering juga memengaruhi biaya operasional: setiap request SSR memakai CPU server, sedangkan file statis dilayani hampir tanpa biaya. Memilih mode yang tepat adalah keputusan arsitektur sekaligus keuangan.

#SSG, SSR, dan Hybrid Rendering

#Tiga Strategi Dasar

SSG (static site generation) merender halaman sekali saat build dan menyajikannya sebagai file statis. SSR (server-side rendering) merender di server saat diminta. SvelteKit memungkinkan keduanya sekaligus — bahkan dalam satu aplikasi.

Ada satu mode tambahan yang sering terlewat: halaman yang di-render di server saat build dan dihidrasi di klien (SSG plus hydration). Kombinasi ini memberi HTML cepat dengan interaktivitas penuh.

#Perilaku Per Halaman

Mode rendering ditentukan per halaman melalui konfigurasi di +page.js:

Prerender satu halaman

export const prerender = true

Dengan prerender = true, halaman diproduksi sebagai HTML statis saat build. Nilai lain yang relevan: ssr = false untuk menonaktifkan rendering server, dan csr = false untuk menonaktifkan hidrasi di klien. Kombinasi nilai ini adalah cara SvelteKit mengontrol mode per halaman tanpa konfigurasi global.

#Load Functions dan Server-side Data

#Data Disediakan Sebelum Render

Load functions menyediakan data untuk halaman sebelum komponen dirender. Data bisa diambil di server atau klien, tergantung file tempatnya ditulis:

Load function untuk data server

export async function load({ fetch }) {
  const res = await fetch("/api/posts")
  if (!res.ok) {
    throw new Error("Gagal memuat posting")
  }
  return { posts: await res.json() }
}

fetch yang diterima load function bekerja di server maupun klien secara mulus. Data hasil load dikirim ke halaman, dan proses ini berjalan di server saat SSR aktif — sehingga HTML pertama sudah berisi konten, bukan spinner.

Load function juga bisa memanggil await parent() untuk mewarisi data dari layout di atasnya, atau mengembalikan data yang dialirkan untuk bagian yang bisa ditampilkan lebih dulu.

#Memisahkan Data per Rute

Data yang hanya dipakai layout induk diletakkan di load function layout; data khusus halaman di load function halaman. SvelteKit menggabungkan keduanya tanpa duplikasi, dan urutan pengerjaannya bisa diatur dengan await parent dari halaman ke layout.

Data yang diambil di server juga bisa ditandai sebagai streaming, sehingga bagian halaman yang lambat tidak menahan bagian yang cepat. Pengguna melihat konten pertama lebih dulu sementara sisanya menyusul.

#Islands Architecture dan Partial Hydration

#Konsep Islands

Islands architecture merender sebagian besar halaman sebagai HTML statis dan hanya menghidrasi bagian yang interaktif. Hasilnya: lebih sedikit JavaScript yang diunduh dan dieksekusi di klien.

Istilah islands pertama kali populer di komunitas framework server-rendered, dan sekarang menjadi pola yang diadopsi lintas ekosistem karena menghemat byte JavaScript secara signifikan.

#Partial Hydration di SvelteKit

SvelteKit tidak memakai islands secara literal, tetapi mendukung pendekatan serupa. Halaman yang di-prerender tetap mendapat interaktivitas pada komponen yang butuh state:

<script>
  let aktif = $state(false)
</script>
 
<button onclick={() => (aktif = !aktif)}>Buka menu</button>

Komponen ini hidup di antara markup statis. Halaman utamanya dirender server, sementara tombol ini menghidrasi dan merespons interaksi — seperti island di tengah laut HTML statis.

Kombinasi prerender dengan komponen interaktif membuat halaman blog atau marketing terasa statis namun tetap hidup. Pengguna mendapatkan HTML cepat; komponen yang butuh state baru dimuat JavaScript-nya.

#Kapan Memakai SSR vs SSG

#Kekuatan Masing-masing

SSG unggul untuk konten yang jarang berubah: blog, dokumentasi, dan halaman marketing. Kecepatannya tak terkalahkan karena HTML sudah siap dan bisa di-cache di CDN. SSR unggul untuk data yang personal dan dinamis: dashboard, halaman yang bergantung pada user, dan konten yang sering diperbarui.

Perhatikan juga waktu build: SSG membangun setiap halaman saat rilis, sehingga situs dengan puluhan ribu halaman membutuhkan build yang lebih lama dibanding SSR yang membangun satu halaman sekali.

#Pola Hybrid yang Praktis

Mulailah dari prerender untuk semua yang bisa diprediksi, dan beri prerender = false pada rute dinamis. Pola hybrid ini menurunkan beban server sekaligus menjaga pengalaman personal. Ukur perilaku aplikasi lalu sesuaikan — tidak ada konfigurasi yang salah mutlak.

Untuk situs konten besar, kombinasikan SSG dengan incremental build: hanya halaman yang berubah yang dibangun ulang. Pendekatan ini menjaga kecepatan SSG tanpa mengorbankan skala.

#Penutup

Inti yang harus dibawa pulang:

• SSG, SSR, dan mode hybrid bisa digabung dalam satu aplikasi.
• Atur mode rendering per halaman dengan prerender, ssr, dan csr.
• Load functions menyediakan data sebelum halaman dirender.
• Islands architecture meminimalkan JavaScript yang dihidrasi.
• SSG untuk konten jarang berubah, SSR untuk data personal dan dinamis.
• Gunakan pola hybrid sebagai titik awal yang seimbang.

Di episode 22 selanjutnya kalian akan belajar observability & monitoring — memantau performa frontend dan error, logging masalah klien dan metrik pengguna, real user monitoring dan analytics, serta dukungan produksi dan penanganan insiden. Strategi rendering yang kalian pilih bisa dipantau hasilnya secara nyata.