Kenapa getServerSideProps Bikin Website Next.js Kamu Jadi Lambat dan Gimana Cara Ngatasinnya

Kenapa getServerSideProps Bikin Website Next.js Kamu Jadi Lambat dan Gimana Cara Ngatasinnya
Photo by Markus Spiske/Unsplash

Next.js itu keren, kita semua setuju. Framework ini memberikan fleksibilitas luar biasa, terutama dalam hal rendering data. Tapi, seperti semua teknologi canggih, Next.js punya beberapa jebakan manis yang sering menjebak developer. Salah satunya adalah penggunaan getServerSideProps (GSSP) yang berlebihan atau tidak tepat.

Mungkin kamu pernah mengalami ini: Awalnya website Next.js kamu lari kencang, responsif, TTFB (Time to First Byte) nya singkat. Tapi begitu kamu tambahkan banyak fungsi getServerSideProps, tiba-tiba website terasa berat, lambat, dan loadingnya jadi lama banget—seperti menunggu antrean di jam sibuk.

Kalau kamu merasakan ini, santai. Kamu tidak sendirian. Sebagai tim dari Javapixa Creative Studio yang sering menangani proyek Next.js skala besar dan kompleks, kami melihat masalah ini berulang kali. getServerSideProps adalah pedang bermata dua: kuat untuk data dinamis, tapi bisa jadi biang keladi yang menyebabkan performa website kamu terjun bebas.

Mari kita bongkar kenapa GSSP bikin website Next.js kamu jadi lambat dan bagaimana cara super efektif buat ngatasinnya.

---

Kenapa GSSP Jadi Biang Keladi Next.js yang Lambat?

Untuk memahami masalahnya, kita harus pahami dulu bagaimana GSSP bekerja, terutama jika dibandingkan dengan kembarannya, getStaticProps (GSSP).

Next.js terkenal dengan konsep Prerendering. Ada dua jenis: Static Site Generation (SSG) dan Server-Side Rendering (SSR).

1. SSR Menuntut Kesiapan Penuh pada Setiap Permintaan

Ketika kamu menggunakan getStaticProps, Next.js membuat halaman HTML saat build time (saat kamu menjalankan npm run build). Hasilnya adalah file HTML statis yang bisa disajikan oleh CDN (Content Delivery Network) dengan kecepatan kilat.

Sebaliknya, getServerSideProps (SSR) berjalan pada setiap permintaan (request) yang masuk ke server Next.js.

Bayangkan GSSP itu seperti memesan makanan fresh yang harus dimasak setiap kali ada pelanggan datang. Prosesnya begini:

  1. User Request: Pengguna mengakses URL.
  2. Server Wake Up: Server Next.js menerima permintaan.
  3. GSSP Execution: Server menjalankan fungsi getServerSideProps yang ada di halaman tersebut.
  4. External Fetching: GSSP menghubungi API eksternal, database, atau microservice lain.
  5. Waiting Game: Server Next.js wajib menunggu data itu selesai diambil. Kalau API kamu lambat 500ms, maka 500ms itu akan ditambahkan ke total waktu loading halaman.
  6. HTML Generation: Setelah data lengkap, server baru merender HTML dan mengirimkannya ke browser.

2. Isu Time to First Byte (TTFB)

TTFB adalah metrik krusial yang diukur dari saat pengguna meminta halaman hingga byte pertama respons diterima. Dalam kasus GSSP, seluruh proses fetching data, komputasi, dan rendering HTML terjadi sebelum byte pertama dikirim. Jika proses fetching ini memakan waktu yang lama, TTFB kamu akan melambung tinggi, dan inilah yang membuat pengguna merasa website itu lambat sekali—bahkan sebelum CSS atau JavaScript sempat dimuat.

Website yang memiliki TTFB buruk seringkali dinilai negatif oleh mesin pencari seperti Google, yang berdampak pada skor SEO kamu.

3. Server Overload

Jika website kamu mulai viral dan menerima 1000 requests per detik, 1000 permintaan itu akan memicu 1000 eksekusi GSSP, yang berarti 1000 koneksi ke database atau API eksternal. Server kamu (dan database kamu) bisa collapse atau setidaknya mengalami throttling (pembatasan kinerja).

---

Solusi Aplikatif: Cara Mengatasi Keterlambatan GSSP

