Poin-poin penting dalam memilih SSR, CSR, dan rendering streaming

Banyak tim mendiskusikan SSR, CSR, dan rendering streaming, dan hal pertama yang mereka tanyakan adalah performa.

Berapa lama waktu layar pertama, apakah LCP dapat ditekan, apakah SEO dapat membantu, apakah antarmuka dapat diparalelkan, dan apakah Streaming dapat dibuat kerangka lebih awal. Tentu saja hal ini penting, tetapi jika menyangkut proyek, hal pertama yang mengacaukan halaman sering kali adalah berapa kali data yang sama diambil, di lapisan mana data tersebut di-cache, dan siapa yang akan menutupnya setelah kegagalan.

Penilaian saya adalah: **Kunci dari strategi rendering front-end bukanlah siapa yang lebih mahir, SSR, CSR, atau rendering streaming, tetapi data halaman yang sama harus melalui beberapa kali pengambilan, beberapa kali hidrasi, dan beberapa rangkaian kegagalan rollback. Setelah halaman mengejar SEO, kecepatan interaksi, dan cache hits pada saat yang sama, hal pertama yang lepas kendali biasanya adalah konsistensi data, cakupan kesalahan, dan biaya pemecahan masalah. **

Yang benar-benar mengacaukan halaman biasanya bukan metode rendering itu sendiri.

Saya telah melihat banyak halaman, dan pada awalnya itu hanyalah halaman detail konten biasa:

• Klik pada halaman daftar untuk detailnya;
• Kami berharap mesin pencari dapat meng-crawl layar pertama, sehingga kami memerlukan SSR;
• Terdapat interaksi seperti koleksi, komentar, dan rekomendasi di halaman, sehingga klien harus terus membuat permintaan;
• Untuk membuat layar pertama lebih cepat, antarmuka dibagi menjadi data utama dan blok sekunder;
• Untuk meningkatkan hit rate, server menambahkan edge caching, dan klien menambahkan lapisan request caching.

Hingga saat ini, setiap keputusan dapat dibenarkan.

Masalahnya adalah setelah keputusan-keputusan ini disusun bersama-sama, sebenarnya ada setidaknya empat jalur untuk “data mencapai lokasi kejadian” di halaman:

1. Data yang diperoleh selama rendering pertama server;
2. Data diturunkan saat browser terhidrasi;
3. Setelah klien dipasang, klien mengirim ulang permintaan untuk mendapatkan data baru;
4. Data turunan yang diperbarui secara lokal setelah interaksi pengguna.

Jika tidak ada prioritas yang jelas di antara keempat jalur ini, halaman tersebut akan mulai mengalami beberapa masalah aneh yang familier:

• Apa yang Anda lihat di HTML adalah harga lama, dan akan berubah menjadi harga baru setelah hidrasi;
• Render layar pertama menunjukkan “Favorit”, tetapi setelah klien mengambil alih, berubah kembali menjadi “Bukan Favorit”;
• Blok yang direkomendasikan terlambat satu langkah, dan halaman yang diperbarui sebagian didorong kembali ke nilai lama;
• Saat server melaporkan kesalahan, server menampilkan serangkaian detail, dan setelah klien mencoba lagi, server menampilkan serangkaian detail lainnya.

Masalah-masalah ini disebabkan oleh fakta bahwa status halaman yang sama dibuat dan ditimpa beberapa kali, namun tidak ada yang menentukan siapa yang memiliki keputusan akhir.

SSR menyelesaikan visibilitas layar pertama, tetapi tidak secara otomatis menyelesaikan sumber kebenaran data.

Situasi yang umum adalah menganggap SSR sebagai “memuntahkan halaman yang benar terlebih dahulu”, tetapi kalimat ini hanya berlaku di bawah premis yang sangat sempit: **Data yang diperoleh oleh server adalah data akhir yang benar-benar harus dilihat pengguna kali ini. **

Kenyataannya, premis ini sering kali tidak benar.

