Temu Duga Frontend: Bagaimana Anda Memilih Antara CSR, SSR, SSG, dan ISR?

Prompt dan senario yang berkenaan

Satu platform e-dagang Next.js 16 mempunyai empat keluarga halaman:

• /guides/[slug]: 20,000 panduan awam, disunting setiap minggu, dengan teks kandungan yang mesti boleh dijumpai oleh enjin carian secara andal;
• /products/[id]: satu juta halaman produk awam dengan penerangan dan imej yang boleh lapuk sehingga lima minit, manakala harga dan inventori mesti disahkan secara langsung sebelum pembayaran;
• /search?q=: hasil yang berbeza mengikut pertanyaan carian, penapis, dan status katalog semasa; paparan pertama harus boleh dikongsi, tetapi setiap kombinasi pertanyaan tidak perlu diindeks;
• /account/orders: halaman peribadi yang berbeza mengikut pengguna yang telah log masuk dan tidak boleh dimasukkan ke dalam cache kongsi mahupun indeks carian.

Pasukan mahu mengurangkan beban rendering pelayan asal tanpa mengorbankan kebolehtemuan pada halaman awam atau kereaktifan pada halaman interaktif. Calon mesti memilih strategi rendering utama untuk setiap keluarga laluan, kemudian menyatakan bahagian mana yang boleh menggabungkan strategi berbeza. Jawapan mesti menentukan batas kesegaran data, pencetus pembatalan cache, output kegagalan, dan bukti pengeluaran.

Panduan temu duga frontend awam 2026 secara jelas menyenaraikan pemilihan strategi rendering untuk halaman tertentu dan penentuan antara ISR dan SSR. Satu bank soalan frontend berasingan mempunyai perbandingan khusus untuk CSR, SSR, SSG, dan ISR. Kebanyakan hasil carian hanya terhenti pada jadual kebaikan dan keburukan empat baris. Jarang sekali ada yang menggabungkan pembatalan cache, pengesahan langsung medan kritikal, CDN luaran, dan semantik kegagalan. Soalan ini menambah lapisan keputusan pengeluaran tersebut.

Perkara yang dinilai oleh penemu duga

Pertama, adakah calon menentukan keperluan halaman sebelum memilih akronim? Lokasi rendering bukanlah matlamat utama. Kebolehindeksan awam, kandungan awal, kesegaran data, pemperibadian, trafik, jumlah halaman, kos interaksi, dan tingkah laku kegagalan adalah inputnya. "SSR adalah bagus untuk SEO" tidak boleh digunakan untuk membuat keputusan bagi halaman pesanan atau katalog sejuta halaman.

Kedua, adakah mereka memahami di mana setiap strategi meletakkan kos?

Ketiga, bolehkah mereka mengenal pasti pendekatan hibrid? Halaman produk boleh menggunakan ISR untuk penerangan yang boleh diindeks, mengambil pilihan penghantaran semasa pada klien, dan mengesahkan semula harga serta inventori dalam perkhidmatan pembayaran (checkout). Memilih ISR tidak bermakna setiap medan selamat untuk disampaikan dalam keadaan lapuk. Memilih SSR pula tidak menghapuskan JavaScript klien atau proses penghidratan (hydration).

Keempat, bolehkah mereka menukar pilihan tersebut kepada kontrak yang boleh diuji? Jawapan yang kukuh menyatakan sejauh mana kandungan boleh menjadi lapuk, pihak yang membatalkan cache, perkara yang dipaparkan semasa kegagalan penjanaan semula, sama ada kunci cache menyertakan dimensi pengguna atau rantau, dan berapa banyak JavaScript yang dimuat turun oleh penyemak imbas sebenar. Ia menyediakan metrik binaan, masa jalanan, cache, dan ketepatan perniagaan.

Soalan untuk dijelaskan sebelum menjawab

