Eksperimen Next.js: Seberapa Gila Performa Website Kamu Kalau Kita Maksimalkan App Router

Eksperimen Next.js: Seberapa Gila Performa Website Kamu Kalau Kita Maksimalkan App Router
Photo by Markus Spiske/Unsplash

Kalau bicara soal performa website, kita sering merasa sudah cukup puas kalau skor Lighthouse warnanya hijau. Tapi, kalau kita main di liga Next.js App Router, 'cukup puas' itu nggak ada dalam kamus. Kita nggak cuma mau cepat, kita mau gila. Kita mau experience di website kita serasa instan, bahkan di jaringan 3G.

Next.js App Router bukan sekadar update minor; ini adalah perombakan filosofi rendering. Ia membawa kembali kegagahan Server Components (RSC) sebagai default, membalikkan dominasi Client Side Rendering (CSR) yang selama ini membuat website kita berat di awal loading.

Eksperimen performa ini bukan cuma tentang trik kecil, tapi tentang bagaimana kita merancang ulang mentalitas coding kita. Mari kita bedah tuntas, seberapa gila performa website kamu kalau kita benar-benar maksimalkan potensi App Router.

---

Filosofi Dasar: Menghidupkan Server Components Seutuhnya

Hal pertama yang harus kita pahami adalah App Router menjadikan Server Component (SC) sebagai raja. Ini adalah penentu utama performa gila.

1. Minimalkan Batas Hidrasi (The Hydration Trap)

Hydration adalah proses di mana React di sisi klien "mengambil alih" markup HTML yang sudah di-render oleh server, melampirkan event listeners, dan membuat website menjadi interaktif. Hydration itu mahal. Semakin banyak JavaScript yang harus diunduh dan diproses klien, semakin lama waktu yang dibutuhkan.

Tips Taktis:

Pikirkan SC sebagai HTML Enhancer: Anggap Server Components kamu sebagai cara untuk menghasilkan HTML secepat kilat. Hanya logic yang mutlak* membutuhkan interaksi pengguna (misalnya, tombol Like, form input yang kompleks) yang boleh menggunakan Client Components ('use client'). Pindahkan Logic Non-Interaktif ke SC: Punya fungsi untuk memformat tanggal? Ambil data dari API? Hitung statistik? Semua itu wajib dilakukan di Server Components. Dengan begini, kode tersebut tidak pernah dikirim ke bundle* JavaScript klien. Gunakan Props Sebagai Jembatan: Jika kamu punya komponen besar, pecah menjadi bagian-bagian statis (SC) dan bagian interaktif kecil (CC). SC akan merender HTML statis, lalu mengirimkan data yang sudah matang sebagai props* ke CC yang kecil. Ini seperti mengirimkan paket yang sudah jadi, bukan bahan mentahnya.

2. Pemanfaatan server-only Package

Untuk memastikan kamu nggak sengaja mengimpor kode server (seperti database connection atau private API keys) ke dalam Client Components, manfaatkan package server-only. Next.js akan memblokir build jika kode yang diimpor oleh server-only diletakkan di dalam berkas yang menggunakan 'use client'. Ini bukan hanya soal keamanan, tapi juga pencegahan bundle size yang nggak perlu.

---

Strategi Data Fetching Paling Agresif

Performa sebuah website modern seringkali ditentukan oleh seberapa cepat kita bisa mengambil data. App Router menawarkan paradigma fetching yang jauh lebih unggul daripada menggunakan useEffect yang berat.

3. Mengandalkan fetch() Bawaan Next.js

Di dalam Server Components, Next.js memperluas fungsi fetch() bawaan JavaScript dengan fitur memoization dan caching otomatis. Ini adalah kunci performa gila.

Otomatisasi Deduplikasi (Memoization): Jika kamu memanggil fetch('api/data') di dua Server Components yang berbeda dalam single render pass, Next.js akan secara otomatis hanya menjalankan permintaan jaringan itu sekali. Ini mencegah waterfall (permintaan yang menunggu yang lain selesai) dan mengurangi beban jaringan secara drastis tanpa perlu state management atau caching library* eksternal.

