Memahami jalur kritis

Jalur rendering penting mengacu pada langkah-langkah yang terlibat hingga halaman web mulai dirender di browser. Untuk merender halaman, browser memerlukan dokumen HTML itu sendiri serta semua resource penting yang diperlukan untuk merender dokumen tersebut.

Proses pengiriman dokumen HTML ke browser dibahas oleh Modul pertimbangan performa HTML umum sebelumnya. Namun, dalam modul ini, kita akan melihat lebih banyak apa yang dilakukan browser setelah mendownload dokumen HTML untuk merender halaman.

Rendering progresif

Web didistribusikan secara alami. Tidak seperti aplikasi native yang diinstal sebelum digunakan, browser tidak dapat bergantung pada situs yang memiliki semua resource yang diperlukan untuk merender halaman. Oleh karena itu, browser sangat mahir dalam merender halaman secara progresif. Aplikasi native biasanya memiliki fase penginstalan, lalu fase berjalan. Namun, untuk halaman web dan aplikasi web, batas antara kedua fase ini tidak terlalu berbeda, dan browser telah didesain secara khusus dengan mempertimbangkan hal tersebut.

Jika browser telah memiliki resource untuk merender halaman, browser biasanya akan mulai melakukannya. Pilihannya menjadi sekitar kapan akan merender: kapan waktunya terlalu awal?

Jika browser merender sesegera mungkin ketika hanya memiliki beberapa HTML—tetapi sebelum memiliki CSS atau JavaScript yang diperlukan—halaman tersebut akan terlihat rusak dan berubah sesaat selama render akhir. Ini akan menjadi pengalaman yang lebih buruk dibandingkan pertama kali menampilkan layar kosong untuk sementara waktu hingga browser memiliki lebih banyak resource yang diperlukan untuk render awal yang menawarkan pengalaman pengguna yang lebih baik.

Di sisi lain, jika browser menunggu semua resource tersedia, bukannya melakukan rendering berurutan, pengguna akan menunggu lama; sering kali tidak perlu, jadi jika halaman dapat digunakan pada waktu yang jauh lebih awal.

Browser perlu mengetahui jumlah minimum resource yang harus ditunggu agar tidak menyajikan pengalaman yang jelas-jelas rusak. Di sisi lain, browser juga tidak boleh menunggu lebih lama dari yang diperlukan sebelum menampilkan beberapa konten kepada pengguna. Urutan langkah yang diambil browser sebelum melakukan render awal dikenal sebagai jalur rendering penting.

Memahami jalur rendering penting dapat membantu meningkatkan performa web dengan memastikan Anda tidak memblokir rendering halaman awal lebih dari yang diperlukan. Namun, pada saat yang sama, penting juga untuk tidak mengizinkan rendering terjadi terlalu awal dengan menghapus resource yang diperlukan untuk render awal tersebut dari jalur rendering penting.

Jalur rendering (penting)

Jalur rendering melibatkan langkah-langkah berikut:

  • Membuat Document Object Model (DOM) dari HTML.
  • Membuat CSS Object Model (CSSOM) dari CSS.
  • Menerapkan JavaScript yang mengubah DOM atau WebView.
  • Mengonstruksikan pohon render dari DOM dan WebView.
  • Lakukan operasi gaya dan tata letak pada halaman untuk melihat elemen apa yang sesuai dengan tempatnya.
  • Melukiskan piksel elemen dalam memori.
  • Gabungkan piksel jika ada yang tumpang tindih.
  • Gambar secara fisik semua piksel yang dihasilkan ke layar.
Diagram proses rendering, seperti yang dijelaskan dalam daftar sebelumnya.

Pengguna akan melihat konten di layar hanya setelah semua langkah ini diselesaikan.

Proses rendering ini terjadi beberapa kali. Render awal akan memicu proses ini, tetapi seiring makin banyaknya resource yang memengaruhi rendering halaman, browser akan menjalankan kembali proses ini—atau mungkin hanya sebagian darinya—untuk memperbarui apa yang dilihat pengguna. Jalur rendering penting berfokus pada proses yang sebelumnya diuraikan untuk render awal, dan bergantung pada resource penting yang diperlukan untuknya.

