Next.js SSR vs SSG vs ISR: Memahami Perbedaan & Kapan Menggunakannya (Panduan Developer)

Dalam dunia pengembangan web modern, kecepatan, performa, dan optimasi SEO adalah kunci. Bagi developer yang bekerja dengan React, Next.js telah menjadi framework pilihan karena kemampuannya dalam menghadirkan aplikasi web performa tinggi. Salah satu kekuatan terbesar Next.js terletak pada strategi rendering-nya yang fleksibel: Server-Side Rendering (SSR), Static Site Generation (SSG), dan Incremental Static Regeneration (ISR).

Banyak developer, terutama yang baru terjun ke Next.js, sering bingung kapan harus menggunakan strategi yang mana. Pemilihan strategi yang tepat bisa berdampak besar pada Time To First Byte (TTFB), First Contentful Paint (FCP), dan bahkan peringkat SEO Anda. Mari kita kupas tuntas perbedaan mendasar dari ketiga strategi ini, bagaimana cara kerjanya, kelebihan dan kekurangannya, serta kapan waktu terbaik untuk menggunakannya.

Next.js dan Strategi Rendering

Sebelum kita menyelam lebih dalam, mari kita pahami mengapa strategi rendering ini begitu penting. Secara tradisional, aplikasi web React bersifat Client-Side Rendered (CSR), di mana browser mengunduh bundel JavaScript, lalu menjalankan kode untuk merender UI. Ini bisa menghasilkan waktu muat awal yang lambat (karena browser harus mengunduh dan mengeksekusi JS terlebih dahulu) dan tantangan SEO (karena crawler search engine mungkin kesulitan mengindeks konten tanpa JS).

Next.js hadir untuk mengatasi masalah ini dengan menyediakan opsi pre-rendering. Artinya, HTML untuk halaman tertentu bisa dihasilkan sebelum dikirim ke browser. Ada dua bentuk utama pre-rendering: Server-Side Rendering (SSR) dan Static Site Generation (SSG). ISR adalah evolusi dari SSG yang menawarkan fleksibilitas lebih.

Apa itu Rendering Strategy?

Rendering strategy mengacu pada cara dan waktu sebuah halaman web dibangun menjadi HTML yang dapat dikonsumsi oleh browser. Dalam Next.js, ini bukan hanya tentang menampilkan data, tetapi juga tentang bagaimana data tersebut diambil dan diintegrasikan ke dalam HTML, yang pada akhirnya memengaruhi performa, skalabilitas, dan pengalaman pengguna.

Server-Side Rendering (SSR): Dinamis di Setiap Permintaan

Server-Side Rendering (SSR) adalah strategi di mana setiap permintaan untuk sebuah halaman akan diproses oleh server, yang kemudian mengambil data yang diperlukan, merender halaman menjadi HTML lengkap, dan mengirimkannya ke browser. Ini berarti halaman yang Anda lihat selalu merupakan versi terbaru dengan data paling fresh.

Cara Kerja SSR di Next.js

Di Next.js, Anda mengimplementasikan SSR menggunakan fungsi asinkron getServerSideProps. Fungsi ini akan dijalankan di sisi server pada setiap permintaan yang masuk ke halaman tersebut. Data yang dikembalikan dari getServerSideProps akan diteruskan sebagai props ke komponen React halaman Anda.

Workflow SSR:

1. Pengguna membuat permintaan ke halaman Next.js.
2. Server Next.js menjalankan fungsi getServerSideProps.
3. getServerSideProps mengambil data dari API eksternal, database, atau sumber lainnya.
4. Server merender komponen React halaman menjadi HTML lengkap, menyertakan data yang baru diambil.
5. HTML lengkap dikirim ke browser pengguna.
6. Browser menerima HTML dan menampilkan halaman. JavaScript kemudian “menghidrasi” halaman untuk menjadikannya interaktif.

Kelebihan SSR

• Data Selalu Terbaru: Setiap kali halaman dimuat, data diambil ulang, memastikan pengguna selalu melihat informasi terkini. Sangat cocok untuk konten yang sering berubah.
• SEO Optimal: Search engine crawler mendapatkan HTML yang sudah lengkap dengan semua konten, sehingga sangat baik untuk SEO.
• Akses Awal ke Konten: Pengguna tidak perlu menunggu JavaScript diunduh dan dieksekusi untuk melihat konten awal.