Misalnya, informasi produk di layar beranda halaman detail ditampilkan oleh server, namun informasi berikut sering kali tidak ditampilkan:

• Apakah pengguna telah mengklik favorit;
• Kumpulan rekomendasi mana yang saat ini terkena dampak kelompok eksperimental;
• Inventarisasi yang relevan secara geografis;
• Harga atau hak terkait login;
• Pembaruan asinkron selesai tepat setelah halaman dipasang.

Saat ini, SSR hanya dapat menjamin bahwa “pertama-tama keluarkan satu versi untuk menampilkan hasilnya”, tetapi tidak dapat menjamin bahwa versi hasil ini akan menjadi kebenaran akhir dari keseluruhan halaman.

Setelah tim juga mengharuskan “server membuat HTML terlebih dahulu, dan klien mengambil alih lalu menambahkan personalisasi”, sistem secara alami akan dibagi menjadi dua rangkaian penilaian:

• Server menentukan tampilan halaman pertama kali;
• Klien menentukan seperti apa tampilan halaman pada akhirnya.

Jika kondisi akses, waktu caching, dan strategi toleransi kesalahan di kedua sisi tidak sepenuhnya konsisten, halaman tersebut pasti tidak konsisten.

Jadi yang seharusnya ditanyakan SSR adalah:

• Berapa lama data yang dikeluarkan oleh server dapat tetap segar kali ini;
• Bidang mana yang boleh ditutup setelah hidrasi;
• Bidang mana yang harus didasarkan pada hasil terbaru dari klien;
• Apakah kegagalan sisi server dan kegagalan sisi klien merupakan rangkaian semantik yang sama?

Tanpa mengklarifikasi masalah ini terlebih dahulu, SSR hanya akan mengirimkan versi jawaban tertentu kepada pengguna pada waktu yang lebih awal, dibandingkan menyelesaikan konsistensi pada tingkat yang lebih tinggi.

Masalah sebenarnya dengan CSR adalah mudahnya menulis semantik penyegaran secara longgar

CSR sering dikritik karena lambat, dan memang demikian adanya. Namun masalah saya yang lebih umum adalah proyek CSR cenderung menulis “tarik ulang data lagi” sebagai tindakan default yang tidak dibatasi.

Halaman ini diinisialisasi dan ditarik satu kali; Potong tabnya dan tarik sekali; Tarik kembali fokus jendela; Setelah operasi pengguna berhasil, tarik kembali dengan mudah; Pustaka permintaan secara otomatis mencoba lagi.

Kodenya terlihat alami, tetapi efek akhirnya mungkin:

• Status halaman ditimpa beberapa kali dalam waktu singkat;
• Permintaan lama yang dikembalikan kemudian akan menggantikan permintaan baru yang dikembalikan terlebih dahulu;
• Pembaruan optimis mulai berlaku dan ditunda karena pengambilan ulang penuh;
• Komponen lokal tertentu di-refresh secara terpisah, dan status tingkat halaman disusun kembali menjadi versi hasil yang lain.

Masalah seperti ini sangat umum terjadi dalam CSR, karena klien secara alami menganggap “menarik kembali data terbaru sekarang” sebagai tindakan berbiaya rendah. Namun selama halaman memiliki daftar, ringkasan, dan masukan interaktif, pengambilan ulang adalah tindakan menilai ulang status keseluruhan halaman.

Jika tidak ada aturan yang jelas, CSR pada akhirnya akan menjadi: tidak peduli siapa yang mendapatkan data terlebih dahulu, siapa yang berhak menentukan siapa yang pada akhirnya berhasil mendapatkan data.

Tentu saja, halaman tersebut tidak stabil saat ini. Ini tidak ada kaitannya dengan CSR itu sendiri dan lebih berkaitan dengan membuka jalur penulisan yang terlalu lebar.

Biaya rendering streaming yang paling mudah diremehkan adalah biaya interpretasi status yang disebabkan oleh “kedatangan batch”

