Есть ли ограничение по количеству HTML-элементов, которые браузер может отображать без проблем? - PullRequest
11 голосов
/ 04 июля 2010

По сути, у меня есть огромная таблица, которая становится еще больше при прокрутке пользователя вниз (автоматическая предварительная загрузка последующих строк).В какой-то момент браузер становится вялым, он на мгновение зависает, когда я нажимаю или пытаюсь прокрутить, и чем медленнее он становится, тем больше строк он получает.Интересно, есть ли ограничения на количество элементов, которые может содержать страница?Или, возможно, это просто утечка моего javascript где-то (хотя у меня есть только один обработчик событий, прикрепленный к телу таблицы - и скрипт, который анализирует всплывающие события mousedown).

Обновление: Задержка становится заметной после тысячи загруженных строк.Скорость самой прокрутки довольно терпима, но, например, выделение строки, по которой щелкнули (с помощью одного обработчика событий на tbody), болезненно (это занимает не менее 2-3 секунд, а задержка увеличивается с увеличением количества строк).Я наблюдаю задержку во всех браузерах.Не только я, но почти каждый, кто посещает страницу, так что я думаю, что в какой-то степени это влияет на каждую платформу.

Обновление : я привел здесь простой пример: http://client.infinity -8.me / table.php? Num = 1000 (вы можете передать любое число, которое вы хотите num ), в основном он отображает таблицу с num строками иимеет один обработчик событий, прикрепленный к родительской таблице.Из этого я должен сделать вывод, что в действительности не наблюдается заметного снижения производительности, вызванного количеством дочерних элементов.Так что это, вероятно, утечка где-то еще: (

Ответы [ 11 ]

6 голосов
/ 04 июля 2010

Еще одна вещь, на которую вы должны обратить внимание, это размер таблицы.Если ваша таблица имеет стиль table-width:auto;, браузер должен измерить каждый элемент таблицы, чтобы определить его размер.Это может стать безумно медленным.

Вместо этого выберите фиксированную ширину или, по крайней мере, стиль таблицы, используя table-width:fixed.

4 голосов
/ 04 июля 2010

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

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

Вы также можете рассмотреть альтернативный интерфейс, такой как пейджинг.

4 голосов
/ 04 июля 2010

Если у вас есть JS в каждой строке таблицы, то старые компьютеры не справятся с этим.Что касается самого HTML, вам не о чем беспокоиться.

Вам следует беспокоиться о том факте, что обычному человеку не нравятся большие таблицы, для этого и создана нумерация страниц.Разделите его с помощью подкачки страниц для лучшего удобства использования или других проблем.

Подумайте о книге, в которой нет страниц, а есть одна большая страница.Даже если ваши глаза (ПК в нашем случае) могут справиться с этим.

0 голосов
/ 04 июля 2010

Если есть какие-либо ограничения, это зависит от браузера.Но проблема у вас не в пределе, так как браузер по-прежнему отображает страницу.

Большие таблицы всегда являются проблемой для браузеров.Рендеринг большого стола занимает много времени.Поэтому часто бывает полезно разбить большую таблицу на меньшие таблицы .

Кроме того, вы, вероятно, хотите указать ширину столбцов .Без этого браузер должен загрузить всю таблицу, прежде чем он сможет рассчитать ширину каждого столбца и отобразить таблицу.Если вы укажете ширину в HTML-коде, браузер сможет отображать страницу, пока она еще загружается.(Примечание: недостаточно указать ширину всей таблицы, необходимо указать ширину каждого столбца.)

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

Но самый эффективный способ - разделить данные на несколько страниц.Пользователи, вероятно, тоже предпочитают это.Вот почему, например, Google отображает только очень много результатов на каждой странице.

0 голосов
/ 04 июля 2010

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

Вместо этого я предлагаю вам создать страницу, управляемую AJAX, где вы позволяете пользователю видеть часть данных, а если ему нужно больше, вы просто загружаете эту часть набора данных и заменяете текущий набор данных стр. Это нумерация страниц. Поиск Google - отличный пример этого.

0 голосов
/ 04 июля 2010

Зависит.Например, IE не начнет отображать таблицу, пока не будет загружен весь контент.Таким образом, если у вас есть таблица из 5000 строк, ей необходимо загрузить все 5000 строк данных перед рендерингом любой из них, когда другие браузеры начнут рендерить, как только они получат частичные данные, и просто немного откорректировать (при необходимости) по мере роста таблицы.

Вообще говоря, рендеринг замедляется с количеством узлов, но также и со сложностью узлов ... Избегайте вложенных таблиц и, если это вообще возможно, попытайтесь разбить огромные таблицы на куски ... Например, каждые 100 строк (если это возможно))

0 голосов
/ 04 июля 2010

Не обращайте внимания на использование ОЗУ или ЦП, каков реальный размер файла после его предварительной загрузки?

Если ваша таблица действительно настолько велика, вы могли бы заставить своих пользователей загружать мегабайты данных - я обнаружил,что некоторые машины склонны зависать после 2-4 МБ данных.

0 голосов
/ 04 июля 2010

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

Если вы не определите больше, какое ваше оборудование и браузер, вам сложно помочь.Кроме того, никто не может сделать какие-либо предложения относительно возможной производительности вашего Javascript, если вы не публикуете код.Даже если это всего лишь один обработчик событий, если он зацикливается бесконечно или его вызывают для каждого элемента, это может значительно замедлить процесс рендеринга.

0 голосов
/ 04 июля 2010

Какой браузер вы используете?Некоторые браузеры могут обрабатывать вещи лучше, чем другие - например, если вы используете IE, я не удивлюсь, если он медлительный - он не обрабатывает события javascript, а также браузеры на основе веб-набора.Другое дело, очевидно, ваш компьютер (RAM и CPU).Но, честно говоря, у большинства компьютеров не должно быть проблем с этим, если мы не говорим более 10000 строк ... и даже тогда ...

Можете ли вы опубликовать какой-нибудь код?

0 голосов
/ 04 июля 2010

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

У меня были проблемы с добавлением более 100 таблиц в div (как старый обходной путь для IE6, который не мог динамически создавать элементы таблицы).

...