Next.js sangat kuat, tetapi penggunaannya butuh strategi yang matang. Berikut adalah beberapa tips highly relevant dan up-to-date dari Javapixa Creative Studio untuk mengatasi masalah kinerja GSSP.

1. Audit dan Pindah ke Incremental Static Regeneration (ISR)

Ini adalah solusi utama dan terbaik di ekosistem Next.js. Jangan gunakan SSR jika kamu tidak benar-benar butuh data yang harus sepenuhnya real-time (misalnya, data dashboard terautentikasi).

Kapan GSSP bisa diganti ISR? Halaman seperti daftar produk, artikel berita, halaman detail produk yang datanya diperbarui beberapa kali sehari atau bahkan setiap jam. Data ini tidak harus di-fetch pada setiap permintaan.

Dengan ISR, kamu mengubah getServerSideProps menjadi getStaticProps dan menambahkan parameter revalidate:

javascript
export async function getStaticProps() {
  const res = await fetch('https://api.example.com/products');
  const products = await res.json();

Dampaknya: Halaman disajikan dari cache (instan) selama 60 detik. TTFB kamu langsung mendekati nol. Hanya permintaan pertama setelah 60 detik yang akan memicu proses fetching data di latar belakang (background). Ini adalah win-win solution untuk performa dan kesegaran data.

2. Implementasi HTTP Caching Headers

Jika kamu benar-benar tidak bisa lepas dari GSSP (misalnya karena perlu pengecekan cookie atau token autentikasi pada level server), kamu harus mengimplementasikan caching yang solid melalui HTTP Headers.

Gunakan header seperti Cache-Control di dalam respons GSSP kamu.

javascript
export async function getServerSideProps({ req, res }) {
  // Tambahkan Header Cache-Control
  res.setHeader(
    'Cache-Control',
    // Stale-While-Revalidate: Berikan versi lama dari cache (max-age),
    // tapi cek di latar belakang (stale-while-revalidate) untuk mendapatkan versi baru.
    // Jika tidak ada CDN, ini akan dicache di browser (private)
    'public, s-maxage=10, stale-while-revalidate=59'
  );const data = await fetchSlowData();
  
  // Catatan: Jika halaman ini untuk pengguna yang terautentikasi (dashboard), 
  // ganti 'public' menjadi 'private' agar hanya browser user tersebut yang mencache.

Header s-maxage=10 memberi tahu proxy atau CDN (jika kamu menggunakan Vercel, Cloudflare, atau sejenisnya) untuk menyajikan halaman yang di-cache selama 10 detik. Ini akan secara dramatis mengurangi beban server Next.js kamu.

3. Paralelkan Data Fetching Menggunakan Promise.all

Seringkali, satu halaman membutuhkan data dari beberapa endpoint API yang berbeda (misalnya, data user, data notifikasi, dan data daftar teman). Developer pemula sering melakukan ini secara berurutan:

javascript
// GSSP yang LAMBAT (Berurutan)
const userData = await fetchUser(); // Tunggu 300ms
const notifData = await fetchNotifications(); // Tunggu lagi 200ms
const friendData = await fetchFriends(); // Tunggu lagi 400ms
// Total Waktu Fetching: 900ms

Jika permintaan API itu independen satu sama lain, tidak ada alasan untuk menunggu. Gunakan Promise.all untuk mengeksekusi semua permintaan secara bersamaan (paralel):

javascript
// GSSP yang CEPAT (Paralel)
const [userData, notifData, friendData] = await Promise.all([
  fetchUser(), // 300ms
  fetchNotifications(), // 200ms
  fetchFriends(), // 400ms
]);
// Total Waktu Fetching: max(300, 200, 400) = 400ms (Peningkatan 2x!)

Mengoptimalkan kecepatan data fetching di dalam GSSP adalah kunci untuk menurunkan TTFB.

4. Minimalkan Data yang Di-fetch (Efisien Data Transfer)

Apakah halaman kamu benar-benar membutuhkan 50 field dari database untuk setiap item? Seringkali, developer secara ceroboh mengambil objek data yang sangat besar hanya untuk menampilkan 3 atau 4 properti di UI.

Jika kamu mengambil data dari database atau GraphQL, pastikan kamu hanya select field yang benar-benar dibutuhkan oleh halaman tersebut. Mengurangi ukuran payload data (data transfer size) akan mempercepat waktu respons API, yang secara langsung mempercepat eksekusi GSSP kamu.

5. Pindahkan Data Non-Esensial ke Client-Side Rendering (CSR)

Tidak semua data harus ada pada rendering awal. Data yang bisa dimuat setelah halaman utama selesai dirender bisa dipindahkan ke Client-Side Rendering (CSR), seringkali menggunakan hook seperti SWR atau React Query.

Contoh Kasus: Kamu punya halaman produk.

  • Apa yang harus di GSSP? Nama produk, harga, deskripsi (konten inti untuk SEO).
  • Apa yang bisa di CSR? Rekomendasi produk terkait, daftar review, data ketersediaan stok yang sangat fluktuatif (opsional), atau widget chat.

Dengan memisahkan data esensial dan non-esensial, kamu memastikan bahwa TTFB tetap rendah karena GSSP hanya mengurus data minimal, sementara data pelengkap akan dimuat secara asinkron di latar belakang setelah user melihat halaman.

6. Optimalkan Database dan Query

Ingat, GSSP hanyalah perantara. Seringkali, penyebab utama kelambatan GSSP bukan karena kode Next.js kamu, melainkan karena API atau database di belakangnya yang lambat.

Sebagai studio pengembang aplikasi profesional, Javapixa Creative Studio selalu menekankan bahwa performa backend adalah pondasi.

Langkah Optimasi Backend:

  • Indexing: Pastikan tabel database kamu memiliki index yang tepat pada kolom yang sering digunakan untuk pencarian (WHERE) atau pengurutan (ORDER BY).

N+1 Problem: Hindari melakukan N jumlah query database dalam satu permintaan GSSP (masalah N+1). Gunakan teknik join atau batching* untuk mendapatkan semua data yang dibutuhkan hanya dalam satu query.

  • Cek Jarak Geografis: Pastikan server Next.js kamu dan server API/Database berada dalam region geografis yang dekat (ideal: di cloud yang sama) untuk meminimalkan latensi jaringan.

---

Kapan getServerSideProps Benar-Benar Diperlukan? (The Balance)

Meskipun kritik kita pedas, GSSP tetaplah alat yang sangat berharga. Kamu harus menggunakannya ketika:

  1. Halaman Autentikasi/Dashboard: Ketika kamu perlu memeriksa token autentikasi atau cookie di server sebelum merender halaman rahasia.
  2. Data Sangat Real-Time: Untuk kasus di mana data harus benar-benar up-to-the-second dan tidak bisa ditoleransi adanya penundaan (misalnya, sistem lelang aktif atau bursa saham).
  3. A/B Testing pada Server: Jika kamu perlu menentukan varian konten yang akan ditampilkan berdasarkan permintaan pengguna sebelum JavaScript dimuat.

Intinya, jika datanya adalah public atau tidak membutuhkan otorisasi spesifik per permintaan, pilihlah SSG/ISR. Jika datanya private dan harus selalu terbaru, barulah GSSP menjadi pilihan yang tepat, namun wajib diiringi dengan strategi caching dan paralel fetching yang optimal.

Kesimpulan

getServerSideProps adalah fitur powerful di Next.js, tapi kekuatannya datang dengan tanggung jawab besar terhadap performa. Penggunaan yang ceroboh bisa merusak TTFB, menghancurkan skor Lighthouse, dan membuat pengguna frustrasi.

Jika kamu menghadapi tantangan performa yang serius, selalu mulai dengan pertanyaan: Bisakah ini di-cache? Jika jawabannya ya, pindah ke ISR. Jika harus GSSP, pastikan kamu memaralelkan fetching data dan menerapkan HTTP Caching Headers yang agresif.

Membangun aplikasi Next.js modern yang cepat dan scalable membutuhkan keahlian mendalam dalam arsitektur rendering. Di Javapixa Creative Studio, kami berfokus pada pembangunan solusi digital yang tidak hanya terlihat bagus, tetapi juga unggul dalam performa dan kecepatan, memastikan website atau aplikasi kamu siap menghadapi lonjakan traffic tanpa mengalami hiccup. Jangan biarkan GSSP memperlambat ambisi digitalmu. Mari optimalkan bersama.