Resource apa yang ada di jalur rendering penting?

Browser harus menunggu beberapa sumber daya penting untuk didownload sebelum dapat menyelesaikan render awal. Referensi ini mencakup:

  • Bagian dari HTML.
  • CSS yang memblokir rendering di elemen <head>.
  • JavaScript yang memblokir rendering di elemen <head>.

Poin pentingnya adalah browser memproses HTML seperti streaming. Begitu browser mendapatkan bagian mana pun dari HTML halaman, browser mulai memprosesnya. Selanjutnya, browser dapat—dan sering kali melakukannya—memutuskan untuk merendernya dengan baik sebelum menerima HTML halaman lainnya.

Yang penting, untuk render awal, browser biasanya tidak akan menunggu:

  • Semua HTML.
  • Font.
  • Gambar.
  • JavaScript yang tidak memblokir rendering di luar elemen <head> (misalnya, elemen <script> yang ditempatkan di akhir HTML).
  • CSS yang tidak memblokir perenderan di luar elemen <head>, atau CSS dengan nilai atribut media yang tidak berlaku untuk area tampilan saat ini.

Font dan gambar sering kali dianggap oleh browser sebagai konten yang harus diisi selama perenderan ulang halaman berikutnya, sehingga tidak perlu menahan rendering awal. Namun, hal ini dapat berarti bahwa area ruang kosong dibiarkan di render awal saat teks disembunyikan menunggu font, atau hingga gambar tersedia. Lebih buruk lagi adalah ketika ruang yang cukup tidak disediakan untuk jenis konten tertentu—terutama ketika dimensi gambar tidak disediakan dalam HTML—tata letak halaman dapat bergeser ketika konten ini dimuat nanti. Aspek pengalaman pengguna ini diukur dengan metrik Pergeseran Tata Letak Kumulatif (CLS).

Elemen <head> merupakan kunci untuk memproses jalur rendering penting. Sehingga bagian berikutnya membahasnya secara mendetail. Mengoptimalkan konten elemen <head> adalah aspek utama performa web. Namun, untuk memahami jalur rendering penting untuk saat ini, Anda hanya perlu mengetahui bahwa elemen <head> berisi metadata tentang halaman dan resource-nya, tetapi tidak ada konten sebenarnya yang dapat dilihat pengguna. Konten yang terlihat dimuat dalam elemen <body> yang mengikuti elemen <head>. Sebelum browser dapat merender konten apa pun, browser perlu merender konten serta metadata tentang cara merendernya.

Namun, tidak semua resource yang direferensikan dalam elemen <head> benar-benar diperlukan untuk render halaman awal, sehingga browser hanya menunggu resource yang diperlukan. Untuk mengidentifikasi resource mana yang berada di jalur rendering penting, Anda perlu memahami CSS dan JavaScript yang memblokir perenderan dan pemblokir parser.

Resource yang memblokir rendering

Beberapa resource dianggap sangat penting sehingga browser menjeda rendering halaman hingga ditangani. CSS masuk ke dalam kategori ini secara {i>default<i}.

Saat browser melihat CSS—baik itu CSS inline dalam elemen <style>, atau resource eksternal yang direferensikan dan ditentukan oleh elemen <link rel=stylesheet href="...">—browser akan menghindari rendering konten lagi sampai selesai mendownload dan memproses CSS tersebut.

Hanya karena rendering blok resource, bukan berarti resource tersebut menghentikan browser untuk melakukan hal lain. Browser berupaya untuk seefisien mungkin. Jadi, saat browser merasa perlu mendownload resource CSS, browser akan memintanya dan menjeda rendering, namun akan tetap melakukan pemrosesan sisa HTML dan mencari pekerjaan lain untuk dilakukan pada saat yang sama.

Resource yang memblokir rendering, seperti CSS, digunakan untuk memblokir semua rendering halaman saat ditemukan. Artinya, apakah beberapa CSS memblokir perenderan atau tidak bergantung pada apakah browser telah menemukannya. Beberapa browser (awalnya Firefox, dan sekarang juga Chrome) hanya memblokir rendering konten di bawah resource yang memblokir rendering. Artinya, untuk jalur pemblokir render yang penting, kami biasanya tertarik dengan resource yang memblokir rendering di <head>, karena resource tersebut secara efektif memblokir rendering seluruh halaman.

