Gesaan dan konteks
Halaman tersebut mengandungi navigasi, kandungan artikel, cadangan, komen, dan tindakan diperibadikan. Artikel harus dipaparkan dengan cepat; modul yang perlahan tidak boleh menyekat bait pertama atau menjejaskan keseluruhan halaman apabila satu perkhidmatan gagal. Reka bentuk penstriman SSR dengan Suspense dan terangkan cara pelayan menghantar shell, cara sempadan diselesaikan, cara kegagalan diturunkan taraf (degrade), dan cara klien pulih selepas skrip dimuatkan.
React mendokumentasikan bahawa penstriman boleh menghantar shell dan sandaran terlebih dahulu, kemudian menggantikannya apabila sempadan selesai. Temu duga ini menguji sama ada anda boleh menukar mekanisme tersebut kepada tingkah laku tamat masa, ralat, cache, dan pemantauan yang terkawal.
Perkara yang dinilai oleh penemu duga
Kupas tentang shell yang stabil berbanding sempadan tak segerak, penyahduplikasian permintaan, tamat masa sempadan, ralat pelayan, percubaan semula klien, varian cache, pembatalan, kebolehcapaian, dan Core Web Vitals. Nyatakan kandungan yang mesti segerak dan kandungan yang boleh ditangguhkan.
Soalan penjelasan untuk ditanya
- Adakah sasaran skrin pertama ialah TTFB, LCP, atau masa untuk interaksi, dan apakah belanjawan untuk setiap satu?
- Apakah tahap ketersediaan dan privasi yang terpakai untuk artikel, cadangan, komen, dan pemperibadian?
- Adakah halaman dicache pada CDN, dan apakah varian pengguna, wilayah, atau eksperimen yang wujud?
- Jika modul perlahan gagal, patutkah UI menunjukkan keadaan kosong, data lapuk, atau mencuba semula?
- Laluan teras manakah yang mesti berfungsi jika JavaScript klien gagal?
Jawapan 30 saat
"Hantar shell yang tidak bergantung pada data perlahan, kemudian bahagikan cadangan, komen, dan pemperibadian kepada sempadan Suspense dengan belanjawan yang eksplisit. Setiap sempadan mempunyai tamat masa pelayan, ralat yang boleh dicerap, dan sandaran yang boleh diterima, supaya kegagalan kekal setempat. Klien mengendalikan percubaan semula yang terhad dan interaksi selepas penghidratan. Cache hanya serpihan awam yang selamat, dan pantau TTFB, LCP, INP, ralat, serta kependaman sempadan."
Perbincangan mendalam langkah demi langkah
Langkah 1: Petakkan shell dan sempadan
Lengkapkan penghalaan, tajuk, struktur artikel, dan semantik utama secara segerak. Letakkan cadangan, komen, dan pemperibadian dalam sempadan yang berasingan. Sempadan harus mewakili kawasan yang boleh difahami pengguna, bukan sekadar himpunan sebarangan kebergantungan jauh.
shell: navigation + heading + article outline
boundary A: recommendations, budget 300 ms
boundary B: comments, budget 500 ms
boundary C: personalized actions, private and uncachedKekalkan pengepala, dimensi, dan semantik dalam setiap sandaran untuk mengelakkan anjakan susun atur (layout shift). Jangan memecahkan halaman terlalu banyak sehingga pengguna tidak dapat memahami apa yang sedang dimuatkan.
Langkah 2: Bina penstriman dan pembatalan
Gunakan API pemaparan pelayan penstriman rangka kerja supaya shell memasuki respons terlebih dahulu dan sempadan menyusul apabila data diselesaikan. Lampirkan tarikh akhir permintaan; selepas tamat masa, batalkan panggilan jauh dan keluarkan sandaran yang boleh diterima. Klien tidak sepatutnya menunggu tugasan pelayan yang telah pun dibatalkan.
Rekodkan peristiwa mula, selesai, tamat masa, dan ralat sempadan. Apabila klien terputus sambungan, batalkan pengambilan yang belum selesai supaya halaman yang ditinggalkan tidak menggunakan kapasiti pangkalan data atau cadangan.
Langkah 3: Kendalikan ralat pelayan dan klien
Ralat di dalam sempadan pelayan harus diselesaikan kepada sandaran sempadan tersebut sambil mengekalkan shell dan elemen setara yang telah selesai. Lampirkan pengecam sempadan yang stabil dan ID jejak permintaan untuk pengendali, manakala salinan yang dihadapi pengguna hanya menyatakan bahawa bahagian tersebut tidak tersedia buat sementara waktu.
Selepas kod klien dimuatkan, benarkan percubaan semula terhad berasaskan backoff untuk sempadan yang layak. Percubaan semula memerlukan had percubaan, syarat kedaksaan (idempotency), dan pembatalan. Jika skrip klien gagal, teks artikel, pautan, dan borang teras harus kekal boleh digunakan.
Langkah 4: Tentukan sempadan cache
Cache kandungan artikel awam dan modul bukan pengguna dengan kunci untuk laluan, bahasa, wilayah, dan versi kandungan. Sempadan yang diperibadikan tidak boleh memasuki cache HTML awam; eksperimen mesti eksplisit dalam kunci atau diasingkan pada edge.
Hit cache tidak boleh menyembunyikan data sumber yang lapuk. Rekodkan masa penjanaan, tamat tempoh, dan versi untuk setiap serpihan, serta gunakan dasar kesegaran yang konsisten. Berhati-hati semasa mencache strim bercantum akhir; serpihan yang selamat biasanya merupakan sempadan yang lebih baik.
Langkah 5: Kekalkan kebolehcapaian dan kestabilan susun atur
Kekalkan tajuk semantik, tanda tempat (landmarks), dan kekangan dimensi yang sama dalam sandaran dan kandungan akhir. Penggantian tidak boleh mengalihkan fokus papan kekunci ke nod yang tidak kelihatan. Kawasan dinamik memerlukan pengumuman status yang sesuai tanpa membaca keseluruhan halaman berulang kali.
Rizabkan dimensi imej dan media serta pastikan geometri rangka (skeleton) stabil; pantau CLS. Kekalkan kandungan utama artikel di dalam sempadan awal yang boleh dilihat, dan jangan letakkan elemen LCP di belakang permintaan ekor panjang (long-tail) yang tidak terkawal.
Langkah 6: Tambah pintu pelepasan dan kebolehcerapan
Ujian pra-pelepasan merangkumi kebergantungan perlahan, respons 500, pemutusan sambungan, kegagalan skrip klien, pencemaran cache, dan pembatalan. Dalam pengeluaran, ukur TTFB, LCP, INP, p50/p95 sempadan, kadar tamat masa, kadar sandaran, dan kejayaan percubaan semula mengikut laluan, sempadan, dan kebergantungan.
Semasa ujian kenari (canary), perhatikan shell dan sempadan kritikal sebelum membuka pemperibadian berisiko tinggi. Jika ralat atau kependaman ekor melepasi ambang, undurkan komposisi sempadan atau sandaran statik dan bukannya meluaskan trafik.
Contoh jawapan yang mantap
Saya akan mentakrifkan belanjawan skrin pertama dan tahap ketersediaan, kemudian membahagikan shell artikel, cadangan, komen, dan pemperibadian kepada sempadan Suspense yang bebas. Setiap sempadan menerima tamat masa, sandaran, laluan pembatalan, dan ID jejak; kegagalan kekal setempat. Serpihan awam menggunakan dimensi cache yang selamat, manakala pemperibadian tidak pernah memasuki cache kongsi. Saya akan menguji pemutusan sambungan dan kegagalan skrip, serta memantau LCP, INP, CLS, p95 sempadan, dan kadar sandaran.
Kesilapan biasa
- Membungkus keseluruhan halaman dalam satu sempadan → kebergantungan paling perlahan menyekat segala-galanya → bahagikan mengikut kawasan yang boleh difahami pengguna.
- Tidak memberikan dimensi tetap pada sandaran → penggantian menghasilkan CLS → peruntukkan ruang dan kekalkan semantik.
- Meletakkan HTML diperibadikan dalam cache awam → data pengguna boleh bocor → asingkan serpihan peribadi dan sertakan dimensi kunci yang selamat.
- Mencuba semula selama-lamanya selepas tamat masa pelayan → tekanan kebergantungan diperbesarkan → gunakan belanjawan, backoff, had, dan pembatalan.
- Menguji kejayaan sahaja → pemutusan sambungan atau kegagalan skrip menjadikan halaman tidak boleh digunakan → uji ralat, pembatalan, dan penurunan taraf tanpa skrip.
Soalan susulan dan respons
Soalan susulan 1: Adakah lebih banyak sempadan sentiasa lebih baik?
Tidak. Sempadan harus dipetakan kepada kawasan pengguna dan domain kegagalan yang bebas. Sempadan yang terlalu terperinci menambah hingar sandaran, kos pemantauan, dan varian cache; sempadan yang kasar membesarkan domain sekatan.
Soalan susulan 2: Bagaimanakah anda mengelakkan satu ralat daripada menamatkan keseluruhan penstriman?
Kekalkan pemulihan di dalam laluan pelayan dan klien bagi sempadan tersebut, kekalkan shell yang telah dihantar, dan sediakan sandaran yang stabil untuk setiap sempadan. Uji kegagalan selepas sebahagian daripada respons telah dihantar.
Soalan susulan 3: Metrik manakah yang membuktikan reka bentuk ini berfungsi?
Jejak TTFB, LCP, INP, CLS, p95 sempadan, kadar tamat masa, kadar sandaran, dan kejayaan percubaan semula secara bersama. Masa tindak balas purata sahaja menyembunyikan kependaman ekor dan kegagalan setempat.
Soalan susulan 4: Bagaimanakah anda mengelakkan kebocoran cache eksperimen atau data pengguna?
Sertakan dimensi keselamatan pengguna, eksperimen, wilayah, bahasa, dan versi kandungan dalam kunci. Serpihan yang keselamatannya tidak dapat dibuktikan kekal di luar cache awam, dan ujian main semula rentas pengguna mengesahkan pengasingan tersebut.