Frontend Interview: Bagaimana Cara Memilih Antara CSR, SSR, SSG, dan ISR?

Perintah dan skenario yang berlaku

Sebuah platform perdagangan Next.js 16 memiliki empat kelompok halaman:

• /guides/[slug]: 20.000 panduan publik, diedit setiap minggu, yang teks isinya harus dapat ditemukan secara andal oleh mesin pencari;
• /products/[id]: satu juta halaman produk publik yang deskripsi dan gambarnya boleh basi hingga lima menit, sedangkan harga dan inventaris harus dikonfirmasi langsung sebelum checkout;
• /search?q=: hasil yang bervariasi sesuai dengan kueri, filter, dan status katalog saat ini; tampilan pertama harus dapat dibagikan, tetapi setiap kombinasi kueri tidak perlu diindeks;
• /account/orders: halaman privat yang bervariasi berdasarkan pengguna yang masuk dan tidak boleh masuk ke cache bersama maupun indeks pencarian.

Tim menginginkan lebih sedikit rendering di origin tanpa mengorbankan keterlacakan pada halaman publik atau responsivitas pada halaman interaktif. Kandidat harus memilih strategi rendering utama untuk setiap kelompok rute, lalu menentukan area mana yang dapat menggabungkan strategi yang berbeda. Jawaban harus mendefinisikan batas kesegaran (freshness bound), pemicu pembatalan (invalidation trigger), output kegagalan, dan bukti produksi.

Panduan wawancara frontend publik tahun 2026 secara eksplisit mencantumkan pemilihan strategi rendering untuk halaman tertentu dan memutuskan antara ISR dan SSR. Bank soal frontend terpisah memiliki perbandingan khusus untuk CSR, SSR, SSG, dan ISR. Banyak hasil pencarian hanya berhenti pada tabel pro-dan-kontra empat baris. Sedikit yang menggabungkan pembatalan, verifikasi langsung pada field penting, CDN eksternal, dan semantik kegagalan. Pertanyaan ini menambahkan lapisan keputusan produksi tersebut.

Apa yang dievaluasi oleh pewawancara

Pertama, apakah kandidat menentukan kebutuhan halaman sebelum memilih akronim? Lokasi rendering bukanlah tujuannya. Kemampuan indeks publik, konten awal, kesegaran, personalisasi, lalu lintas, jumlah halaman, biaya interaksi, dan perilaku kegagalan adalah inputnya. “SSR bagus untuk SEO” tidak dapat menentukan halaman pesanan atau katalog satu juta halaman.

Kedua, apakah mereka memahami di mana masing-masing strategi menempatkan biaya?

Ketiga, dapatkah mereka mengidentifikasi model hibrida? Halaman produk dapat menggunakan ISR untuk deskripsi yang dapat diindeks, mengambil pilihan pengiriman saat ini di klien, dan memvalidasi ulang harga serta inventaris di layanan checkout. Memilih ISR tidak membuat setiap field aman untuk disajikan secara basi. Memilih SSR tidak menghilangkan JavaScript klien atau hidrasi.

Keempat, dapatkah mereka mengubah pilihan tersebut menjadi kontrak yang dapat diuji? Jawaban yang kuat menyatakan seberapa basi konten yang diizinkan, siapa yang membatalkannya, apa yang ditampilkan saat pembuatan ulang gagal, apakah kunci cache menyertakan pengguna atau wilayah, dan seberapa banyak JavaScript yang diunduh browser sebenarnya. Ini memberikan metrik build, runtime, cache, dan kebenaran bisnis.

Pertanyaan untuk diklarifikasi sebelum menjawab

• Apakah halaman tersebut publik dan dimaksudkan untuk pengindeksan? Teks isi publik, judul, canonical, dan status sebaiknya

ada dalam respons awal. Pesanan privat memerlukan autentikasi, tidak ada caching bersama, dan kebijakan noindex yang eksplisit.

• Seberapa cepat definisi "real time"? Deskripsi boleh berusia lima menit, sedangkan harga dan inventaris memengaruhi janji

pembayaran. Field-field tersebut tidak dapat mewarisi SLA cache yang sama.

• Dimensi apa yang mengubah konten? Lokal, wilayah, mata uang, autentikasi, dan grup eksperimen dapat mengubah

kunci cache. Dimensi yang hilang dapat menyajikan data yang salah atau privat; terlalu banyak dimensi merusak hit rate.

• Berapa jumlah halaman dan bagaimana distribusi pembaruannya? Mem-build satu juta URL pada setiap rilis tidaklah menarik. Jika

