Rendering sisi klien untuk HTML dan interaktivitas

Merender HTML dengan JavaScript berbeda dengan merender HTML yang dikirim oleh server—dan hal itu dapat memengaruhi performa. Pelajari perbedaannya dalam panduan ini, dan apa yang dapat Anda lakukan untuk mempertahankan performa rendering situs Anda—terutama yang berkaitan dengan interaksi.

Jeremy Wagner

Penguraian dan rendering HTML adalah sesuatu yang dilakukan browser dengan sangat baik secara default untuk situs yang menggunakan logika navigasi bawaan browser—terkadang disebut "pemuatan halaman tradisional" atau "navigasi berat". Situs tersebut terkadang disebut aplikasi multi-halaman (MPA).

Namun, developer dapat mengatasi setelan default browser agar sesuai dengan kebutuhan aplikasi mereka. Hal ini tentu saja berlaku untuk situs yang menggunakan pola aplikasi halaman tunggal (SPA), yang membuat sebagian besar HTML/DOM secara dinamis di klien dengan JavaScript. Pola desain ini disebut rendering sisi klien, dan dapat memengaruhi Interaction to Next Paint (INP) situs Anda jika pekerjaan yang terlibat berlebihan.

Panduan ini akan membantu Anda mempertimbangkan perbedaan antara menggunakan HTML yang dikirim oleh server ke browser dan membuatnya di klien dengan JavaScript, serta bagaimana cara yang terakhir dapat menyebabkan latensi interaksi yang tinggi pada saat-saat penting.

Cara browser merender HTML yang disediakan oleh server

Pola navigasi yang digunakan dalam pemuatan halaman tradisional melibatkan penerimaan HTML dari server pada setiap navigasi. Jika Anda memasukkan URL di kolom URL browser atau mengklik link di MPA, serangkaian peristiwa berikut akan terjadi:

1. Browser mengirimkan permintaan navigasi untuk URL yang diberikan.
2. Server merespons dengan HTML dalam potongan.

Langkah terakhir ini sangat penting. Hal ini juga merupakan salah satu pengoptimalan performa paling mendasar dalam pertukaran server/browser, dan dikenal sebagai streaming. Jika server dapat mulai mengirim HTML sesegera mungkin, dan browser tidak menunggu seluruh respons tiba, browser dapat memproses HTML dalam potongan saat tiba.

Seperti kebanyakan hal yang terjadi di browser, penguraian HTML terjadi dalam tugas. Saat HTML di-streaming dari server ke browser, browser mengoptimalkan penguraian HTML tersebut dengan melakukannya sedikit demi sedikit saat bit stream tersebut tiba dalam potongan. Konsekuensinya adalah browser akan memberikan prioritas ke thread utama secara berkala setelah memproses setiap potongan, sehingga menghindari tugas panjang. Artinya, pekerjaan lain dapat terjadi saat HTML sedang diuraikan, termasuk pekerjaan rendering inkremental yang diperlukan untuk menampilkan halaman kepada pengguna, serta memproses interaksi pengguna yang mungkin terjadi selama periode pengaktifan penting halaman. Pendekatan ini menghasilkan skor Interaction to Next Paint (INP) yang lebih baik untuk halaman.

Poin pentingnya? Saat Anda melakukan streaming HTML dari server, Anda akan mendapatkan penguraian dan rendering HTML inkremental serta penyerahan otomatis ke thread utama tanpa biaya. Anda tidak akan mendapatkan hal itu dengan rendering sisi klien.

Cara browser merender HTML yang disediakan oleh JavaScript

Meskipun setiap permintaan navigasi ke halaman memerlukan sejumlah HTML yang disediakan oleh server, beberapa situs akan menggunakan pola SPA. Pendekatan ini sering kali melibatkan payload HTML awal minimal yang disediakan oleh server, tetapi kemudian klien akan mengisi area konten utama halaman dengan HTML yang dirakit dari data yang diambil dari server. Navigasi berikutnya—terkadang disebut sebagai "navigasi ringan" dalam hal ini—ditangani sepenuhnya oleh JavaScript untuk mengisi halaman dengan HTML baru.