• Adakah halaman tersebut untuk tatapan awam dan bertujuan untuk pengindeksan? Teks kandungan awam, tajuk, pautan kanonikal, dan status sebaik-baiknya perlu ada dalam respons awal. Pesanan peribadi memerlukan pengesahan identiti, tiada caching kongsi, dan dasar noindex yang eksplisit.
• Berapa pantas yang dimaksudkan dengan "masa nyata"? Penerangan produk mungkin boleh berusia lima minit, manakala harga dan inventori mempengaruhi janji pembayaran. Medan tersebut tidak boleh berkongsi SLA cache yang sama.
• Apakah dimensi yang mengubah kandungan? Lokal (locale), rantau, mata wang, status pengesahan identiti, dan kumpulan eksperimen boleh mengubah kunci cache. Dimensi yang tertinggal boleh menyajikan data yang salah atau data peribadi; dimensi yang terlalu banyak pula akan merosakkan kadar hit cache.
• Berapakah jumlah halaman dan taburan kemas kininya? Membina satu juta URL pada setiap pelepasan versi adalah tidak praktikal. Jika 95% daripadanya adalah halaman long-tail, binalah laluan popular terlebih dahulu dan jana selebihnya pada akses kali pertama.
• Adakah peristiwa penerbitan boleh diandalkan? Bolehkah CMS atau katalog mengeluarkan ID entiti? Jika peristiwa boleh hilang, tambahkan luput berasaskan masa, penyelarasan berkala, atau pembatalan manual sebagai pampasan.
• Bagaimanakah caching digunakan dalam penggunaan sistem? Satu proses, berbilang kontena, platform terurus, dan CDN luaran menyebarkan pembatalan cache secara berbeza. Membersihkan cache pelayan Next.js mungkin membiarkan salinan CDN lain kekal utuh.
• Sekiranya berlaku kegagalan, adakah kandungan lama lebih selamat daripada kandungan yang salah? Menyajikan panduan yang berjaya dihasilkan sebelum ini biasanya munasabah. Harga, inventori, dan status pesanan mesti disahkan oleh perkhidmatan berwibawa (authoritative service).
• Apakah kriteria kejayaan? Tentukan kelengkapan kandungan yang boleh diindeks, TTFB/LCP/INP, kadar hit cache, kelewatan penjanaan semula, usia kandungan, QPS rendering pelayan asal, tempoh binaan, kadar ralat, dan kadar konflik pembayaran.

Kerangka jawapan 30 saat

"Saya membahagikan laluan mengikut keterbukaan awam, variasi bagi setiap permintaan, kesegaran data, dan jumlah halaman. Panduan kebanyakannya menggunakan SSG dan dibatalkan mengikut laluan semasa penerbitan. Butiran produk menggunakan ISR untuk kandungan badan yang menjimatkan kos dan boleh diindeks, dengan peristiwa katalog ditambah sandaran masa lima minit; harga dan inventori dikemas kini dalam klien dan disahkan semula semasa pembayaran. Carian menggunakan SSR bagi setiap pertanyaan, tanpa berkongsi respons yang mengandungi dimensi pengguna. Pesanan peribadi menggunakan rangka pelayan yang disahkan dan kemas kini data CSR. Saya mengesahkan tingkah laku cache dalam binaan pengeluaran dan memantau usia kandungan, kadar hit, TTFB, LCP, saiz JavaScript, kegagalan penjanaan semula, dan konflik perniagaan, tanpa hanya bergantung pada satu skor Lighthouse semata-mata."

Penjelasan mendalam langkah demi langkah

Langkah 1: Gunakan satu matriks keputusan untuk memilih strategi utama bagi setiap laluan

Nilaikan setiap keluarga halaman melalui matriks yang sama daripada bermula dengan API rangka kerja:

"SSG ditambah pembatalan semasa penerbitan" menggunakan penjanaan semula berperingkat pada masa jalanan, walaupun model kandungan utamanya kekal sebagai halaman statik prabina. Ia lebih menjimatkan kos berbanding SSR untuk setiap permintaan kepada 20,000 panduan dan lebih bersasar berbanding membina semula keseluruhan tapak web hanya kerana pembetulan kesilapan ejaan (typo). Semua panduan boleh dibina pada peringkat awal; jika jumlahnya bertambah, bina awal laluan popular dan jana selebihnya pada permintaan pertama.

