Nextjs Kamu Berat di Client Side Mungkin Ini Penyebab dan Solusi Gampang Buat Kamu

Nextjs Kamu Berat di Client Side Mungkin Ini Penyebab dan Solusi Gampang Buat Kamu
Photo by Sebastian Herrmann/Unsplash

Nextjs itu sering dielu-elukan sebagai framework dewa penolong buat urusan performance dan SEO. Janjinya muluk-muluk: situs yang cepat, server-side rendering (SSR) yang bikin load time awal ngebut, dan pengalaman develop yang menyenangkan. Tapi, jujur deh, buat kamu yang sudah pakai Next.js, pasti pernah kan ngerasa pas load awal cepet, eh pas mulai interaksi atau navigasi, kok situsnya kayak mendadak berat?

Bahkan, ada yang initial load-nya sudah pakai SSR atau Static Generation (SSG), tapi pas diukur pakai Lighthouse, skor TBT (Total Blocking Time) dan LCP (Largest Contentful Paint)-nya tetap jeblok. Client side kamu rasanya kayak lagi bawa karung semen. Kalau kamu mengalami ini, tenang saja, kamu tidak sendirian.

Next.js itu pondasinya memang kuat, tapi dia hanya alat. Kalau cara pakainya kurang pas, potensi masalah yang muncul justru ada di fase hydration atau saat client mulai mengambil alih kendali dari server.

Sebagai bagian dari tim ahli di Javapixa Creative Studio, yang setiap hari berkutat dengan optimasi Next.js untuk aplikasi skala besar, kami sudah sering melihat (dan membetulkan) kesalahan-kesalahan umum ini. Ini dia penyebab utama kenapa Next.js kamu jadi berat di sisi client dan solusi gampang yang bisa langsung kamu terapkan.

---

Kenapa Next.js Kamu "Napasnya Pendek" Setelah Server Render?

Inti dari Next.js adalah membuat initial load sangat cepat karena semua HTML sudah di-render di sisi server. Tapi, setelah HTML itu terkirim, browser harus melakukan proses hydration. Hydration adalah proses di mana React "membangkitkan" komponen HTML statis tersebut menjadi komponen interaktif yang bisa merespons event dari pengguna.

Kalau proses hydration ini lambat, atau bundle JavaScript yang harus di-download oleh client ukurannya jumbo, di situlah masalah muncul. Berikut adalah beberapa biang keladinya:

1. Kamu Impor Perpustakaan Segede Gajah (Padahal Cuma Pakai Sedikit)

Ini adalah error paling klasik. Kamu mungkin butuh satu fungsi kecil dari sebuah library pihak ketiga yang sangat besar (misalnya, utility library yang punya ratusan fungsi, atau date picker dengan banyak fitur yang tidak kamu gunakan).

Ketika kamu menggunakan sintaks import { fungsiA } from 'library-berat'; di bagian atas file, Webpack (yang digunakan Next.js) akan memasukkan seluruh kode dari library 'library-berat' itu ke dalam bundle utama, padahal kamu hanya butuh fungsiA. Ini namanya bundling bloat.

Contoh Kasus: Kamu hanya butuh fungsi format tanggal dari lodash atau moment.js, tapi kamu impor semua isinya. Alhasil, ukuran chunk JS kamu langsung melonjak beberapa ratus KB.

2. Tidak Peka Terhadap "Tree Shaking"

Tree Shaking adalah proses yang dilakukan bundler (Webpack/Rollup) untuk menghilangkan kode yang tidak digunakan (mati) dari bundle akhir. Next.js sudah sangat baik dalam melakukan tree shaking, tetapi dia hanya bisa melakukannya jika kamu mengimpor kode dengan cara yang benar.

Beberapa library lama atau yang tidak didesain dengan baik untuk module system modern (ES Modules) seringkali menghalangi proses tree shaking. Akibatnya, banyak kode sampah ikut terbawa ke client side.

3. Komponen Interaktif Terlalu Banyak di Halaman Awal

Misalnya, halaman beranda kamu punya 10 widget yang semuanya interactive (punya state, punya event handler). Next.js harus menghidrasi kesepuluh komponen itu secara bersamaan. Semakin banyak komponen yang harus dihidrasi, semakin lama proses TBT (Total Blocking Time) kamu.