95% adalah halaman long-tail, lakukan prebuild pada jalur populer dan hasilkan sisanya pada akses pertama.

• Apakah event publikasi dapat diandalkan? Bisakah CMS atau katalog memancarkan ID entitas? Jika event bisa hilang, tambahkan masa kedaluwarsa

berbasis waktu, rekonsiliasi, atau pembatalan manual sebagai kompensasi.

• Bagaimana caching diterapkan? Satu proses, banyak kontainer, platform terkelola, dan CDN eksternal menyebarkan

pembatalan secara berbeda. Pembersihan cache server Next.js mungkin membiarkan salinan CDN lain tetap utuh.

• Saat terjadi kegagalan, apakah konten lama lebih aman daripada konten yang salah? Menyajikan panduan terakhir yang berhasil biasanya wajar.

Harga, inventaris, dan status pesanan harus dikonfirmasi oleh layanan yang berwenang.

• Apa saja kriteria keberhasilannya (success gates)? Tentukan kelengkapan konten yang dapat diindeks, TTFB/LCP/INP, hit rate, penundaan pembuatan ulang,

usia konten, QPS render origin, durasi build, tingkat kesalahan, dan tingkat konflik checkout.

Kerangka jawaban 30 detik

“Saya membagi rute berdasarkan sifat publik, variasi per permintaan, kesegaran, dan jumlah halaman. Panduan terutama menggunakan SSG dan dibatalkan berdasarkan path saat publikasi. Detail produk menggunakan ISR untuk isi halaman berbiaya rendah dan dapat diindeks, dengan event katalog ditambah fallback waktu lima menit; harga dan inventaris disegarkan di klien dan dikonfirmasi ulang oleh checkout. Pencarian adalah SSR per kueri, tanpa membagikan respons yang berisi dimensi pengguna. Pesanan privat menggunakan shell server terautentikasi dan pembaruan data CSR. Saya memverifikasi perilaku cache dalam build produksi dan memantau usia konten, hit rate, TTFB, LCP, ukuran JavaScript, kegagalan pembuatan ulang, dan konflik bisnis, tanpa memercayai satu skor Lighthouse saja.”

Pembahasan mendalam langkah demi langkah

Langkah 1: Gunakan satu matriks keputusan untuk memilih strategi utama per rute

Tempatkan setiap kelompok halaman melalui matriks yang sama daripada memulai dari API framework:

“SSG ditambah pembatalan publikasi” menggunakan pembuatan ulang bertahap saat runtime, meskipun model konten utamanya tetap berupa halaman statis yang telah di-prerender. Ini lebih murah daripada SSR untuk setiap permintaan ke 20.000 panduan dan lebih terarah daripada membangun ulang seluruh situs hanya untuk sebuah typo. Semua panduan dapat di-build pada awalnya; jika jumlahnya bertambah, lakukan prebuild pada jalur populer dan hasilkan sisanya pada permintaan pertama.

ISR cocok untuk detail produk karena isinya bersifat publik, dilihat berulang kali, dan diizinkan basi dalam waktu singkat. Pengaturan revalidasi lima menit bukanlah batas maksimum mutlak lima menit dalam setiap kondisi. Permintaan pertama setelah interval tersebut mungkin masih menerima HTML yang basi sementara pembuatan ulang di latar belakang dimulai. Halaman dengan lalu lintas rendah dapat terpicu lebih lambat, dan pembuatan ulang yang gagal akan memperpanjang masa pakai versi lama. Jika publikasi harus segera muncul, batalkan berdasarkan ID produk setelah penulisan berhasil dan pertahankan jendela waktu hanya sebagai kompensasi.

Ruang kueri pencarian terlalu besar untuk di-prebuild. SSR dapat menempatkan konten yang konsisten dengan kueri dan status nyata dalam respons pertama. Kunci cache harus menyertakan setiap parameter publik yang mengubah hasil. Respons yang melibatkan autentikasi atau harga yang dipersonalisasi harus bersifat privat atau tidak di-cache. Klien mengambil alih filter, paginasi, dan input setelah tampilan pertama.

Halaman pesanan tidak mendapatkan keuntungan dari HTML publik yang dapat diindeks. Server dapat membuat shell yang terautentikasi, sementara CSR memuat daftar dan status langsung dari API pengguna. Respons tersebut tidak boleh masuk ke cache bersama. CSR adalah pilihan rendering; autentikasi dan otorisasi tetap berada di server.

Langkah 2: Nyatakan ISR sebagai kontrak kesegaran dan pembatalan