Inovasi yang lebih baru adalah atribut blocking=render, yang ditambahkan ke Chrome 105. Hal ini memungkinkan developer untuk secara eksplisit menandai elemen <link>, <script>, atau <style> sebagai pemblokir rendering hingga elemen diproses, tetapi tetap mengizinkan parser untuk terus memproses dokumen.

Resource yang memblokir parser

Resource pemblokir parser adalah resource yang mencegah browser mencari pekerjaan lain dengan terus mengurai HTML. JavaScript secara default adalah pemblokiran parser (kecuali jika secara khusus ditandai sebagai asinkron atau ditangguhkan), karena JavaScript dapat mengubah DOM atau Memorystore setelah eksekusinya. Oleh karena itu, browser tidak mungkin melanjutkan pemrosesan resource lain sebelum mengetahui dampak penuh dari JavaScript yang diminta pada HTML halaman. Oleh karena itu, JavaScript sinkron akan memblokir parser.

Resource yang memblokir parser juga memblokir perenderan secara efektif. Karena tidak dapat melanjutkan resource yang memblokir penguraian hingga diproses sepenuhnya, parser tidak dapat mengakses dan merender konten setelahnya. Browser dapat merender HTML apa pun yang diterima sejauh ini selagi menunggu, tetapi jika terkait jalur rendering penting, setiap resource pemblokir parser di <head> berarti semua konten halaman diblokir agar tidak dirender.

Pemblokiran parser dapat menimbulkan biaya performa yang sangat besar—lebih dari sekadar memblokir rendering. Karena alasan ini, browser akan mencoba mengurangi biaya ini dengan menggunakan parser HTML sekunder yang dikenal sebagai pemindai pramuat untuk mendownload resource mendatang saat parser HTML utama diblokir. Meskipun tidak sebaik mengurai HTML, cara ini setidaknya memungkinkan fungsi jaringan di browser bekerja sebelum parser yang diblokir, yang berarti tidak akan diblokir lagi di masa mendatang.

Mengidentifikasi resource pemblokiran

Banyak alat audit performa mengidentifikasi resource yang memblokir render dan parser. WebPageTest menandai resource yang memblokir rendering dengan lingkaran oranye di sebelah kiri URL resource:

Screenshot diagram waterfall jaringan yang dibuat oleh WebPageTest. Resource pemblokir parser ditandai dengan lingkaran oranye di sebelah kiri URL resource, dan waktu mulai render diidentifikasi dengan garis hijau tua solid.

Semua resource yang memblokir rendering harus didownload dan diproses sebelum rendering dapat dimulai, yang ditandai dengan garis hijau tua solid di waterfall.

Lighthouse juga menyoroti resource yang memblokir render, tetapi dengan cara yang lebih halus, dan hanya jika resource benar-benar menunda rendering halaman. Hal ini dapat membantu untuk menghindari positif palsu (PP) jika Anda seharusnya meminimalkan pemblokiran render. Menjalankan URL halaman yang sama seperti gambar WebPageTest sebelumnya melalui Lighthouse hanya mengidentifikasi salah satu stylesheet sebagai resource yang memblokir rendering.

Screenshot audit Lighthouse untuk menghilangkan resource yang memblokir render. Audit menunjukkan resource yang memblokir rendering, dan durasi waktu pemblokirannya.

Mengoptimalkan jalur rendering penting

Pengoptimalan jalur rendering penting mencakup pengurangan waktu untuk menerima HTML (yang diwakili oleh metrik Time to First Byte (TTFB)) seperti yang dijelaskan dalam modul sebelumnya, dan pengurangan dampak resource yang memblokir render. Konsep ini dibahas dalam modul berikutnya.

Jalur rendering konten penting

Sejak lama, jalur rendering penting hanya berhubungan dengan render awal. Namun, lebih banyak metrik yang berfokus pada pengguna untuk performa web telah muncul, yang menimbulkan pertanyaan apakah titik akhir jalur rendering penting harus menjadi gambar pertama, atau salah satu dari gambar yang lebih konten yang menyusul setelahnya.