Kekurangan SSR

• TTFB Lebih Lambat: Karena server harus memproses setiap permintaan, mengambil data, dan merender HTML, Time To First Byte (waktu hingga byte pertama diterima) bisa lebih lambat dibandingkan SSG.
• Beban Server Tinggi: Setiap permintaan membebani server. Semakin banyak lalu lintas, semakin tinggi beban kerja server.
• Tidak Dapat Menggunakan CDN untuk HTML: Karena HTML dihasilkan per permintaan, CDN tidak bisa menyimpan salinan HTML yang sudah jadi.

Kapan Menggunakan SSR?

SSR adalah pilihan ideal untuk halaman-halaman yang membutuhkan data real-time atau sangat dinamis, personalisasi tinggi, dan sering berubah. Contoh kasus penggunaan yang umum:

• Dasbor Pengguna: Menampilkan data spesifik pengguna yang selalu berubah (misalnya, notifikasi, statistik akun).
• Halaman Profil yang Dipersonalisasi: Konten yang bergantung pada sesi atau otentikasi pengguna.
• Halaman Berita atau Bursa Saham: Konten yang harus selalu terbaru setiap kali pengguna memuat halaman.
• Aplikasi E-commerce dengan Inventori yang Berubah Cepat: Menampilkan ketersediaan stok produk terkini.

Contoh Implementasi getServerSideProps

import Layout from '../components/Layout';

function Dashboard({ userPosts }) {
  return (
    
      <h1>Halo, Selamat Datang di Dashboard!</h1>
      <p>Jumlah Post Anda: {userPosts.length}</p>
      <ul>
        {userPosts.map(post => (
          <li key={post.id}>{post.title}</li>
        ))}
      </ul>
    
  );
}

export async function getServerSideProps(context) {
  // Contoh mengambil data dari API yang membutuhkan otentikasi
  const res = await fetch(`https://api.example.com/user/posts`, {
    headers: {
      Cookie: context.req.headers.cookie, // Meneruskan cookie untuk otentikasi
    },
  });
  const userPosts = await res.json();

  if (!userPosts) {
    return {
      notFound: true,
    };
  }

  return {
    props: {
      userPosts,
    },
  };
}

export default Dashboard;

Static Site Generation (SSG): Kecepatan Maksimal di Waktu Build

Static Site Generation (SSG) adalah strategi di mana halaman-halaman HTML sudah dibuat sepenuhnya pada waktu build aplikasi. Setelah dibangun, file-file HTML ini dapat disajikan langsung dari CDN (Content Delivery Network) tanpa perlu server untuk memproses permintaan lagi. Ini menghasilkan performa yang luar biasa cepat dan skalabilitas tinggi.

Cara Kerja SSG di Next.js

Di Next.js, SSG diimplementasikan menggunakan fungsi asinkron getStaticProps. Fungsi ini hanya akan dijalankan satu kali saat aplikasi di-build. Data yang diambil akan digunakan untuk merender halaman menjadi HTML statis. Jika Anda memiliki rute dinamis (misalnya /posts/[id].js), Anda juga memerlukan fungsi getStaticPaths untuk memberi tahu Next.js rute-rute mana yang perlu di-prerender.

Workflow SSG:

1. Pada waktu build, Next.js menjalankan fungsi getStaticProps untuk setiap halaman.
2. getStaticProps mengambil data yang diperlukan (misalnya, daftar posting blog dari CMS).
3. Next.js merender komponen React halaman menjadi file HTML statis lengkap, menyertakan data yang sudah diambil.
4. File-file HTML statis ini, beserta aset lainnya (JS, CSS, gambar), disimpan di direktori .next/ dan siap untuk di-deploy.
5. Ketika pengguna membuat permintaan ke halaman, CDN atau server web menyajikan langsung file HTML statis yang sudah jadi.
6. Browser menampilkan HTML. JavaScript kemudian “menghidrasi” halaman.

Kelebihan SSG