Rute produk memerlukan dua kontrak:

Cacheable body: name, description, images, category
  Event invalidation: after product:{id} updates successfully
  Time fallback: 300 seconds
  Failure semantics: serve the last successful version and alert

Critical live fields: price, inventory, delivery eligibility
  Page display: refresh from the authority and show update time
  Checkout submission: recompute on the server and confirm changes

Panduan ISR Next.js menyatakan bahwa permintaan pertama setelah interval dapat menerima konten basi saat pembuatan ulang berjalan di latar belakang. Permintaan berikutnya menerima versi baru setelah berhasil. Jika pembuatan ulang melempar error, versi terakhir yang berhasil tetap di-cache dan permintaan lain akan mencoba lagi. Pantau usia konten; nilai konfigurasi bukanlah bukti bahwa SLA bisnis terpenuhi.

Di Next.js 16, revalidateTag(tag, "max") menggunakan stale-while-revalidate dan cocok untuk artikel, katalog, atau isi produk yang mengizinkan penundaan singkat. Ketika pengguna harus segera membaca hasil tulisannya sendiri, updateTag dalam Server Action menyediakan semantik read-your-writes. Keduanya bukanlah tombol “bersihkan cache” yang dapat dipertukarkan. Sumber event, kebasian yang diizinkan, dan lokasi pemanggilan menentukan operasi mana yang sesuai.

Gambarkan juga rantai propagasinya. Browser, CDN, cache rute Next.js, cache data, dan layanan upstream masing-masing dapat memiliki TTL. Panduan resmi CDN memperingatkan bahwa pembatalan path atau tag di Next.js tidak secara otomatis membersihkan salinan CDN yang di-cache secara terpisah. Jika CDN eksternal ditambahkan, bersihkan juga varian HTML dan data yang cocok, atau buat TTL-nya memenuhi kontrak kesegaran yang sama. Self-hosting multi-instance juga memerlukan cache bersama atau status tag yang disinkronkan agar satu instance tidak tetap basi.

Langkah 3: Tangani batasan SEO, interaksi, dan kegagalan secara terpisah

Google dapat mengeksekusi JavaScript dan mengindeks HTML yang dirender, tetapi proses rendering masuk ke dalam antrean, dan bot lain mungkin tidak mengeksekusi JavaScript. Panduan publik dan isi produk harus menempatkan teks yang terlihat, judul, canonical, data terstruktur, dan status yang tepat dalam HTML awal. Jangan mengembalikan shell 200 kosong dan membiarkan klien mengubah produk yang hilang menjadi “not found”. Server atau jalur pembuatan statis harus menghasilkan 404 yang sebenarnya.

Prerendering tidak secara otomatis membuat halaman menjadi cepat atau interaktif. Halaman SSR/SSG/ISR dengan terlalu banyak komponen klien tetap membayar biaya unduh, parsing, dan hidrasi JavaScript. CSR yang dipecah dengan baik dengan data terdekat dapat berkinerja baik pada navigasi yang sudah masuk. Ukur TTFB, LCP, INP, long task, JavaScript yang diunduh dan dieksekusi, serta waktu dari terlihat hingga interaktif.

Klasifikasikan perilaku kegagalan berdasarkan risiko data:

• Pembuatan ulang panduan atau isi produk gagal: sajikan versi terakhir yang berhasil, tampilkan waktu pembaruannya, dan beri peringatan tentang usia data.
• Upstream pencarian time out: tampilkan kegagalan yang dapat dicoba lagi atau cache singkat yang diizinkan secara eksplisit, bukan hasil kosong yang dibuat-buat.
• API harga atau inventaris gagal: jangan konfirmasi nilai lama; wajibkan percobaan ulang sebelum checkout.
• API pesanan gagal: pertahankan UI yang sudah dimuat dan tawarkan percobaan ulang; jangan pernah melakukan fallback lintas pengguna melalui cache bersama.
• Event pembatalan mengalami lag: rekonsiliasi versi entitas, temukan halaman yang tertinggal dari otoritas, dan terbitkan pembatalan kompensasi.

Langkah 4: Verifikasi dengan build produksi dan metrik bisnis

Mode pengembangan (development) tidak dapat membuktikan perilaku pembuatan statis dan ISR. Lakukan build untuk produksi dan jalankan server produksi sebelum memverifikasi keempat kelompok rute. Cakup setidaknya pengujian berikut:

1. Periksa output build dan konfirmasikan setiap rute bersifat statis, on-demand, atau dinamis sesuai rencana, bukan secara tidak sengaja

