SSR Itu Awal, Streaming UI dan Partial Rendering yang Beneran Bikin App Ngebut

Kamu sudah pake SSR, bundle udah di-split, LCP udah turun. Tapi user tetap nunggu. Bukan karena server lambat, tapi karena browser harus nunggu semua data siap sebelum satu piksel pun muncul. Rasanya kayak restoran yang nggak nyajiin minuman sebelum steak matang. Padahal user cuma mau baca judul dulu.

Di sinilah streaming UI dan partial rendering masuk. Ini bukan sekadar optimization setelah SSR. Ini cara fundamental mengubah urutan tampilnya konten. Kamu nggak lagi kirim halaman utuh, tapi kirim potongan UI secara progresif.

Masalah yang Nggak Disadari Setelah SSR

SSR memang ngirim HTML dari server. Tapi ada jebakan halus. Kalau satu endpoint lambat, satu query database berat, atau satu API eksternal timeout, seluruh halaman ikut tertahan. Browser nggak bisa render apa pun sebelum stream selesai.

Ini namanya waterfall blocking. Setiap data jadi dependency dari seluruh halaman. Padahal header, sidebar, footer, dan judul artikel sudah siap dari tadi.

Masalah ini makin nyata di halaman dashboard, e-commerce dengan rekomendasi produk, atau portal konten dengan data analytics. Satu komponen lambat bikin semua komponen lain ikut nunggu.

Apa Itu Streaming UI?

Streaming UI adalah kemampuan mengirim HTML dari server secara bertahap. Browser menerima chunk pertama langsung, render apa yang bisa, lalu menyisipkan chunk berikutnya begitu siap. Bayangin kayak video streaming, tapi yang dikirim adalah potongan HTML.

React 18 dan Next.js App Router mendukung ini lewat React.lazy() dan <Suspense>. Server mengirim placeholder (fallback skeleton) dulu, lalu stream konten asli begitu data selesai. Tanpa blocking. Tanpa menunggu.

Referensi resmi: React 18 Suspense documentation dan Next.js Streaming guide.

Partial Rendering, Kirim yang Cepat Dulu

Partial rendering adalah ide bahwa tidak semua bagian halaman harus tiba bersamaan. Header statis, navigasi, dan konten utama bisa muncul duluan. Komponen berat seperti rekomendasi produk, chart analytics, atau komentar bisa menyusul.

Bedanya dengan loading spinner biasa, partial rendering pakai Suspense boundary untuk menentukan zona yang boleh ditunda. Di luar boundary itu, halaman sudah interaktif. Di dalam boundary, fallback ditampilkan sampai data datang.

Ini cara kerja di Next.js App Router:

// app/dashboard/page.tsx
import { Suspense } from "react";
import { Header, Sidebar, AnalyticsChart, RecentOrders } from "./components";

export default function DashboardPage() {
  return (
    <div>
      <Header />
      <Sidebar />
      
      {/* Bagian ini langsung render, nggak nunggu */}
      <h2>Dashboard Overview</h2>
      
      {/* Bagian ini boleh nyusul */}
      <Suspense fallback={<ChartSkeleton />}>
        <AnalyticsChart />
      </Suspense>
      
      <Suspense fallback={<OrdersSkeleton />}>
        <RecentOrders />
      </Suspense>
    </div>
  );
}

Yang terjadi: Header dan Sidebar muncul instan. Chart skeleton tampil dulu, lalu diganti chart asli. Orders skeleton tampil dulu, lalu diganti data orders. Nggak ada blocking antar komponen.

Kenapa Ini Lebih Penting dari yang Kamu Kira

Banyak developer percaya bahwa total load time adalah metrik utama. Padahal user nggak peduli kapan halaman “selesai”. Mereka peduli kapan mereka bisa mulai membaca atau mulai interaksi.

Streaming UI secara radikal memperbaiki metrik berikut:

• First Contentful Paint (FCP): konten pertama muncul jauh lebih awal karena nggak blocked.
• Time to First Byte (TTFB): server langsung kirim chunk awal tanpa menunggu semua query selesai.
• Largest Contentful Paint (LCP): elemen utama bisa dirender lebih dulu tanpa diganggu komponen lambat.
• Interaction to Next Paint (INP): browser punya ruang napas karena main thread nggak dibombardir JS sekaligus.

Cek metrik lebih detail di web.dev tentang streaming.

Suspense Boundary yang Strategis, Bukan Sekadar Pembungkus

Kesalahan paling umum: bungkus seluruh halaman dalam satu Suspense. Itu sama aja kayak SSR biasa, nggak ada streaming. Malah tambah overhead.

Yang benar: pecah menjadi beberapa Suspense boundary kecil. Setiap boundary independen. Setiap komponen punya fallback sendiri. Setiap data lambat cuma nge-block areanya sendiri, bukan seluruh halaman.

Pola yang sering menang di production:

• Shell (header, nav, footer): render langsung, tanpa Suspense.
• Konten utama: Suspense boundary tersendiri, fallback skeleton artikel.
• Sidebar / rekomendasi: Suspense boundary lain, muncul belakangan.
• Komentar / UGC: Suspense boundary paling santai, bisa loading paling akhir.

Prinsipnya: semakin tidak kritis, semakin boleh ditunda. Ini yang bikin halaman terasa progresif dan nggak bikin user frustrasi.

Streaming dan SEO, Apakah Aman?

Googlebot sudah bisa memproses HTML yang di-stream secara bertahap. Selama konten utama ada di chunk pertama, SEO tetap aman. Search engine nggak peduli apakah sidebar atau footer datang belakangan.

Yang perlu dijaga: jangan taruh konten esensial di dalam Suspense boundary dengan query lambat. Kalau data utama lama, Google bisa indexing halaman dengan skeleton sebagai konten. Jadi, pastikan konten utama tidak terbungkus Suspense yang lambat.

Koneksi ke artikel lain: kalau kamu pakai React Server Components sebagai fondasi, streaming UI adalah natural next step. Baca juga React Server Components Bikin App Ngebut, Ini Manfaat Nyatanya dan Server Components vs Client Components buat fondasi arsitekturnya.

Framework Praktis: 3C untuk Streaming Boundary

Waktu nentuin di mana taruh Suspense boundary, pakai 3C ini:

• Critical: apakah user butuh lihat ini dalam 1 detik pertama? Kalau iya, render langsung, jangan masuk Suspense.
• Complementary: apakah ini pelengkap yang tetap penting tapi boleh delay 1-3 detik? Suspense dengan skeleton yang rapi.
• Cosmetic: apakah ini aksesoris yang bisa delay 3+ detik? Suspense atau lazy load dengan prioritas rendah.

Framework sederhana ini bikin tim nggak debat panjang. Lihat komponen, kasih label C, lalu tentukan boundary-nya.

Kapan Streaming UI Kurang Efektif?

Nggak semua halaman cocok di-stream. Kalau halaman sangat interaktif sejak awal, misalnya editor teks, spreadsheet, atau aplikasi kolaborasi real-time, manfaat streaming lebih kecil. Karena mayoritas UI memang harus interaktif dan client-side.

Juga, kalau semua data halaman datang dari satu endpoint cepat yang selesai dalam 50ms, streaming nggak kasih perbedaan signifikan. Overhead Suspense boundary malah bisa bikin lebih lambat.

Gunakan streaming saat: halaman punya sumber data heterogen dengan kecepatan berbeda. Itu sweet spot-nya.

Kesalahan Implementasi yang Bikin Streaming Nggak Efektif

• Satu Suspense boundary besar: bikin seluruh halaman nunggu lagi, sama kayak SSR biasa.
• Fallback terlalu berat: skeleton dengan animasi kompleks justru bikin CPU sibuk.
• Streaming tapi fetch tetap blocking: kalau data fetching di server masih waterfall, streaming nggak bantu.
• Konten utama di dalam Suspense lambat: user lihat skeleton lebih lama dari konten asli.

FAQ

Apa beda streaming UI dengan SSR biasa?

SSR biasa ngirim HTML utuh setelah semua data siap. Streaming UI ngirim HTML bertahap, bagian cepat muncul duluan sementara bagian lambat menyusul tanpa blocking.

Apakah streaming UI butuh React Server Components?

Nggak wajib, tapi sangat direkomendasikan. React Server Components membuat rendering di server lebih natural. Tanpa RSC, streaming tetap bisa pakai Suspense di client, tapi benefit pengurangan JavaScript di browser jadi tidak maksimal.

Apakah streaming UI aman untuk SEO?

Aman selama konten utama ada di chunk pertama. Hindari membungkus konten esensial dalam Suspense dengan query lambat karena Googlebot bisa mengindeks skeleton sebagai konten.

Framework apa yang mendukung streaming UI saat ini?

Next.js App Router adalah yang paling matang. Remix juga punya defer() untuk streaming. Nuxt 3 mendukung <Suspense> untuk partial rendering. Di luar React, Astro dengan partial hydration juga menawarkan pola serupa.

Kesimpulan

Streaming UI dan partial rendering adalah evolusi setelah SSR yang sering terlewat. Banyak tim berhenti setelah SSR jalan, padahal cara konten dikirim sama pentingnya dengan siapa yang merender.

Mulai dari audit halaman yang paling banyak dikomplain user. Cek apakah ada komponen lambat yang memblokir seluruh halaman. Bungkus dengan Suspense boundary, kasih skeleton yang ringan, dan biarkan konten cepat tampil duluan. Efeknya sering langsung terasa: user berhenti ngeluh “loading lama”, padahal total waktu teknisnya sama.

Ini bukan magic. Ini soal urutan pengiriman. Dan urutan itu sering lebih penting daripada kecepatan.

Ada pengalaman streaming UI di production? Atau malah jebakan yang bikin tambah lambat? Drop di kolom komentar. Dan kalau kamu mau update artikel performa web seperti ini langsung ke inbox, cek newsletter di bawah.