• Performa Luar Biasa Cepat: Halaman disajikan langsung dari CDN, menghasilkan TTFB yang sangat rendah dan performa yang optimal.
• Skalabilitas Tinggi: Server tidak perlu melakukan komputasi untuk setiap permintaan, sehingga mudah diskalakan dengan CDN.
• Keamanan: Karena tidak ada server-side logic yang dieksekusi pada setiap permintaan, area serangan potensial berkurang.
• Biaya Lebih Rendah: Mengurangi beban server berarti bisa menggunakan sumber daya yang lebih sedikit.
• SEO yang Sangat Baik: Sama seperti SSR, crawler search engine mendapatkan HTML yang sudah lengkap.

Kekurangan SSG

• Data Stale: Konten hanya di-refresh jika aplikasi di-build ulang. Jika data berubah setelah build, halaman akan menampilkan data lama sampai build baru dilakukan.
• Waktu Build yang Panjang: Untuk situs dengan ribuan halaman, proses build bisa memakan waktu sangat lama.
• Tidak Cocok untuk Konten Dinamis Tinggi: Sulit untuk melayani konten yang sangat personal atau sering berubah.

Kapan Menggunakan SSG?

SSG adalah pilihan terbaik untuk situs yang kontennya jarang berubah atau tidak membutuhkan data real-time, tetapi sangat mementingkan kecepatan dan SEO. Contoh kasus penggunaan yang umum:

• Blog atau Situs Berita Arsip: Postingan blog atau artikel lama yang tidak sering diperbarui.
• Halaman Pemasaran atau Landing Page: Konten promosi yang statis dan membutuhkan kecepatan tinggi.
• Dokumentasi atau Panduan: Informasi teknis yang stabil.
• Situs E-commerce dengan Produk yang Stabil: Halaman produk yang informasinya tidak berubah setiap menit.

Contoh Implementasi getStaticProps

import Layout from '../components/Layout';

function PostList({ posts }) {
  return (
    
      <h1>Daftar Postingan</h1>
      <ul>
        {posts.map(post => (
          <li key={post.id}>{post.title}</li>
        ))}
      </ul>
    
  );
}

export async function getStaticProps() {
  // Data akan diambil saat waktu build
  const res = await fetch('https://jsonplaceholder.typicode.com/posts?_limit=10');
  const posts = await res.json();

  return {
    props: {
      posts,
    },
  };
}

export default PostList;

Mengelola Dynamic Routes dengan getStaticPaths

Untuk halaman seperti pages/posts/[id].js, Anda perlu memberi tahu Next.js id mana saja yang perlu di-prerender menjadi HTML statis. Di sinilah fungsi getStaticPaths berperan.

// pages/posts/[id].js
import Layout from '../../components/Layout';

function Post({ post }) {
  if (!post) return <div>Loading...</div>; // Fallback for pages not pre-rendered

  return (
    
      <h1>{post.title}</h1>
      <p>{post.body}</p>
    
  );
}

export async function getStaticPaths() {
  // Ambil semua ID posting yang ingin di-prerender
  const res = await fetch('https://jsonplaceholder.typicode.com/posts?_limit=10');
  const posts = await res.json();

  const paths = posts.map(post => ({
    params: { id: post.id.toString() },
  }));

  return {
    paths,
    fallback: 'blocking', // 'blocking' atau true atau false
  };
}

export async function getStaticProps({ params }) {
  // Ambil data untuk setiap ID posting
  const res = await fetch(`https://jsonplaceholder.typicode.com/posts/${params.id}`);
  const post = await res.json();

  if (!post.id) { // Jika post tidak ditemukan (misalnya API error atau ID tidak valid)
    return {
      notFound: true,
    }
  }

  return {
    props: {
      post,
    },
  };
}

export default Post;

Properti fallback di getStaticPaths penting:

• fallback: false: Hanya jalur yang ditentukan di paths yang akan di-prerender. Jika ada permintaan ke jalur yang tidak ada, akan menghasilkan 404.
• fallback: true: Jika ada permintaan ke jalur yang tidak di-prerender, Next.js akan menyajikan versi “fallback” dari halaman (biasanya menampilkan loading state) lalu mencoba merendernya di sisi server. Setelah berhasil, halaman tersebut akan disimpan sebagai statis untuk permintaan selanjutnya.
• fallback: 'blocking': Mirip dengan true, tetapi server akan memblokir permintaan hingga halaman selesai di-render dan disimpan. Tidak ada loading state, pengguna akan menunggu hingga halaman lengkap.

Incremental Static Regeneration (ISR): Menggabungkan Kecepatan dan Kesegaran Data

