Почему не лучше использовать фрагмент документа для повышения производительности при добавлении нескольких элементов в DOM
Прежде всего, это не то же самое, что этот вопрос, хотя вы можете подумать, что это как первый взгляд: Действительно ли использование фрагмента документа повышает производительность?
Смотрите: эта рабочий пример js https://jsperf.com/fragment-no-clone
Если вы создаете кучу новых узлов в цикле с намерением добавить их в DOM, в моем MIND гораздо быстрее сначала создать фрагмент, добавить эти элементы к фрагменту, а затем добавить фрагмент в DOM. после все настроено. (в отличие от создания элемента, добавить в DOM, создать следующий элемент, добавить в DOM один за другим)
Вот немного кода, чтобы проиллюстрировать, что я имею в виду:
Использование фрагмента
let fragment = document.createDocumentFragment();
for (var i = 0; i < 100; i++) {
let element = document.createElement('div');
fragment.appendChild(element);
}
document.body.appendChild(fragment);
Не использовать фрагмент
for (var i = 0; i < 100; i++) {
let element = document.createElement('div');
document.body.appendChild(element);
}
Причина, по которой я думаю, что фрагмент должен быть быстрее, заключается в том, что я понимаю, как работают браузеры: если я просто добавляю элементы один за другим немедленно, тогда браузеру нужно больше рисовать и вычислять, тогда как если я настрою его красиво во фрагменте, а затем добавить все сразу, браузеру нужно только нарисовать / вычислить однажды
ТЕМ НЕ МЕНИЕ.
На самом деле я не вижу такого прироста производительности. При тестировании Chrome / Safari на этой скрипке разница незначительна, и хотя в Firefox есть небольшой прирост в пользу использования фрагмента, ничего особенного.
Так что же происходит под капотом? Мое понимание полностью ошибочно?
@vlaz ооо хорошо, так что, может быть, моя интуиция все-таки верна
я вижу, что НЕ использовать фрагмент быстрее в chrome / safari, но только на крошечный бит, недостаточно, чтобы действительно что-то значить. Они в основном идут рука об руку.
Просто чтобы вы знали - я написал этот комментарий, когда начал читать вопрос. Затем я запустил тест в Chrome и дочитал вопрос. Пришлось немного подождать, так как Chrome еще не закончил. В Chrome разница была довольно небольшой, и хотя второй подход был быстрее, примерно на процент. ОБА были намного медленнее, чем FF, однако - в FF с использованием фрагмента заявленная скорость составляла ~ 450 операций в секунду, при прямом заходе на посадку ~ 200 операций в секунду. В Chrome для сравнения оба были ~ 120-130.
Я думаю, что тест покажет разные результаты для вставляемых сложных узлов DOM - я имею в виду узлы, к которым будут применены стили CSS, которые потенциально могут потребовать повторного размещения элементов в контейнерах, что каждый раз было бы более сложным перекомпоновкой. Фрагмент документа должен минимизировать их влияние.
@vlaz О, действительно хороший момент, о котором я не подумал, спасибо. Это, наверное, ответ. Может попробую составить тест для подтверждения!
На самом деле, я смотрел на тот другой вопрос, который вы упомянули, и заметил кое-что в комментариях к принятому ответу: he jsPerf test here does not incorporate page reflows Я подозревал, что это может быть так - я не думал, что он действительно помещает ваши данные в какую-то отображаемую DOM. Если он находится в чем-то вроде скрытого iframe, он не будет перекомпонован. Так что, возможно, более точным тестом будет создание HTML-страницы и повторное испытание обоих подходов с помощью инструментов измерения производительности разработчика.
DOM - это просто объект js. Таким образом, ваши два теста действительно не должны показывать слишком большой разницы (только до оптимизатора js). Нет, браузеру не нужно ни перерисовывать, ни делать перекомпоновку при каждом изменении в DOM. В лучшем случае они сделают это только один раз (обычно незадолго до следующего обновления экрана). Однако некоторые методы DOM вызывают перекомпоновку, и если вы вызовете один из этих методов в своем цикле, вы увидите огромную разницу.
@Kaiido, спасибо, я просто немного поиграл с ним, и это действительно так. Я знал о том, как некоторые методы вызывают перекомпоновку, но по какой-то причине я подумал, что внесение любых изменений в DOM будет иметь аналогичные побочные эффекты - зачем еще реагировать, используя, например, «теневой дом». Я хотел бы получить подробную разбивку, если кто-то захочет ответить, но я также думаю о том, чтобы просто потратить больше времени на изучение себя и ответ на свой вопрос, ха.
![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)
See: this js fiddle https://jsperf.com/fragment-no-cloneфрагмент документа почти в два раза быстрее для меня в Firefox.