Тестирование больших гридов в современных браузерах

Тест и информация ниже - от 2016 года. Технологии и браузеры не стоят на месте...

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

Но насколько комфортна работа браузеров с большими объёмами отображаемых данных? Автор решил это проверить, используя произвольное количество гридов (блоков с табличными данными). Гриды традиционно используются для предоставления справочной информации и быстрого поиска-выбора той или иной позиции из списка.

Была сделана тестовая страница с гридами, здесь-же описание теста и результатов, включая «неожиданности» для некоторых разработчиков.
P.S. Не забывайте, что большие гриды требуют много памяти.

Описание тестирования Гридов

Тестирование больших гридов в браузере

Тестировались два варианта расположения Гридов:

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

Тестовая страница сделана в соответствии с W3C-стандартами и адаптирована под мобильные и сенсорные.

Замеры времени (тайминги) не используются, так как к реальному рендерингу страницы не имеют никакого отношения. Обращаю внимание на огромную разницу при рендеринге результатов выполнения JavaScript и замеряемым временем выполнения JavaScript - это две большие разницы!
Многие разработчики ошибаются, слепо доверяя таймингам, а скорость рендеринга не проверяют - но разница явно видна глазами при увеличении количества добавляемых HTML-объектов. Скорость доступа JavaScript к DOM - это что угодно, но не рендеринг!
Поэтому существует устойчивое заблуждение, что прямые DOM-операции работают быстрее, чем вставка через .innerHTML, что является грубейшей ошибкой тестирования.

На самом деле, .innerHTML выигрывает по скорости рендеринга объёмных объектов, даже в современных браузерах (на мобильных в 10 и более раз), позволяя браузерам использовать внутренние механизмы оптимизации. На десктопных Chrome и FireFox последних версий, .innerHTML как минимум не уступает в скорости DOM. Подробности и ссылки на тесты ниже по тексту.

Тестировались обычные «классические» Гриды с минимальной функциональностью, достаточной для работы (навигация, выбор ячейки, поддержка сенсорных экранов). Клавиши навигации: Arrows, Home, End, Ctrl(Cmd)+Home, Ctrl(Cmd)+End.
Большие веб-Гриды в тесте были сделаны без интерактивных изменений данных. Для частичных изменений HTML-содержимого, будет неправильным перезаписывать весь большой блок HTML-кода родителя, лучше использовать методы вложенных небольших объектов - .innerHTML, .insertAdjacentHTML(), а так же .createDocumentFragment() или прямые DOM-операции.

Некоторые из способов повышения производительности:

  • для построения гридов использовались таблицы table, так как они наиболее быстрые при рендеринге (особенно критично в FireFox, который тормозит уже на 1000 ячейках при единственном перемещаемом Гриде, если их все не засунуть в одну таблицу).
  • для IE используется свойство display:block/none, для Chromium, FireFox и Opera 12 используется свойство visibility:visible/hidden - таким образом браузеры быстрее обновляют состояние окон с Гридами со скрытого на видимый, ещё Opera12 попутно избавляется от визуального глюка с тенями. Ранее в FireFox (до версии 45.0) использовалось display:block/none, так что обновите свой FireFox, если тормозит.
  • используется requestAnimationFrame, если браузер это поддерживает, но толку от этого не замечено, браузеры видимо уже давно оптимизируют сами так или иначе. Автор включал/выключал использование этой технологии ( VcorpJS умеет делать по-разному ), но разницы не заметил.
    На практике преимущества этой технологии очень сложно получить - нужно следить за пиковыми нагрузками, таймерами в коде и объёмами перерисовки (rendering), в результате получаемая выгода ничтожна по сравнению с возрастающей сложностью разработки и дальнейшей поддержки. Не говоря уже о смене версии браузера, которая может приподнести сюрприз. Думаю, что requestAnimationFrame полезна в операциях, не связанных напрямую с рендерингом HTML-объектов, например, при рисовании на холсте Canvas.
  • .innerHTML, как показали тесты, при спорной разнице в скорости исполнения JavaScript (по сравнению с DOM-операциями), работает быстрее.
    По скорости отображения (рендерингу) - .innerHTML не медленнее, а часто быстрее вставок через DOM-операции. Это хорошо видно на мобильных и SmartTV, где разница в скорости рендеринга достигает 10 и более раз в пользу .innerHTML при значительном увеличении количества добавляемых HTML-объектов, несмотря на бОльшие тайминги - по сравнению с DOM (скорость доступа JavaScript к DOM - это ни разу не рендеринг).
    Преимущество .innerHTML так-же проявляется в IE11 (в 8-10 раз) и Opera12 (в 1.5 раза) - по скорости JavaScript - ну и рендеринг быстрее.
    В Chrome (Chromium) и FireFox (Gecko) на обычном компьютере скорость рендеринга визуально одинакова при любом виде добавления новых объектов, так-же одинакова скорость JavaScript при полном обновлении содержимого родительского блока (тайминги).