Incremental Static Regeneration (ISR) adalah inovasi dari Next.js yang mencoba mengambil yang terbaik dari SSG dan SSR. ISR memungkinkan Anda memiliki kecepatan SSG (halaman disajikan dari CDN) tetapi dengan kemampuan untuk memperbarui konten tanpa harus melakukan full rebuild situs. Ini seperti memiliki situs statis yang bisa diperbarui secara berkala.

Cara Kerja ISR di Next.js

ISR diaktifkan dengan menambahkan properti revalidate ke objek yang dikembalikan oleh getStaticProps. Nilai revalidate adalah durasi dalam detik yang menandakan berapa lama halaman dapat disajikan dari cache sebelum Next.js mencoba untuk membangun ulang halaman tersebut di latar belakang.

Workflow ISR:

1. Pada waktu build, Next.js menjalankan getStaticProps dan menghasilkan file HTML statis, sama seperti SSG.
2. Ketika pengguna pertama kali mengakses halaman, CDN menyajikan HTML statis yang sudah di-cache.
3. Setelah durasi revalidate (misalnya 60 detik) berlalu, dan ada permintaan baru ke halaman tersebut:
   1. Next.js masih menyajikan halaman yang ada di cache (data lama) kepada pengguna.
   2. Di latar belakang, Next.js menjalankan ulang getStaticProps untuk mengambil data terbaru dan membangun ulang halaman.
   3. Setelah halaman berhasil dibangun ulang, versi baru akan menggantikan yang lama di cache, siap disajikan untuk permintaan berikutnya.
4. Jika ada kesalahan saat membangun ulang di latar belakang, Next.js akan tetap menyajikan versi lama yang ada di cache, sehingga tidak ada pengalaman buruk bagi pengguna.

Kelebihan ISR

• Performa Cepat: Seperti SSG, halaman disajikan langsung dari CDN, menghasilkan TTFB yang rendah.
• Kesegaran Data yang Lebih Baik: Konten dapat diperbarui secara berkala tanpa perlu full rebuild.
• Skalabilitas Tinggi: Masih sangat skalabel karena sebagian besar permintaan dilayani oleh CDN.
• Graceful Degradation: Jika terjadi kesalahan saat revalidation, versi lama akan tetap disajikan.
• Waktu Build Cepat: Tidak perlu rebuild seluruh aplikasi saat hanya beberapa halaman yang berubah.

Kekurangan ISR

• Data Mungkin Sedikit Stale: Ada periode di mana pengguna mungkin melihat data lama hingga halaman berhasil di-revalidate.
• Konfigurasi Lebih Kompleks: Membutuhkan pemahaman tentang cache dan waktu revalidation.
• Membutuhkan Server untuk Revalidation: Meskipun sebagian besar disajikan dari CDN, server Next.js tetap perlu berjalan untuk melakukan proses revalidation di latar belakang.

Kapan Menggunakan ISR?

ISR adalah solusi yang sangat kuat untuk situs yang membutuhkan kombinasi kecepatan SSG dengan kebutuhan untuk memperbarui konten secara berkala tanpa intervensi manual atau downtime. Contoh kasus penggunaan yang umum:

• Situs Berita atau Blog yang Aktif: Postingan yang diperbarui sesekali atau ada tambahan komentar baru.
• Halaman Produk E-commerce: Harga atau deskripsi produk yang bisa berubah dalam interval tertentu.
• Halaman Daftar Event: Event yang mungkin diperbarui statusnya atau detailnya.
• Dokumentasi dengan Pembaruan Rutin: Halaman panduan yang perlu direvisi secara berkala.

Contoh Implementasi getStaticProps dengan revalidate

// pages/products/[slug].js
import Layout from '../../components/Layout';

function Product({ product }) {
  if (!product) return <div>Loading...</div>; // Fallback state if revalidation is happening

  return (
    
      <h1>{product.name}</h1>
      <p>Harga: ${product.price}</p>
      <p>{product.description}</p>
      <p><small>Terakhir Diperbarui: {new Date(product.lastUpdated).toLocaleString()}</small></p>
    
  );
}

export async function getStaticPaths() {
  const res = await fetch('https://api.example.com/products/slugs'); // Ambil semua slug produk
  const slugs = await res.json();

  const paths = slugs.map(slug => ({
    params: { slug },
  }));

  return { paths, fallback: 'blocking' };
}

