Kenapa Next.js Kamu Lelet Padahal Udah Pakai Vercel Trik Optimize Hydration Biar LCP Gak Merah

Kenapa Next.js Kamu Lelet Padahal Udah Pakai Vercel Trik Optimize Hydration Biar LCP Gak Merah
Photo by Konrad Hofmann/Unsplash

Dunia web development hari ini penuh dengan janji-janji kecepatan. Ketika kita bicara tentang performa tinggi, pasti nama Next.js dan Vercel selalu disebut-sebut. Next.js menawarkan Server-Side Rendering (SSR) atau Static Site Generation (SSG), sementara Vercel memberikan deployment super cepat di Edge Network mereka. Logikanya, kombinasi ini harusnya membuat website kita ngebut tanpa ampun, bukan?

Tapi, realitanya seringkali berbeda. Kamu mungkin sudah deploy di Vercel, skor First Contentful Paint (FCP) kamu hijau cemerlang, tapi kok Largest Contentful Paint (LCP) masih saja merah, atau yang lebih parah, interaksi awal terasa laggy? Kamu klik tombol, tapi dia diam sebentar sebelum merespon.

Jangan panik, kamu tidak sendirian. Masalahnya bukan terletak pada Vercel atau Next.js secara fundamental. Masalahnya seringkali ada di satu proses kritis yang sering diabaikan: Hydration.

Sebagai tim ahli di Javapixa Creative Studio yang sehari-hari menangani performa high-traffic applications, kami tahu betul bahwa hydration bottleneck adalah musuh utama LCP dan Total Blocking Time (TBT) kamu. Mari kita bongkar kenapa website Next.js kamu yang seharusnya fast malah jadi flat saat dibuka, dan trik apa yang bisa kamu lakukan untuk mengoptimalkannya.

---

Mitos Vercel dan Realita Performance

Banyak developer muda berpikir, "Kalau saya pakai Next.js dan Vercel, semua masalah performa otomatis hilang." Ini adalah mitos yang harus segera kita luruskan.

Vercel sangat superior dalam hal delivery speed dan caching. Mereka memastikan bundle HTML, CSS, dan aset kamu dikirim ke pengguna secepat mungkin, dari server terdekat. Inilah kenapa FCP kamu biasanya bagus (pengguna cepat melihat tampilan).

Namun, Vercel tidak bisa mengoptimalkan kode JavaScript yang kamu tulis. Setelah HTML statis mendarat di browser pengguna, browser harus mengunduh, mem-parsing, dan mengeksekusi bundle JavaScript kamu. Di sinilah proses hydration terjadi, dan ini adalah tugas berat yang harus dilakukan oleh Main Thread di browser pengguna. Jika proses ini terlalu lama, LCP kamu akan turun drastis, dan metrik TBT (yang mengukur seberapa lama browser terblokir) akan melonjak tinggi.

Mengenal LCP dan Kenapa Hydration Merusaknya

LCP adalah metrik Core Web Vitals yang mengukur waktu yang dibutuhkan untuk merender elemen visual terbesar yang terlihat oleh pengguna (viewport). LCP yang bagus harus di bawah 2,5 detik.

Dalam kasus aplikasi Next.js:

  1. Server side (SSR/SSG): Next.js merender tampilan awal (HTML). Ini cepat.
  2. Client side (Hydration): Browser menerima HTML dan mulai mengunduh JavaScript. Ketika JavaScript selesai diunduh dan dieksekusi, React mulai mengambil alih DOM, mencocokkan struktur virtual DOM dengan DOM yang sudah ada, dan melampirkan event listener.

Jika elemen LCP kamu (misalnya, hero image besar atau blok teks utama) berada di area yang membutuhkan interaktivitas tinggi atau dikelilingi oleh banyak komponen React, browser harus menunggu hydration selesai sebelum bisa menandai elemen LCP tersebut selesai dimuat sepenuhnya.

Intinya: Semakin besar dan kompleks bundle JavaScript kamu, semakin lama proses hydration, dan semakin lama Main Thread terblokir, yang secara langsung menyeret LCP kamu ke jurang kegelapan.

---

Trik Jitu Optimize Hydration Ala Javapixa Creative Studio

Lalu, bagaimana cara kita memastikan proses hydration ini secepat kilat? Jawabannya adalah dengan mengurangi beban kerja Main Thread dan memecah tugas menjadi bagian-bagian kecil.