Render streaming dalam dua tahun terakhir dapat dengan mudah dikatakan sebagai keuntungan bersih:

• Kerangka itu tiba lebih awal;
• Konten utama muncul lebih dulu;
• Tidak masalah jika blok sekundernya nanti;
• Pengalaman pengguna akan lebih lancar.

Ini semua benar. Namun hal ini memiliki harga yang jarang dipertimbangkan secara serius dalam tinjauan rencana: halaman ** tidak lagi hanya memiliki dua status: “tiba” atau “tidak tiba”, namun memiliki beberapa blok yang tiba dalam batch, kesalahan dalam batch, dan rollback dalam batch. **

Setelah halaman dipecah menjadi fragmen asinkron seperti konten utama, komentar, rekomendasi, ruang iklan, dan lapisan mengambang yang dipersonalisasi, bukan hanya kinerja yang perlu ditangani, namun masalah teknis berikut:

• Apakah versi data master yang diandalkan oleh blok tertentu yang datang terlambat dan versi layar pertama adalah sama;
• Ketika blok utama berhasil dan blok sekunder gagal, apakah seluruh halaman masih dianggap berhasil;
• Apakah konten yang sudah dikeluarkan dalam aliran dapat dibatalkan oleh fragmen berikutnya;
• Pengguna telah memulai operasi setelah fragmen halaman pertama tiba. Akankah fragmen selanjutnya menimpa hasil interaksi.

Biaya ini tidak abstrak. Saya telah melihat halaman yang mengeluarkan informasi utama dan menambahkan rekomendasi terkait dan hak pengguna dalam format streaming. Ternyata bug yang paling sulit dipecahkan secara online adalah “salinan hak yang dilihat oleh beberapa pengguna akan berpindah dua kali dalam dua detik.”

Akhirnya diperiksa, itu adalah:

• Segmen pertama server menggunakan snapshot ekuitas lama di cache publik;
• Segmen streaming berikutnya menggunakan antarmuka baru dengan mode pengguna;
• Setelah klien terhidrasi, bidang tampilan dihitung ulang berdasarkan status login lokal.

Ketiga kumpulan sumber tersebut masuk akal, tetapi jika digabungkan, halaman tersebut tidak terasa seperti sebuah sistem.

Yang harus didesain terlebih dahulu adalah baris data utama halaman tersebut.

Di akhir diskusi tentang strategi rendering, saya menjadi semakin khawatir tentang apakah halaman tersebut memiliki jalur data utama yang jelas.

Yang disebut jalur utama data adalah menentukan hal-hal berikut terlebih dahulu:

1. Data manakah yang menjadi dasar layar pertama?

Ketika HTML layar pertama keluar, bidang mana yang sudah dapat dianggap sebagai nilai sebenarnya yang dapat ditampilkan dan mana yang hanya merupakan hasil placeholder harus dinyatakan dengan jelas.

Misalnya:

• Teks artikel dapat berdasarkan hasil SSR;
• Status suka pengguna hanya dapat ditentukan oleh permintaan status login klien;
• Blok yang direkomendasikan dideklarasikan dari awal sebagai “penyelesaian asinkron, tidak berpartisipasi dalam nilai sebenarnya di layar pertama”.

Selama lapisan ini tidak ditentukan, setiap putaran permintaan berikutnya akan bersaing dengan putaran sebelumnya untuk mendapatkan hak interpretasi.

2. Kolom mana yang boleh ditimpa, dan kolom mana yang hanya bisa diisi secara bertahap?

Banyak halaman yang ditulis berantakan karena semua data yang datang kemudian diatur secara default ke “yang terbaru dan lebih dapat dipercaya”. Tidak terlalu.

Beberapa bidang cocok untuk cakupan, seperti inventaris, harga, dan jumlah orang yang online; Beberapa kolom hanya dapat diisi, seperti pagination komentar dan daftar rekomendasi; Beberapa bidang harus ditimpa dengan penilaian versi, seperti status koleksi yang baru saja dioperasikan pengguna.