Итак, рендеринг и отзывчивость веб-страниц более быстрые при использовании .innerHTML
Поэтому используется создание текстовой строки с HTML-содержимым Грида, с последующей вставкой через .innerHTML, так-же выбрана эта модель из-за кросс-браузерности валидного HTML-кода и по причине большого количества ячеек, которые проще собрать строкой, а работа со строками давно уже оптимизирована - это очень быстрые операции. Плюс можно работать с уже готовыми HTML-строками.

Важно для мобильных! - Простой тест для мобильных на планшете и SmartTV показал, что отображение (рендеринг) созданного блока работает в несколько раз быстрее при .innerHTML, несмотря на более длительные тайминги по сравнению с DOM. Разница достигает 10 и более раз при увеличении количества создаваемых объектов! Хотя время доступа к DOM быстрее... но этот факт к скорости рендеринга не имеет никакого отношения и показывает только скорость доступа JavaScript к DOM браузера.

Способы приближения к реальности:

  • каждая ячейка содержит уникальное содержимое (номер строки и столбца), иначе тест получается на 100% «синтетическим» и неверным.
  • фоновая анимация и анимационное меню - для проверки замедления отзывчивости страницы при операциях с Гридами.
  • анимация прозрачности при появлении или исчезании окон (отключается при 1000 или более ячеек в гриде (для Chromium от 10000)) - смена прозрачности может довольно сильно «подсадить» скорость отзывчивости веб-страницы.
  • тестовая страница имеет простую вёрстку, НО - адаптирована под мобильные и сенсорные; так же, чтобы тест не был слишком синтетическим, на страницу специально добавлены блоки со свойствами margin и float:left/right - наличие которых показывает заметное замедление отзывчивости практически всех браузеров, хотя ситуация постепенно улучшается и возможно, скоро это не будет создавать тормозов.
  • вместо механизма Drag & Drop используется реальное перемещение объекта (окна) и изменение его размеров - так перемещаемый объект выглядит сам собой, а не непонятно чем.

Итоги тестирования Гридов

Тест нескольких больших и маленьких Гридов проводился на браузерах: Chrome (плюс Chromium 45 и 47), FireFox, IE11, IE9, Opera12 и IE8 (XP). Тестовая страница открывалась на разных компьютерах, под win7 64 и winXP, а так-же на планшете Android и на SmartTV LG.

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

Самые большие тормоза - в моменты обновления данных Грида любого типа - это самая тормознутая операция, не зависящая от вида и местоположения Грида. Здесь самые быстрые - Chromium и Opera12. Динамика блока с Гридом тормозит в моменты окончания перемещения блока или смены его размеров или смены видимости, со своими особенностями у разных браузеров (отзывчивость Opera12 самая быстрая).

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

Несколько мелких Гридов, работающих одновременно, визуально намного быстрее и отзывчивее одного большого, даже если их суммарный объём данных намного больше.

1. Чемпионом по скорости оказался браузер Chrome и отдельно веб-движок Chromium 45 и 47, который тоже тестировался, так как автор его использует в связке с Lazarus. Но у них существует глюк - если очень большой HTML-объект с фокусом становится невидимым (продолжая существовать в скрытом виде), страница начинает жутко тормозить и движок грузит ядро процессора до тех пор, пока пользователь куда-нибудь не ткнёт (программная установка фокуса не помогает). По этой причине и по ряду других, выбрана модель работы Гридов без смены фокуса (активный Грид всегда тот, что на переднем плане, если этот грид перемещаемый).