Banyak developer Next.js yang lupa bahwa tidak semua komponen harus dihidrasi saat initial load. Jika sebuah komponen ditaruh di bagian bawah (di bawah fold), atau hanya muncul setelah di-scroll, kenapa harus di-load sekarang?

4. Malas Pakai next/image dan next/font

Ini adalah dosa besar di ekosistem Next.js. Next.js memberikan komponen

bukan cuma buat gaya-gayaan. Komponen ini melakukan banyak optimasi di belakang layar: lazy loading otomatis, responsive sizing, format conversion (WebP), dan placeholder blur.

Jika kamu masih menggunakan tag

biasa, semua optimasi itu hilang. Browser harus mengunduh full resolution gambar (seringkali JPEG raksasa) segera, yang secara langsung memperlambat LCP dan memakan banyak bandwidth client.

5. Cache dan Configuration yang Kurang Optimal

Meskipun Next.js sudah mengatur cache dengan cerdas, terkadang konfigurasi header di sisi deployment atau middleware yang kamu buat malah mengganggu mekanisme cache Next.js, menyebabkan aset yang seharusnya sudah di-cache malah di-download ulang.

---

Solusi Gampang: Resep Jitu Next.js Anti Berat

Setelah tahu biang keladinya, sekarang saatnya kita bahas solusinya. Ini adalah teknik-teknik yang sering kami terapkan di Javapixa Creative Studio untuk memastikan aplikasi Next.js klien kami berjalan secepat kilat.

1. Jurus Wajib: Dynamic Imports (Code Splitting Tingkat Dewa)

Ini adalah senjata paling ampuh untuk mengurangi ukuran bundle yang harus di-load saat halaman pertama kali dibuka. Next.js sudah menyediakan fitur ini secara built-in melalui next/dynamic.

Cara Kerjanya: Daripada mengimpor komponen saat file dimuat (import KomponenBerat from './KomponenBerat'), kamu menginstruksikan Next.js untuk memuat komponen tersebut hanya ketika benar-benar dibutuhkan, menjadikannya chunk JS yang terpisah.

javascript
// Dulu (Berat):
// import ChartComponent from 'react-chartjs-2';// Sekarang (Gunakan next/dynamic):
import dynamic from 'next/dynamic';const ChartComponent = dynamic(() => import('react-chartjs-2'), {
  ssr: false, // Penting! Jika komponen ini hanya butuh di sisi client
  loading: () => Memuat Chart...,
});function Dashboard() {
  return (
    
      {/ ChartComponent hanya akan di-load saat dibutuhkan /}
      
    
  );
}

Tips Pro: Gunakan ssr: false untuk komponen yang sangat bergantung pada API browser (seperti peta, chart interaktif, atau komponen yang manipulasi DOM secara langsung). Ini akan mencegah komponen tersebut di-render di server, mengurangi beban server dan memastikan client hanya mengunduh JS yang mereka butuhkan.

2. Memanfaatkan Batasan Client Component dan Server Component (Next.js 13/14)

Jika kamu sudah menggunakan App Router (Next.js 13 ke atas), kamu punya alat yang sangat kuat untuk memisahkan beban: Server Component dan Client Component.

Server Components (Default): Tidak ada JavaScript yang dikirim ke client*. Cocok untuk bagian statis, mengambil data, dan layout. Client Components (Ditandai use client): Hanya komponen yang benar-benar butuh interaksi, state, atau event handler* yang harus menggunakan ini.

Prinsip Utama: Sebisa mungkin, biarkan semua komponen menjadi Server Component. Baru gunakan Client Component untuk bagian yang sangat spesifik (misalnya, tombol Like, atau input form). Jika kamu punya komponen induk besar yang menggunakan use client, semua komponen anaknya akan ikut terhidrasi di client, bahkan jika mereka sebenarnya statis.

Solusi "Wrapper Zero JS": Pastikan kamu "mencekik" batasan use client sedekat mungkin ke komponen yang membutuhkan interaksi. Jangan tandai Layout utama kamu dengan use client.

3. Prioritas Rendering dengan priority di

Next.js