4. Parallel Data Fetching dengan Suspense (The Asynchronous Revolution)

Ini adalah trik paling powerfull di App Router. Daripada menunggu data satu per satu (waterfall), kita harus menjalankan semua permintaan data secara paralel.

Cara Konvensional (Buruk):

javascript
// Data 1 (500ms) -> Data 2 (500ms) -> Total 1000ms

Cara Gila (App Router):

Kita tidak perlu Promise.all di satu tempat. Cukup panggil await fetch() di dalam komponen yang berbeda.

javascript
// Di root layout atau page.tsx:
// Ambil Komponen A dan Komponen B secara bersamaan
export default async function DashboardPage() {
  return (
    <>
      }>
         // Melakukan await fetch() di dalamnya
      
      }>
         // Melakukan await fetch() di dalamnya
      
    
  );
}

Ketika Next.js melihat dua komponen ini, ia akan mulai mengeksekusi fetching untuk keduanya secara bersamaan.

Peran Suspense: Suspense memungkinkan sisa halaman (layout, navigasi) untuk tetap ditampilkan segera (di-stream) sementara data untuk ComponentA dan ComponentB masih dalam proses pengambilan. Begitu data siap, placeholder (fallback) akan digantikan secara smooth. Ini memberikan perceived performance* (performa yang dirasakan pengguna) yang luar biasa cepat.

5. Caching Strategis: revalidateTag

Next.js App Router memberikan kontrol caching yang sangat granular. Daripada mengandalkan Vercel Cache yang default, kamu bisa menentukan seberapa sering data harus diperbarui.

Gunakan opsi next.revalidate di dalam fetch atau menggunakan revalidateTag untuk manual cache invalidation.

javascript
// Contoh 1: Revalidate setiap 60 detik
const res = await fetch('https://api.example.com/products', {
  next: { revalidate: 60 }
});// Contoh 2: Tagging untuk revalidation manual
const res = await fetch('https://api.example.com/user', {
  next: { tags: ['user-profile'] }
});

Dengan caching yang cerdas ini, pada sebagian besar kunjungan, server tidak perlu memanggil API eksternal sama sekali, melainkan langsung menyajikan data dari cache, menghasilkan respons yang mendekati nol latensi.

---

Disiplin Komponen Klien dan Ukuran Bundle

Meski Server Components adalah penyelamat, kita tetap harus berhati-hati dengan Client Components (CC) yang menjadi pintu masuk ke bundle size yang besar.

6. Isolasi Library Berat

Punya library yang besar seperti D3.js, Chart.js, atau pustaka animasi berat? Jangan pernah mengimpornya di file layout.tsx atau page.tsx utama.

The Golden Rule: Impor library berat hanya di dalam Client Component yang spesifik yang membutuhkannya.

Contoh:

javascript
// components/ChartComponent.tsx (gunakan 'use client' di sini)
import { HeavyChartLibrary } from 'heavy-chart-library'; 
// ... logic

Dengan mengisolasi library ini, Webpack/Turbopack bisa melakukan code splitting yang efektif. Library berat itu hanya akan dimuat oleh browser ketika pengguna benar-benar mengunjungi halaman yang memerlukan grafik tersebut.

7. Menggunakan Dynamic Imports dengan Suspense

Untuk memastikan bahwa CC yang besar dimuat secara asinkron (malas), gunakan next/dynamic yang dikombinasikan dengan Suspense.

javascript
import { Suspense } from 'react';
import dynamic from 'next/dynamic';const DynamicMap = dynamic(() => import('@/components/MapComponent'), {
  loading: () => Memuat peta...,
  ssr: false, // Penting jika library tidak ramah SSR
});

Ini memastikan bahwa klien tidak perlu memuat MapComponent (yang mungkin berukuran ratusan KB) di awal, hanya memuatnya ketika komponen tersebut siap dirender.