2. FireFox - версия 45.0 поставила этот браузер на 2 место, ранее это был самый тормознутый из современных браузеров, когда дело касается больших Гридов. Немного исправляло ситуацию использование таблиц table и уменьшение количества колонок (менее 10), но... если существовал хотя-бы один большой Грид, было неадекватное время ожидания, когда нужно обновить данные даже в мелких Гридах, даже очистка Грида - неадекватные тормоза. В версии 45.0 стало намного быстрее, но без использования table - это тормоз.

3. Opera 12 (кстати там нет requestAnimationFrame), при больших Гридах подтормаживает вся страница, но стабильная отзывчивость лучше других браузеров. Это можно заметить в момент окончания перемещения большого Грида или изменения размеров его окна. К сожалению, у Opera 12 визуальные глюки с рамками таблиц, поэтому выделять ячейки лучше другими способами. Строковые операции кушают память в несколько раз больше, чем в современных браузерах, но память быстро освобождается. В некоторых случаях Opera 12 самая быстрая при перерисовке.

4. IE 11 - скорость исполнения JavaScript чуть ниже, чем в FireFox, более медлителен при перемещении Гридов, до появления версии FireFox 45.0 был быстрее (визуально отзывчивее) при одновременной работе с несколькими большими Гридами. После выхода FireFox 45.0 оказался на 4 месте.

5. IE 9 - устаревший браузер, скорость JavaScript и отзывчивость на больших Гридах низкая, но в принципе работает.

... IE8 жуткий тормоз, есть глюки с навигацией внутри гридов, страдает визуальное оформление (нет поддержки CSS3), но это winXP, поэтому он тоже тут. Насколько помню, IE8 уступает в скорости IE6. Рекомендуется не использовать, безнадёжно устарел.

Несколько слов о мобильных и SmartTV

Тестовая страница проверялась на недорогом планшете ASUS Fonepad ME371MG 16Gb, который имеет слегка глючный встроенный браузер (из-за эмуляции всех события мыши в добавок к тачпадовским), а так же браузер Chrome. Встроенный браузер работал вполне комфортно (учитывая специфику мобильного) с несколькими Гридами по 500-1000 ячеек. При создании грида на 3000 ячеек отзывчивость страницы очень сильно упала. Браузер Chrome работал получше - комфортная работа с несколькими Гридами ограничилась 2 тыс. ячейками на Грид.

SmartTV LG средней ценовой категории оказался хуже планшета, есть пульт-указка с колесом прокрутки, а так-же внешняя клавиатура с тачпадом. Работать неудобно, клавиши навигации не работают, перемещение объектов не работает, видимо при нажатой кнопке не возникают события move.

Выводы

Комфортная работа с Гридами в реальном приложении зависит не столько от скорости подгрузки и обработки данных или скорости исполнения JavaScript, сколько от скорости рендеринга этих данных браузером.

Несмотря на максимальную оптимизацию в современных браузерах, от особенностей и специфики DOM -> медленный рендеринг никуда не деться...

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

Но если посмотреть на прогресс браузеров за последние 5-7 лет, то вполне вероятно достижение комфорта при работе 50 тыс. ячеек и более.

P.S. .innerHTML по-прежнему выигрывает в скорости, позволяя браузерам использовать внутренние механизмы оптимизации при рендеринге.

imho:

По моему скромному мнению, самые функциональные и динамичные гриды делаются на блочных элементах без использования таблиц table (таблицы нужны тупо для быстроты отображения данных), но с этой задачей пока справляются лишь Chromium и Opera 12 - и на небольших объёмах.
Сделать этот тест быстрее не получится на известных библиотеках и фреймворках, нужен оптимизированный «велосипед», что я и сделал (VcorpJS).

  • Vcorp.ru - Главная страница сайта
  • Генерация скриптов
  • Тест больших гридов в перемещаемых окнах
  • Тестирование 3D графики в браузерах
  •  
  • «VcorpJS» - Главная страница раздела
  • «Vcorp Generator» - Главная страница раздела
  • «Lazarus fpCEF3» - Главная страница раздела
  • Открывать окно навигации
    <<<
    Изменить высоту >>