Rendering sisi klien juga dapat terjadi di non-SPA dalam kasus yang lebih terbatas saat HTML ditambahkan secara dinamis ke DOM melalui JavaScript.

Ada beberapa cara umum untuk membuat HTML atau menambahkan ke DOM melalui JavaScript:

1. Properti innerHTML memungkinkan Anda menetapkan konten pada elemen yang ada melalui string, yang diuraikan browser menjadi DOM.
2. Metode document.createElement memungkinkan Anda membuat elemen baru untuk ditambahkan ke DOM tanpa menggunakan penguraian HTML browser.
3. Dengan metode document.write, Anda dapat menulis HTML ke dokumen (dan browser akan memparsingnya, seperti pada pendekatan #1). Namun, karena beberapa alasan, penggunaan document.write sangat tidak dianjurkan.

Konsekuensi pembuatan HTML/DOM melalui JavaScript sisi klien bisa sangat signifikan:

• Tidak seperti HTML yang di-streaming oleh server sebagai respons terhadap permintaan navigasi, tugas JavaScript di klien tidak dipecah secara otomatis, yang dapat menghasilkan tugas panjang yang memblokir thread utama. Artinya, INP halaman Anda dapat terpengaruh secara negatif jika Anda membuat terlalu banyak HTML/DOM sekaligus di klien.
• Jika HTML dibuat di klien selama proses startup, resource yang dirujuk di dalamnya tidak akan ditemukan oleh pemindai pramuat browser. Hal ini tentu akan berdampak negatif pada Largest Contentful Paint (LCP) halaman. Meskipun ini bukan masalah performa runtime (melainkan masalah penundaan jaringan dalam mengambil resource penting), Anda tidak ingin LCP situs Anda terpengaruh dengan mengabaikan pengoptimalan performa browser mendasar ini.

Yang dapat Anda lakukan terkait dampak performa rendering sisi klien

Jika situs Anda sangat bergantung pada rendering sisi klien dan Anda telah mengamati nilai INP yang buruk dalam data lapangan Anda, Anda mungkin bertanya-tanya apakah rendering sisi klien ada hubungannya dengan masalah tersebut. Misalnya, jika situs Anda adalah SPA, data kolom Anda dapat mengungkapkan interaksi yang bertanggung jawab atas pekerjaan rendering yang cukup besar.

Apa pun penyebabnya, berikut beberapa kemungkinan penyebab yang dapat Anda pelajari untuk membantu mengatasi masalah ini.

Berikan sebanyak mungkin HTML dari server

Seperti yang disebutkan sebelumnya, browser menangani HTML dari server dengan cara yang sangat berperforma secara default. Hal ini akan memecah penguraian dan rendering HTML dengan cara yang menghindari tugas yang berjalan lama, dan mengoptimalkan jumlah total waktu thread utama. Hal ini menghasilkan Total Waktu Pemblokiran (TBT) yang lebih rendah, dan TBT berkorelasi kuat dengan INP.

Anda mungkin mengandalkan framework frontend untuk membangun situs Anda. Jika ya, Anda harus memastikan bahwa Anda merender HTML komponen di server. Tindakan ini akan membatasi jumlah rendering sisi klien awal yang diperlukan situs Anda, dan akan menghasilkan pengalaman yang lebih baik.

• Untuk React, Anda harus menggunakan Server DOM API untuk merender HTML di server. Namun, perlu diketahui: metode rendering sisi server tradisional menggunakan pendekatan sinkron, yang dapat menyebabkan Waktu ke Byte Pertama (TTFB) yang lebih lama, serta metrik berikutnya seperti First Contentful Paint (FCP) dan LCP. Jika memungkinkan, pastikan Anda menggunakan API streaming untuk Node.js atau runtime JavaScript lainnya sehingga server dapat mulai melakukan streaming HTML ke browser sesegera mungkin. Next.js—framework berbasis React—menyediakan banyak praktik terbaik secara default. Selain merender HTML secara otomatis di server, framework ini juga dapat membuat HTML secara statis untuk halaman yang tidak berubah berdasarkan konteks pengguna (seperti autentikasi).
• Vue juga melakukan rendering sisi klien secara default. Namun, seperti React, Vue juga dapat merender HTML komponen Anda di server. Manfaatkan API sisi server ini jika memungkinkan, atau pertimbangkan abstraksi tingkat yang lebih tinggi untuk project Vue Anda agar praktik terbaik lebih mudah diterapkan.
• Svelte merender HTML di server secara default—meskipun jika kode komponen Anda memerlukan akses ke namespace khusus browser (misalnya, window), Anda mungkin tidak dapat merender HTML komponen tersebut di server. Jelajahi pendekatan alternatif jika memungkinkan agar Anda tidak menyebabkan rendering sisi klien yang tidak perlu. SvelteKit—yang untuk Svelte sama seperti Next.js untuk React—menyematkan sebanyak mungkin praktik terbaik ke dalam project Svelte Anda, sehingga Anda dapat menghindari potensi masalah dalam project yang hanya menggunakan Svelte.

Membatasi jumlah node DOM yang dibuat di klien

Jika DOM besar, pemrosesan yang diperlukan untuk merendernya cenderung meningkat. Baik situs Anda adalah SPA yang lengkap, atau menyisipkan node baru ke DOM yang ada sebagai hasil interaksi untuk MPA, pertimbangkan untuk menjaga DOM tersebut sekecil mungkin. Tindakan ini akan membantu mengurangi pekerjaan yang diperlukan selama rendering sisi klien untuk menampilkan HTML tersebut, sehingga diharapkan dapat menjaga INP situs Anda tetap rendah.

Mempertimbangkan arsitektur pekerja layanan streaming

Ini adalah teknik lanjutan—yang mungkin tidak mudah diterapkan untuk setiap kasus penggunaan—tetapi teknik ini dapat mengubah MPA Anda menjadi situs yang terasa dimuat secara instan saat pengguna berpindah dari satu halaman ke halaman berikutnya. Anda dapat menggunakan pekerja layanan untuk melakukan pra-cache bagian statis situs Anda di CacheStorage sambil menggunakan ReadableStream API untuk mengambil HTML halaman lainnya dari server.

Jika Anda berhasil menggunakan teknik ini, Anda tidak membuat HTML di klien, tetapi pemuatan sebagian konten secara instan dari cache akan memberikan kesan bahwa situs Anda dimuat dengan cepat. Situs yang menggunakan pendekatan ini dapat terasa hampir seperti SPA, tetapi tanpa kekurangan rendering sisi klien. Hal ini juga mengurangi jumlah HTML yang Anda minta dari server.

Singkatnya, arsitektur pekerja layanan streaming tidak menggantikan logika navigasi bawaan browser, tetapi menambahkannya. Untuk mengetahui informasi selengkapnya tentang cara mencapainya dengan Workbox, baca Aplikasi multi-halaman yang lebih cepat dengan aliran.

Kesimpulan

Cara situs Anda menerima dan merender HTML akan memengaruhi performa. Saat Anda mengandalkan server untuk mengirim semua (atau sebagian besar) HTML yang diperlukan agar situs Anda berfungsi, Anda akan mendapatkan banyak hal secara gratis: parsing dan rendering inkremental, serta penyerahan otomatis ke thread utama untuk menghindari tugas yang panjang.

Rendering HTML sisi klien menimbulkan sejumlah potensi masalah performa yang dalam banyak kasus dapat dihindari. Namun, karena persyaratan setiap situs, hal ini tidak sepenuhnya dapat dihindari 100% sepanjang waktu. Untuk mengurangi potensi tugas panjang yang dapat terjadi akibat rendering sisi klien yang berlebihan, pastikan Anda mengirimkan sebanyak mungkin HTML situs dari server jika memungkinkan, menjaga ukuran DOM sekecil mungkin untuk HTML yang harus dirender di klien, dan mempertimbangkan arsitektur alternatif untuk mempercepat pengiriman HTML ke klien sekaligus memanfaatkan penguraian dan rendering inkremental yang disediakan browser untuk HTML yang dimuat dari server.

Jika Anda dapat membuat rendering sisi klien situs Anda seminimal mungkin, Anda tidak hanya akan meningkatkan INP situs Anda, tetapi juga metrik lainnya seperti LCP, TBT, dan bahkan TTFB dalam beberapa kasus.

Gambar banner besar dari Unsplash, oleh Maik Jonietz.