Next.js: Streaming rendering untuk mengurangi beban TTFB dan CPU

Satu hal untuk disebutkan..

Render streaming biasanya tidak akan menambahkan banyak peningkatan CPU karena jumlah pekerjaan yang harus dilakukan adalah sama. Tapi itu akan mengurangi waktu respon.

Merupakan ide bagus untuk menyediakan cara untuk menyesuaikan sistem rendering SSR. Tapi saya pikir untuk saat ini, kita akan tetap menggunakan metode renderToString() React secara default.

Ini adalah sesuatu yang bisa kita lakukan setelah 2.0.

Render streaming biasanya tidak akan menambahkan banyak peningkatan CPU karena jumlah pekerjaan yang harus dilakukan adalah sama.

_dari aickin/react-dom-stream _

Satu panggilan ke ReactDOM.renderToString dapat mendominasi CPU dan membuat permintaan lainnya kelaparan. Ini sangat merepotkan pada server yang melayani campuran halaman kecil dan besar.

Bukankah streaming secara bijaksana akan mengurangi alokasi memori dan penggunaan CPU untuk halaman besar dengan menjadi asinkron dan parsial?

Pikir ini sepanjang baris yang sama. Adakah yang sudah mencoba https://github.com/FormidableLabs/rapscallion ?

Ini menyediakan antarmuka streaming sehingga Anda dapat segera mulai mengirim konten ke klien.

Fitur lain dari dokumen:

• Rendering tidak sinkron dan non-blocking.
• Rapscallion kira-kira 50% lebih cepat dari renderToString.
• Ini menyediakan antarmuka streaming sehingga Anda dapat segera mulai mengirim konten ke klien.
• Ini menyediakan fitur templating, sehingga Anda dapat membungkus HTML komponen Anda di boilerplate tanpa melepaskan manfaat streaming.
• Ini menyediakan API caching komponen untuk lebih mempercepat rendering Anda.

Menambahkan contoh Rapscallion di #2279... dapat mengonfirmasi bahwa Rapscallion + Next itu gila. Render berbasis streaming/janji memang luar biasa, tetapi caching tingkat komponen adalah pengubah permainan bagi kami... :godmode:

Sekarang React 16 memiliki renderToNodeStream , itu akan menjadi keuntungan besar bagi next.js untuk menambahkan opsi untuk menggunakannya daripada renderToString . Bagaimana menurut Anda, @timneutkens?

Itu sudah ada dalam daftar hal-hal yang kami tambahkan 👍

Ada berita tentang ini?

https://github.com/zeit/next.js/pull/4074#issuecomment -466996162

Ada berita?

Next.js perlu mengekspos render kustom (dengan renderToString sebagai perender default) agar pengguna dapat menggunakan perender async khusus mereka.
Kurangnya fitur ini memaksa saya untuk menggunakan razzle untuk menggunakan perender async :( (DX-nya tidak jauh dari NextJS, tetapi saya harus menerimanya untuk melanjutkan).

Saya suka segala sesuatu tentang Next.js kecuali dua hal:

• Perender asinkron khusus.
• Konfigurasi babel khusus untuk server dan klien.

ada roadmap/rencana dukungan rendering streaming? jadi diharapkan memiliki ini di next.js .

Menunggu tim React yang mengimplementasikan React Fizz / rencana mereka untuk itu.

@timneutkens Apa masalahnya, PR untuk melacak di sini?

Dari posting blog Facebook, diterbitkan pada 8 Agustus 2019
https://reactjs.org/blog/2019/08/08/react-v16.9.0.html

Pembaruan pada Server Rendering
Kami telah memulai pekerjaan pada perender server baru yang mendukung Suspense, tetapi kami tidak mengharapkannya siap untuk rilis awal Mode Bersamaan. Rilis ini akan, bagaimanapun, memberikan solusi sementara yang memungkinkan perender server yang ada memancarkan HTML untuk fallback Suspense dengan segera, dan kemudian merender konten aslinya pada klien. Ini adalah solusi yang saat ini kami gunakan sendiri di Facebook hingga penyaji streaming siap.

Untuk siapa pun yang masih menunggu dukungan streaming server :)

Apakah ada pembaruan atau metode lain untuk mengimplementasikan renderToNodeStream di next.js ?

Apakah ada pembaruan?

<3

Perubahan apapun?

@StarpTech Saya telah melihat sedikit tentang ini (penasaran dengan fitur ini juga!) dan sepertinya tim reaksi sedang mengerjakan sesuatu yang disebut react-flight , yang mungkin akan menjadi dasar untuk solusi streaming yang kami tunggu di sini :)

reaksi-penerbangan:

Ini adalah paket eksperimental untuk menggunakan model streaming React kustom.

PR yang relevan yang menyoroti cara kerja bagian dalam, ditafsirkan oleh saya (bukan ahli dalam semua ini )
#17285 : Api dasar untuk penerbangan, server harus dapat mengalirkan semuanya sebagai string, tetapi tinggalkan placeholder untuk potongan yang diselesaikan secara asinkron di server. Sintaks yang tidak lengkap, namun menarik, untuk bagaimana reaksi akan mengetahui dari aliran tipe data apa yang sebenarnya diwakilinya ada di sini .

#17398 PR yang lebih baru, menambahkan api untuk Chunks jadi (jika Anda merasa beruntung) Anda dapat mencoba bagian itu sendiri. Tidak yakin bagaimana semuanya akan bersatu tetapi saya agak senang melihat semua pekerjaan ini selesai :)

