DOM (Document Object Model) - це інтерфейс програмування для документів HTML і XML, а також назва структури HTML-документа, що складається з гілок і вузлів, які містять об'єкти.
Історія об'єктної моделі документів бере свій початок з так званих"браузерних війн" кінця 1990-х років між Netscape Navigator і Microsoft Internet Explorer, а також JavaScript і JScript, першими мовами сценаріїв, які були широко впроваджені в JavaScript-движках веб-браузерів.
Структура DOM в WordPress: дерево, гілки та вузли
DOM в WordPress не дуже відрізняється від будь-якого іншого веб-сайту.
<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)
- Дерево: Вся сторінка представлена у вигляді дерева з кореневим вузлом
(<html>)та його дочірніми елементами. - Гілки: кожен елемент у
<div>,<header>,<footer>і т.д. представляє гілку дерева. - Вузли: Всі елементи HTML, такі як
<p>,<img>або<a>,є вузлами, які висять на гілках. Ці вузли можуть бути внутрішніми (що містять інші вузли) або зовнішніми ("листя" дерева, які не мають інших дочірніх елементів).
Таким чином, щільність гілок буде залежати від типу та кількості елементів, які її складають. Наприклад, складне навігаційне меню в WordPress може генерувати кілька рівнів гілок і десятки вузлів через кількість посилань і підменю.
Ви можете думати про вузли як про всі HTML-елементи на сторінці. Чим більше елементів, тим більше часу це займає, що призводить до збільшення загального часу виконання блоку(TBT).
Це може бути складним завданням для оптимізації в WordPress, оскільки ви не можете просто видалити елементи DOM, які складають структуру сторінки. Однак ми можемо вибірково відображати ці елементи і завантажувати ряд об'єктів під згином, зменшуючи таким чином загальний розмір DOM.
Навіщо зменшувати розмір DOM?
Громіздке DOM-дерево може сповільнити час завантаження вашого сайту кількома способами, збільшуючи використання пам'яті через довші та повільніші обчислення стилів, а також витрачаючи зайві кошти на передачу даних для користувачів.
Ці різні сценарії можуть включати непотрібне завантаження вузлів, які не видно при першому завантаженні сторінки, постійне повторення обчислень положення і стилю вузлів, а також зберігання надмірної кількості посилань на вузли, що перевантажує пам'ять пристроїв користувачів.
Короткострокові та довгострокові переваги оптимізації швидкості завантаження сторінок вже пояснювалися в тисячі і одній статті. Якщо коротко, то в короткостроковій перспективі ви уникнете того, що люди покинуть ваш сайт, втомившись чекати, і, швидше за все, вони проведуть на ньому більше часу. Швидкість завантаження є одним з факторів, визнаних Google при SEO-позиціонуванні, і я розумію, що для решти пошукових систем це теж так, тому в довгостроковій перспективі дорогоцінний органічний трафік буде збільшуватися.
Що спричиняє збільшення розміру DOM?
На кінцевий розмір DOM впливає багато факторів, таких як сам шаблон, те, що додають різні плагіни, які ви використовуєте, і тип контенту, який ви додаєте, наприклад, складні блоки або огидні "повзунки" зображень і т.д. . Також код, згенерований, наприклад, так званими "Білдерами".
Наприклад, до 2022 року, коли я відмовився від Elementor, тому що він не піддавався оптимізації і рідко коли не ламався майже в кожному оновленні, плюс пара невдалих досвідів з технічною підтримкою, цей конструктор перетворив веб-код на справжній алфавітний суп і кошмар з тисячами помилок .
У квітні того ж року Elementor представив Flexbox "Контейнер" як дуже нову і революційну новинку, коли контейнер вже був основою GenerateBlocks протягом багатьох років.
Як виміряти DOM?
Для вимірювання я вибрав пост, який ще не дуже оптимізований, трохи довгий і з різними типами елементів.
Почнемо з найвідомішого і найпопулярнішого: PageSpeed Insights . Google позначає там як попередження(помаранчевим кольором), коли елемент body має більше 800 вузлів, і як повідомлення про помилку(червоним кольором), коли елемент body має більше 1400 вузлів, а також повідомлення з такою рекомендацією:"Уникайте надмірного розміру DOM".
Залежно від вмісту та структури кожної сторінки, яку ви аналізуєте, ви знайдете більше або менше підказок щодо того, які елементи можна атакувати. Перевага полягає в тому, що зазвичай показується зображення, яке вказує на відповідний елемент.
Ще раз хочу нагадати, що всі ці попередження є лише рекомендаціями, і що не варто панікувати або зациклюватися на цих показниках. Існують сторінки, які пропонують хороший користувацький досвід і хорошу швидкість при низьких показниках PageSpeed.
За допомогою GTmetrix ми, як правило, отримуємо ті ж самі результати на DOM.
Однак тут його "водоспадний" графік запитів дуже корисний, щоб з першого погляду оглянути всі елементи, відсортовані за типом і за часом їхнього завантаження.
Але найпростіший і найшвидший спосіб - через будь-який браузер. Відкрийте сторінку, яку потрібно проаналізувати, клацніть правою кнопкою миші / "оглянути", і на вкладці "Мережа" ви побачите набагато детальніший водоспад , оскільки ви можете заповнити його, прокручуючи сторінку, і всі файли, які вона містить, будуть додані. Потім ви можете відсортувати їх за вагою, типом, часом тощо.
Під цим вікном ви знайдете зведення результатів. Зліва - кількість запитів. Праворуч, синім кольором - час події DOMContentLoaded, а червоним - час завантаження цієї сторінки.
Зменшіть розмір DOM за допомогою "Lazy Elements" від Perfmatters.
Perfmatters, цей важливий плагін , який я не втомлююся рекомендувати, додав у своїй версії 2.3.3 від 28 серпня 2024 року опцію під назвою Lazy Elements, яка, хоча він все ще знаходиться в бета-версії, дійсно добре працює для полегшення завдання полегшення DOM.
Ця функція дозволяє додавати неправильно назване"ліниве завантаження" до певних елементів та їхніх нащадків (дочірніх елементів) шляхом додавання будь-якої частини рядка атрибутів (class="example") батьківського контейнера.
У документації, наданій Perfmatters щодо цього нового функціоналу, нас попереджають , що не варто намагатися застосувати "Lazy Load" до елементів, які знаходяться над згином. Тобто те, що завантажується на екран і перше, що бачить користувач без прокрутки вниз.
Далі зазначається, що якщо ви бачите, що щось візуально зламано, переконайтеся, що ви використовували унікальний рядок на сторінці, який не є спільним з іншими елементами.
Як і у випадку з повільно завантажуваними зображеннями, вміст розміщується всередині файлу . Це означає, що все, що завантажується ліниво, все ще технічно доступне для сканування та індексації Google. Однак вони не можуть сказати напевно, як Google буде ставитися до елементів з Lazy Load в рядку. Тому вони рекомендують, з точки зору SEO, спочатку протестувати.
Він також попереджає, що не варто намагатися застосувати Lazy Load до елементів, що містять зображення, які запускають "лайтбокс". Так і є, я зміг переконатися, що рідна функція лайтбоксу WordPress перестає працювати, коли клас елемента, який її реалізує, додається до списку.
В іншому випадку "Ліниві елементи" працюють чудово. Завдяки цій функції я заощадила багато часу на проріджуванні DOM з хорошими результатами. Я сподіваюся, що Perfmatters продовжить свій розвиток, щоб покращити та розширити свої можливості.
