Подтвердить что ты не робот

Есть ли ограничение на количество элементов html, что браузер может отображать без проблем?

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

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

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

4b9b3361

Ответ 1

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 4

Я не думаю, что есть предел. Тем не менее, чем длиннее HTML файл, тем больше ресурсов потребуется вашему компьютеру. Но таблица должна быть очень большой...

Ответ 5

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

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

Ответ 6

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

Другое дело - ваш компьютер (оперативная память и процессор). Но, честно говоря, у большинства компьютеров не должно быть проблем с этим, если мы не говорим о 10000+ строках... и даже тогда...

Можете ли вы разместить код?

Ответ 7

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

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

Ответ 8

Никогда не используйте RAM или CPU, каков фактический размер файла после его предварительной загрузки?

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

Ответ 9

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

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

Ответ 10

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

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

Ответ 11

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

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

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

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

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