_Ini mungkin sedikit di luar topik, tapi semoga menarik bagi orang-orang yang berlangganan masalah ini :)_

@pepf terima kasih atas infonya!

Hm. Terima kasih sobat semua, info menarik. Saya hanya berpikir mengapa NextJS harus menunggu React mendukung SSR untuk ketegangan dan hal-hal lain, dan tidak hanya menggunakan streamAsString sekarang?

@arunoda Saya pikir itu akan mengurangi konsumsi memori, sangat penting untuk fungsi lambda memori rendah atau Pekerja Cloudflare.

Ada berita tentang ini?

Ada berita?

Ada kabar guys? :P

Mengingat bahwa ketegangan reaksi terasa seperti tidak akan pernah keluar, apakah ada cara kita dapat meninjau kembali ini? Saya melihat waktu render awal 800-1000ms pada halaman konten rendah yang cukup umum (yang dirender dari fungsi tanpa server di vercel). Streaming HTML secara teori dapat meningkatkan titik kontak awal itu dan menghasilkan ux pemuatan pertama yang jauh lebih cepat.

Apakah itu batasan Vercel daripada NextJS? Apakah Vercel menjadi korban startup dingin yang sama seperti yang dilakukan Lambda? Tim saya menjalankan banyak situs konten berat dan pengaturan waktu kami di bawah 50 md untuk seluruh permintaan. Saya tidak berpikir streaming akan menjadi peluru perak di sini.

Saya tidak berharap itu menjadi peluru perak, tapi itu pasti akan menjadi peningkatan yang disambut baik.

50ms terdengar sangat kecil dan relatif terlalu tidak signifikan untuk dioptimalkan dibandingkan dengan waktu mulai dingin yang disebutkan, tetapi tidak saat merender di edge dengan sesuatu seperti Cloudflare Worker (ini sebanyak ping ke lokasi edge Cloudflare terdekat, atau setidaknya setengah ), Pekerja Cloudflare merespons dengan sangat cepat, biasanya di bawah 5 milidetik, saat mulai dingin. Sebaliknya, fungsi Lambda dan Lambda@Edge dapat mengambil alih satu detik untuk merespons dari awal yang dingin.
Saya tahu ini tidak membuat kasus yang lebih baik untuk Varcel (yang membangun cdn sendiri) mempekerjakan pengembang next.js untuk memprioritaskan ini.

Apakah ada dokumentasi atau repositori di mana orang telah berhasil menerapkan next.js ke pekerja cloudflare? Saya melakukan beberapa googling dan tidak dapat menemukan banyak tentang itu. Itu akan luar biasa.

Dikirim dari ponsel saya

Pada 5 Juli 2020, pukul 17:47, Wis [email protected] menulis:

50ms terdengar sangat rendah dan relatif tidak signifikan untuk dioptimalkan dibandingkan dengan waktu mulai dingin yang disebutkan, tetapi 50ms sangat banyak saat merender di edge dengan sesuatu seperti Cloudflare Worker (ini sama seperti ping ke lokasi tepi Cloudflare terdekat, atau setidaknya setengah), Pekerja Cloudflare merespons dengan sangat cepat, biasanya di bawah 5 milidetik, saat mulai dingin. Sebaliknya, fungsi Lambda dan Lambda@Edge dapat mengambil alih satu detik untuk merespons dari awal yang dingin.
Saya tahu ini tidak membuat kasus yang lebih baik untuk Varcel (yang membangun cdn sendiri) mempekerjakan pengembang next.js untuk memprioritaskan ini.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub, atau berhenti berlangganan.

50ms terdengar sangat kecil dan relatif terlalu tidak signifikan untuk dioptimalkan dibandingkan dengan waktu mulai dingin yang disebutkan

Untuk memperjelas, saya tidak mengeluh tentang waktu respons 50 ms saya - saya hanya menunjukkan bahwa SRR NextJS relatif berkinerja bahkan dari utara 3k permintaan / menit untuk halaman konten-berat, jadi masalah Switz mungkin ada di tempat lain.

Apakah ada dokumentasi atau repositori di mana orang telah berhasil menerapkan next.js ke pekerja cloudflare?

Saya juga akan tertarik dengan itu. Kami saat ini menjalankan di Fargate tetapi mendorong aplikasi kami ke tepi akan menjadi langkah logis berikutnya.

Saya telah membuat semua kemungkinan peningkatan dalam HTML saya dan waktu respons server sangat cepat! :(

@huggler Anda dapat menggabungkan contoh ini dengan cacheable-response . Anda dapat menggunakan Redis (atau cache dalam memori misalnya) untuk menyimpan html dalam cache. Ini meningkatkan waktu respons server.

Apakah ada dokumentasi atau repositori di mana orang telah berhasil menerapkan next.js ke pekerja cloudflare? Saya melakukan beberapa googling dan tidak dapat menemukan banyak tentang itu. Itu akan luar biasa.

@switz @tills13 apakah Anda memeriksa https://fab.dev/ ? Kami memainkannya pada awal 2020 dan itu dalam status pra-rilis, tetapi tampaknya mereka telah melangkah cukup jauh. Salah satu batasan yang mendukung mereka adalah Cloudflare itu sendiri, tetapi banyak hal mungkin telah berubah sekarang.

Sudah lama tidak menengok. Harus mengevaluasi kembali. Terakhir kali saya melihat, ada beberapa pengorbanan yang cukup serius.

Saya juga mengawasi https://github.com/flareact/flareact.

Ada pembaruan tentang ini?