Kamu sudah pakai React modern, tetapi app tetap terasa berat? Seringnya masalahnya bukan di framework, melainkan di keputusan sederhana, logic ini jalan di server atau di client.
Server Components vs Client Components bukan sekadar fitur baru. Ini cara mikir arsitektur. Kalau salah taruh, bundle JavaScript membengkak, hydration melambat, dan UX ikut kena. Kalau pas, halaman lebih cepat, interaksi tetap halus, dan beban browser turun jauh.
Jawaban Singkat
Gunakan Server Components untuk fetch data, render konten statis, akses secret, dan pekerjaan yang tidak butuh interaksi browser. Gunakan Client Components hanya untuk state lokal, event handler, efek browser, dan UI interaktif. Semakin kecil area client, semakin ringan bundle JavaScript-mu.
Kenapa Banyak Dev Masih Salah Bagi Tugas?
Banyak tim masih pakai pola lama, semua komponen interaktif dianggap aman dijalankan di client. Padahal setiap komponen client membawa biaya, JavaScript tambahan, hydration, parsing, lalu eksekusi di browser.
Akibatnya, app terlihat modern, tetapi performanya boros. Ini sering kejadian di dashboard, e-commerce, landing page SaaS, sampai portal konten.
Prinsip Dasar, Putuskan Berdasarkan Biaya Runtime
Cara paling aman bukan bertanya, bisa dijalankan di mana? Tanya begini, siapa yang paling mahal kalau menjalankan logic ini?
- Server cocok untuk data fetching, auth checks, formatting berat, markdown parsing, dan akses DB atau API private.
- Client cocok untuk klik tombol, input form, modal, tabs, drag and drop, dan state UI sementara.
Rule praktisnya sederhana. Kalau browser tidak perlu tahu prosesnya, pindahkan ke server.
Framework 3L, Logic, Latency, Liveness
Biar keputusanmu konsisten, pakai framework sederhana ini.
1. Logic
Apakah logic butuh akses database, token rahasia, filesystem, atau operasi berat? Kalau iya, taruh di server. Browser tidak perlu ikut kerja rodi.
2. Latency
Apakah hasilnya harus muncul cepat saat page load? Kalau iya, server sering lebih unggul karena HTML sudah datang lengkap. Ini bagus buat SEO dan perceived performance.
3. Liveness
Apakah UI harus hidup setelah render, misalnya search box realtime, accordion, atau filter interaktif? Kalau iya, bagian itu client. Namun, potong sekecil mungkin, jangan satu halaman penuh dijadikan client hanya karena ada satu tombol.
Kesalahan yang Paling Sering Terjadi
- Semua halaman diberi “use client” → bundle naik, hydration membesar.
- Fetch data di client padahal bisa di server → loading spinner bertambah, SEO melemah.
- Wrapper interaktif terlalu tinggi → child component ikut jadi client, padahal mayoritas statis.
- Library berat dipasang global → halaman sederhana ikut menanggung biaya.
Ide yang Sering Terasa Aneh, Interaktivitas Sedikit Lebih Baik daripada UI Super Dinamis
Ini yang sering dilupakan. Banyak dev mengejar UI yang serba realtime, padahal user sering cuma butuh halaman cepat, jelas, dan responsif seperlunya.
Contohnya, daftar produk atau artikel. Render list, metadata, dan navigasi di server. Lalu aktifkan client hanya pada komponen kecil seperti sort dropdown, wishlist button, atau filter panel. Hasilnya biasanya lebih cepat daripada membiarkan seluruh halaman hidup di browser.
Dengan kata lain, interactivity islands sering lebih efektif daripada full client rendering.
Kapan Harus Pakai Server Components?
- Menampilkan artikel, produk, profil, dokumentasi, landing page.
- Fetch data dari DB, CMS, atau API private.
- Personalization ringan berbasis cookie atau session.
- Transformasi data berat, misalnya sorting besar, formatting, atau markdown rendering.
- Komponen yang butuh SEO kuat dan first paint cepat.
Kalau kamu sedang bangun site content-heavy, baca juga Headless WordPress Next.js: Situs Cepat, UX Mantap.
Kapan Harus Pakai Client Components?
- Form dengan validasi instan.
- Modal, tooltip, tabs, dropdown, toast.
- Chart interaktif.
- Drag and drop, rich text editor, command palette.
- Komponen yang memakai
useState,useEffect, event handler, atau browser API.
Client Components tetap penting. Tujuannya bukan menghindari client, tetapi membatasi client ke area yang benar-benar butuh.
Pola Arsitektur yang Biasanya Menang
Server shell, client islands
Bangun kerangka halaman di server. Lalu sisipkan pulau interaktif kecil di titik penting. Ini pola yang paling sering memberi trade-off bagus antara UX, SEO, dan ukuran bundle.
Fetch high, interact low
Ambil data setinggi mungkin di server. Simpan interaksi sedekat mungkin ke komponen kecil. Ini mencegah prop drilling state yang nggak perlu dan menjaga batas client tetap tipis.
Static by default
Anggap semua komponen statis dulu. Baru ubah ke client kalau ada alasan nyata. Bukan sebaliknya.
Cara Audit Supaya Bundle JavaScript Nggak Gendut
- Cek komponen yang memakai
"use client". - Lihat apakah komponen parent membuat subtree besar ikut client.
- Audit library besar seperti charting, editor, date picker.
- Pindahkan data fetching ke server bila memungkinkan.
- Pakai dynamic import untuk fitur yang jarang dipakai.
Kalau timmu lagi serius soal stack modern, artikel TypeScript Jadi Default Bahasa Web Scalable juga relevan buat fondasi codebase jangka panjang.
Checklist Cepat Sebelum Menentukan Render Logic
- Apakah butuh secret, DB, atau API private? Server.
- Apakah butuh klik, input, atau animasi interaktif? Client.
- Apakah penting untuk SEO dan fast initial render? Server.
- Apakah hanya sebagian kecil UI yang interaktif? Buat island client kecil.
- Apakah library terlalu berat untuk semua user? Lazy load.
Referensi Teknis yang Layak Kamu Simpan
FAQ
Apakah Server Components selalu lebih cepat?
Nggak selalu. Untuk konten awal dan pengurangan bundle, biasanya iya. Namun untuk interaksi setelah halaman terbuka, Client Components tetap dibutuhkan.
Apakah Client Components buruk untuk SEO?
Bukan buruk, tetapi kalau data utama baru muncul setelah fetch di browser, crawler dan user bisa menerima pengalaman awal yang lebih lemah. Karena itu, konten utama lebih aman dirender di server.
Apakah semua aplikasi Next.js harus dominan server?
Tidak mutlak. Namun default yang sehat biasanya server-first, lalu client secukupnya. Pendekatan ini lebih mudah dikontrol saat app membesar.
Penutup
Keputusan antara Server Components vs Client Components sebenarnya bukan soal tren. Ini soal disiplin arsitektur. Kalau kamu menaruh logic di tempat yang tepat, app terasa lebih ringan, SEO lebih kuat, dan maintenance ikut lebih waras.
Mulai dari aturan sederhana, render di server sampai browser benar-benar perlu mengambil alih. Setelah itu, audit komponen client satu per satu. Biasanya di situlah bundle yang gendut mulai ketahuan.
Kalau kamu punya kasus arsitektur React atau Next.js yang bikin galau, drop di komentar. Kita bedah bareng. Lalu kalau mau update artikel teknis seperti ini langsung ke inbox, cek blok newsletter di bawah.