Tampilan alternatifnya adalah berkonsentrasi pada waktu hingga Largest Contentful Paint (LCP)—atau bahkan First Contentful Paint (FCP)—sebagai bagian dari jalur rendering yang konten (atau jalur kunci seperti yang mungkin dipanggil orang lain). Dalam hal ini, Anda mungkin perlu menyertakan resource yang tidak selalu memblokir—seperti yang telah menjadi definisi umum jalur rendering penting—tetapi diperlukan untuk merender contentful paint.

Terlepas dari definisi pastinya yang Anda definisikan sebagai "penting", memahami apa yang menahan render awal dan konten utama Anda adalah hal yang penting. Paint pertama mengukur peluang pertama yang memungkinkan untuk merender apa pun bagi pengguna. Idealnya, ini harus sesuatu yang bermakna—bukan sesuatu seperti warna latar belakang—tetapi meskipun tidak memuaskan, tetap ada nilai dalam menyajikan sesuatu kepada pengguna, yang merupakan argumen untuk mengukur jalur rendering penting seperti yang telah didefinisikan secara tradisional. Pada saat yang sama, pengukuran saat konten utama ditampilkan kepada pengguna juga penting.

Mengidentifikasi jalur rendering contentful

Banyak alat yang dapat mengidentifikasi elemen LCP dan kapan mereka melakukan rendering. Selain elemen LCP, Lighthouse juga akan membantu mengidentifikasi fase LCP dan waktu yang dihabiskan dalam setiap fase guna membantu Anda memahami tempat terbaik untuk memfokuskan upaya pengoptimalan:

Screenshot audit LCP Lighthouse, yang menunjukkan elemen LCP halaman dan jumlah waktu yang dihabiskan dalam beberapa fase seperti TTFB, penundaan pemuatan, waktu pemuatan, dan penundaan render.

Untuk situs yang lebih kompleks, Lighthouse juga menandai rantai permintaan penting dalam audit terpisah:

Screenshot diagram rantai permintaan penting Lighthouse, yang menunjukkan resource penting mana yang disusun bertingkat di bawah resource penting lainnya, serta total latensi yang terlibat dalam rantai permintaan penting.

Audit Lighthouse ini mengamati semua resource yang dimuat dengan prioritas tinggi, sehingga menyertakan font web dan konten lain yang ditetapkan Chrome sebagai resource prioritas tinggi, meskipun sebenarnya resource tersebut tidak memblokir perenderan.

Menguji pengetahuan Anda

Apa yang dimaksud dengan jalur rendering kritis?

Jumlah minimum resource yang diperlukan untuk merender halaman sepenuhnya.
Coba lagi.
Jumlah minimum resource yang diperlukan untuk melakukan render halaman awal.
Benar.

Resource apa yang terlibat dalam jalur rendering penting?

Bagian dari HTML.
Benar.
CSS yang memblokir rendering di elemen <head>.
Benar.
JavaScript yang memblokir rendering di elemen <head>.
Benar.

Mengapa pemblokiran render merupakan bagian penting dari rendering halaman?

Untuk mencegah halaman awalnya dirender dalam kondisi tidak dapat digunakan atau tampak rusak.
Benar.
Untuk mencegah pengguna melihat halaman hingga halaman dirender sepenuhnya.
Coba lagi.

Mengapa JavaScript memblokir parser HTML (dengan asumsi atribut defer, async, atau module tidak ditentukan pada elemen <script>)?

Tanpa setidaknya satu dari atribut tersebut, <script> akan memblokir parser dan memblokir render.
Benar.
Semua JavaScript memblokir parser, terlepas dari atribut tersebut.
Coba lagi.
JavaScript sinkron harus dieksekusi saat parser mencapainya karena dapat mengubah DOM.
Benar.

Berikutnya: Mengoptimalkan pemuatan resource

Modul ini membahas beberapa teori di balik cara browser merender halaman web, dan khususnya apa yang diperlukan untuk menyelesaikan rendering awal halaman. Modul berikutnya membahas cara mengoptimalkan jalur rendering ini dengan mempelajari cara mengoptimalkan pemuatan resource.