Performa rendering

Pengguna akan melihat jika situs dan aplikasi tidak berjalan dengan baik, sehingga pengoptimalan kinerja rendering sangatlah penting!

Pengguna web saat ini mengharapkan bahwa laman yang mereka kunjungi akan interaktif dan lancar, dan di situlah Anda perlu lebih memfokuskan waktu dan usaha. Halaman tidak hanya dimuat dengan cepat, tetapi juga merespons input pengguna dengan cepat di sepanjang siklus hidupnya. Bahkan, aspek pengalaman pengguna ini persis seperti yang diukur metrik Interaction to Next Paint (INP). Bagus INP berarti halaman responsif secara konsisten dan andal terhadap mereka.

Meskipun komponen utama yang membuat laman terasa ringkas melibatkan jumlah JavaScript yang Anda jalankan sebagai respons terhadap interaksi pengguna, apa yang adalah perubahan visual pada antarmuka pengguna. Perubahan visual pada pengguna antarmuka adalah hasil dari beberapa jenis pekerjaan, sering kali secara kolektif disebut sebagai rendering, dan pekerjaan ini harus terjadi secepat mungkin sehingga pengalaman pengguna terasa cepat dan dapat diandalkan.

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

Catatan tentang kecepatan refresh perangkat

Sebagian besar perangkat saat ini memuat ulang layar 60 kali per detik. Setiap pembaruan menghasilkan output visual yang Anda lihat, dan umumnya dikenal sebagai bingkai. Di kolom video berikut, konsep {i>frame<i} didemonstrasikan:

Meskipun layar perangkat selalu diperbarui dengan kecepatan konsisten, aplikasi yang yang berjalan di perangkat mungkin tidak selalu dapat menghasilkan cukup {i>frame<i} untuk cocok dengan kecepatan refresh. Misalnya, jika ada animasi atau transisi berjalan, browser harus mencocokkan kecepatan refresh perangkat untuk menghasilkan setiap kali layar dimuat ulang.

Mengingat bahwa tampilan biasa diperbarui 60 kali per detik, beberapa perhitungan cepat akan mengungkapkan bahwa browser memiliki waktu 16,66 milidetik untuk menghasilkan setiap {i>frame<i}. Pada kenyataannya, browser memiliki {i>overhead<i} sendiri untuk setiap {i>frame<i}, sehingga semua pekerjaan Anda harus diselesaikan dalam waktu 10 milidetik. Ketika Anda gagal untuk memenuhi anggaran ini, kecepatan frame turun, dan konten halaman bergoyang di layar. Ini fenomena ini sering disebut jank.

Namun, target Anda berubah berdasarkan jenis pekerjaan yang Anda coba lakukan. Memenuhi ambang batas 10 milidetik sangat penting untuk animasi, ketika di layar diinterpolasikan ke serangkaian {i>frame<i} antara dua poin. Ketika menyangkut perubahan terpisah dalam antarmuka pengguna—yaitu, bergerak dari satu keadaan ke keadaan lain tanpa gerakan di antaranya—itu sebaiknya Anda melakukan perubahan tersebut dalam jangka waktu yang terasa instan untuk pengguna. Dalam kasus seperti ini, 100 milidetik adalah angka yang sering dikutip, tetapi metrik INP "bagus" 200 milidetik atau lebih rendah untuk mengakomodasi lebih banyak perangkat dengan kemampuan yang beragam.

Apa pun tujuan Anda—apakah mereka menghasilkan banyak {i>frame<i} yang dianimasikan diperlukan untuk menghindari jank, atau hanya menghasilkan perubahan visual diskrit antarmuka pengguna secepat mungkin—memahami cara piksel browser {i>pipelines<i} sangat penting untuk pekerjaan Anda.

Pipeline piksel

Ada lima bidang utama yang perlu Anda ketahui dan perhatikan dalam bekerja sebagai pengembang web. Kelima area ini adalah yang paling Anda kuasai dikontrol, dan masing-masing mewakili poin kunci dalam pipeline piksel ke layar:

