Ukuran DOM yang besar memiliki lebih banyak pengaruh terhadap interaktivitas daripada yang Anda perkirakan. Panduan ini menjelaskan alasannya dan tindakan yang dapat Anda lakukan.
Tidak ada solusi lain: saat Anda membangun halaman web, halaman tersebut akan memiliki Document Object Model (DOM). DOM merepresentasikan struktur HTML halaman Anda, dan memberi JavaScript serta CSS akses ke struktur dan konten halaman.
Namun, masalahnya adalah ukuran DOM memengaruhi kemampuan browser untuk merender halaman dengan cepat dan efisien. Secara umum, semakin besar DOM, semakin mahal untuk merender halaman tersebut terlebih dahulu dan memperbarui renderingnya nanti di siklus proses halaman.
Hal ini akan bermasalah di halaman dengan DOM yang sangat besar jika interaksi yang mengubah atau memperbarui DOM memicu pekerjaan tata letak yang mahal dan memengaruhi kemampuan halaman untuk merespons dengan cepat. Pekerjaan tata letak yang mahal dapat memengaruhi Interaction to Next Paint (INP) halaman; Jika Anda ingin halaman merespons interaksi pengguna dengan cepat, sebaiknya pastikan ukuran DOM Anda hanya sebesar yang diperlukan.
Kapan DOM halaman terlalu besar?
Menurut Lighthouse, ukuran DOM halaman berlebihan jika melebihi 1.400 node. Lighthouse akan mulai menampilkan peringatan saat DOM halaman melebihi 800 node. Ambil contoh HTML berikut:
<ul>
<li>List item one.</li>
<li>List item two.</li>
<li>List item three.</li>
</ul>
Dalam kode di atas, ada empat elemen DOM: elemen <ul>
, dan tiga elemen turunan <li>
-nya. Halaman web Anda hampir pasti akan memiliki lebih banyak node dari ini, jadi penting untuk memahami apa yang dapat Anda lakukan untuk menjaga ukuran DOM tetap terkendali—serta strategi lain untuk mengoptimalkan pekerjaan rendering setelah Anda mendapatkan DOM halaman sekecil mungkin.
Bagaimana pengaruh DOM besar terhadap performa halaman?
DOM besar memengaruhi performa halaman dalam beberapa cara:
- Selama render awal halaman. Saat CSS diterapkan ke halaman, struktur yang mirip dengan DOM yang dikenal sebagai CSS Object Model (CSSOM) akan dibuat. Seiring dengan peningkatan kekhususan CSS, GCLID menjadi lebih kompleks, dan diperlukan lebih banyak waktu untuk menjalankan pekerjaan tata letak, penataan gaya, pengomposisian, dan penggambaran yang diperlukan untuk menggambar laman web ke layar. Pekerjaan tambahan ini meningkatkan latensi interaksi untuk interaksi yang terjadi di awal selama pemuatan halaman.
- Saat interaksi memodifikasi DOM, baik melalui penyisipan atau penghapusan elemen, maupun dengan memodifikasi konten dan gaya DOM, pekerjaan yang diperlukan untuk merender pembaruan tersebut bisa mengakibatkan pekerjaan tata letak, penataan gaya, pengomposisian, dan penggambaran yang sangat mahal. Seperti halnya dengan render awal halaman, peningkatan kekhususan pemilih CSS bisa ditambahkan ke pekerjaan rendering saat elemen HTML disisipkan ke dalam DOM sebagai hasil dari interaksi.
- Saat JavaScript melakukan kueri DOM, referensi ke elemen DOM disimpan di memori. Misalnya, jika Anda memanggil
document.querySelectorAll
untuk memilih semua elemen<div>
di halaman, biaya memori bisa cukup besar jika hasilnya menampilkan sejumlah besar elemen DOM.
![Screenshot tugas panjang yang disebabkan oleh pekerjaan rendering yang berlebihan di panel performa Chrome DevTools. Stack panggilan tugas yang panjang menunjukkan waktu yang signifikan yang dihabiskan untuk menghitung ulang gaya halaman, serta pra-lukis.](https://web.dev/static/articles/dom-size-and-interactivity/image/a-screenshot-a-long-task-a768ec4a643a9.png?authuser=19&hl=id)
Semua ini dapat memengaruhi interaktivitas, tetapi item kedua dalam daftar di atas sangat penting. Jika interaksi menghasilkan perubahan pada DOM, interaksi tersebut dapat memulai banyak pekerjaan yang dapat menyebabkan INP yang buruk di halaman.
Bagaimana cara mengukur ukuran DOM?
Anda dapat mengukur ukuran DOM dengan beberapa cara. Metode pertama menggunakan Lighthouse. Saat Anda menjalankan audit, statistik di DOM halaman saat ini akan berada di bagian "Hindari ukuran DOM yang berlebihan" di bagian "Diagnostik" {i>heading<i}. Di bagian ini, Anda dapat melihat jumlah total elemen DOM, elemen DOM yang berisi elemen turunan terbanyak, serta elemen DOM terdalam.
Metode yang lebih sederhana melibatkan penggunaan konsol JavaScript di alat developer pada browser utama mana pun. Untuk mendapatkan jumlah total elemen HTML di DOM, Anda dapat menggunakan kode berikut di konsol setelah halaman dimuat:
document.querySelectorAll('*').length;
Jika ingin melihat pembaruan ukuran DOM secara realtime, Anda juga dapat menggunakan alat pemantau performa. Dengan menggunakan alat ini, Anda bisa menghubungkan operasi tata letak dan gaya (serta aspek kinerja lainnya) bersama ukuran DOM saat ini.
![Screenshot pemantau performa di Chrome DevTools. Di sebelah kiri, ada berbagai aspek performa halaman yang dapat terus dipantau selama masa aktif halaman. Pada screenshot, jumlah node DOM, tata letak per detik, dan penghitungan ulang gaya per bagian sedang dipantau secara aktif.](https://web.dev/static/articles/dom-size-and-interactivity/image/a-screenshot-the-perform-d46dd7f32a5de.png?authuser=19&hl=id)
Jika ukuran DOM mendekati ambang batas ukuran DOM Lighthouse—atau gagal sama sekali—langkah berikutnya adalah mencari tahu cara mengurangi ukuran DOM untuk meningkatkan kemampuan halaman Anda merespons interaksi pengguna sehingga INP situs web Anda dapat meningkat.
Bagaimana cara mengukur jumlah elemen DOM yang dipengaruhi oleh interaksi?
Jika memprofilkan interaksi lambat di lab yang Anda duga ada hubungannya dengan ukuran DOM halaman, Anda bisa mengetahui jumlah elemen DOM yang terpengaruh dengan memilih aktivitas apa pun di profiler yang berlabel "ReCalculate Style" dan mengamati data kontekstual di panel bawah.
![Screenshot aktivitas penghitungan ulang gaya yang dipilih di panel performa Chrome DevTools. Di bagian atas, jalur interaksi menunjukkan interaksi klik, dan sebagian besar pekerjaan dihabiskan untuk melakukan penghitungan ulang gaya dan pekerjaan pra-penggambaran. Di bagian bawah, panel menampilkan detail selengkapnya untuk aktivitas yang dipilih, yang melaporkan bahwa 2.547 elemen DOM terpengaruh.](https://web.dev/static/articles/dom-size-and-interactivity/image/a-screenshot-selected-st-9a6c0cc217aa3.png?authuser=19&hl=id)
Pada screenshot di atas, amati bahwa penghitungan ulang gaya suatu pekerjaan—saat dipilih—menampilkan jumlah elemen yang terpengaruh. Meskipun screenshot di atas menunjukkan kasus ekstrem mengenai efek ukuran DOM terhadap pekerjaan rendering di halaman yang berisi banyak elemen DOM, info diagnostik ini berguna dalam kasus apa pun untuk menentukan apakah ukuran DOM merupakan faktor pembatas dalam waktu yang diperlukan oleh frame berikutnya untuk menggambar sebagai respons terhadap suatu interaksi.
Bagaimana cara mengurangi ukuran DOM?
Selain mengaudit HTML situs untuk mencari markup yang tidak perlu, cara utama untuk mengurangi ukuran DOM adalah mengurangi kedalaman DOM. Salah satu sinyal bahwa DOM Anda mungkin terlalu dalam adalah jika Anda melihat markup yang terlihat seperti ini di tab Elements pada alat developer browser Anda:
<div>
<div>
<div>
<div>
<!-- Contents -->
</div>
</div>
</div>
</div>
Saat melihat pola seperti ini, Anda mungkin dapat menyederhanakannya dengan meratakan struktur DOM Anda. Melakukan hal itu akan mengurangi jumlah elemen DOM, dan mungkin memberi Anda kesempatan untuk menyederhanakan gaya halaman.
Kedalaman DOM mungkin juga merupakan gejala framework yang Anda gunakan. Secara khusus, framework berbasis komponen—seperti framework yang mengandalkan JSX—mengharuskan Anda menyusun bertingkat beberapa komponen di container induk.
Namun, banyak framework memungkinkan Anda menghindari penyusunan bertingkat menggunakan apa yang dikenal sebagai fragmen. Framework berbasis komponen yang menawarkan fragmen sebagai fitur mencakup (tetapi tidak terbatas pada) hal berikut:
Dengan menggunakan fragmen dalam framework pilihan Anda, Anda dapat mengurangi kedalaman DOM. Jika khawatir dengan dampak perataan struktur DOM terhadap gaya, Anda dapat memanfaatkan mode tata letak yang lebih modern (dan lebih cepat) seperti flexbox atau grid.
Strategi lain yang dapat dipertimbangkan
Walaupun Anda bersusah payah meratakan hierarki DOM dan menghapus elemen HTML yang tidak perlu untuk menjaga DOM sekecil mungkin, namun tetap bisa cukup besar dan memulai banyak pekerjaan rendering karena perubahannya sebagai respons terhadap interaksi pengguna. Jika Anda berada di posisi ini, ada beberapa strategi lain yang dapat Anda pertimbangkan untuk membatasi pekerjaan rendering.
Pertimbangkan pendekatan tambahan
Anda mungkin berada dalam posisi dengan sebagian besar halaman Anda awalnya tidak terlihat oleh pengguna saat pertama kali dirender. Hal ini dapat menjadi peluang untuk memuat HTML secara lambat dengan menghilangkan bagian DOM tersebut saat memulai, tetapi tambahkan saat pengguna berinteraksi dengan bagian halaman yang memerlukan aspek halaman yang awalnya tersembunyi.
Pendekatan ini bermanfaat baik selama pemuatan awal maupun bahkan mungkin setelahnya. Untuk pemuatan halaman awal, Anda akan melakukan lebih sedikit pekerjaan rendering di awal, yang berarti bahwa payload HTML awal Anda akan lebih ringan dan akan dirender lebih cepat. Hal ini akan memberikan lebih banyak peluang bagi interaksi selama periode penting tersebut untuk dijalankan dengan lebih sedikit persaingan untuk mendapatkan perhatian thread utama.
Jika Anda memiliki banyak bagian halaman yang awalnya tersembunyi saat dimuat, hal ini juga dapat mempercepat interaksi lain yang memicu pekerjaan rendering ulang. Namun, seiring bertambahnya interaksi lain ke DOM, pekerjaan rendering akan meningkat seiring pertumbuhan DOM di sepanjang siklus proses halaman.
Menambahkan DOM dari waktu ke waktu bisa menjadi hal yang rumit, dan ada konsekuensinya sendiri. Jika Anda menggunakan rute ini, Anda mungkin membuat permintaan jaringan guna mendapatkan data untuk mengisi HTML yang ingin Anda tambahkan ke halaman sebagai respons terhadap interaksi pengguna. Meskipun permintaan jaringan yang sedang berlangsung tidak diperhitungkan dalam INP, hal ini dapat meningkatkan latensi yang dirasakan. Jika memungkinkan, tampilkan indikator lingkaran berputar pemuatan atau indikator lain bahwa data sedang diambil sehingga pengguna memahami bahwa sesuatu sedang terjadi.
Membatasi kompleksitas pemilih CSS
Saat browser mengurai pemilih di CSS, browser harus menelusuri hierarki DOM untuk memahami bagaimana—dan apakah—pemilih tersebut diterapkan pada tata letak saat ini. Semakin kompleks pemilih ini, semakin banyak pekerjaan yang harus dilakukan browser untuk melakukan rendering awal halaman, serta peningkatan penghitungan ulang gaya dan tata letak kerja jika halaman berubah sebagai akibat dari interaksi.
Menggunakan properti content-visibility
CSS menawarkan properti content-visibility
, yang secara efektif merupakan cara untuk merender elemen DOM luar layar dengan lambat. Saat elemen mendekati area pandang, elemen akan dirender sesuai permintaan. Manfaat content-visibility
tidak hanya memotong sejumlah besar pekerjaan rendering pada render halaman awal, tetapi juga melewati pekerjaan rendering untuk elemen di luar layar saat DOM halaman diubah sebagai hasil dari interaksi pengguna.
Kesimpulan
Mengurangi ukuran DOM Anda hanya pada hal-hal yang benar-benar diperlukan adalah cara yang baik untuk mengoptimalkan INP situs Anda. Dengan melakukan hal ini, Anda bisa mengurangi jumlah waktu yang diperlukan browser untuk melakukan pekerjaan layout dan rendering saat DOM diperbarui. Meskipun Anda tidak dapat mengurangi ukuran DOM secara signifikan, ada beberapa teknik yang dapat Anda gunakan untuk mengisolasi pekerjaan rendering ke subhierarki DOM, seperti pembatasan CSS dan properti CSS content-visibility
.
Bagaimanapun Anda melakukannya, menciptakan lingkungan di mana pekerjaan rendering diminimalkan—serta mengurangi jumlah pekerjaan rendering yang dilakukan halaman Anda sebagai respons terhadap interaksi—hasilnya adalah bahwa situs web Anda akan terasa lebih responsif terhadap pengguna saat mereka berinteraksi dengan mereka. Artinya, Anda akan memiliki INP yang lebih rendah untuk situs Anda, dan hal ini berarti memberikan pengalaman pengguna yang lebih baik.
Banner besar dari Unsplash, oleh Louis Reed.