1. Dinamic Imports: Senjata Utama Melawan Bundle Bloat

Ini adalah tips klasik, tapi masih menjadi penyelamat utama. Next.js menyediakan fitur next/dynamic yang memungkinkan kamu melakukan code splitting tingkat komponen. Jangan pernah memuat komponen yang tidak langsung terlihat atau tidak langsung dibutuhkan interaksinya pada load awal.

Contoh Kasus:

Bayangkan kamu memiliki CommentSection dan ChatWidget di bagian bawah halaman. Kedua komponen ini mungkin butuh 50kb JavaScript tambahan. Jika kamu memuatnya saat load awal, 50kb itu akan menambah waktu parsing dan hydration untuk seluruh halaman, termasuk komponen LCP di atas.

Solusi:

Gunakan dynamic dengan opsi ssr: false jika komponen tersebut sepenuhnya bersifat interaktif dan tidak perlu di-render di server (misalnya, peta interaktif, third-party chat widget).

javascript
import dynamic from 'next/dynamic';const CommentSection = dynamic(() => import('../components/CommentSection'), {
  loading: () => Loading Comments...,
  ssr: false, // Penting! Jika tidak butuh server-side rendering
});

Tips Ekstra: Gunakan dynamic dengan trigger seperti Intersection Observer atau idle callback untuk memuat komponen hanya ketika mereka mendekati viewport atau saat browser sedang santai. Ini disebut Lazy Hydration atau Selective Hydration (meskipun istilah ini lebih tepat untuk fitur React 18, kita bisa mengimplementasikan polanya di Next.js 13/14).

2. Memanfaatkan React Server Components (RSC) Hingga Maksimal

Sejak Next.js 13 dengan App Router, kita diperkenalkan pada React Server Components (RSC). Ini adalah game-changer untuk masalah hydration.

Filosofi Inti RSC: Kenapa komponen yang hanya bertugas mengambil data dan menampilkan UI statis harus di-hydrate di client?

Dengan RSC (komponen yang secara default berada di server), kita dapat:

Mengurangi Client Bundle Size: Kode JavaScript untuk komponen server tidak pernah dikirim ke browser*.

  • Mengurangi Hydration Scope: Hanya komponen yang ditandai dengan 'use client' yang perlu di-hydrate.

Terapkan Prinsip "Boundary of Interactivity":

Pastikan parent component kamu adalah Server Component. Bungkus hanya bagian terkecil yang memerlukan interaktivitas dengan 'use client'.

SALAH: Membuat seluruh PostDetailPage menjadi client component hanya karena ada satu tombol Like*. BENAR: Buat PostDetailPage sebagai Server Component. Lalu, buat komponen LikeButton terpisah dan tandai itu sebagai client component*.

Dengan cara ini, Next.js hanya akan melakukan hydration pada bundle kecil LikeButton, sementara 99% konten lain (artikel, header, sidebar statis) akan disajikan sebagai HTML murni tanpa biaya hydration.

3. Mengontrol Ukuran DOM dan Kompleksitas Komponen

Hydration juga bergantung pada seberapa besar dan kompleks pohon DOM yang harus dicocokkan oleh React. Semakin banyak elemen dan level nesting, semakin lama waktu yang dibutuhkan Main Thread.

A. Kurangi Prop Drilling dan Context yang Berlebihan:

Setiap kali React harus menghidrasi, ia memeriksa props dan context. Jika kamu memiliki global context yang besar dan kompleks yang diakses oleh ratusan komponen kecil, biaya hydration akan meningkat. Evaluasi ulang apakah state harus bersifat global atau bisa diisolasi.

B. Hati-hati dengan Third-Party Scripts:

Third-party scripts (Analytics, iklan, chat widgets) seringkali menjadi pembunuh performa karena memblokir Main Thread sebelum hydration selesai.

Gunakan komponen next/script dan atur strateginya:

strategy="beforeInteractive": Untuk script yang harus* dimuat sebelum hydration (sangat jarang).

  • strategy="afterInteractive": Default. Dimuat setelah hydration selesai.

strategy="lazyOnload": Paling aman. Dimuat saat browser sedang idle*.