---

Optimasi Build-Time dan Deployment

Performa tidak hanya ditentukan saat runtime, tapi juga saat proses build dan bagaimana aplikasi kita di-deploy.

8. Pemanfaatan next/image dan Prioritas LCP

Next.js sudah menyediakan komponen next/image yang memaksa kamu untuk optimasi gambar (format AVIF/WebP, resizing, caching). Tapi untuk performa gila, kita harus lebih agresif pada Largest Contentful Paint (LCP).

Atribut priority: Pastikan semua gambar yang terlihat di viewport* pertama (elemen LCP) menggunakan prop priority. Ini memberi tahu Next.js dan browser untuk memprioritaskan pemuatan gambar tersebut. Font Optimization: Gunakan next/font. Ini menghilangkan network request tambahan untuk font dan mengoptimalkan pemuatan font secara internal. Jangan biarkan flash of unstyled text* (FOUT) merusak pengalaman instan yang sudah kamu buat.

9. Pilih Runtime yang Tepat: Edge vs. Node.js

Next.js memungkinkan kita memilih runtime untuk API Routes atau Middleware.

Edge Runtime: Ini adalah lingkungan yang sangat cepat dan ringan, ideal untuk tugas yang membutuhkan latensi mendekati nol (misalnya, A/B testing, autentikasi cepat, geo-blocking*). Gunakan Edge untuk Middleware dan API kecil yang bersifat IO-bound.

  • Node.js Runtime (Default): Lebih cocok untuk tugas berat seperti koneksi database atau komputasi yang intensif.

Menggunakan Edge untuk Middleware memastikan bahwa proses routing dan logic awal berjalan sangat cepat sebelum permintaan mencapai origin server kamu.

---

Pengukuran Performa: Core Web Vitals adalah Segalanya

Performa gila tidak berarti apa-apa kalau tidak bisa diukur. Kita harus melacak metrik yang benar-benar dirasakan pengguna.

10. Fokus pada INP (Interaction to Next Paint)

Setelah Google mengumumkan INP menggantikan FID sebagai metrik utama interaktivitas, kita harus fokus memastikan interaksi klien sangat responsif.

Kurangi Event Handlers yang Berat: Jika kamu punya event handler yang melakukan komputasi kompleks, gunakan teknik debouncing atau throttling*. Batasi Penggunaan State Global yang Berlebihan: Setiap perubahan state yang luas di Client Components memicu re-render yang bisa menghambat main thread. Gunakan state lokal atau library state management yang dioptimasi (seperti Zustand atau Jotai) dan pastikan hanya komponen yang perlu* yang mendengar perubahan tersebut.

11. Manfaatkan Vercel Analytics (atau sejenisnya)

Lupakan hasil Lighthouse di PC kamu yang super cepat. Performa sejati diukur di dunia nyata (RUM - Real User Monitoring). Jika kamu deploy di Vercel, manfaatkan Analytics bawaan yang melacak Core Web Vitals dari pengguna asli. Jika tidak, gunakan tools seperti Google Analytics 4 (GA4) atau New Relic untuk melacak LCP, CLS, dan INP secara live.

Kesimpulan: Performa Gila Adalah Soal Arsitektur

Eksperimen Next.js App Router ini menunjukkan bahwa performa "gila" bukan lagi hasil dari optimasi micro kecil-kecilan, melainkan hasil dari keputusan arsitektur yang solid:

  1. Prioritaskan Server Components (SC).
  2. Lakukan Data Fetching Secara Paralel dengan Suspense.
  3. Jadikan Client Component (CC) sebagai lapisan interaksi yang tipis.

Dengan mengikuti tips ini, kamu tidak hanya akan mendapatkan skor Lighthouse yang sempurna, tetapi yang lebih penting, kamu akan menciptakan pengalaman pengguna yang terasa instan. Website kamu akan terasa seperti aplikasi native, dan itulah level "performa gila" yang harus kita kejar.