Software engineering di dunia web udah makin kompleks. Semuanya berlomba-lomba bikin framework yang diklaim paling cepat. Padahal dulunya cukup pake library legendaris jQuery doang😅. Termasuk cara render halaman web, dulunya dari server cukup kirim semua kontennya dan render di web browser. Tapi jaman sekarang itu udah dianggap lambat. Google selaku mesin pencari terkenal juga sangat selektif memilih website yang akan di-index di hasil pencariannya. Saat ini setidaknya ada 5 strategy untuk melakukan rendering halaman web.
Client-Side Rendering (CSR)
Ini adalah cara yang umum dilakukan dari dulu dan diimplementasi oleh hampir semua framework JS. Cara kerjanya, dari web akan mengirimkan request untuk halaman tertentu ke server. Lalu server akan akan mengirimkan response berupa HTML, CSS, dan JS ke web browser. Setelah terdownload itu semua, web akan melakukan rendering dari response tersebut dari melakukan fetching data, build konten, hingga semuanya muncul di web. Keunggulannya, halamannya langsung menjadi interaktif setelah mendapatkan response karena udah ada JS di dalamnya😎. Kelemahannya adalah script JS itu biasanya gede, sehingga butuh waktu untuk mendapatkan response. Ditambah lagi setelah download biasanya ada hal-hal yang perlu dieksekusi oleh JS di web browser yang mempengaruhi tampilan awal web seperti fetching data ke backend hingga build konten di web browser. Jadinya website kita akan loading terus sampai eksekusinya selesai hingga render dengan sempurna😓. User harus menunggu semuanya complete agar halamannya viewable. Ini jelek buat SEO karena search engine memprioritaskan halaman yang viewable dengan cepat untuk di-index. Website modern jaman sekarang udah mulai meninggalkan CSR karena hal ini. Tapi bukan berarti CSR adalah strategy yang buruk. CSR masih diperlukan untuk halaman yang ga terlalu mementingkan SEO dan membutuhkan halaman tersebut interaktif sebelum bisa digunakan seperti website game. Ketika kita membuka website seperti game tentu JS-nya harus benar-benar ter-download semuanya di browser, kalau ga game-nya jadi ga bisa dimainkan.
Server-Side Rendering (SSR)
SSR muncul untuk memecahkan permasalahan pada CSR. Beberapa framework yang terkenal memiliki fitur ini seperti React, Next, Vue, Gatsby, dan masih banyak lagi. Cara kerjanya, dari web akan mengirimkan request untuk halaman tertentu ke server. Lalu server akan memproses request tersebut layaknya browser tapi kali ini di sisi server. Seperti memproses HTML, CSS, JS, fetching data ke backend, build konten, dan lainnya. Jadi, proses rendering yang biasanya dilakukan di web browser kali ini dilakukan di server. Melakukan render di server tentu lebih cepat dibanding di web browser. Ada beberapa faktor yang membuat rendering di server lebih cepat dibanding di web browser seperti spec hardware yang digunakan di browser client yang berbeda-beda, koneksi jaringan client, hingga lokasi client mengakses web. Outputnya adalah HTML & CSS doang saat load pertama kali. Ga ada JS sama sekali. Sehingga di web browser halaman yang dituju akan viewable dengan cepat karena response di awal hanya HTML & CSS doang. Makanya, SEO pada web SSR lebih baik dibanding CSR. Walaupun kontennya bersifat dinamis, tapi response awalnya adalah konten statis karena hanya menampilkan HTML & CSS😎. Selanjutnya, di process background, server akan mengirimkan JS ke web browser. Setelah JS terdownload, barulah script JS dieksekusi di web browser dan halaman tersebut menjadi interaktif. Proses transisi halaman statis yang viewable hingga menjadi interaktif inilah yang disebut Hydration seperti yang pernah gw bahas di post Minified React Error. Jadi, saat pertama kali tampil halamannya masih statis dan ga langsung interaktif, melainkan butuh waktu agar menjadi interaktif saat JS sudah terdownload. Misalkan di halaman itu ada form yang ada efek tertentu ketika mengisi form, maka saat pertama kali diakses form itu cuma bisa dilihat dan belum ada efek interaktif yang berfungsi hingga proses Hydration kelar. Setelah Hydration kelar barulah semua hal terkait JS bisa berfungsi dan web tersebut jadi interaktif. Secara SEO itu ga masalah karena yang diprioritaskan untuk di-index oleh search engine adalah website yang halamannya muncul dengan cepat, bukan halaman yang interaktif. Tapi bukan berarti SSR ini menjadi solusi yang sempurna. Kita masih butuh proses rendering, tapi di sisi server dan itu tetap butuh waktu untuk mendapatkan response dari server meskipun udah lebih baik dibanding CSR. Apalagi kalau JS yang dieksekusi cukup besar, maka butuh waktu juga ketika render di server & load JS di web browser saat Hydration😓. Contoh halaman yang cocok menggunakan SSR adalah halaman website portal berita yang sering update, konten beritanya dinamis tapi loading-nya cukup cepat sehingga bagus untuk SEO. Ketika ada perubahan berita pun perubahannya dapat muncul saat itu juga dengan loading yang lebih cepat dibanding CSR.
Static Site Generator (SSG)
Karena SSR juga memiliki kelemahan, maka muncul rendering strategy baru, yaitu SSG. Salah satu pelopor SSG adalah framework Gatsby yang kemudian diikuti oleh Next, Astro, dan beberapa framework lainnya. Rendering tidak lagi dilakukan tiap diakses seperti CSR atau SSR, melainkan sekali doang saat build di server. Ini mirip SSR, tapi kali ini ga ada rendering sama sekali saat diakses, melainkan server langsung memberikan response halaman statis HTML & CSS yang udah di-render saat build sehingga response awal halamannya lebih cepat lagi dibanding SSR apalagi CSR😎. Setelah itu barulah terjadi proses Hydration kayak SSR. Kelemahannya adalah website kita jadi statis, ketika mengubah halaman maka kita butuh build dan deploy ulang agar hasilnya terlihat. Apalagi kalau kontennya banyak, maka proses build dan deploy jadi makin lama karena butuh render semua halaman😓. Contoh halaman yang cocok menggunakan SSG adalah web blog yang perubahan kontennya ga terlalu sering atau web portfolio karena dapat membuat loading halaman jadi sangat cepat dibanding CSR dan SSR sehingga bagus banget untuk SEO.
Deferred Static Generation (DSG)
Secara SEO dan loading time SSG memang lebih baik dibanding CSR dan SSR, tapi kalau kontennya banyak, maka proses build dan deploy akan jadi lambat. Makanya muncul lagi rendering strategy yang baru, yaitu DSG. Ini juga diperkenalkan oleh Gatsby sebagai alternatif SSG. Cara kerjanya sebenarnya mirip dengan SSG. Bedanya, kita bisa memilih mana aja halaman yang di-render saat build, dan mana aja halaman yang di-render saat pertama kali akses. Jadi saat build hanya halaman yang kita pilih aja yang akan di-render. Misalkan kita set halaman yang dibuat lebih dari sebulan yang lalu tidak di-render saat build, maka halaman tersebut hanya akan di-render saat ada user yang mengakses halaman itu. Proses renderingnya juga hanya sekali saat pertama kali akses doang. Akses selanjutnya pada halaman tersebut tidak perlu rendering lagi karena halaman yang udah di-render akan digunakan kembali seperti halaman yang di-render saat build. Sekarang proses build dan deploy jadi lebih cepat karena ga perlu render semua halaman saat build😎. Sisanya sama seperti SSG mulai dari proses request hingga proses Hydration tidak ada perbedaan behavior dan sama-sama cepat loadingnya & bagus dari sisi SEO. Kekurangannya masih sama seperti SSG, meskipun proses build dan deploy jadi lebih cepat, tetap saja kita perlu build dan deploy ulang kalau ada perubahan halaman😓. Lalu, tentu saja saat pertama kali akses halaman yang belum di-render responsenya jadi lebih lambat. Contoh halaman yang cocok menggunakan DSG adalah web blog yang kontennya cukup banyak dan konten yang lama jarang di-update. Proses build dan deploy web blog jadi lebih cepat karena kita bisa filter halaman mana aja yang ingin kita render saat build dan halaman mana aja yang ingin kita render hanya saat ada yang akses untuk pertama kali. Loading halaman juga cepat dan bisa di-index oleh search engine sehingga bagus juga untuk SEO.
Incremental Static Regeneration (ISR)
DSG menyelesaikan permasalahan SSG saat build dan deploy, tapi masih memiliki kekurangan saat kontennya berubah. ISR muncul menyelesaikan masalah tersebut. Ide ini diperkenalkan oleh framework Next. Cara kerjanya, semua halaman tetap di-render saat build seperti SSG, tapi halaman yang sudah di-render saat build tersebut dapat kita revalidate agar melakukan build ulang secara otomatis dalam waktu tertentu tanpa harus build dan deploy manual. Kita juga dapat memilih halaman mana aja yang akan di-build ulang secara otomatis dan mana aja yang ga perlu di-build ulang otomatis. Misalkan kita atur tiap 30 menit ada halaman tertentu yang akan di-build ulang otomatis. Maka tiap 30 menit halaman tersebut akan melakukan build otomatis tanpa kita lakukan secara manual. Jadi kalau misalkan ada perubahan konten pada halaman tersebut, maka maksimal dalam jangka waktu 30 menit kontennya akan ter-update tanpa perlu build dan deploy ulang semua halaman😎. Sisanya kurang lebih sama seperti SSG dan DSG mulai dari saat akses oleh web browser hingga proses Hydration. Secara performa juga sama cepatnya seperti SSG dan DSG. Kekurangannya, tetap saja kontennya statis dan butuh waktu untuk melihat update konten halaman terbaru sesuai konfigurasi yang kita atur. Meskipun di framework Next ada fitur On-Demand Regeneration menggunakan ISR dimana kita bisa melakukan revalidate secara manual, tapi tetap saja butuh tindakan manual untuk hal ini😓. Lalu, saat terjadi revalidate pada suatu halaman, responsenya juga jadi lebih lambat waktu diakses. Contoh halaman yang cocok menggunakan ISR adalah web analitik yang perubahan kontennya berkala dan ga harus real time sehingga kita tidak perlu build semua halaman untuk perubahan tersebut.
Verdict
CSR vs SSR vs SSG vs DSG vs ISR adalah strategy rendering yang sering diperdebatkan. Masing-masing strategy hanya cocok pada situasi tertentu. CSR cocok untuk halaman yang membutuhkan interaktif yang tinggi seperti website game. SSR cocok untuk halaman yang membutuhkan konten dinamis dan perubahannya real time seperti portal berita. SSG cocok untuk halaman yang kontennya cenderung statis dan tidak terlalu sering diubah seperti web portfolio atau web blog. DSG cocok untuk halaman yang kontennya tidak terlalu sering diubah tapi jumlahnya cukup banyak seperti web blog. ISR cocok untuk halaman yang kontennya berubah secara berkala tapi perubahannya ga terlalu real time seperti web analitik. Tapi tenang aja, web framework modern biasanya memiliki lebih dari satu fitur rendering strategy. Seperti Next yang memiliki fitur CSR, SSR, SSG, dan ISR. Atau Gatsby yang memiliki fitur SSG, CSR, SSR, dan DSG. Jadi kita bisa memilih strategy tertentu untuk halaman spesifik. Ga harus terpaku terhadap satu strategy aja untuk keseluruhan website.