ISR sesuai untuk butiran produk kerana kandungannya adalah awam, kerap dilihat, dan dibenarkan untuk lapuk seketika. Tetapan pengesahan semula lima minit bukanlah had maksimum lima minit yang mutlak dalam semua keadaan. Permintaan pertama selepas tempoh tersebut mungkin masih menerima HTML lapuk sementara penjanaan semula latar belakang bermula. Halaman dengan trafik rendah mungkin mencetuskannya lebih lewat, dan kegagalan penjanaan semula akan melanjutkan jangka hayat versi lama. Jika penerbitan perlu dipaparkan serta-merta, batalkan mengikut ID produk selepas proses penulisan berjaya dan kekalkan tetingkap masa hanya sebagai pampasan.

Ruang pertanyaan carian terlalu besar untuk dibina lebih awal. SSR boleh meletakkan kandungan yang konsisten dengan pertanyaan dan status sebenar dalam respons pertama. Kunci cache mesti menyertakan setiap parameter awam yang mengubah hasil. Respons yang melibatkan pengesahan identiti atau harga diperibadikan mesti ditetapkan sebagai peribadi atau tidak dicache. Klien mengambil alih penapis, penomboran halaman (pagination), dan input selepas paparan pertama.

Halaman pesanan tidak mendapat sebarang faedah daripada HTML awam yang boleh diindeks. Pelayan boleh membina rangka yang disahkan, manakala CSR memuatkan senarai dan status langsung daripada API pengguna. Respons tersebut tidak boleh memasuki cache kongsi. CSR ialah pilihan rendering; pengesahan identiti dan kebenaran akses tetap perlu dilakukan pada pelayan.

Langkah 2: Nyatakan ISR sebagai kontrak kesegaran data dan pembatalan cache

Laluan 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 bahawa permintaan pertama selepas selang masa tersebut boleh menerima kandungan lapuk semasa penjanaan semula berjalan di latar belakang. Permintaan seterusnya akan menerima versi baharu selepas ia berjaya. Jika penjanaan semula gagal (throws an error), versi terakhir yang berjaya akan kekal dicache dan permintaan lain akan mencuba semula. Pantau usia kandungan; nilai konfigurasi bukanlah bukti bahawa SLA perniagaan dipenuhi.

Dalam Next.js 16, revalidateTag(tag, "max") menggunakan konsep stale-while-revalidate dan sesuai untuk artikel, katalog, atau kandungan produk yang membenarkan kelewatan singkat. Apabila pengguna mesti membaca hasil penulisan mereka sendiri secara serta-merta, updateTag dalam Server Action menyediakan semantik read-your-writes. Kedua-duanya bukan butang "kosongkan cache" yang boleh ditukar ganti sewenang-wenangnya. Sumber peristiwa, toleransi kelapukan yang dibenarkan, dan lokasi panggilan menentukan operasi mana yang sesuai.

Gambarkan juga rantaian penyebarannya. Penyemak imbas, CDN, cache laluan Next.js, cache data, dan perkhidmatan huluan masing-masing boleh mempunyai TTL. Panduan rasmi CDN memberi amaran bahawa pembatalan laluan atau tag dalam Next.js tidak membersihkan salinan CDN yang dicache secara berasingan secara automatik. Jika CDN luaran ditambah, bersihkan juga varian HTML dan data yang sepadan, atau pastikan TTL CDN tersebut memenuhi kontrak kesegaran yang sama. Pengehosan sendiri pelbagai instans (multi-instance self-hosting) juga memerlukan cache kongsi atau keadaan tag yang diselaraskan supaya satu instans tidak kekal lapuk.

Langkah 3: Kendalikan batasan SEO, interaksi, dan kegagalan secara berasingan

Google boleh melaksanakan JavaScript dan mengindeks HTML yang dirender, tetapi pemprosesan rendering memasuki giliran, dan bot lain mungkin tidak melaksanakan JavaScript. Panduan awam dan kandungan produk harus meletakkan teks yang boleh dilihat, tajuk, kanonikal, data berstruktur, dan status yang betul dalam HTML awal. Jangan kembalikan rangka 200 yang kosong dan membiarkan klien menukar produk yang hilang menjadi "tidak dijumpai". Laluan pelayan atau penjanaan statik harus menghasilkan 404 yang sebenar.