Jika tidak ada aturan penggantian tingkat bidang, semakin banyak permintaan berikutnya, semakin besar kemungkinan nilai lama akan menggantikan nilai baru.

3. Apakah kegagalan sisi server dan kegagalan sisi klien memiliki semantik yang sama?

Hal ini mudah diabaikan.

Di beberapa sistem, ketika permintaan server gagal, permintaan tersebut akan langsung diturunkan ke modul default; ketika klien gagal, tombol coba lagi kesalahan independen ditampilkan. Hasil yang dilihat pengguna adalah:

• Saat menyegarkan halaman, konten ini menghilang secara diam-diam;
• Setelah halaman dipasang, konten ini tiba-tiba muncul status kesalahan.

Hal ini karena sistem tidak memiliki penjelasan terpadu untuk “kegagalan”.

Di blok yang sama, jika semantik kegagalan server dan klien berbeda, akan sulit untuk menjawab saat pemecahan masalah: Apakah ini penurunan versi normal atau tampilan tidak normal?

Kesalahpahaman umum: menganggap “menarik data terbaru sekali lagi” sebagai jaminan

Ketika banyak tim menghadapi masalah konsistensi, reaksi pertama mereka adalah “kemudian klien akan mengambil data terbaru lagi”.

Trik ini seringkali efektif dalam jangka pendek karena menyegarkan beberapa data SSR lama. Namun dalam jangka panjang, hal ini dapat dengan mudah meningkatkan masalah dari “layar pertama terkadang agak tua” menjadi “seluruh halaman bersaing untuk mendapatkan hak interpretasi akhir”.

Tautan gagal yang paling umum adalah ini:

1. Server pertama-tama mengambil data versi A dan merender layar pertama;
2. Setelah browser dipasang, klien secara otomatis menarik versi B;
3. Pengguna segera mengklik koleksi tersebut, dan pembaruan optimis lokal berubah menjadi C;
4. Versi B meminta pengembalian yang terlambat dan mendorong C kembali;
5. Kembali ke antarmuka koleksi dan halaman berubah kembali ke D.

Secara teknis, setiap langkah adalah “benar”.

Namun bagi pengguna, halaman tersebut mengubah jawaban empat kali dalam tiga detik. Pada titik ini, sulit untuk mengatakan apakah inti permasalahannya adalah RSK atau CSR, karena permasalahan sebenarnya adalah: **Halaman tersebut tidak menentukan prioritas mana yang harus diberikan pada penulisan interaktif atau penyegaran penuh. **

Contoh balasan: Tidak semua halaman layak untuk SSR atau streaming

Ada juga kesalahpahaman yang sangat nyata, yaitu menganggap strategi rendering sebagai daftar kemampuan platform.

Jika kerangka kerja tersebut mendukung RSK, maka kerangka tersebut cenderung merupakan RSK di seluruh lokasi; Mendukung rendering streaming dan mulai menghapus blok; Jika Anda khawatir tentang SEO, gunakan sisi server untuk semua halaman detail secara default; Jika Anda khawatir dengan lambatnya, tambahkan lapisan cache klien lainnya.

Akhirnya, biaya interpretasi sistem ini meroket.

Beberapa halaman tidak sebanding dengan strategi rendering yang rumit:

• Halaman backend dengan status login yang kuat, personalisasi yang kuat, dan nilai mesin pencari yang rendah;
• Halaman transaksi yang data real-time-nya jauh lebih tinggi daripada nilai layar statis pertama;
• Halaman operasi dengan sedikit konten di layar pertama tetapi banyak interaksi.

Jika SSR diinstal pada halaman tersebut, dan kemudian penarikan tambahan sisi klien dan streaming parsial ditambahkan, manfaatnya seringkali tidak sebaik menulis data di bawah CSR dengan jujur.

