Sisi klien vs. Sisi server vs. Pra-rendering untuk Aplikasi Web

Ada sesuatu yang terjadi dalam komunitas front-end baru-baru ini. Render sisi server semakin menarik berkat React dan fitur hidrasi sisi server bawaannya. Tapi itu bukan satu-satunya solusi untuk memberikan pengalaman cepat kepada pengguna dengan skor time-to-first-byte (TTFB) super cepat: Pra-rendering juga merupakan strategi yang cukup bagus. Apa perbedaan antara solusi ini dan aplikasi yang dibuat oleh klien sepenuhnya?

Aplikasi yang diberikan oleh klien

Karena kerangka kerja seperti Angular, Ember.js, dan Backbone ada, pengembang front-end cenderung merender segala sesuatu di sisi klien. Berkat Google dan kemampuannya untuk "membaca" JavaScript, ia bekerja dengan cukup baik, dan bahkan SEO friendly.

Dengan solusi rendering sisi klien, Anda mengarahkan permintaan ke satu file HTML dan server akan mengirimkannya tanpa konten apa pun (atau dengan layar pemuatan) hingga Anda mengambil semua JavaScript dan membiarkan browser mengompilasi semuanya sebelum merender konten.

Di bawah koneksi internet yang baik dan andal, ini cukup cepat dan berfungsi dengan baik. Tapi itu bisa jauh lebih baik, dan tidak harus sulit untuk membuatnya seperti itu. Itulah yang akan kita lihat di bagian berikut.

Rendering Sisi Server (SSR)

Solusi SSR adalah sesuatu yang sering kami lakukan, bertahun-tahun yang lalu, tetapi cenderung melupakan solusi rendering sisi klien.

Dengan solusi rendering sisi server lama , Anda membuat halaman web—dengan PHP misalnya—server mengkompilasi semuanya, menyertakan data, dan mengirimkan halaman HTML yang terisi penuh ke klien. Itu cepat dan efektif.

Tapi… setiap kali Anda menavigasi ke rute lain, server harus melakukan pekerjaan dari awal lagi: Dapatkan file PHP, kompilasi, dan kirimkan HTML, dengan semua CSS dan JS menunda pemuatan halaman hingga beberapa ratus ms atau bahkan seluruh detik.

Bagaimana jika Anda dapat melakukan pemuatan halaman pertama dengan solusi SSR, dan kemudian menggunakan kerangka kerja untuk melakukan perutean dinamis dengan AJAX, hanya mengambil data yang diperlukan?

Inilah sebabnya mengapa SSR semakin menarik dalam komunitas karena React mempopulerkan masalah ini dengan solusi yang mudah digunakan: Metode RenderToString .

Aplikasi web jenis baru ini disebut aplikasi universal atau aplikasi isomorfik . Masih ada beberapa kontroversi mengenai arti sebenarnya dari istilah-istilah ini dan hubungan di antara mereka, tetapi banyak orang menggunakannya secara bergantian.

Bagaimanapun, keuntungan dari solusi ini adalah dapat mengembangkan aplikasi sisi server dan sisi klien dengan kode yang sama dan memberikan pengalaman yang sangat cepat kepada pengguna dengan data khusus. Kerugiannya adalah Anda harus menjalankan server.

SSR digunakan untuk mengambil data dan mengisi halaman sebelumnya dengan konten khusus, memanfaatkan koneksi internet server yang andal. Artinya, koneksi internet server sendiri lebih baik daripada koneksi internet pengguna dengan lie-fi), sehingga dapat mengambil dan menggabungkan data sebelum mengirimkannya ke pengguna.

Dengan data yang telah diisi sebelumnya, menggunakan aplikasi SSR juga dapat memperbaiki masalah yang dimiliki aplikasi yang dibuat oleh klien dengan berbagi sosial dan sistem OpenGraph. Misalnya, jika Anda hanya memiliki satu file index.html untuk dikirim ke klien, mereka hanya akan memiliki satu jenis metadata—kemungkinan besar metadata beranda Anda. Ini tidak akan dikontekstualisasikan ketika Anda ingin berbagi rute yang berbeda, jadi tidak ada rute Anda yang akan ditampilkan di situs lain dengan konten pengguna yang tepat (deskripsi dan gambar pratinjau) yang ingin dibagikan pengguna kepada dunia.

Pra-rendering

Server wajib untuk aplikasi universal dapat menjadi penghalang bagi sebagian orang dan mungkin berlebihan untuk aplikasi kecil. Inilah sebabnya mengapa pra-rendering bisa menjadi alternatif yang sangat bagus.