• JavaScript: JavaScript biasanya digunakan untuk menangani tugas yang akan menghasilkan dalam perubahan visual pada antarmuka pengguna. Misalnya, bisa jadi ini adalah animate, mengurutkan set data, atau menambahkan elemen DOM ke halaman. Meskipun demikian, JavaScript tidak sepenuhnya diperlukan untuk memicu perubahan visual: CSS animasi, transisi CSS, dan Web Animations API dapat menganimasikan konten halaman.
• Penghitungan gaya: Ini adalah proses mencari tahu aturan CSS mana berlaku untuk elemen HTML mana berdasarkan pemilih kecocokan. Misalnya, .headline adalah contoh pemilih CSS yang berlaku untuk semua elemen HTML dengan nilai atribut class yang berisi class headline. Dari di sana, setelah aturan diketahui, aturan tersebut akan diterapkan, dan gaya akhir untuk elemen dihitung.
• Tata letak: Setelah browser mengetahui aturan mana yang berlaku untuk elemen, browser dapat mulai menghitung geometri halaman, seperti berapa banyak elemen ruang mengambil, dan di mana mereka muncul di layar. Model tata letak web berarti bahwa satu elemen dapat mempengaruhi elemen lain. Misalnya, lebar <body> biasanya memengaruhi dimensi elemen turunannya sampai ke atas dan ke bawah, sehingga proses itu bisa sangat merepotkan browser.
• Menggambar: Pengecatan adalah proses pengisian piksel. Model ini melibatkan gambar teks, warna, gambar, batas, bayangan, dan pada dasarnya setiap visualisasi aspek elemen setelah tata letaknya pada laman dihitung. Gambar biasanya dilakukan pada beberapa permukaan, sering disebut {i>layer<i}.
• Komposit: Karena bagian halaman berpotensi tersusun ke atas beberapa lapisan, mereka harus diterapkan ke layar dalam urutan yang benar sehingga halaman dirender seperti yang diharapkan. Hal ini sangat penting untuk elemen yang tumpang tindih dengan yang lain, karena kesalahan dapat mengakibatkan satu elemen muncul dari atas yang lain secara tidak benar.

Masing-masing bagian dari pipeline piksel ini mewakili peluang untuk memperkenalkan jank dalam animasi, atau menunda pengecatan bingkai bahkan untuk visual diskret perubahan pada antarmuka pengguna. Oleh karena itu, penting untuk memahami dengan tepat bagian pipeline mana yang terpicu oleh kode Anda, dan menyelidiki apakah Anda membatasi perubahan hanya pada bagian pipeline piksel yang diperlukan merendernya.

Anda mungkin pernah mendengar istilah "rasterisasi" digunakan bersama dengan "{i>Paint<i}". Ini adalah karena menggambar sebenarnya adalah dua tugas:

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

Yang kedua disebut "rasterisasi", jadi setiap kali Anda melihat catatan cat di DevTools, Anda harus menganggapnya termasuk rasterisasi. Di beberapa arsitektur, pembuatan daftar panggilan gambar, dan raster dilakukan pada {i>thread<i} yang berbeda, tapi itu tidak berada di bawah kendali Anda sebagai developer.

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

1. JS / CSS > Gaya > Tata letak > Cat > Campuran

Jika Anda mengubah "tata letak" seperti properti yang mengubah geometri seperti lebar, tinggi, atau posisinya (seperti CSS left atau top ), browser harus memeriksa semua elemen lain dan "mengubah posisi/geometri" tindakan kami. Area yang terkena dampak harus dicat ulang, dan lapisan akhir perlu disusun kembali bersama-sama.

2. JS / CSS > Gaya > Cat > Campuran

Jika Anda mengubah "hanya cat" untuk elemen di CSS—misalnya, properti seperti background-image, color, atau box-shadow—langkah tata letak tidak diperlukan untuk melakukan pembaruan visual pada halaman. Dengan menghilangkan tata letak — jika memungkinkan—Anda menghindari pekerjaan tata letak yang berpotensi mahal yang dapat sebaliknya, berkontribusi pada latensi yang signifikan dalam menghasilkan {i>frame<i} berikutnya.

3. JS / CSS > Gaya > Campuran

Jika Anda mengubah properti yang tidak memerlukan tata letak atau penggambaran, browser bisa langsung menuju ke langkah komposisi. Ini adalah yang termurah jalur yang diinginkan melalui pipeline piksel untuk titik tekanan tinggi dalam siklus proses halaman Anda, seperti animasi atau scroll. Fakta yang menarik: Chromium dioptimalkan men-scroll halaman sehingga hal ini hanya terjadi di thread compositor di mana mungkin, artinya meskipun halaman tidak merespons, Anda masih dapat men-scroll halaman dan melihat bagian yang sebelumnya digambar ke layar.

Performa web adalah seni untuk menghindari pekerjaan, sekaligus meningkatkan efisiensi dari pekerjaan yang diperlukan sebisa mungkin. Dalam banyak kasus, ini tentang bekerja dengan browser, bukan melawannya. Perlu diingat bahwa upaya yang sebelumnya ditampilkan di pipeline berbeda dalam hal biaya komputasi; beberapa tugas secara inheren lebih mahal daripada yang lain!

Mari kita pelajari lebih dalam berbagai bagian pipeline. Kami akan memeriksanya 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 web yang bereaksi cepat terhadap interaksi pengguna dan dengan lancar. Pakar performa Paul Lewis siap membantu Anda menghancurkan jank dan membuat aplikasi web yang mempertahankan kinerja 60 frame per detik. Anda akan keluar materi ini dengan alat yang Anda perlukan untuk membuat profil aplikasi, dan mengidentifikasi penyebab performa rendering yang kurang optimal. Anda juga akan mempelajari proses rendering browser pipeline dan mengungkap pola yang memudahkan untuk membangun {i>website<i} cepat yang menyenangkan untuk digunakan oleh pengguna.

Ini adalah kursus gratis yang ditawarkan melalui Udacity dan Anda dapat mengikutinya kapan saja.