Существуют задачи для браузеров, при которых открытие даже небольших (до 10КБ) страниц будет заметно «тормозить». Некоторые из этих задач вполне могут встретиться на практике.

Самый быстрый браузер

В последние годы интернет-обозреватели не радуют нас разнообразием рекламы: «С новой версией NN ваш веб-сёрфинг станет ещё безопаснее!» – наиболее типичный призыв производителей. А когда-то Оперу принято было называть «реактивной». Важна ли сейчас скорость работы браузера для пользователей?

С одной стороны, вопрос вроде бы глуповатый. Пользователю, конечно, нужна скорость: щёлкнул по ссылке – получил результат. Если между этими двумя событиями проходит много времени, пользователь раздражается. Но чаще всего страницы открываются медленно не из-за «медленного» браузера, а из-за плохой связи. Бывают, однако, исключения.

Мы провели несколько тестов на локальном компьютере, чтобы выявить условия, при которых открытие даже небольших (до 10КБ) страниц будет существенно «тормозить». Некоторые условия получились явно искусственными, а некоторые вполне могут встретиться на практике.

Наши опыты исходили их трёх этапов работы браузера: 1) распознавание кода HTML (структуры DOM) страницы, 2) выполнение задач Javascript, 3) вывод страницы на экран. Первый этап нами вообще не учитывался (да и нельзя его измерить с помощью Javascript, в отличие от последующих). Для генерации некоторого текста Javascript'ом и вывода его на экран мы попытались наглядно отобразить время работы браузеров. Опыты проводились на достаточно старом компьютере AMD Athlon 999МГц, 512 МБ ОЗУ (Windows XP). Браузеры: Google Chrome 3.0, Firefox 3.0 (FF), Opera 9.27, Internet Explorer 6.0 (IE или ИЕ). Сатурн был в зените, Луна в третьей четверти.

1. Генерация однородных элементов

Первый тест – генерация пробелов и элементов INPUT. По умолчанию в нём заданы значения «10000 пробелов» и «1000 INPUT» (всё это генерирует и выводит на экран простенький Javascript), после открытия страницы можно задать другие значения. За основные (показательные для нашего компьютера) мы выбрали 30000 и 13000. Вот что при этом показал Google Chrome:

Простой тест скорости – Google Chrome

Забавным и поучительным оказалось сравнение результатов Google Chrome с IE: при всей чудовищной тупости последнего (скорость Javascript в 1000 раз ниже!) на экран результаты работы IE выводит быстрее, чем Google Chrome:

Простой тест скорости – IE

Опера почему-то в 100 раз медленнее, чем пустые (261 мс), сгенерировала элементы INPUTы с текстом (20470 мс), но в целом результаты особо не удивили:

Простой тест скорости – Опера

Опера выделилась, как всегда, лишь своеборазной интерпретацией HTML – «бесконечная» строка в элементе PRE оказалась у неё вполне конечной и равной (38 попугаев) примерно 698 элементов INPUT, из-за чего пришлось добавить для Оперы CSS-правило, сваливающее все инпуты в кучу с помощью position:absolute.

Самый потрясающий результат, однако, показал – вы не поверите! – Firefox: для «фотографии на память» нам пришлось установить в нём значение всего 1600 инпутов. Потому что при значении 13000 FF, подумав минут 5, выдал окошко:

Видели когда-нибудь такое в Firefox?

Затем, при выборе в этом окне кнопки «Продолжить» FF зависал на неопределённое время (для измерения которого нужен, вероятно, более терпеливый экспериментатор). Вот этот печальный результат нашего любимого, хвалёного Firefox'а:

Простой тест скорости – Firefox

Firefox, надо сказать, вообще оказался самым капризным клиентом при фотографировании: он мог, например, подумав над заданием секунд 15, указать в отчётах по 40 мс для всех тестов. Памяти FF тоже жрёт больше всех:

Потребление памяти браузерами

Здесь приведены небольшие значения, при недолгой работе браузеров. При открытии же большого количества окон FF (и вообще Gecko) может захватывать у Windows XP до 600МБ и больше (другие браузеры намного скромнее). Сложно сказать, в каких случаях такая «жадная» стратегия может себя оправдывать: FF стремится сначала захватить и перемолоть всё сразу (и первичный код страницы, и сгенерированное содержимое) а потом одним махом вывалить всё на экран. В результате возникает иллюзия, что Опера работает быстрее, – она выдаёт на экран результаты более мелкими порциями, и, пока FF «думает» над белым экраном, у Оперы уже появляется на странице какой-то текст.

2. Генерация таблицы символов Юникод

Пример, показывающий, что у Firefox'а не всё в порядке с выводом не экран, конечно, сильно преувеличен. Вряд ли в жизни вам встретится необходимость вывода на одной странице хотя бы одной сотни элементов INPUT. Вот два более насущных примера: Коды символов Юникод и Коды символов Юникод (таблица). Снимки результатов тестов можно посмотреть отдельно: Chrome, FF, IE6, Opera.