Prarendering tidak semestinya menjadikan halaman pantas atau interaktif secara automatik. Halaman SSR/SSG/ISR dengan terlalu banyak komponen klien masih menanggung kos muat turun, penghuraian, dan penghidratan JavaScript. CSR yang diasingkan dengan baik bersama data berhampiran boleh berprestasi tinggi pada navigasi pengguna yang telah log masuk. Ukur TTFB, LCP, INP, tugasan panjang (long tasks), JavaScript yang dimuat turun dan dilaksanakan, serta masa dari mula kelihatan hingga boleh berinteraksi.

Klasifikasikan tingkah laku kegagalan mengikut risiko data:

• Penjanaan semula panduan atau kandungan produk gagal: sajikan versi terakhir yang berjaya, paparkan masa kemas kininya, dan aktifkan amaran mengenai usia kandungan.
• Perkhidmatan huluan carian tamat masa: tunjukkan kegagalan yang boleh dicuba semula atau cache pendek yang dibenarkan secara eksplisit, bukan hasil kosong rekaan.
• API harga atau inventori gagal: jangan sahkan nilai lama; wajibkan percubaan semula sebelum pembayaran.
• API pesanan gagal: kekalkan UI yang telah dimuatkan dan sediakan pilihan cuba semula; jangan sesekali beralih kepada data pengguna lain melalui cache kongsi.
• Peristiwa pembatalan cache tertangguh: selaraskan versi entiti, cari halaman yang ketinggalan di belakang sumber autoriti, dan keluarkan pembatalan cache pampasan.

Langkah 4: Sahkan dengan binaan pengeluaran dan metrik perniagaan

Mod pembangunan (development mode) tidak dapat membuktikan tingkah laku penjanaan statik dan ISR. Bina untuk pengeluaran dan jalankan pelayan pengeluaran sebelum mengesahkan kesemua empat keluarga laluan. Pastikan sekurang-kurangnya ujian ini diliputi:

1. Periksa output binaan dan sahkan setiap laluan adalah statik, atas permintaan (on-demand), atau dinamik seperti yang diharapkan, bukannya secara tidak sengaja menjadi SSR disebabkan oleh satu bacaan yang tidak dicache.
2. Minta satu produk secara berulang untuk membuktikan hit cache; kemudian kemas kininya dan rekodkan masa bagi peristiwa, pembatalan cache, dan kemunculan HTML baharu yang pertama.
3. Gagalkan kebergantungan penjanaan semula, buktikan kandungan terakhir yang berjaya kekal dipaparkan dan ralat direkodkan, kemudian pulihkan perkhidmatan.
4. Buat permintaan dengan lokal, rantau, mata wang, dan status pengesahan yang berbeza untuk membuktikan kelengkapan kunci cache dan pengasingan respons peribadi.
5. Ambil HTML awal secara terus untuk mengesahkan kandungan, metadata, kanonikal, dan 404, kemudian gunakan penyemak imbas sebenar untuk penghidratan.
6. Buat model CDN luaran dan berbilang instans; buktikan pembatalan sampai ke setiap lapisan dan instans.
7. Dengan taburan halaman sebenar, ukur masa binaan, QPS rendering pelayan asal, kadar hit, TTFB, LCP, INP, dan kos JS.
8. Bandingkan nilai yang dipaparkan dengan autoriti pembayaran dan perhatikan konflik harga/inventori, supaya pengoptimuman tidak menjejaskan ketepatan transaksi.

Lakukan migrasi laluan demi laluan. Perhatikan trafik dan ketepatan SSR semasa, kemudian pindahkan panduan berisiko rendah kepada penghantaran statik. Jalankan ISR produk dalam mod bayangan (shadow mode) terlebih dahulu dengan merekodkan perkara yang akan dikembalikan oleh cache. Sajikannya hanya selepas pembatalan terbukti andal. Sediakan kaedah rollback ke strategi sebelumnya bagi setiap laluan, yang dicetuskan oleh isu ketepatan atau batas usia kandungan.

