Сколько HTML-элементов могут "современные" браузеры "обрабатывать" сразу?

Ответ 1

Ваш ответ: 1 или миллионы. Я собираюсь скопировать/вставить ответ из аналогичного вопроса в SO.

Если честно, если вам действительно нужен абсолютный ответ на этот вопрос, тогда вам, возможно, захочется пересмотреть свой дизайн.

Никаких ответов, приведенных здесь, не будет правильным, так как это зависит от многих факторов, характерных для вашего приложения. Например. тяжелый или маленький Использование CSS, размер разделов, количество фактической визуализации графики требуется для каждого div, целевого браузера/платформы, количества событий DOM слушателей и т.д.

Просто потому, что вы можете это не значит, что вам нужно!:-) "

Посмотрите: сколько у вас может быть div, прежде чем dom замедляется и становится неустойчивым?

Это действительно неопровержимый вопрос, при котором слишком много факторов на слишком многих углах. Я скажу это, однако, при загрузке одной страницы я использовал javascript setinterval в 1 мс, чтобы постоянно добавлять новые divs на страницу с индексом, увеличивающимся на 1. Мой браузер Chrome просто прошел 20 000 и использует 600MB Ram.

Ответ 2

Это вопрос, для которого только статистически разумный ответ может быть точным и всеобъемлющим.

Почему

Соответствующим уравнением является это: где N - количество узлов, байты _N - это суммарные байты, необходимые для представления их в DOM, диапазон индексов node - n ∈ [0, N), bytesOverhead - это объем памяти, используемый для node с абсолютной минимальной конфигурацией атрибута и innerHTML, а bytesContent - это объем памяти, используемый для заполнения такого минимального node.

bytes _N= Σ ^N (bytesContent _n + bytesOverhead _n)

Значение, заданное в вопросе, - это максимальное значение N в наихудшем карманном устройстве, операционной системе, браузере и условиях работы. Решение для N для каждой перестановки не является тривиальным. Уравнение выше показывает три зависимости, каждая из которых может кардинально изменить ответ.

Зависимости

• Средний размер node зависит от среднего количества байтов, используемых в каждом для хранения содержимого, например текста UTF-8, имен атрибутов и значений или кешированной информации.
• Средние накладные расходы объекта DOM зависят от пользовательского агента HTTP, который управляет представлением DOM каждого документа. W3C Часто задаваемые вопросы по объектной модели документа:" Хотя все реализации DOM должны быть совместимы, они могут значительно различаться в размере кода, требовании памяти и производительность отдельных операций.
• Память, доступная для использования в представлениях DOM, зависит от используемого браузера по умолчанию (который может варьироваться в зависимости от того, какие браузеры или пользователи предпочитают карманные устройства), переопределение пользователя браузера по умолчанию, версия операционной системы, объем памяти карманного устройства, общие фоновые задачи и другое потребление памяти.

Строгое решение

Можно было выполнить тесты для определения (1) и (2) для каждого из общих HTTP-агентов, используемых на карманных устройствах. Распределение пользовательских агентов для любого данного сайта можно получить, настроив механизм ведения журнала веб-сервера, чтобы поместить HTTP_USER_AGENT, если он по умолчанию отсутствует, а затем удаляет все, кроме этого поля в журнале, и подсчитывает экземпляры каждого значения.

Количество байтов на символ должно быть проверено как для значений атрибутов, так и для внутреннего текста UTF-8 (или любого другого), чтобы получить четкую пару факторов для вычисления (1).

Доступная память также нуждается в тестировании в самых разных условиях, что само по себе является крупным исследовательским проектом.

Особое значение выбранного N должно быть ZERO для обработки наихудшего случая, поэтому можно было бы выбрать определенный процент типичных случаев контента, структур node и условий времени выполнения. Например, можно взять образец случаев, используя некоторую форму рандомизированного in situ (в нормальных условиях окружающей среды) исследования и найти N, который удовлетворяет 95% этих случаев.

Возможно, множество случаев может быть проверено указанными способами и результатами, помещенными в таблицу. Это будет прямым ответом на ваш вопрос.

Я предполагаю, что для получения разумных результатов понадобится хорошо образованный программист по мобильному программному обеспечению со вспышкой для математики, особенно статистика, пять полных недель.

Более практическое оценивание

Можно угадать худший сценарий. С несколькими полными днями исследований и несколькими приложениями с доказательством концепции это предложение можно было бы уточнить. Отсутствие времени для этого, здесь хорошая первая догадка.

Рассмотрим сотовый телефон, который разрешает 1 Гбайт для DOM, потому что нормальные условия эксплуатации используют 3 Гбайта из 4 ГБ для вышеупомянутых целей. Можно предположить, что средний расход памяти для node будет следующим, чтобы получить цифру шарового поля.

• 2 байта на символ для 40 символов внутреннего текста за node
• 2 байта на символ для 4 значений атрибутов по 10 символов
• 1 байт на символ для 4 имен атрибутов по 4 символа
• 160 байт для служебных данных C/С++ node в менее эффективных случаях

В этом случае N _{худший_карт} наихудший наименьший узел,

= 1,024 X 1,024 X 1,024
  / (2 X 40  +  2 X 4 X 10  +  1 X 4 X 4  +  160)

= 3,195,660 . 190,476.

Я бы, однако, не создал документ в браузере с тремя миллионами узлов DOM, если бы его вообще можно было избежать. Рассмотрите возможность использования более распространенной практики ниже.

Общая практика

Лучшее решение - оставаться далеко ниже того, что может быть N _{most_case}, и просто уменьшить общее количество узлов до степени, используя стандартные методы разработки HTTP.

• Уменьшите размер и сложность того, что отображается на любой странице, что также улучшает визуальную и концептуальную четкость.
• Запросить минимальные объемы данных с сервера, отложить контент, который еще не виден с помощью методов оконной обработки, или сбалансировать время отклика с потреблением памяти в хорошо спланированных способах.
• Используйте асинхронные вызовы, чтобы помочь с этим минимализмом.