JAKARTA, cssmayo.com – Sebelum era JavaScript framework yang mendominasi, hampir semua website bekerja dengan cara yang sama: pengguna meminta halaman, server memproses permintaan, menghasilkan HTML lengkap, dan mengirimkannya ke browser. Browser hanya perlu menampilkan HTML yang sudah jadi. Cara kerja ini dikenal sebagai server side rendering — dan meski sempat tergeser oleh Single Page Application, ia kini kembali dengan posisi yang lebih kuat dari sebelumnya.
Server side rendering (SSR) adalah teknik di mana HTML halaman web dihasilkan di server pada setiap kali ada permintaan dari pengguna, bukan di browser klien. Selain itu, berbeda dari Static Site Generation yang menghasilkan HTML saat build time, SSR menghasilkan HTML secara dinamis saat runtime — sehingga setiap pengguna bisa mendapat konten yang dipersonalisasi sesuai konteks mereka.
Cara Kerja Server Side Rendering
Proses server side rendering mengikuti alur yang jelas setiap kali ada permintaan:
- Request diterima: Browser pengguna mengirimkan HTTP request ke server untuk halaman tertentu.
- Server memproses: Server mengambil data yang diperlukan — dari database, API, atau sumber lain — dan menggabungkannya dengan template untuk menghasilkan HTML lengkap.
- HTML dikirim: Server mengirimkan HTML yang sudah lengkap ke browser. Selain itu, browser langsung bisa menampilkan konten tanpa perlu menunggu JavaScript dieksekusi.
- Hydration (untuk framework modern): Setelah HTML ditampilkan, JavaScript di-load dan “menghidupkan” halaman — menghubungkan event handler dan membuat halaman interaktif. Proses ini disebut hydration.
Keunggulan Server Side Rendering
SSR menawarkan beberapa keunggulan yang membuatnya tetap relevan dan bahkan semakin populer:
- SEO optimal: Search engine menerima HTML yang sudah lengkap berisi semua konten. Tidak ada masalah dengan bot yang tidak bisa menjalankan JavaScript. Hasilnya adalah indexing yang lebih baik dan ranking yang lebih tinggi untuk konten yang bergantung pada SEO.
- First Contentful Paint (FCP) cepat: Pengguna melihat konten lebih cepat karena browser langsung menampilkan HTML yang diterima dari server — tanpa menunggu bundle JavaScript besar diunduh dan dieksekusi.
- Konten yang dipersonalisasi: Karena HTML dihasilkan per-request, server bisa menyesuaikan konten berdasarkan sesi pengguna, lokasi, preferensi, atau data lainnya secara langsung dalam HTML awal.
- Tidak bergantung pada JavaScript klien: Pengguna dengan JavaScript yang dinonaktifkan atau perangkat lama yang lambat mengeksekusi JS tetap mendapat konten yang bisa dibaca.
Framework Server Side Rendering Modern
Beberapa framework terkemuka yang mendukung SSR:
- Next.js: Framework React yang paling populer untuk SSR. Fungsi
getServerSidePropsmemungkinkan pengambilan data di server untuk setiap request. Selain itu, Next.js mendukung SSR, SSG, dan ISR dalam satu framework yang sama. - Nuxt.js: Ekuivalen Next.js untuk ekosistem Vue. Menyediakan SSR yang sangat mudah dikonfigurasi dengan DX yang sangat baik.
- SvelteKit: Framework Svelte yang mendukung SSR dengan cara yang sangat elegan dan performa yang luar biasa.
- Remix: Framework React yang sangat berorientasi pada web standards dan server-first philosophy. Setiap route di Remix mendukung loader di server yang berjalan sebelum rendering.
- Astro: Meski dikenal sebagai SSG framework, Astro juga mendukung SSR untuk halaman yang memerlukan konten dinamis.
SSR vs SSG vs CSR: Perbandingan Lengkap
Memahami perbedaan ketiga pendekatan membantu membuat keputusan yang tepat:
Client Side Rendering (CSR): Server hanya mengirimkan shell HTML kosong dan bundle JavaScript. Browser mengunduh JS, mengeksekusinya, lalu mengambil data dan merender konten. Lambat untuk FCP namun setelah load pertama navigasi sangat cepat. Cocok untuk aplikasi web yang mengutamakan interaktivitas.
Static Site Generation (SSG): HTML dihasilkan saat build time dan disimpan sebagai file statis. Sangat cepat karena bisa disajikan dari CDN. Tidak bisa menampilkan konten yang berbeda per-pengguna. Cocok untuk konten yang tidak sering berubah.
Server Side Rendering (SSR): HTML dihasilkan per-request di server. Bisa menampilkan konten dinamis dan personal. Lebih lambat dari SSG karena ada pemrosesan server setiap request, namun jauh lebih fleksibel. Selain itu, cocok untuk halaman yang membutuhkan data real-time atau konten yang dipersonalisasi.
Streaming SSR: Generasi Berikutnya
React 18 memperkenalkan Streaming SSR yang mengubah cara kerja SSR secara fundamental. Alih-alih menunggu seluruh halaman selesai dirender sebelum mengirimkan HTML, streaming SSR mengirimkan HTML secara bertahap saat setiap bagian selesai dirender.
Dengan demikian, pengguna mulai melihat konten pertama jauh lebih cepat. Bagian yang memerlukan data lambat tidak menghalangi bagian lain yang sudah siap. Hasilnya adalah pengalaman yang terasa jauh lebih responsif meski server masih memproses sebagian halaman.
Tantangan dalam Server Side Rendering
SSR bukan tanpa tantangan yang perlu dipahami dan diantisipasi sejak awal:
Waktu respons server: Karena HTML dihasilkan per-request, setiap permintaan memerlukan waktu pemrosesan di server. Query database yang lambat, API eksternal yang tidak responsif, atau logika rendering yang kompleks bisa langsung berdampak pada pengalaman pengguna. Hasilnya adalah Time to First Byte yang lebih tinggi dibandingkan SSG yang hanya melayani file statis.
Beban server yang lebih tinggi: Server harus bekerja lebih keras karena harus merender HTML untuk setiap request. Saat trafik melonjak, server perlu di-scale secara vertikal atau horizontal untuk menangani beban yang meningkat. Selain itu, caching di level CDN menjadi lebih kompleks karena konten bisa berbeda per-pengguna.
Hydration mismatch: Ini adalah salah satu error yang paling sering ditemui dalam SSR — saat HTML yang dihasilkan server berbeda dengan apa yang React atau Vue hasilkan di browser saat hydration. Error ini bisa disebabkan oleh penggunaan data yang bergantung pada waktu, browser API yang tidak tersedia di server, atau kondisi race yang halus.
State management yang lebih kompleks: State aplikasi perlu dikelola dengan hati-hati agar tidak “bocor” antar request dari pengguna yang berbeda — sebuah masalah keamanan yang serius jika tidak ditangani dengan benar.
Tips Mengoptimalkan Server Side Rendering
Beberapa strategi yang membantu SSR berjalan lebih efisien:
- Caching agresif: Cache hasil rendering untuk halaman yang tidak berbeda antar pengguna menggunakan cache di memori (Redis) atau di CDN. Dengan demikian, beban server berkurang drastis untuk konten yang bersifat semi-statis.
- Defer data yang tidak kritis: Gunakan Streaming SSR untuk mengirimkan shell halaman lebih cepat, sementara data yang lambat dimuat secara asinkron di background.
- Optimasi query database: Gunakan query yang efisien, indeks yang tepat, dan connection pooling untuk memastikan pengambilan data tidak menjadi bottleneck rendering.
- Pisahkan SSR dan SSG: Gunakan SSR hanya untuk halaman yang benar-benar memerlukan data real-time atau personalisasi. Sisanya gunakan SSG untuk menghemat sumber daya server.
Kesimpulan
Server side rendering adalah pendekatan yang telah melewati ujian waktu dan terus berkembang dengan inovasi seperti streaming dan partial hydration. Untuk aplikasi yang mengutamakan SEO, personalisasi konten, dan pengalaman pengguna yang cepat bahkan pada koneksi lambat, SSR tetap menjadi pilihan yang sangat kuat. Selain itu, dengan framework modern yang membuat implementasi SSR semakin mudah, tidak ada alasan untuk tidak mempertimbangkan SSR sebagai pilihan utama dalam arsitektur web yang baru. Kunci keberhasilan SSR adalah menggunakannya secara selektif — menerapkannya di halaman yang benar-benar membutuhkan dinamisme, dan membiarkan SSG menangani sisanya.
Eksplorasi lebih dalam Tentang topik: Techno
Cobain Baca Artikel Lainnya Seperti: Static Site Generation: Pendekatan Web yang Cepat dan Aman
