Performa rendering

Pengguna akan menyadari jika situs dan aplikasi tidak berjalan dengan baik, sehingga mengoptimalkan performa rendering sangatlah penting.

Pengguna web saat ini mengharapkan halaman yang mereka kunjungi akan interaktif dan lancar, dan di situlah Anda perlu semakin memfokuskan waktu dan upaya Anda. Halaman tidak hanya harus dimuat dengan cepat, tetapi juga merespons input pengguna dengan cepat di seluruh siklus prosesnya. Faktanya, aspek pengalaman pengguna ini adalah hal yang diukur oleh metrik Interaction to Next Paint (INP). INP yang baik berarti halaman secara konsisten dan andal merespons kebutuhan pengguna.

Meskipun komponen utama yang membuat halaman terasa cepat melibatkan jumlah JavaScript yang Anda jalankan sebagai respons terhadap interaksi pengguna, yang diantisipasi pengguna adalah perubahan visual pada antarmuka pengguna. Perubahan visual pada antarmuka pengguna adalah hasil dari beberapa jenis pekerjaan, yang sering disebut secara kolektif sebagai rendering, dan pekerjaan ini harus dilakukan secepat mungkin agar pengalaman pengguna terasa cepat dan andal.

Untuk menulis halaman yang merespons interaksi pengguna dengan cepat, Anda perlu memahami cara HTML, JavaScript, dan CSS ditangani oleh browser, serta memastikan bahwa kode yang Anda tulis—dan kode pihak ketiga lainnya yang Anda sertakan—berjalan seefisien mungkin.

Catatan tentang kecepatan refresh perangkat

Sebagian besar perangkat saat ini me-refresh layarnya 60 kali per detik. Setiap refresh menghasilkan output visual yang Anda lihat, dan umumnya dikenal sebagai frame. Dalam video berikut, konsep frame ditunjukkan:

Meskipun layar perangkat selalu di-refresh dengan kecepatan yang konsisten, aplikasi yang berjalan di perangkat mungkin tidak selalu dapat menghasilkan frame yang cukup untuk menyesuaikan kecepatan refresh tersebut. Misalnya, jika ada animasi atau transisi yang berjalan, browser harus mencocokkan kecepatan refresh perangkat untuk menghasilkan satu frame setiap kali layar di-refresh.

Mengingat bahwa tampilan standar diperbarui 60 kali per detik, penghitungan cepat akan menunjukkan bahwa browser memiliki waktu 16,66 milidetik untuk menghasilkan setiap frame. Namun, pada kenyataannya, browser memiliki overhead-nya sendiri untuk setiap frame, sehingga semua pekerjaan Anda harus diselesaikan dalam waktu 10 milidetik. Jika Anda gagal memenuhi anggaran ini, kecepatan frame akan turun, dan konten halaman akan bergetar di layar. Fenomena ini sering disebut jank.

Namun, target Anda berubah berdasarkan jenis pekerjaan yang Anda coba lakukan. Memenuhi batas 10 milidetik sangat penting untuk animasi, di mana objek di layar diinterpolasi di seluruh rangkaian frame di antara dua titik. Terkait perubahan terpisah pada antarmuka pengguna—yaitu, beralih dari satu status ke status lain tanpa gerakan di antaranya—sebaiknya Anda melakukan perubahan tersebut dalam jangka waktu yang terasa instan bagi pengguna. Dalam kasus seperti ini, 100 milidetik adalah angka yang sering dikutip, tetapi nilai minimum "baik" metrik INP adalah 200 milidetik atau lebih rendah untuk mengakomodasi lebih banyak perangkat dengan berbagai kemampuan.

Apa pun sasaran Anda—baik menghasilkan banyak frame yang diperlukan animasi untuk menghindari jank, atau sekadar menghasilkan perubahan visual yang terpisah di antarmuka pengguna secepat mungkin—memahami cara kerja pipeline piksel browser sangat penting untuk pekerjaan Anda.

Pipeline piksel

Ada lima area utama yang perlu Anda ketahui dan perhatikan dalam pekerjaan Anda sebagai developer web. Kelima area ini adalah area yang paling dapat Anda kontrol, dan masing-masing mewakili poin penting dalam pipeline piksel ke layar:

• JavaScript: JavaScript biasanya digunakan untuk menangani pekerjaan yang akan menghasilkan perubahan visual pada antarmuka pengguna. Misalnya, ini bisa berupa fungsi animate jQuery, mengurutkan set data, atau menambahkan elemen DOM ke halaman. Namun, JavaScript tidak mutlak diperlukan untuk memicu perubahan visual: animasi CSS, transisi CSS, dan Web Animations API mampu menganimasikan konten halaman.
• Penghitungan gaya: Ini adalah proses untuk mencari tahu aturan CSS mana yang berlaku untuk elemen HTML mana berdasarkan pemilih yang cocok. Misalnya, .headline adalah contoh pemilih CSS yang berlaku untuk elemen HTML apa pun dengan nilai atribut class yang berisi class headline. Dari sana, setelah aturan diketahui, aturan tersebut akan diterapkan, dan gaya akhir untuk setiap elemen akan dihitung.
• Tata letak: Setelah browser mengetahui aturan yang berlaku untuk suatu elemen, browser dapat mulai menghitung geometri halaman, seperti seberapa besar ruang yang digunakan elemen, dan tempat elemen tersebut muncul di layar. Model tata letak web berarti bahwa satu elemen dapat memengaruhi elemen lainnya. Misalnya, lebar elemen <body> biasanya memengaruhi dimensi elemen turunannya di seluruh hierarki, sehingga prosesnya bisa cukup rumit bagi browser.
• Paint: Painting adalah proses pengisian piksel. Proses ini melibatkan penggambaran teks, warna, gambar, batas, bayangan, dan pada dasarnya setiap aspek visual elemen setelah tata letaknya di halaman dihitung. Gambar biasanya dibuat di beberapa permukaan, yang sering disebut lapisan.
• Komposit: Karena bagian halaman berpotensi digambar ke beberapa lapisan, bagian tersebut perlu diterapkan ke layar dalam urutan yang benar agar halaman dirender seperti yang diharapkan. Hal ini sangat penting untuk elemen yang tumpang-tindih dengan elemen lain, karena kesalahan dapat menyebabkan satu elemen muncul di atas elemen lain secara tidak benar.

