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 имеет более 1 400 узлов, и сообщение с рекомендацией:"Избегайте чрезмерного размера DOM".
В зависимости от содержания и структуры каждой анализируемой страницы вы найдете больше или меньше подсказок о том, какие элементы можно атаковать. Преимуществом является то, что обычно на экране появляется изображение, указывающее на нужный элемент.
Еще раз хочу напомнить, что все эти предупреждения - лишь рекомендации, и не стоит паниковать или зацикливаться на этих показателях. Есть страницы, которые предлагают хороший пользовательский опыт и хорошую воспринимаемую скорость при низких показателях PageSpeed.
С GTmetrix мы получим те же результаты в DOM.
Однако здесь очень полезен график "водопада" запросов, позволяющий с первого взгляда увидеть все элементы, отсортированные по типу и времени, которое требуется для их загрузки.
Но самый простой и быстрый способ - через любой браузер. Откройте анализируемую страницу, щелкните правой кнопкой мыши / "осмотреть", и на вкладке "Сеть" вы найдете гораздо более подробный водопад , потому что вы можете завершить его, прокрутив страницу, и все файлы, которые она содержит, будут добавлены. Затем вы можете отсортировать их по весу, типу, времени и т. д.
Под этим окном вы найдете сводку результатов. Слева - количество запросов. Справа синим цветом показано время события DOMContentLoaded, а красным - время загрузки страницы.
Уменьшите размер DOM с помощью "Ленивых элементов" от Perfmatters.
Perfmatters, этот незаменимый плагин, который я не устаю рекомендовать, добавил в свою версию 2.3.3 от 28 августа 2024 года опцию под названием Lazy Elements, которая, хотя и находится в бета-версии, работает очень хорошо, облегчая задачу по облегчению DOM.
Эта функция позволяет добавить неправильно названную"Ленивую загрузку" к определенным элементам и их потомкам (дочерним элементам) путем добавления любой части строки атрибутов (class="example") родительского контейнера.
В документации, предоставленной Perfmatters по этой новой функциональности, нас предупреждают, что не стоит пытаться применять "Ленивую загрузку" к элементам, которые находятся выше сгиба. То есть к тому, что загружается на экране и является первым, что видит пользователь, не прокручивая страницу вниз.
Далее отмечается, что если вы видите, что что-то визуально нарушено, убедитесь, что вы использовали уникальную строку на странице, которая не используется совместно с другими элементами.
Как и в случае с медленно загружающимися изображениями, содержимое помещается внутрь . Это означает, что все, что загружается с задержкой, технически все еще доступно для просмотра и индексации Google. Однако они не могут с уверенностью сказать, как Google будет относиться к элементам с Lazy Load в строке. Поэтому с точки зрения SEO они рекомендуют сначала протестировать.
Он также предупреждает, что не следует пытаться применить Lazy Load к элементам, содержащим изображения, которые запускают "лайтбокс". Так оно и есть, я смог убедиться, что родная функция WordPress lightbox перестает работать, когда в список добавляется класс элемента, который ее реализует.
В остальном "Ленивые элементы" работают отлично. Благодаря этой функции я сэкономил много времени на прореживании DOM с хорошими результатами. Надеюсь, Perfmatters продолжит свое развитие, чтобы улучшить и расширить свои возможности.