В них результаты всех браузеров достаточно ровные, предсказуемо тормозит ИЕ. FF проявляет ещё один «экранный» недостаток: после некоторого времени «простоя» в фоновом режиме (окно заслонено другими приложениями), при активации окна FF с таблицей символов содержимое страницы «проявляется» не сразу, а через несколько секунд (и FF в это время сильно грузит процессор). Вероятно, это больше проблема ресурсов компьютера, чем прикладного софта, но проявляется эта проблема, из всех браузеров, ярче всего именно в Firefox'е.

ИЕ отличается в тестах с таблицей символов ещё одной неприятной особенностью: большинство символов он пытается вывести шрифтом по умолчанию, и выходят они поэтому пустыми квадратиками (все остальные браузеры автоматом ищут и подставляют шрифты, в которых есть искомые символы Юникод).

3. DOM2, пример из практики

В последнее время мы активно начали использовать на разных сайтах работу со списками на стороне клиента. Если в списке, например, 10 фраз (например, список ссылок в главном меню), то понятно, что с ним нечего особенно «работать» – он просто выводится на экран, и пользователь может ткнуть мышкой в любой его элемент. Если в списке 100 элементов, он уже не поместится на экране, и пользователю сложнее найти нужный элемент и ткнуть в него мышкой.

В списке макетов газеты Деловая неделя около 300 элементов, и для удобства пользователей мы добавили в начало списка окно поиска и небольшой javascript, который при наборе букв в окне поиска делает видимыми элементы списка, в которых есть данные буквы, и делает невидимыми все остальные элементы списка. Мы не измеряли скорость обработки поиска на данной странице, но при использовании Google Chrome и так видно, что работа происходит в режиме «реального времени» (даже на нашем слабом Атлоне): при вводе букв список меняется практически мгновенно. В ИЕ скрипт данной страницы отрабатывает с заметной (примерно секундной) задержкой.

Список рубрик справочника предприятий может содержать от 700 до 1000 элементов. С ним Google Chrome работает почти так же быстро, как и с 300-элементным списком; Firefox и Опера тоже в общем-то позволяют использовать этот фильтр. Но при попытке отбирать элементы через ИЕ наше дополнительное удобство превращается в фатальное препятствие. Скорость работы можно посмотреть на специальной тестовой странице Javascript: фильтрация элементов списка. Вот время обработки одного запроса в ИЕ на нашем компьютере:

Отбор элементов списка – ИЕ

Сравните с Gogle Chrome, FF, Opera.

Не бросать же из-за одной паршивой овцы такую отличную идею! Придётся при получении запросов от ИЕ опцию отбора элементов на стороне клиента отключать (ну, когда страницу рубрик часто открывать начнут). Да. А у нас ведь ещё список предприятий есть. Там их несколько тысяч...

© 2009, «Деловая неделя», Михаил Гутентог
http://mix4mobile.in.ua/mobile/skachat-google-chrome-na-telefon.php

Комментарии

Гость 18.05.2010 17:47:36

Интересно вот что. За последние годы люди стали привыкать к правильному поведению браузеров (такому, как ожидается). И с этой точки зрения, ИЕ (даже 8) по-прежнему ведёт себя «неправильно», а самым «правильным» выглядит Firefox. Firefox жрёт хренову тучу памяти, и у нас, в фирме, например, рекомендовано поэтому при работе на сервере пользоваться только ИЕ (который и памяти меньше тратит, и работает часто быстрее). Но теперь, после «правильного» ФФ, уже очень трудно переломить себя – быстрый и оптимальный для Windows ИЕ8 НЕ УДОБЕН!!

лесник 07.11.2009 21:22:41

Невежливо, наверное, было бы обойти сейчас молчанием Сафари 4 для Windows – ведь именно он настойчиво появляется в первой десятке Гугла при поиске "самого быстрого" браузера. Действительно, на быстром компьютере Сафари показывает результаты на 100 мс лучше, чем у Google Chrome (540 ms – вывод пустых INPUT, 751 ms – вывод INPUT с текстом):

Простой тест скорости – Сафари 4

Таблицу символов, однако, Сафари генерирует примерно вдвое дольше, чем Google Chrome (но зато выводит на экран вдвое быстрее):

Коды символов Юникод – Сафари 4

С большим списком Сафари работает примерно так же (примерно на 1 ms медленнее, чем Google Chrome):

Отбор элементов списка – Сафари 4

Но всё равно эти сведения не имеют практической ценности, так как при запуске Сафари 4 на Windows компьтер начинает страшно тормозить (невозможно даже текст набирать в Блокноте).

лесник 07.11.2009 21:22:27

Интересно, что ИЕ7 и FF3.5 полностью унаследовали проблемы со скоростью своих предшественников. Точно такие же тормоза в описанных нами случаях. А вот ИЕ8 уже сильно нас удивил – стал работать "как все": быстро считать и медленно выводить на экран. При этом почему-то "бесконечная строка" в ИЕ8 стала конечной, как в Опере:

Простой тест скорости – ИЕ8

Может, ОНИ украли у Оперы алгоритмы вместе со всеми недостатками?.. Ну, главный ОРГвывод для нас всё равно положительный – теперь можно ИЕ (в надежде что всё равно скоро все 8 установят) из работы с большими списками не исключать:

Отбор элементов списка – ИЕ8

(тесты на компьютере Pentium 4 CPU 2.53 GHz 1.00 ГБ ОЗУ)