DOM (Document Object Model) adalah antarmuka pemrograman untuk dokumen HTML dan XML dan nama yang diberikan pada struktur dokumen HTML, yang terdiri dari cabang dan simpul yang berisi objek.
Sejarah Model Objek Dokumen berawal dari apa yang disebut"perang peramban" pada akhir tahun 1990-an antara Netscape Navigator dan Microsoft Internet Explorer, serta JavaScript dan JScript, bahasa skrip pertama yang diimplementasikan secara luas di mesin JavaScript pada peramban web.
Struktur DOM di WordPress: pohon, cabang, dan node
DOM di WordPress tidak jauh berbeda dengan situs web lainnya.
<html> <-- Árbol (nodo raíz)
│
├── <head> <-- Rama
│ ├── <title> <-- Nodo (hoja)
│ └── <meta> <-- Nodo (hoja)
│
└── <body> <-- Rama
├── <header> <-- Rama
│ └── <h1> <-- Nodo (hoja)
│
├── <div> <-- Rama
│ ├── <p> <-- Nodo (interno)
│ └── <img> <-- Nodo (hoja)
│
└── <footer> <-- Rama
└── <a> <-- Nodo (hoja)
- Pohon: Seluruh halaman direpresentasikan sebagai pohon dengan simpul akar
(<html>)
dan elemen-elemen turunannya. - Cabang: Setiap elemen dalam
<div>,
<header>,
<footer>, dsb.,
merepresentasikan sebuah cabang pohon. - Node: Semua elemen HTML, seperti
<p>,
<img
>,
atau<a>,
adalah node yang menggantung pada cabang. Node ini dapat bersifat internal (berisi node lain) atau eksternal ("daun" dari pohon yang tidak memiliki anak).
Dengan demikian, kepadatan cabang akan bergantung pada jenis dan jumlah elemen yang menyusunnya. Sebagai contoh, menu navigasi yang kompleks di WordPress dapat menghasilkan beberapa tingkat cabang dan puluhan node karena jumlah tautan dan submenu.
Anda bisa menganggap node sebagai semua elemen HTML pada sebuah halaman. Semakin banyak elemen yang Anda miliki, biasanya semakin lama waktu yang dibutuhkan, yang mengarah ke Total Block Time(TBT) yang lebih tinggi.
Ini bisa menjadi hal yang sulit untuk dioptimalkan di WordPress, karena Anda tidak bisa begitu saja menghapus elemen DOM yang membentuk struktur halaman. Namun, kita bisa menampilkan elemen-elemen ini secara selektif dan memuat serangkaian objek di bawah lipatan, sehingga mengurangi ukuran DOM secara keseluruhan.
Mengapa mengurangi ukuran DOM?
Pohon DOM yang besar dapat memperlambat waktu muat situs Anda dalam beberapa cara, meningkatkan penggunaan memori dengan menyebabkan perhitungan gaya yang lebih lama dan lebih lambat, serta mengeluarkan biaya data yang tidak perlu bagi pengguna.
Skenario yang berbeda ini dapat mencakup pemuatan node yang tidak perlu yang tidak terlihat saat pengguna pertama kali memuat halaman, pengulangan posisi node dan penghitungan gaya secara konstan, dan penyimpanan jumlah referensi yang berlebihan ke node yang membebani memori perangkat pengguna.
Manfaat jangka pendek dan jangka panjang dari mengoptimalkan kecepatan muat halaman telah dijelaskan dalam seribu satu artikel. Singkatnya, dalam jangka pendek Anda menghindari orang-orang meninggalkan situs Anda karena bosan menunggu dan kemungkinan besar mereka akan menghabiskan lebih banyak waktu di sana. Kecepatan memuat adalah salah satu faktor yang diakui oleh Google dalam penentuan posisi SEO dan saya memahami bahwa hal ini juga berlaku untuk mesin pencari lainnya, sehingga dalam jangka panjang lalu lintas organik yang berharga akan meningkat.
Apa yang menyebabkan ukuran DOM bertambah besar?
Ukuran akhir DOM dipengaruhi oleh banyak faktor seperti templat itu sendiri, berbagai plugin yang Anda gunakan, dan jenis konten yang Anda tambahkan, seperti blok yang rumit atau "penggeser" gambar yang jahat, dan lain-lain. Juga kode yang dihasilkan misalnya oleh apa yang disebut "Pembangun".
Misalnya, hingga tahun 2022, tahun di mana saya meninggalkan Elementor karena menolak pengoptimalan dan jarang sekali tidak merusak sesuatu di hampir setiap pembaruan, ditambah beberapa pengalaman buruk dengan dukungan teknis mereka, pembangun ini mengubah kode web menjadi sup alfabet yang nyata dan mimpi buruk dengan ribuan
Pada bulan April di tahun yang sama, Elementor memasukkan "Wadah" Flexbox sebagai hal yang sangat baru dan revolusioner, ketika wadah tersebut telah menjadi dasar GenerateBlocks selama bertahun-tahun.
Bagaimana cara mengukur DOM?
Untuk pengukuran, saya telah memilih tiang yang belum terlalu dioptimalkan, agak panjang dan dengan jenis elemen yang berbeda.
Mari kita mulai dengan yang paling terkenal dan paling populer: PageSpeed Insights . Google menandai di sana sebagai peringatan(berwarna oranye) ketika elemen tubuh memiliki lebih dari 800 node dan sebagai peringatan kesalahan(berwarna merah) ketika elemen tubuh memiliki lebih dari 1.400 node dan pesan dengan rekomendasi ini:"Hindari ukuran DOM yang berlebihan".
Tergantung pada konten dan struktur setiap halaman yang Anda analisis, Anda akan menemukan lebih banyak atau lebih sedikit petunjuk tentang elemen mana yang dapat Anda serang. Keuntungannya adalah biasanya menunjukkan gambar yang menunjuk ke elemen yang dimaksud.
Sekali lagi, saya ingin mengingatkan Anda bahwa semua peringatan ini hanyalah rekomendasi dan Anda tidak perlu panik atau terobsesi dengan metrik ini. Ada beberapa halaman yang menawarkan pengalaman pengguna yang baik dan kecepatan yang dirasakan baik dengan skor PageSpeed yang rendah.
Dengan GTmetrix, kita umumnya akan mendapatkan hasil yang sama pada DOM.
Namun, di sini grafik "air terjun" permintaannya sangat berguna untuk memeriksa sekilas semua item yang diurutkan berdasarkan jenis dan waktu yang dibutuhkan untuk memuat.
Tetapi cara termudah dan tercepat adalah melalui peramban apa pun. Buka halaman yang akan dianalisis dan klik kanan / "periksa" dan di tab "Jaringan" Anda akan menemukan air terjun yang jauh lebih rinci karena Anda dapat menyelesaikannya dengan menggulir halaman dan semua file yang dikandungnya akan ditambahkan. Anda kemudian dapat mengurutkannya berdasarkan berat, jenis, waktu, dll.
Di bawah jendela ini Anda akan menemukan ringkasan hasilnya. Di sebelah kiri, jumlah permintaan. Di sebelah kanan, dengan warna biru, waktu kejadian DOMContentLoaded dan warna merah waktu pemuatan halaman tersebut.
Kurangi ukuran DOM dengan "Elemen Malas" dari Perfmatters.
Perfmatters, plugin penting yang tidak pernah bosan saya rekomendasikan, menambahkan dalam versi 2 . 3.3 tanggal 28 Agustus 2024 sebuah opsi yang disebut Lazy Elements yang, meskipun masih dalam versi Beta, bekerja dengan sangat baik untuk memfasilitasi tugas meringankan DOM.
Fungsi ini memungkinkan penambahan"Lazy Load" yang salah nama ke elemen tertentu dan turunannya (anak) dengan menambahkan satu bagian dari string atribut ("contoh") dari wadah induk.
Dalam dokumentasi yang disediakan oleh Perfmatters mengenai fungsionalitas baru ini, kita diperingatkan untuk tidak mencoba menerapkan "Lazy Load" ke elemen yang berada di atas lipatan. Yaitu, apa yang dimuat di layar dan hal pertama yang dilihat pengguna tanpa menggulir ke bawah.
Lebih lanjut dicatat bahwa jika Anda melihat ada sesuatu yang rusak secara visual, pastikan bahwa Anda telah menggunakan string unik pada halaman yang tidak dibagikan dengan elemen lain.
Seperti halnya gambar yang dimuat secara lambat, konten ditempatkan di dalam file . Ini berarti bahwa apa pun yang dimuat dengan lambat secara teknis masih dapat dirayapi dan diindeks oleh Google. Namun, mereka tidak dapat memastikan bagaimana Google akan memperlakukan elemen dengan Lazy Load dalam sebuah string. Jadi mereka merekomendasikan, dalam hal SEO, untuk mengujinya terlebih dahulu.
Ini juga memperingatkan untuk tidak mencoba menerapkan Lazy Load pada elemen yang berisi gambar yang memulai "lightbox". Dan begitulah, saya telah dapat memverifikasi bahwa fungsi lightbox WordPress asli berhenti bekerja ketika kelas elemen yang mengimplementasikannya ditambahkan ke dalam daftar.
Kalau tidak, "Lazy Elements" bekerja dengan sempurna. Berkat fitur ini, saya telah menghemat banyak waktu untuk menipiskan DOM dengan hasil yang bagus. Saya berharap Perfmatters akan melanjutkan pengembangannya untuk meningkatkan dan memperluas opsinya.
Artikel terkait