export async function getStaticProps({ params }) {
  const res = await fetch(`https://api.example.com/products/${params.slug}`);
  const product = await res.json();

  if (!product.id) {
    return {
      notFound: true,
    }
  }

  return {
    props: {
      product: { ...product, lastUpdated: new Date().toISOString() }, // Menambahkan timestamp
    },
    revalidate: 60, // Halaman ini akan di-revalidate paling cepat setiap 60 detik
  };
}

export default Product;

Perbandingan Langsung: SSR vs. SSG vs. ISR

Agar lebih jelas, mari kita bandingkan ketiga strategi rendering ini dari berbagai aspek kunci.

Tabel Perbandingan

Berikut adalah ringkasan perbandingan SSR, SSG, dan ISR:

• Waktu Rendering:
  • SSR: Saat permintaan diterima (per permintaan).
  • SSG: Saat waktu build (satu kali).
  • ISR: Saat waktu build dan kemudian di latar belakang setelah interval revalidate.
• Kesegaran Data:
  • SSR: Selalu terbaru (real-time).
  • SSG: Stale hingga rebuild.
  • ISR: Hampir terbaru (ada potensi jeda hingga revalidate).
• Performa (TTFB):
  • SSR: Lebih lambat (tergantung kecepatan API dan server).
  • SSG: Sangat cepat (dari CDN).
  • ISR: Sangat cepat (dari CDN, mirip SSG).
• Skalabilitas:
  • SSR: Memerlukan server yang kuat dan skalabel.
  • SSG: Sangat mudah diskalakan dengan CDN.
  • ISR: Sangat mudah diskalakan dengan CDN, namun memerlukan server untuk proses revalidation.
• Kebutuhan Server:
  • SSR: Selalu membutuhkan server aktif.
  • SSG: Hanya butuh server saat build (untuk deployment, tidak saat runtime).
  • ISR: Membutuhkan server aktif untuk proses revalidation, tetapi sebagian besar permintaan dilayani oleh CDN.
• Kasus Penggunaan Terbaik:
  • SSR: Dasbor pribadi, halaman profil, konten real-time, otentikasi.
  • SSG: Blog, dokumentasi, landing page, situs perusahaan statis.
  • ISR: Blog aktif, halaman produk e-commerce, situs berita, konten yang diperbarui sesekali.

Aspek Kunci Perbedaan

Inti dari perbedaan ini adalah kapan dan bagaimana data diambil dan diubah menjadi HTML. SSR melakukannya per permintaan, SSG melakukannya saat build, dan ISR adalah kombinasi keduanya yang memungkinkan pembaruan secara bertahap di latar belakang setelah build awal.

• SSR: Kompromi antara kesegaran data dan kecepatan. Anda mendapatkan data paling fresh, tetapi dengan sedikit penundaan karena setiap permintaan harus diproses server.
• SSG: Prioritas utama adalah kecepatan dan skalabilitas. Anda mengorbankan kesegaran data real-time demi performa maksimal.
• ISR: Mencoba menyeimbangkan keduanya. Anda mendapatkan kecepatan SSG, tetapi dengan mekanisme untuk memperbarui konten tanpa downtime atau full rebuild.

Pengalaman dan Pertimbangan Praktis

Memilih strategi rendering di Next.js seringkali bukan keputusan hitam-putih. Sebagai developer, kita perlu mempertimbangkan banyak faktor.

Memilih Strategi yang Tepat

Dalam praktik, proses pemilihan strategi biasanya didasarkan pada karakteristik utama dari sebuah halaman:

1. Apakah data halaman ini sering berubah? Jika ya, SSR atau ISR mungkin lebih cocok. Jika tidak, SSG adalah juara.
2. Seberapa penting kesegaran data secara real-time? Untuk harga saham atau notifikasi pribadi, SSR mutlak. Untuk artikel blog yang diperbarui seminggu sekali, ISR sudah lebih dari cukup.
3. Seberapa besar performa awal (TTFB) menjadi prioritas? Untuk landing page yang ingin menghasilkan konversi tinggi, SSG atau ISR dengan TTFB super rendah adalah pilihan utama.
4. Apakah ada banyak halaman dinamis? Untuk ratusan ribu halaman produk, SSG + fallback: blocking atau ISR adalah solusi yang lebih baik daripada SSR yang akan membebani server secara masif.