Untuk script yang memuat iframe atau elemen berat lainnya (seperti Google Maps), gunakan lazyOnload dan manfaatkan fitur placeholder agar UI tidak kosong saat loading.

4. Optimalisasi Aset Kritis: Next/Image

Next.js memberikan solusi unggulan untuk gambar, yaitu next/image. Jangan abaikan fitur ini!

Gambar, terutama elemen LCP (gambar hero), adalah penyebab utama LCP yang buruk.

Pastikan:

  1. Gunakan priority={true}: Khusus untuk gambar yang berada di viewport pertama (elemen LCP). Ini memberi tahu Next.js untuk memuat gambar secepat mungkin dan mencegah blokir resource.
  2. Atur Ukuran (Width/Height): Selalu tentukan width dan height eksplisit agar browser tahu berapa ruang yang harus disiapkan. Ini mencegah Layout Shift (CLS) dan mempercepat render LCP.
  3. Format Modern: Pastikan gambar diubah menjadi format modern seperti WebP atau AVIF oleh Next.js Image Optimizer.

5. Strategi Debugging: Menemukan Si Pemblokir Utama

Kamu sudah mencoba semua trik di atas, tapi LCP masih merah? Saatnya masuk ke tahap debugging yang serius.

A. Gunakan Lighthouse dan Web Vitals Report

Fokus pada metrik Total Blocking Time (TBT). Jika TBT kamu di atas 300ms, kamu punya masalah hydration atau Main Thread yang parah.

Lighthouse akan menunjukkan "Reduce JavaScript execution time." Klik detailnya. Lihat Execution Timeline di DevTools untuk mengidentifikasi fungsi/komponen mana yang memakan waktu terlama saat parsing dan evaluation.

B. Next.js Bundle Analyzer

Seringkali, masalah hydration disebabkan oleh bundle size yang kelebihan berat karena dependensi yang tidak disengaja.

Gunakan @next/bundle-analyzer untuk memvisualisasikan bundle JavaScript kamu. Cari tahu:

Apakah ada library besar yang kamu impor secara penuh padahal hanya butuh fungsi kecil (misalnya, lodash*).

  • Apakah ada dependensi duplikat.

Apakah ada komponen client yang ternyata membawa banyak kode node_modules* bersamanya.

Jika kamu menemukan library besar, coba lakukan tree-shaking atau beralih ke library yang lebih ringan (misalnya, menggunakan utility functions bawaan daripada mengimpor seluruh library).

6. Isolasi Dependencies Klien yang Berat

Beberapa library pihak ketiga memang sangat berat (misalnya, beberapa date pickers yang kompleks, editor teks WYSIWYG, atau charting libraries).

Jika kamu terpaksa menggunakan library yang berat dan harus dijalankan di client (karena butuh interaksi):

Isolasi Total: Jangan tempatkan client component* berat ini di komponen yang lebih tinggi dalam pohon React. Conditional Load: Gunakan next/dynamic dengan trigger spesifik. Misalnya, hanya load editor WYSIWYG setelah pengguna mengklik tombol 'Edit' atau setelah sesi login terverifikasi. Jangan pernah memuatnya saat initial load* halaman statis.

---

Penutup: Kecepatan Adalah Reputasi

Di era digital yang bergerak sangat cepat, performa bukan lagi sekadar nice-to-have, melainkan kebutuhan fundamental. Kombinasi Next.js dan Vercel memang kuat, tetapi tanpa strategi hydration yang matang, kecepatan yang dijanjikan tidak akan pernah tercapai. LCP yang rendah dan TBT yang tinggi adalah sinyal bahwa Main Thread pengguna sedang berjuang keras.

Jika kamu merasa solusi teknis di atas terlalu rumit untuk diimplementasikan sendiri, atau kamu butuh audit performa menyeluruh untuk aplikasi production kamu, Javapixa Creative Studio siap membantu. Kami tidak hanya membangun aplikasi yang indah, tetapi juga memastikan setiap baris kode dioptimalkan untuk kecepatan maksimum.

Kami membantu bisnis mengubah aplikasi Next.js yang 'lelet' menjadi mesin performa yang gesit, memastikan user experience kamu tidak terhambat oleh hydration bottleneck yang menjengkelkan. Jangan biarkan LCP kamu merah. Hubungi tim Javapixa Creative Studio hari ini untuk mengamankan performa aplikasi Next.js kamu.