Размер DOM

Обычно разработчики не задумываются о количестве элементов в DOM и используют столько, сколько нужно. А иногда используют сильно больше, чем нужно. На многих проектах в DevTools можно увидеть “ёлочку”:

<div>
  <div>
    <div>
      <div>
        <div>
          <div>
            <div>
              <!-- контент -->  
            </div>
          </div>
        </div>
      </div>
    </div>
  </div>
</div>

Предполагаю, что это происходит из-за ограничений фреймворков, когда у компонента мог быть только один корневой элемент. И, конечно, этим корневым элементом выступал <div>. При глубокой вложенности компонентов появлялась “ёлочка”. В современных версиях фреймворков эти ограничения уже не актуальны, но много проектов написано на старых версиях.

Чем плоха такая “ёлочка” и большое количество элементов в DOM? Тем, что это влияет на производительность. На каждый HTML-элемент браузеры создают объект DOM, у которого большое количество свойств, методов, вложенных объектов и связей с другими объектами. Значения всех свойств и связи нужно просчитать. Также браузеры вычисляют значения всех CSS-свойств и положение на экране для отрисовки. Оптимизация работы с DOM происходит постоянно, поэтому все расчёты происходят очень быстро. Тем не менее, чем больше элементов DOM, тем:

- больше оперативной памяти нужно для хранения объектов
- больше процессорного времени уходит на вычисление свойств, стилей, компоновку и отрисовку
- больше операций происходит при изменении DOM

Поэтому следует избегать “ёлочки” и большого количества элементов в DOM. Google Lighthouse выдаст предупреждение “избегайте чрезмерного размера DOM”, если:

- в документе более 1400 элементов
- есть элементы с глубиной вложенности более 32 уровней
- есть элементы, у которых более 60 дочерних элементов

На эти цифры и стоит опираться. Говоря об общем количестве элементов, стоит придерживаться принципа чем меньше, тем лучше.

Как уменьшить количество элементов:

- фрагменты в React <></>
- виртуализация большого набора данных (отображение только той части списка или таблицы, которая видна на экране)
- разбиение большого количества данных на страницы (пагинация), при этом не более 60 элементов набора данных на страницу
- фильтрация, поиск и группировка большого количества данных для уменьшения выборки
- альтернативные решения вместо бесконечных лент, ленивой дозагрузки и формирования большого набора данных на одной странице
- динамическая генерация интерфейса (модальные окна, тултипы), но осторожно, потому что генерировать сложные интерфейсы на лету тоже не очень производительно
- раскладка контента по областям при помощи CSS Grid вместо дополнительных контейнеров и обёрток
- адаптивный дизайн, чтобы избегать отдельных скрытых частей интерфейса для разных экранов