Saya sering melihat developer secara otomatis memilih SSR untuk semua halaman “dinamis”. Padahal, banyak kasus yang bisa dioptimalkan dengan ISR, yang menawarkan performa lebih baik dari sisi client dan skalabilitas lebih tinggi.

Dampak pada Performa dan SEO

• Performa: SSG dan ISR akan memberikan performa frontend yang superior dalam hal loading speed (FCP, LCP) karena HTML disajikan dari CDN. SSR masih sangat baik untuk SEO, tetapi pengalaman pengguna awal mungkin terasa sedikit lebih lambat karena server harus bekerja keras untuk setiap permintaan.
• SEO: Ketiga strategi ini sama-sama bagus untuk SEO karena semuanya menghasilkan HTML yang sudah di-prerender. Google crawler dan crawler lainnya bisa dengan mudah mengindeks konten Anda. Namun, kecepatan halaman (Core Web Vitals) juga merupakan faktor peringkat, jadi SSG/ISR seringkali memiliki keunggulan kecil di sini.

Pendekatan Hybrid: Memaksimalkan Potensi Next.js

Salah satu hal terbaik tentang Next.js adalah Anda tidak perlu terpaku pada satu strategi. Anda bisa menggunakan SSR untuk dasbor pengguna, SSG untuk halaman blog statis, dan ISR untuk halaman produk. Kemampuan untuk mencampur dan mencocokkan strategi ini di tingkat halaman memberikan fleksibilitas luar biasa untuk membangun aplikasi yang sangat optimal.

Dalam proyek skala besar, pendekatan hybrid ini adalah kunci. Contohnya, halaman homepage mungkin menggunakan SSG untuk bagian-bagian yang stabil, tetapi memuat komponen SSR atau client-side fetching untuk bagian yang personalisasi. Pemahaman mendalam tentang kapan menggunakan yang mana akan meningkatkan performa aplikasi Anda secara signifikan dan mengurangi beban infrastruktur.

Masalah yang Sering Terjadi

Meskipun Next.js menawarkan fleksibilitas yang hebat, ada beberapa masalah umum yang sering dihadapi developer saat mengimplementasikan strategi rendering ini.

Data Stale pada SSG/ISR

• Gejala: Pengguna melihat data lama meskipun sudah ada pembaruan di database atau CMS.
• Penyebab:
  • Pada SSG, Anda lupa melakukan rebuild setelah data berubah.
  • Pada ISR, nilai revalidate terlalu tinggi, sehingga jeda waktu hingga halaman diperbarui terlalu lama.
  • Cache CDN atau browser yang agresif masih menyajikan versi lama.
• Solusi:
  • Untuk SSG, otomatiskan proses rebuild (misalnya, via webhook dari CMS setelah publish).
  • Untuk ISR, sesuaikan nilai revalidate sesuai kebutuhan kesegaran data (misal: 60 detik untuk berita, 3600 detik untuk artikel jarang berubah).
  • Pertimbangkan on-demand revalidation jika Anda perlu memperbarui halaman tertentu secara instan.

Beban Server Tinggi pada SSR

• Gejala: Server melambat atau crash saat trafik tinggi.
• Penyebab:
  • Terlalu banyak halaman yang menggunakan SSR padahal bisa menggunakan SSG atau ISR.
  • Fungsi getServerSideProps melakukan operasi yang berat atau memanggil API yang lambat.
• Solusi:
  • Audit halaman-halaman yang menggunakan SSR. Bisakah beberapa diganti dengan ISR atau SSG?
  • Optimalkan logika di getServerSideProps: pastikan panggilan API efisien, tambahkan cache jika memungkinkan.
  • Scale up atau scale out server Anda.

Invalidasi Cache yang Rumit

• Gejala: Setelah memperbarui konten, halaman di Next.js tidak menampilkan perubahan, bahkan setelah rebuild atau waktu revalidate berlalu.
• Penyebab:
  • Cache di tingkat CDN (jika ada).
  • Cache di tingkat browser.
  • Next.js masih menyajikan stale data karena proses revalidation belum selesai atau gagal.
• Solusi:
  • Pastikan header cache-control dikonfigurasi dengan benar.
  • Lakukan hard refresh browser atau hapus cache browser untuk pengujian.
  • Gunakan fitur on-demand revalidation (Next.js 12+) untuk memaksa pembaruan halaman secara spesifik.