Contoh jawapan berkualiti tinggi

"Saya tidak akan memilih satu akronim sahaja untuk keseluruhan aplikasi. Panduan adalah bersifat awam, seragam, dan jarang disunting, jadi saya membina HTML statik dan membatalkan laluannya selepas penerbitan CMS berjaya. Teks awal kekal boleh diindeks dan hampir setiap permintaan menggunakan caching statik. Terdapat sejuta URL produk, jadi saya membina awal produk popular dan menjana selebihnya pada akses pertama. Kandungan produk menggunakan ISR, dibatalkan mengikut ID produk, dengan 300 saat hanya sebagai pampasan bagi peristiwa yang hilang. Permintaan pertama selepas tamat tempoh mungkin masih menerima kandungan lama dan memulakan penjanaan latar belakang, jadi saya memantau jurang antara masa kemas kini entiti dan masa penjanaan cache dan bukannya berjanji bahawa 300 saat bermakna had maksimum yang mutlak."

"Harga, inventori, dan kelayakan penghantaran tidak berkongsi tetingkap kelapukan kandungan produk. Penyemak imbas mengemas kininya daripada perkhidmatan autoriti, dan proses pembayaran mengira semula nilai tersebut pada pelayan serta meminta pengesahan jika harga telah berubah. Carian mempunyai terlalu banyak kombinasi dan berubah bagi setiap pertanyaan, jadi paparan pertamanya ialah SSR dan klien mengendalikan penapis seterusnya. Respons yang mengandungi pengesahan identiti atau syarat yang diperibadikan tidak akan memasuki cache kongsi. Pesanan menggunakan rangka yang disahkan dan data CSR, dengan kebenaran pengguna sebelah pelayan dan noindex."

"Saya mengesahkan mod laluan sebenar dengan binaan pengeluaran, kemudian menguji hit cache, pembatalan peristiwa, sandaran 300 saat, kegagalan penjanaan semula, dan pemulihan. CDN luaran mesti dibersihkan bersama Next.js, dan berbilang instans memerlukan pembatalan yang diselaraskan. Saya memeriksa HTML awam awal untuk teks kandungan, kanonikal, dan status, kemudian mengukur TTFB, LCP, INP, dan kos JavaScript dalam penyemak imbas sebenar. Akhir sekali, saya membandingkan harga yang dipaparkan dengan harga semasa pembayaran. Prestasi yang lulus tetapi ketepatan transaksi merosot tetap dianggap sebagai satu kegagalan."

Kesilapan lazim dan penambahbaikan

• Memilih satu strategi untuk keseluruhan aplikasi → Halaman awam, carian, dan peribadi mempunyai keperluan yang berbeza → Tentukan mengikut laluan dan kadangkala mengikut bahagian data.
• Menganggap SSR sebagai jaminan SEO → Metadata, status, kanonikal, dan pautan yang boleh dirayap masih boleh menjadi salah → Periksa HTML awal dan output perayap (crawler).
• Menyatakan CSR tidak boleh dilihat langsung oleh enjin carian → Google boleh merender JavaScript, tetapi dengan giliran pemprosesan dan keupayaan bot yang berbeza → Lakukan prarendering untuk kandungan awam utama dan terangkan kekangan ini dengan tepat.
• Menganggap revalidate=300 sebagai SLA lima minit yang mutlak → Trafik rendah, tugasan latar belakang, dan kegagalan boleh memanjangkan kelapukan → Gabungkan pembatalan berasaskan peristiwa, pemantauan usia, dan sandaran berasaskan masa.
• Memberikan satu peraturan kesegaran untuk keseluruhan halaman → Penerangan produk bertolak ansur dengan kelapukan; harga dan inventori tidak boleh dijanjikan daripadanya → Asingkan data mengikut tahap risiko dan semak semula pada sempadan transaksi.
• Hanya membersihkan cache Next.js → CDN luaran atau instans lain mungkin masih menyimpan salinan → Petakan setiap cache dan uji penyebarannya.
• Menganggap prarendering bermakna pantas → JavaScript yang berlebihan, penghidratan, dan perkhidmatan huluan yang perlahan masih menjejaskan prestasi → Ukur rangkaian, thread utama, Web Vitals, dan metrik pelayan.
• Menguji ISR hanya dalam mod pembangunan → Tingkah laku pembangunan tidak mewakili caching pengeluaran → Gunakan binaan dan pelayan pengeluaran untuk ujian hit, pembatalan, dan kegagalan.
• Menggunakan halaman lapuk untuk menyembunyikan setiap ralat → Carian kosong, harga lapuk, atau pesanan rentas pengguna menyebabkan keputusan salah atau kebocoran data → Tentukan stale-if-error berdasarkan tahap risiko data.

