Partial Hydration: Cara Pangkas JavaScript Website Bisnis di 2026

TL;DR: Partial hydration adalah pola arsitektur front-end di mana hanya komponen interaktif yang memuat JavaScript-nya, sementara sisa halaman tetap HTML statis. Untuk website bisnis Indonesia yang banyak diakses lewat HP kelas menengah, pola ini bisa memangkas bundle awal 30-60% dan mengangkat skor Core Web Vitals tanpa mengorbankan interaktivitas. Implementasinya bisa lewat Astro, Qwik, atau React Server Components di Next.js App Router.

Beberapa kali saya mengaudit website bisnis klien yang skor LCP-nya jelek di Lighthouse. Pola yang berulang: halaman landing dengan 80% konten statis, tapi mengirim 400 KB JavaScript ke browser hanya karena framework default melakukan hydration penuh. Pengunjung di HP kelas menengah harus menunggu 3-4 detik sebelum halaman bisa di-scroll dengan nyaman.

Solusinya bukan ganti framework total, tapi memilih ulang batas antara HTML statis dan komponen yang benar-benar butuh JavaScript. Inilah inti partial hydration.

Kenapa Bundle Besar Mahal untuk Bisnis Indonesia

Per April 2026, Speedtest Global Index menempatkan koneksi mobile Indonesia di peringkat sekitar 80-90 dunia. Artinya banyak calon pelanggan Anda membuka website dari koneksi 4G yang tidak stabil dan HP yang RAM-nya pas-pasan. Setiap kilobyte JavaScript di-parse, di-compile, dan di-execute di browser mereka.

Hubungannya dengan konversi cukup langsung: data internal dari beberapa audit yang saya kerjakan menunjukkan korelasi antara LCP di atas 4 detik dan bounce rate di atas 60%. Largest Contentful Paint yang melambat sering kali terjadi bukan karena gambar besar, melainkan karena thread JavaScript sibuk menjalankan hydration kode yang sebetulnya tidak akan disentuh pengguna.

Tiga Pola Implementasi Partial Hydration

Pendekatan islands architecture paling agresif dalam memangkas JavaScript, cocok untuk landing page dan blog korporat. Untuk SaaS atau dashboard yang banyak interaksi, Next.js dengan React Server Components lebih praktis karena tim React tidak perlu belajar framework baru.

Studi Kasus Singkat dari Audit Klien

Saat mengaudit website jasa konsultan klien tahun lalu, halaman utamanya mengirim 380 KB JavaScript untuk fitur yang sebetulnya hanya: form kontak (di footer) dan dropdown navigasi mobile. Setelah memindahkan konten ke komponen server dan menyisakan dua komponen client tadi, bundle awal turun ke sekitar 110 KB. INP membaik dari 320 ms ke 140 ms. Tidak ada perubahan desain visual, hanya pemisahan komponen yang tepat. Detail teknis lebih lanjut bisa dibaca di artikel prerendering vs SSR untuk website bisnis.

Hasil ini tidak universal, ya. Angkanya bervariasi tergantung struktur project dan dependensi. Tapi prinsipnya konsisten: setiap komponen yang dipaksa di-hydrate padahal tidak interaktif adalah pemborosan.

Cara Mulai Audit Hari Ini

Untuk tim yang sudah pakai Next.js App Router, langkah praktisnya:

1. Buka file-file yang punya 'use client' di paling atas.
2. Tanyakan: apakah komponen ini benar-benar butuh state atau event handler?
3. Jika jawabannya tidak, hapus 'use client' dan biarkan jadi server component.
4. Untuk komponen yang interaktif tapi tidak kritis (chat widget, popup newsletter), tunda load-nya pakai dynamic import dengan ssr: false dan strategi lazy.
5. Ukur ulang lewat PageSpeed Insights untuk lihat dampak ke LCP dan INP.

Untuk yang masih pakai Pages Router atau framework lain, evaluasi pemindahan ke Astro untuk landing page marketing, sembari menjaga aplikasi inti di stack lama.

Pertanyaan Umum

Apakah partial hydration aman untuk SEO?

Aman. HTML tetap dirender server, jadi Googlebot dan crawler AI Search membaca konten sama seperti biasa. Yang berubah hanya jumlah JavaScript yang dikirim ke browser pengguna.

Bagaimana dengan animasi yang butuh JavaScript?

Animasi ringan (Framer Motion, CSS transition) tetap bisa berjalan di komponen client kecil. Yang penting batasi cakupannya. Hindari membungkus seluruh halaman dengan provider animasi.

Apakah partial hydration bisa diterapkan tanpa mengganti framework?

Untuk Next.js dan SvelteKit, ya, karena keduanya sudah punya konsep server component atau zero-JS by default. Untuk framework lama tanpa konsep ini, migrasi bertahap ke Astro untuk halaman marketing adalah jalur paling masuk akal.

Berapa lama biasanya proses migrasi partial hydration?

Untuk website bisnis 10-20 halaman, audit dan refactor biasanya 1-2 minggu. Untuk aplikasi besar, butuh perencanaan komponen demi komponen, bisa 4-8 minggu.

Penutup: Performa Bukan Soal Framework, Tapi Soal Pilihan

Partial hydration bukan teknologi ajaib. Inti pesannya sederhana: jangan kirim JavaScript yang tidak akan dipakai. Praktik ini adalah disiplin tim front-end yang sadar bahwa setiap kilobyte yang dikirim ke HP pelanggan adalah biaya kognitif dan biaya bisnis.