menjadi SSR karena satu pembacaan yang tidak di-cache.

1. Minta satu produk secara berulang untuk membuktikan hit cache; lalu perbarui produk tersebut dan catat waktu event, pembatalan, serta waktu HTML baru pertama kali muncul.
2. Gagalkan dependensi pembuatan ulang, buktikan isi terakhir yang berhasil tetap ada dan error dicatat, lalu pulihkan.
3. Minta lokal, wilayah, mata uang, dan status autentikasi yang berbeda untuk membuktikan kelengkapan kunci dan isolasi respons privat.
4. Ambil HTML awal secara langsung untuk memverifikasi isi, metadata, canonical, dan 404, lalu gunakan browser sungguhan untuk hidrasi.
5. Buat model CDN eksternal dan banyak instance; buktikan pembatalan mencapai setiap lapisan dan instance.
6. Dengan distribusi halaman yang sebenarnya, ukur waktu build, QPS render origin, hit rate, TTFB, LCP, INP, dan biaya JS.
7. Bandingkan nilai yang ditampilkan dengan otoritas checkout dan pantau konflik harga/inventaris, sehingga optimasi tidak mengubah

kebenaran transaksi.

Migrasikan rute demi rute. Amati lalu lintas dan kebenaran SSR saat ini, lalu pindahkan panduan berisiko rendah ke pengiriman statis. Jalankan ISR produk dalam mode bayangan (shadow mode) terlebih dahulu dengan mencatat apa yang akan dikembalikan oleh cache. Sajikan hanya setelah pembatalan terbukti andal. Pertahankan rollback per rute ke strategi sebelumnya, yang dipicu oleh batas kebenaran atau batas usia konten.

Contoh jawaban berkualitas tinggi

“Saya tidak akan memilih satu akronim untuk seluruh aplikasi. Panduan bersifat publik, seragam, dan jarang diedit, jadi saya membuat HTML statis dan membatalkan path setelah publikasi CMS berhasil. Teks awal tetap dapat diindeks dan hampir setiap permintaan menggunakan caching statis. Ada satu juta URL produk, jadi saya melakukan prebuild pada produk populer dan menghasilkan sisanya pada akses pertama. Isi produk menggunakan ISR, dibatalkan berdasarkan ID produk, dengan 300 detik hanya sebagai kompensasi jika ada event yang hilang. Permintaan pertama setelah kedaluwarsa mungkin masih menerima konten lama dan memulai pembuatan di latar belakang, jadi saya memantau selisih antara waktu pembaruan entitas dan waktu pembuatan cache daripada menjanjikan bahwa 300 berarti batas maksimum mutlak.”

“Harga, inventaris, dan kelayakan pengiriman tidak mewarisi jendela kebasian isi halaman. Browser menyegarkannya dari layanan otoritas, dan checkout menghitungnya kembali di server serta meminta konfirmasi jika harga berubah. Pencarian memiliki terlalu banyak kombinasi dan berubah per kueri, sehingga tampilan pertamanya adalah SSR dan klien mengelola filter selanjutnya. Respons yang berisi autentikasi atau ketentuan personalisasi tidak pernah masuk ke cache bersama. Pesanan menggunakan shell terautentikasi dan data CSR, dengan otorisasi pengguna di sisi server dan noindex.”

“Saya memverifikasi mode rute yang sebenarnya dengan build produksi, lalu menguji hit, pembatalan event, fallback 300 detik, kegagalan pembuatan ulang, dan pemulihan. CDN eksternal harus dibersihkan bersama Next.js, dan banyak instance memerlukan pembatalan yang disinkronkan. Saya memeriksa HTML publik awal untuk isi, canonical, dan status, lalu mengukur TTFB, LCP, INP, dan biaya JavaScript di browser nyata. Terakhir, saya membandingkan harga yang ditampilkan dan harga checkout. Performa yang lolos uji sementara kebenaran transaksi menurun tetap merupakan sebuah kegagalan.”

Kesalahan umum dan perbaikannya

• Memilih satu strategi untuk aplikasi → Halaman publik, pencarian, dan privat memiliki persyaratan yang berbeda →

Putuskan per rute dan terkadang per wilayah data.

• Memperlakukan SSR sebagai jaminan SEO → Metadata, status, canonical, dan tautan yang dapat dirayapi masih bisa salah →

Periksa HTML awal dan output crawler.

• Mengatakan CSR sama sekali tidak terlihat oleh pencarian → Google dapat merender JavaScript, dengan antrean dan kemampuan bot yang berbeda →

Lakukan prerender pada konten publik utama dan jelaskan batasannya secara akurat.