Soalan susulan

Bolehkah ISR dikekalkan jika perubahan produk mesti kelihatan secara global dalam masa sepuluh saat?

Boleh, tetapi sepuluh saat mesti dijadikan SLO pembatalan cache hujung-ke-hujung. Selepas transaksi katalog selesai (commit), keluarkan peristiwa berversi secara andal, selaraskan pembatalan tag pada semua instans Next.js, bersihkan CDN luaran, dan uji versi baharu dari pelbagai rantau. Pengesahan semula berasaskan masa hanyalah pampasan, bukan jaminan sepuluh saat. Jika rantaian pembersihan tidak dapat mencapai sasaran, baca medan tersebut secara dinamik atau gunakan laluan cache yang lebih pendek dengan batas masa yang boleh dibuktikan.

Mengapakah penjanaan statik untuk satu juta produk boleh menjadi masalah?

Ia mengikat masa binaan, artifak, dan risiko pelepasan kepada jumlah halaman, walaupun banyak halaman long-tail mungkin tidak akan pernah dibaca. Binalah produk berprofil tinggi (trafik tinggi) terlebih dahulu dan jana selebihnya pada permintaan pertama. Hadkan konkurensi penjanaan semula, elakkan peristiwa yang kerap daripada menyebabkan ledakan penjanaan semula (regeneration storm), dan kekalkan tingkah laku 404 yang andal untuk produk yang tidak wujud.

Bolehkah respons SSR dicache dalam CDN?

Kebolehkongsian bergantung pada sama ada respons tersebut adalah sama merentasi setiap dimensi kunci cache, bukan pada nama SSR. Respons carian awam dengan kunci cache yang lengkap dan kelapukan singkat yang dibenarkan boleh dicache dengan berhati-hati. Respons yang melibatkan kuki, kebenaran pengguna, harga diperibadikan, atau keahlian eksperimen mesti dijadikan peribadi atau tidak dicache. Uji Vary, pembinaan kunci cache, dan pengasingan rentas pengguna selepas log keluar.

Adakah RSC, streaming SSR, dan PPR membatalkan model empat pilihan ini?

Ia membolehkan kerja statik dan dinamik digabungkan secara lebih terperinci dalam satu laluan, tetapi tidak menghapuskan input keputusan asas. Anda masih perlu menyatakan di mana kerja dijalankan, perkara yang terkandung dalam HTML awal, berapa lama data dicache, berapa banyak JavaScript yang diterima oleh klien, dan bagaimana bahagian dinamik mengendalikan kegagalan. Dalam temu duga, tetapkan penghantaran dan kesegaran CSR/SSR/SSG/ISR terlebih dahulu, kemudian terangkan bagaimana RSC, penstriman, atau prarendering separa meningkatkan bahagian tertentu.

Bagaimanakah anda mengelakkan ledakan pembatalan cache (invalidation storm)?

Gabungkan peristiwa berulang mengikut entiti, tolak versi yang lapuk, tambahkan konkurensi penjanaan semula yang terhad serta jitter, dan benarkan hanya satu penjana bagi setiap kunci cache. Pantau kedalaman baris gilir, tempoh penjanaan, kegagalan, dan usia kandungan. Jika tunggakan meningkat, kekalkan bacaan dinamik berwibawa untuk harga dan inventori sementara kandungan produk terus menyajikan versi terakhir yang berjaya.