Menggunakan Strategi yang Salah

• Gejala: Performa situs buruk, waktu muat lambat, atau biaya server membengkak.
• Penyebab: Kurangnya pemahaman tentang kapan dan mengapa harus menggunakan setiap strategi. Misalnya, menggunakan SSR untuk halaman blog yang tidak pernah berubah, atau SSG untuk dasbor real-time.
• Solusi:
  • Lakukan evaluasi ulang kebutuhan setiap halaman.
  • Prioritaskan SSG/ISR sebisa mungkin untuk performa dan skalabilitas, dan gunakan SSR hanya jika memang ada kebutuhan data real-time yang mutlak.
  • Lakukan pengujian performa secara teratur untuk mengidentifikasi bottleneck.

FAQ

Apa itu Hydration di Next.js?

Hydration adalah proses di mana JavaScript sisi klien (yang diunduh setelah HTML awal) mengambil alih HTML statis atau yang di-prerender dari server, melampirkan event listener, dan membuat halaman menjadi interaktif. Ini adalah langkah kunci untuk mengubah halaman yang awalnya statis menjadi aplikasi React yang berfungsi penuh.

Apakah saya bisa mencampur SSR, SSG, dan ISR dalam satu aplikasi?

Tentu saja, dan ini adalah salah satu kekuatan terbesar Next.js! Anda bisa menggunakan strategi yang berbeda untuk setiap halaman dalam aplikasi Anda, atau bahkan mencampur pendekatan (misalnya, menggunakan SSG untuk tata letak utama dan kemudian mengambil data dinamis di sisi klien untuk bagian tertentu).

Mana yang terbaik untuk SEO?

Ketiga strategi Next.js (SSR, SSG, ISR) sama-sama sangat baik untuk SEO karena menghasilkan HTML yang sudah di-prerender, yang mudah dibaca oleh search engine crawler. Namun, SSG dan ISR seringkali memiliki keunggulan kecil dalam metrik performa seperti TTFB dan LCP karena halaman disajikan langsung dari CDN, yang merupakan faktor peringkat SEO.

Bisakah revalidate di ISR diatur secara dinamis?

Nilai revalidate harus berupa angka statis (detik) yang ditentukan pada waktu build atau melalui parameter runtime (meskipun ini tidak disarankan untuk revalidate itu sendiri). Jika Anda membutuhkan pembaruan instan yang tidak tergantung pada waktu, Anda harus mempertimbangkan on-demand revalidation, yang memungkinkan Anda memicu pembaruan halaman tertentu melalui panggilan API setelah konten di-update di CMS.

Kesimpulan

Next.js menyediakan pilihan strategi rendering yang kuat dan fleksibel untuk memenuhi berbagai kebutuhan aplikasi web modern. Server-Side Rendering (SSR) memastikan data selalu segar, ideal untuk konten dinamis dan personalisasi tinggi. Static Site Generation (SSG) memberikan kecepatan dan skalabilitas tak tertandingi untuk konten yang jarang berubah. Sementara itu, Incremental Static Regeneration (ISR) adalah jembatan yang cerdas antara keduanya, menawarkan kecepatan SSG dengan kemampuan untuk memperbarui konten secara inkremental.

Sebagai developer, pemahaman mendalam tentang kapan dan mengapa menggunakan setiap strategi ini adalah aset yang sangat berharga. Jangan takut untuk bereksperimen dan mencampur strategi dalam satu aplikasi. Dengan memilih pendekatan yang tepat untuk setiap bagian aplikasi Anda, Anda bisa membangun situs web yang tidak hanya cepat dan skalabel, tetapi juga memberikan pengalaman pengguna yang luar biasa dan optimal untuk SEO. Jadi, mulailah mempertimbangkan kebutuhan kesegaran data dan performa pada setiap halaman di proyek Next.js Anda!

TAGS: Next.js, SSR, SSG, ISR, Server-Side Rendering, Static Site Generation, Incremental Static Regeneration, Data Fetching, Web Performance, SEO, Developer Tools, JavaScript, React, getStaticProps, getServerSideProps

---

Baca Juga

• Panduan Lengkap Belajar Coding untuk Pemula hingga Profesional