Setiap bagian dari pipeline piksel ini merupakan peluang untuk menimbulkan jank dalam animasi, atau menunda penggambaran frame bahkan untuk perubahan visual yang terpisah pada antarmuka pengguna. Oleh karena itu, penting untuk memahami dengan tepat bagian pipeline mana yang dipicu oleh kode Anda, dan menyelidiki apakah Anda dapat membatasi perubahan hanya pada bagian pipeline piksel yang diperlukan untuk merendernya.

Anda mungkin pernah mendengar istilah "rasterisasi" yang digunakan bersama dengan "gambar". Hal ini karena mengecat sebenarnya terdiri dari dua tugas:

1. Membuat daftar panggilan gambar.
2. Mengisi piksel.

Yang terakhir disebut "rasterisasi", jadi setiap kali Anda melihat data paint di DevTools, Anda harus menganggapnya sebagai termasuk rasterisasi. Dalam beberapa arsitektur, pembuatan daftar panggilan gambar dan rasterisasi dilakukan pada thread yang berbeda, tetapi hal itu tidak berada di bawah kendali Anda sebagai developer.

Anda tidak selalu harus menyentuh setiap bagian pipeline di setiap frame. Faktanya, ada tiga cara pipeline biasanya berjalan untuk frame tertentu saat Anda membuat perubahan visual, baik dengan JavaScript, CSS, atau Web Animations API.

1. JS/CSS > Gaya > Tata Letak > Paint > Komposit

Jika Anda mengubah properti "tata letak", seperti properti yang mengubah geometri elemen seperti lebar, tinggi, atau posisinya (seperti properti CSS left atau top), browser perlu memeriksa semua elemen lainnya dan "membuat ulang" halaman. Setiap area yang terpengaruh perlu dicat ulang, dan elemen akhir yang dicat perlu digabungkan kembali.

2. JS/CSS > Gaya > Paint > Komposit

Jika Anda mengubah properti "khusus gambar" untuk elemen di CSS—misalnya, properti seperti background-image, color, atau box-shadow—langkah tata letak tidak diperlukan untuk menerapkan update visual ke halaman. Dengan menghilangkan langkah tata letak—jika memungkinkan—Anda menghindari pekerjaan tata letak yang berpotensi mahal dan dapat menyebabkan latensi signifikan dalam menghasilkan frame berikutnya.

3. JS/CSS > Gaya > Komposit

Jika Anda mengubah properti yang tidak memerlukan tata letak atau paint, browser dapat langsung beralih ke langkah penggabungan. Ini adalah jalur termurah dan paling diinginkan melalui pipeline piksel untuk titik tekanan tinggi dalam siklus proses halaman, seperti animasi atau scroll. Fakta menarik: Chromium mengoptimalkan scrolling halaman sehingga hanya terjadi di thread compositor jika memungkinkan, yang berarti bahwa meskipun halaman tidak merespons, Anda masih dapat men-scroll halaman dan melihat bagian-bagiannya yang sebelumnya digambar ke layar.

Performa web adalah seni menghindari pekerjaan, sekaligus meningkatkan efisiensi pekerjaan yang diperlukan sebanyak mungkin. Dalam banyak kasus, ini adalah tentang bekerja dengan browser, bukan melawannya. Perlu diingat bahwa pekerjaan yang sebelumnya ditampilkan dalam pipeline berbeda dalam hal biaya komputasi; beberapa tugas pada dasarnya lebih mahal daripada yang lain.

Mari kita bahas berbagai bagian pipeline. Kita akan melihat masalah umum, serta cara mendiagnosis dan memperbaikinya.

Pengoptimalan rendering browser

Performa penting bagi pengguna, dan untuk membangun pengalaman pengguna yang baik, developer web perlu membangun situs yang bereaksi cepat terhadap interaksi pengguna dan merender dengan lancar. Pakar performa Paul Lewis hadir untuk membantu Anda menghilangkan jank dan membuat aplikasi web yang mempertahankan performa 60 frame per detik. Anda akan menyelesaikan kursus ini dengan alat yang diperlukan untuk membuat profil aplikasi, dan mengidentifikasi penyebab performa rendering yang kurang optimal. Anda juga akan mempelajari pipeline rendering browser dan menemukan pola yang memudahkan pembuatan situs cepat yang akan disukai pengguna.

Kursus ini gratis dan ditawarkan melalui Udacity, dan Anda dapat mengikutinya kapan saja.