Saya menemukan solusi ini dengan Preact dan CLI-nya sendiri yang memungkinkan Anda untuk mengkompilasi semua rute yang telah dipilih sebelumnya sehingga Anda dapat menyimpan file HTML yang terisi penuh ke server statis . Ini memungkinkan Anda memberikan pengalaman super cepat kepada pengguna, berkat fungsi hidrasi Preact/React, tanpa perlu Node.js.

Tangkapannya adalah, karena ini bukan SSR, Anda tidak memiliki data khusus pengguna untuk ditampilkan pada saat ini—ini hanya file statis (dan agak umum) yang dikirim langsung pada permintaan pertama, apa adanya. Jadi, jika Anda memiliki data khusus pengguna, di sinilah Anda dapat mengintegrasikan kerangka yang dirancang dengan indah untuk menunjukkan kepada pengguna bahwa data mereka akan datang, untuk menghindari frustrasi di pihak mereka:

Ada tangkapan lain: Agar teknik ini berfungsi, Anda masih perlu memiliki proxy atau sesuatu untuk mengarahkan pengguna ke file yang tepat.

Mengapa?

Dengan aplikasi satu halaman, Anda perlu mengarahkan semua permintaan ke file root, dan kemudian kerangka kerja mengalihkan pengguna dengan sistem perutean bawaannya. Jadi pemuatan halaman pertama selalu file root yang sama.

Agar solusi pra-rendering berfungsi, Anda perlu memberi tahu proxy Anda bahwa beberapa rute memerlukan file tertentu dan tidak selalu file root index.html .

Misalnya, Anda memiliki empat rute ( / , /about , /jobs , dan blog ) dan semuanya memiliki tata letak yang berbeda. Anda memerlukan empat file HTML yang berbeda untuk mengirimkan kerangka ke pengguna yang kemudian akan membiarkan React/Preact/etc. rehidrasi dengan data. Jadi, jika Anda mengarahkan semua rute tersebut ke file root index.html , halaman akan terasa tidak menyenangkan dan tidak nyaman saat memuat, di mana pengguna akan melihat kerangka halaman yang salah hingga selesai memuat dan mengganti tata letak. Misalnya, pengguna mungkin melihat kerangka beranda dengan hanya satu kolom, saat mereka meminta halaman lain dengan galeri mirip Pinterest.

Solusinya adalah memberi tahu proxy Anda bahwa masing-masing dari keempat rute tersebut memerlukan file tertentu:

• https://my-website.com → Arahkan ulang ke file root index.html
• https://my-website.com/about → Arahkan ulang ke file /about/index.html
• https://my-website.com/jobs → Arahkan ulang ke file /jobs/index.html
• https://my-website.com/blog → Arahkan ulang ke file /blog/index.html

Inilah sebabnya mengapa solusi ini dapat berguna untuk aplikasi kecil—Anda dapat melihat betapa menyakitkannya jika Anda memiliki beberapa ratus halaman.

Sebenarnya, tidak wajib melakukannya dengan cara ini—Anda bisa menggunakan file statis secara langsung. Misalnya, https://my-website.com/about/ akan bekerja tanpa pengalihan apa pun karena akan secara otomatis mencari index.html di dalam direktorinya. Tetapi Anda memerlukan proxy ini jika Anda memiliki url param— https://my-website.com/profile/guillaume perlu mengarahkan permintaan ke /profile/index.html dengan tata letaknya sendiri, karena profile/guillaume/index.html tidak ada dan akan memicu kesalahan 404.

Singkatnya, ada tiga tampilan dasar yang dimainkan dengan strategi rendering yang dijelaskan di atas: Layar pemuatan, kerangka, dan halaman penuh setelah akhirnya dirender.

Bergantung pada strateginya, terkadang kami menggunakan ketiga tampilan ini, dan terkadang kami langsung membuka halaman yang dirender sepenuhnya. Hanya dalam satu kasus penggunaan kami dipaksa untuk menggunakan pendekatan yang berbeda:

Rendering Khusus Klien Seringkali Tidak Cukup

Aplikasi yang dibuat oleh klien adalah sesuatu yang harus kita hindari sekarang karena kita dapat melakukan yang lebih baik untuk pengguna. Dan melakukan yang lebih baik, dalam hal ini, semudah solusi pra-rendering. Ini jelas merupakan peningkatan dari perenderan khusus klien dan lebih mudah diterapkan daripada aplikasi yang dirender sepenuhnya di sisi server.

Aplikasi SSR/universal bisa sangat kuat jika Anda memiliki aplikasi besar dengan banyak halaman berbeda. Ini memungkinkan konten Anda untuk fokus dan relevan saat berbicara dengan perayap sosial. Hal ini juga berlaku untuk robot mesin telusur, yang kini memperhitungkan kinerja situs Anda saat memeringkatnya.

Nantikan tutorial lanjutan, di mana saya akan membahas transformasi SPA menjadi versi pra-render dan SSR, dan membandingkan kinerjanya.