Sebaliknya, halaman detail berbasis konten, halaman arahan publik, dan halaman informasi dengan struktur stabil lebih cocok untuk memaksimalkan pendapatan SSR atau streaming. Premisnya masih apakah batas data halaman dapat dipisahkan dengan jelas**.

Untuk memilih metode, lihat tiga hal terlebih dahulu

Jika Anda benar-benar ingin membuat penilaian antara SSR, CSR, dan rendering streaming, saya sarankan membaca tiga hal ini terlebih dahulu daripada membaca halaman promosi framework terlebih dahulu.

Pertama, periksa apakah konten di layar pertama memiliki nilai sebenarnya yang stabil.

Jika sebagian besar konten di layar pertama dapat diperoleh di sisi server, dan perbedaan mode pengguna kecil, SSR akan lebih stabil.

Jika layar pertama sangat bergantung pada status login, status perangkat, dan status real-time, dan server hanya mendapatkan nilai perkiraan yang kedaluwarsa dengan cepat, maka pendapatan SSR akan didiskon karena klien harus segera menghitung ulang lagi.

Kedua, periksa apakah halaman mengizinkan penjelasan batch

Jika halaman secara alami dapat dijangkau dalam blok, seperti teks terlebih dahulu, komentar terakhir, dan rekomendasi terakhir, rendering streaming lebih berharga.

Jika beberapa blok di halaman berbagi sejumlah besar status, dan keterlambatan kedatangan salah satu blok akan membatalkan dua blok sebelumnya, maka rendering streaming tidak hanya akan menghasilkan optimalisasi kinerja, tetapi juga biaya koordinasi status.

Ketiga, lihat apakah penulisan interaktif akan bertentangan dengan jalur penyegaran.

Selama ada tindakan seperti koleksi, keranjang belanja, formulir, dan peralihan izin pada halaman yang akan segera mengubah status, maka perlu fokus pada apakah jalur penulisan interaktif dan jalur penyegaran halaman akan saling menutupi.

Hal ini tidak tetap, apapun strategi rendering yang Anda pilih, itu hanya akan membuat kesalahan di sisi lain.

Batasan yang berlaku

Artikel ini terutama membahas:- Secara bersamaan mengejar SEO, kecepatan paruh atas, dan halaman web yang dipersonalisasi;

• Halaman yang sama memiliki rendering pertama di sisi server, rendering tambahan di sisi klien, dan blok asinkron lokal;
• Masalah hidrasi, caching, dan perakitan streaming yang biasa ditemui saat menggunakan kerangka kerja front-end modern.

Jika halamannya sangat sederhana, baik tampilan konten murni atau pengoperasian latar belakang murni, kompleksitas strategi rendering tidak akan terlalu tinggi. Masalah yang paling mungkin muncul adalah halaman yang “terlihat seperti halaman detail saja, namun sebenarnya membawa distribusi konten, konversi bisnis, dan interaksi pengguna pada saat yang bersamaan”.

Ringkasan

SSR, CSR, dan rendering streaming tidak salah. Apa yang salah adalah menganggapnya sebagai saklar kinerja murni.

Setelah halaman memiliki persyaratan layar pertama, persyaratan cache, dan persyaratan interaksi pada saat yang sama, hal pertama yang benar-benar lepas kendali adalah versi data mana yang dihitung, siapa yang akan bertanggung jawab atas kegagalan, dan siapa yang mengambil prioritas dalam penulisan interaktif dan jalur penyegaran.

Oleh karena itu, yang pertama-tama harus ditentukan oleh strategi rendering front-end adalah berapa kali halaman data ini akan dihasilkan, berapa kali akan ditimpa, berapa kali gagal untuk mundur, dan lapisan mana yang akhirnya akan menutupnya.

Hal ini tidak jelas. Semakin canggih skema renderingnya, semakin terlihat bahwa halaman tersebut ditulis oleh banyak rangkaian mekanisme yang masuk akal pada saat yang bersamaan.