punya fitur priority={true}. Fitur ini seharusnya hanya kamu gunakan untuk gambar-gambar yang muncul di Above the Fold (bagian layar yang terlihat tanpa scroll), seperti logo, hero image, atau gambar utama konten.

Menggunakan priority secara berlebihan justru bisa membuat client lambat. Kenapa? Karena Next.js akan memuat gambar-gambar tersebut segera mungkin. Batasi penggunaan priority hanya untuk 1-2 gambar krusial per halaman. Untuk gambar yang ada di bawah, biarkan fitur lazy loading bekerja otomatis.

4. Analisis Bundle: Kenali Siapa yang Bikin Berat

Kamu tidak akan bisa mengoptimasi jika kamu tidak tahu di mana masalahnya. Kamu harus melihat peta bundle JS kamu. Next.js menyediakan fitur yang terintegrasi dengan Webpack Bundle Analyzer.

Cara Gampang Mengaktifkan:

  1. Instal package yang dibutuhkan: npm install --save-dev @next/bundle-analyzer
  2. Konfigurasi di next.config.js:

javascript
// next.config.js
const withBundleAnalyzer = require('@next/bundle-analyzer')({
  enabled: process.env.ANALYZE === 'true',
});

Jalankan build dengan variabel lingkungan: ANALYZE=true npm run build.

Hasilnya akan muncul visualisasi interaktif berupa peta blok. Blok-blok besar itulah yang harus kamu targetkan untuk di-dynamic import atau dihilangkan. Jika kamu melihat satu library mendominasi peta, cari cara untuk mengimpornya sebagian (menggunakan named imports).

5. Optimasi Data Fetching dan Global State

Jika kamu menggunakan Redux, Zustand, atau global state management lainnya, pastikan store kamu tidak terlalu gemuk atau diinisialisasi secara berlebihan di setiap halaman.

Jika ada data yang hanya dibutuhkan oleh client setelah login, jangan masukkan data tersebut ke dalam initial state yang dikirim dari server saat SSR. Biarkan client mengambilnya menggunakan client-side fetching (misalnya dengan SWR atau React Query) setelah hydration selesai. Ini mengurangi payload awal yang harus diproses oleh browser.

6. Menghilangkan Console.log dan Debugger di Production

Ini terlihat sepele, tapi console.log yang berlebihan (terutama di perulangan atau lifecycle component yang sering render) bisa memberikan beban tambahan yang signifikan pada mesin JavaScript browser client. Pastikan di build production kamu, semua debugging statement ini sudah dihilangkan.

---

Ketika Optimasi Menjadi Tugas Profesional

Melakukan optimasi Next.js hingga mencapai skor Lighthouse 100/100, terutama untuk aplikasi besar seperti e-commerce atau SaaS yang kompleks, bukan lagi sekadar trik, tapi membutuhkan strategi yang mendalam—mulai dari monitoring real-time (Real User Monitoring/RUM), penyesuaian edge caching menggunakan Vercel atau Cloudflare, hingga arsitektur micro-frontend jika diperlukan.

Di sinilah peran Javapixa Creative Studio menjadi krusial.

Kami di Javapixa Creative Studio tidak hanya membangun aplikasi dengan Next.js; kami membangun performance yang berkelanjutan. Kami fokus pada arsitektur yang scalable, memastikan setiap byte JavaScript yang dikirim ke client benar-benar bernilai. Kami menerapkan teknik Pre-rendering yang cerdas, incremental static regeneration (ISR) yang tepat guna, dan memastikan client bundle kamu selalu ramping, gesit, dan anti berat.

Jika kamu merasa sudah mencoba semua tips di atas tapi aplikasi Next.js kamu masih terseok-seok, atau jika proyek kamu sudah terlalu besar hingga debugging performanya jadi mimpi buruk, mungkin sudah saatnya kamu mendelegasikannya kepada ahli.

Kami siap membantu kamu menganalisis bundle size, menyempurnakan caching strategy, dan memastikan pengguna kamu mendapatkan pengalaman tercepat, karena kami paham, dalam dunia digital, kecepatan adalah mata uang. Jangan biarkan client side Next.js kamu jadi beban. Saatnya naik level bersama Javapixa Creative Studio.