• Memperlakukan revalidate=300 sebagai SLA lima menit mutlak → Lalu lintas rendah, pekerjaan latar belakang, dan kegagalan memperpanjang kebasian →

Gabungkan pembatalan event, pemantauan usia, dan fallback waktu.

• Memberikan satu aturan kesegaran untuk seluruh halaman → Deskripsi menoleransi kebasian; harga dan inventaris tidak dapat dijanjikan

darinya → Pisahkan data berdasarkan risiko dan periksa kembali pada batasan transaksi.

• Hanya membersihkan Next.js → CDN eksternal atau instance lain mungkin masih menyimpan salinan → Petakan setiap cache dan uji penyebarannya.
• Mengasumsikan hasil prerender pasti cepat → JavaScript berlebih, hidrasi, dan upstream yang lambat tetap menurunkan performa → **Ukur jaringan,

main thread, Web Vitals, dan metrik server.**

• Menguji ISR hanya dalam mode development → Perilaku development tidak mewakili caching produksi → **Gunakan build

dan server produksi untuk pengujian hit, pembatalan, dan kegagalan.**

• Menggunakan halaman basi untuk menyembunyikan setiap kesalahan → Pencarian kosong, harga basi, atau pesanan lintas pengguna menyebabkan keputusan yang salah atau

kebocoran data → Definisikan stale-if-error berdasarkan risiko data.

Pertanyaan lanjutan

Bisakah ISR dipertahankan jika perubahan produk harus terlihat secara global dalam sepuluh detik?

Bisa, tetapi sepuluh detik harus menjadi SLO pembatalan end-to-end. Setelah transaksi katalog di-commit, pancarkan event berversi secara andal, sinkronkan pembatalan tag di semua instance Next.js, bersihkan CDN eksternal, dan periksa versi baru dari berbagai wilayah. Revalidasi waktu adalah kompensasi, bukan jaminan sepuluh detik. Jika rantai pembersihan tidak dapat memenuhi target, baca field tersebut secara dinamis atau gunakan jalur cache yang lebih pendek yang batasannya dapat dibuktikan.

Mengapa menghasilkan satu juta produk secara statis bisa menjadi masalah?

Hal itu mengikat waktu build, artefak, dan risiko rilis ke jumlah halaman, meskipun banyak halaman long-tail mungkin tidak pernah dibaca. Lakukan prebuild pada produk dengan lalu lintas tinggi dan hasilkan sisanya pada permintaan pertama. Batasi konkurensi pembuatan ulang, cegah event populer menyebabkan badai pembuatan ulang (regeneration storm), dan pertahankan perilaku 404 yang andal untuk produk yang hilang.

Bisakah respons SSR di-cache di CDN?

Dapat dibagikan atau tidaknya bergantung pada apakah respons tersebut identik di setiap dimensi kunci cache, bukan pada nama SSR-nya. Respons pencarian publik dengan kunci lengkap dan kebasian singkat yang diizinkan dapat di-cache secara hati-hati. Respons yang melibatkan cookie, izin pengguna, harga yang dipersonalisasi, atau keanggotaan eksperimen harus bersifat privat atau tidak di-cache. Uji Vary, konstruksi kunci, dan isolasi lintas pengguna setelah logout.

Apakah RSC, streaming SSR, dan PPR membatalkan model empat strategi ini?

Fitur-fitur tersebut memungkinkan pekerjaan statis dan dinamis digabungkan secara lebih mendalam dalam satu rute, tetapi tidak menghapus faktor input keputusan. Anda tetap perlu menyatakan di mana pekerjaan dijalankan, apa yang dimuat oleh HTML awal, berapa lama data di-cache, berapa banyak JavaScript yang diterima klien, dan bagaimana kegagalan wilayah dinamis ditangani. Dalam wawancara, tetapkan pengiriman dan kesegaran CSR/SSR/SSG/ISR, lalu jelaskan bagaimana RSC, streaming, atau partial prerendering menyempurnakan wilayah tertentu.

Bagaimana cara mencegah badai pembatalan (invalidation storm)?

Gabungkan event yang berulang berdasarkan entitas, tolak versi yang usang, tambahkan konkurensi pembuatan ulang yang dibatasi dan jitter, serta izinkan satu generator per kunci cache. Pantau kedalaman antrean, durasi pembuatan, kegagalan, dan usia konten. Jika antrean menumpuk, pertahankan pembacaan dinamis yang berwenang untuk harga dan inventaris sementara isi produk tetap menyajikan versi terakhir yang berhasil.