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