Есть ли предел на число элементов HTML, тот браузер может отобразиться без проблем?
В основном у меня есть огромная таблица, которая становится еще больше, поскольку пользователь прокручивает вниз (автоматические предварительно загружающие последующие строки). В какой-то момент браузер становится вялым, он начинает зависать на мгновение, поскольку я нажимаю вокруг или пытаюсь прокрутить и более вялый, это становится, больше строк, которые это получает. Интересно, существует ли предел на число элементов, которое может содержать страница? Или возможно это - просто мой JavaScript, просачивающийся где-нибудь (хотя у меня есть только один обработчик событий, присоединенный к tbody таблицы - и сценарий, который анализирует, пузырился события mouseDown).
Обновление: Задержка становится примечательной после тысячи загруженных строк. Скорость самой прокрутки довольно терпима, но например выделение нажатой строки (с помощью единственного обработчика событий на tbody) является болезненным (требуется по крайней мере 2-3 секунды, и задержка растет с количеством строк). Я наблюдаю задержку относительно всех браузеров. Это не только я, но и почти все, кто посещает страницу, таким образом, я предполагаю некоторую степень, это влияет на каждую платформу.
Обновление: Я придумал простой пример здесь: http://client.infinity-8.me/table.php?num=1000 (можно передать любое число, которое Вы хотите к цифре), в основном это представляет таблицу с цифровыми строками и присоединило единственный обработчик событий к родительской таблице. Я должен заключить из этого, что на самом деле существует не примечательно выпадающий в производительности, вызванной числом дочерних элементов. Таким образом, это - вероятно, утечка где-то в другом месте :(
11 ответов
Я не думаю, что существует ограничение, определенное стандартом. Возможно, существует предел, жестко закодированный в каждой реализации браузера, хотя я бы предположил, что этот предел, скорее всего, будет составлять миллиарды элементов. Другим ограничением является объем адресуемой памяти.
Для решения вашей проблемы: Помимо автоматической загрузки элементов по мере прокрутки вниз, вы могли бы автоматически выгружать те, которые прокрутились вверх за пределы экрана. Тогда ваша программа будет оставаться быстрой даже после многократной прокрутки.
Возможно, вы также захотите рассмотреть альтернативный интерфейс, такой как пейджинг.
Еще одна вещь, на которую вы должны обратить внимание, - это размер таблицы. Если для вашей таблицы используется стиль table-width: auto; , браузер должен измерить каждый отдельный элемент в таблице, чтобы определить его размер. Это может стать безумно медленным.
Вместо этого выберите фиксированную ширину или, по крайней мере, задайте стиль таблицы, используя table-width: fixed .
Если у вас есть JS в каждой строке таблицы, то старые компьютеры не справятся с этим. Что касается самого HTML, то вам не стоит особо беспокоиться.
Вы должны беспокоиться о том, что нормальный человек не любит большие таблицы, для этого и создана пагинация. Разделите их с помощью пагинации для лучшего удобства использования и других проблем.
Подумайте о книге, в которой нет страниц, а есть одна большая страница, хотели бы вы ее читать? Даже если ваши глаза (в нашем случае компьютер) справятся с этим.
Какой браузер вы используете? Некоторые браузеры могут обрабатывать вещи лучше, чем другие - например, если вы используете IE, я не удивлюсь, если он вялый - он не обрабатывает события javascript так же, как браузеры на основе webkit.
Другое дело, очевидно, ваш компьютер (RAM и CPU). Но, честно говоря, у большинства компьютеров не должно быть проблем с этим, если только мы не говорим о более чем 10000 строках ... и даже тогда ...
Вы можете опубликовать какой-нибудь код?
Учитывая, что существует множество браузеров и механизмов рендеринга, и все они имеют разные характеристики производительности, а также учитывая, что эти механизмы постоянно улучшаются в отношении производительности, а компьютерное оборудование все время становится быстрее: Нет не существует фиксированного верхнего предела, с которым может справиться браузер. Однако существуют текущие верхние ограничения на конкретное оборудование для определенных версий браузеров.
Если вы не укажете больше, какое у вас оборудование и браузер, вам будет сложно помочь. Кроме того, никто не может сделать никаких предположений относительно возможной производительности вашего Javascript, если вы не разместите код. Даже если это всего лишь один обработчик событий, если он зацикливается бесконечно или вызывается для каждого элемента, это может значительно замедлить процесс рендеринга.
В мире действительно нет причин для публикации всего огромного набора данных на одной странице. Если требуется предоставить пользователю все эти данные, вы должны экспортировать их в файл, который может быть прочитан каким-нибудь более совершенным программным обеспечением, чем браузер.
Вместо этого я предлагаю вам создать страницу, управляемую AJAX, где вы позволяете пользователю видеть часть данных, и если им нужно увидеть больше, вы просто загрузите эту часть набора данных и замените текущий набор данных на страница. Это разбивка на страницы. Поиск Google - отличный тому пример.
Если есть какие-то ограничения, то это зависит от браузера. Но у вас проблема не в ограничениях, так как браузер все равно отображает страницу.
Большие таблицы всегда являются проблемой для браузеров. Рендеринг большой таблицы занимает много времени. Поэтому часто хорошей идеей является разделение большой таблицы на более мелкие таблицы.
Далее, вы, вероятно, захотите указать ширину столбцов. Без этого браузеру придется загрузить всю таблицу, прежде чем он сможет рассчитать ширину каждого столбца и отобразить таблицу. Если указать ширину в HTML-коде, браузер сможет отобразить страницу, пока она еще загружается. (Примечание: недостаточно указать ширину всей таблицы, необходимо указать ширину каждого столбца).
Если вы добавите одну строку в большую таблицу с помощью Javascript, браузеру, скорее всего, придется снова отображать всю таблицу. Именно поэтому она становится такой медленной. Если у вас есть маленькие таблицы, только одна маленькая таблица должна быть отображена снова. Еще лучше, если вы загружаете по одной подтаблице за раз, а не только одну строку.
Но самый эффективный метод - разбить данные на несколько страниц. Пользователи, вероятно, тоже предпочитают это. Вот почему, например, Google выводит на каждой странице только такое количество результатов.
Я не думаю, что существует ограничение. Однако, чем длиннее HTML-файл, тем больше ресурсов потребуется вашему компьютеру. Но тогда таблица должна быть очень большой...
Предел действительно определяется пользовательским агентом и используемой клиентской машиной. HTML, так же как и XML, является древовидным форматом данных. Поэтому чем больше элементов, тем дальше по дереву приходится искать браузеру клиента, чтобы отобразить страницу.
У меня были проблемы с добавлением более 100 таблиц в div (как старое обходное решение для IE6, который не мог динамически создавать элементы таблиц).
Не обращайте внимания на использование ОЗУ или ЦП, каков фактический размер файла после предварительной загрузки?
Если ваша таблица действительно настолько огромна, вы могли бы заставить своих пользователей загружать мегабайты данных - я обнаружил, что некоторые машины имеют тенденцию зависать после 2-4 МБ данных.
Зависит. IE, например, не начнет рендеринг таблицы, пока не будет загружено все содержимое. Итак, если у вас была таблица с 5000 строками, ей необходимо загрузить все 5000 строк данных перед рендерингом любой из них, тогда как другие браузеры начинают рендеринг, когда у них есть частичные данные, и просто немного корректируют (при необходимости) по мере роста таблицы.
Вообще говоря, рендеринг замедляется из-за количества узлов, но также и из-за сложности узлов ... Избегайте вложенных таблиц и, если возможно, попытайтесь разбить огромные таблицы на куски ... Например, Каждые 100 строк (если возможно)