3 главные ошибки, которые вредят производительности JavaScript


Оглавление (нажмите, чтобы открыть):

SPBDEV Blog

Что, если бы вам сказали , что все, что вы знали, было ложью? Что произойдет, если вы узнаете, что некоторые ключевые функции, которые наш любимый ECMAScript опубликовал за последние годы, на самом деле представляют собой опасные ловушки производительности, покрытые глазурью, чтобы хорошо смотреться в одной линии с функциональном кодом обратного вызова ?

Эта история начинается несколько лет назад, в наивные дни ES5 .

Момент выпуска ES5 запомнился многим, когда новые классные функции массива были введены в наш дорогой JavaScript. Среди них были для Each, reduce, map, filter — они заставляли нас чувствовать, что язык растет, становится более функциональным, писать код становится более увлекательным и плавным, а результат читается легче и становится более понятным.

Примерно в то же время возникла новая среда — Node.js, она дала нам возможность плавного перехода от внешнего интерфейса к серверному, а также по-настоящему переопределить полную разработку стека.

В настоящее время Node.js, использующий последний ECMAScript над V8, пытается быть признанным частью основных языков разработки на стороне сервера лиги, и поэтому он должен оказаться достойным производительности. Да, есть очень много параметров, которые нужно учитывать, и да, нет идеального языка, который превосходит всех. Но, действительно ли написание кода JavaScript с использованием готовых функций, подобные упомянутой выше функции массива, помогает производительности вашего приложения? Или это все же наносит ущерб?

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

Чтобы проверить это, мы попытались сравнить несколько сценариев и подробно изучили их, чтобы понять результаты, которые были получены. Мы выполнили следующие тесты на Node.js v10.11.0 и в браузере Chrome, и на macOS.

1. Зацикливание по массиву

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

Мы сравнивали суммирование случайных 10 тыс. элементов, используя for, for-of, while, forEach и уменьшая. Запуск тестов 10 000 раз дал следующие результаты:

For Loop, average loop time:

For-Of, average loop time:

ForEach, average loop time:

While, average loop time:

Reduce, average loop time:

В процессе поиска решения, как суммировать массив, сокращение было наилучшим решением, но оно является самым медленным. Наш переход к forEach был не намного лучше. Даже новейший for-of (ES6) обеспечивает низкую производительность. Оказывается, старый добрый цикл for (а также while) обеспечивает производительность в 10 раз лучше!

Как может новейшее и рекомендуемое решение сделать JavaScript намного медленнее? Причина этой боли объясняется двумя основными причинами: сокращение и forEach требует выполнения функции обратного вызова, которая вызывается рекурсивно и раздувает стек, а также дополнительную операцию и проверку, которые выполняются над исполняемым кодом.

2. Дублирование массива

Хотя это звучит как менее интересный сценарий, это столп неизменяемых функций, который не изменяет ввод при генерации вывода.

Результаты тестирования производительности здесь снова показывают одну и ту же интересную тенденцию — при дублировании 10 тыс. массивов из 10 тыс. случайных предметов оказалось быстрее использовать старые привычные решения.

Опять же самая модная операция распространения ES6 `[. arr]` и Array из `Array.from (arr)` плюс карта ES5 `arr.map (x => x)` уступают проверенному срезу `arr.slice () `и concatenate` [] .concat (arr) `.

Duplicate using Slice, average:

Duplicate using Map, average:

Duplicate using Spread, average:

Duplicate using Conct, average:

Duplicate using Array From, average:

Duplicate manually, average:

3. Итерация объектов

Другим частым сценарием является итерация над объектами, это в основном необходимо, когда мы пытаемся пересечь JSON и объекты и не ищем определенного значения ключа. Опять же существуют ветеранские решения, такие как for-in `for (let key in obj)` или более поздние `Object.keys (obj)` (представленные в es6) и `Object.entries (obj)` (из ES8) который возвращает оба ключа и значение.

Анализ эффективности итераций 10 тыс. объектов, каждый из которых содержит 1000 случайных ключей и значений, используя приведенные выше методы, показывает следующее.

Object iterate For-In, average:

Object iterate Keys For Each, average:

Object iterate Entries For-Of, average:

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

Подведем итоги

Вывод ясен: если для вашего приложения важна высокая производительность, или если вашим серверам требуется некоторая загрузка — самые крутые, более читаемые и более чистые варианты будут сильно влиять на производительность вашего приложения, которая может стать до 10 раз медленнее!

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

Форум

Справочник

Поиск по форуму
Расширенный поиск
К странице.
31 мая 2010 — 12:06
  • Perfomance

Сравниваем производительность JavaScript фреймворков

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

В качестве инструмента я взял тест SlickSpeed и установил на свой хостинг, в списке испытуемых оказались следующие фреймворки:

Dojo 1.4.3
JQuery 1.4.2
MooTools 1.2.4
Prototype 1.6.1 и 1.7.2
ExtJS Core 3.1
YUI 3.1.1

А так же браузеры, установленные на моей системе:

Mozilla Firefox 3.6.3
Opera 10.53
Google Chrome 5.0.375.55 beta
Safari 4.0.3
Internet [. ]

8 трюков для ускорения JavaScript

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

ag-Grid — библиотека для отображения больших объемов данных в браузере, внешне похожая на Excel и написанная на JS. Она хорошо работает даже в IE и на больших объемах данных. Сегодня мы расскажем о том, какие оптимизации мы используем, чтобы все работало быстро.

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

Виртуализация строк

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

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

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

Виртуализация колонок

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

Виртуализация колонок позволяет отображать большое количество колонок без деградации производительности.

Распространение событий

Проблема: регистрация обработчиков событий

Библиотека обрабатывает клики и нажатия клавиш для каждой ячейки, так что для каждой ячейки мы вынуждены регистрировать обработчики событий. Всего мы используем восемь событий: click, dblclick, mousedown, contextmenu, mouseover, mouseout, mouseenter and mouseleave.

Добавление обработчиков событий в DOM несколько влияет на производительность. Для таблицы в 20 видимых колонок и 50 видимых строк количество обработчиков равно 20 колонок * 50 строк * 8 событий = 8000 обработчиков событий. По мере прокрутки начинает работать виртуализация, и обработчики постоянно снимаются и регистрируются, создавая тормоза при прокрутке.

Решение: распространение событий

Шесть из восьми событий распространяемы, кроме mouseenter and mouseleave. Так что вместо добавления обработчиков на каждую ячейку мы добавляем обработчик для контейнера, содержащего все ячейки. Таким образом мы добавляем обработчик при инициализации таблицы, а не индивидуально для каждой ячейки.

Вопрос в том, как определить, для какой ячейки вызвано событие?

Вероятно, вы заметили, что мы добавляем атрибуты __col и __row к элементам и думаете, безопасно ли это? Я надеюсь, что да, так как ag-Grid используется в приложении контроля авиатрафика над Австралией, насколько мне известно. Иными словами, библиотека работает так уже давно, и таким образом протестирована в боевой обстановке.

Это похоже на то, как работает React’s Synthetic Events. React использует делегирование событий и обрабатывает события в корне приложения, при этом отслеживая, какие ноды имеют обработчики. В React реализована собственная система событий, которая в итоге вызывает нужные обработчики.

Отбросьте DOM

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

Этот прием работает так: если вы удаляете элемент из DOM (например ячейку), но вы знаете, что родительский элемент (например строка) тоже подлежат удалению, вам нет необходимости удалять ячейки по одной.

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

Используйте innerHTML, где это возможно

Какой самый быстрый способ добавить кучу ячеек и строк в браузер? Стоит ли использовать JavaScript(document.createElement()) для создания каждого элемента, обновления атрибутов и сборки элементов воедино с помощью appendChild()? Или вам стоит работать с фрагментами документа? Или может лучше собрать все в большой кусок HTML и вставить в DOM с помощью innerHTML?

Мы проверили все это. Ответ: используйте innerHTML.

Так что мы выигрываем в скорости с innertHTML, собирая большой HTML и вставляя его в DOM с помощью element.insertAdjacentHTML(). Мы обнаружили, что insertAdjacentHTML() добавляет контент, в то время как innerHTML() заменяет его.

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

Рендеры ячеек — отдельный тип компонентов. Сама идея компонентов хороша для приложений, они как строительные блоки для больших приложений, когда мелкие элементы (компоненты) собираются воедино в большие элементы. Однако в ag-Grid мы делаем ставку на скорость, так что лучше избегать рендеров ячеек в пользу быстрого рендеринга строк с innerHTML.

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

Объединение событий прокрутки

Когда вы прокручиваете таблицу в ag-Grid, виртуализация влечет за собой удаление элементов DOM. Удаление занимает время, и если оно вызывается внутри обработчика события, это пагубно влияет на ощущения от прокрутки.

Чтобы избежать этого, библиотека объединяет несколько близких событий прокрутки с кадрами анимации. Это привычный трюк для достижения плавной прокрутки и он хорошо объясняется в статье Leaner, Meaner, Faster Animations with RequestAnimationFrame. Я не буду повторно объяснять его принцип тут. Достаточно сказать, что мы обнаружили, что этот трюк хорошо поднимает производительность.

Кадры анимации

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

Так что следующий трюк — разбиение отрисовки строк по кадрам анимации. Когда пользователь прокручивает таблицу вертикально, чтобы посмотреть другие строки, вот что происходит внутри:

  • 1 задача: прокрутка к закрепленной панели, если пользователь ее закрепляет
  • n задач: вставить контейнеры со строками (в результате строки раскрашены в нужные цвета)
  • n задач: вставить ячейки, используя innertHTML
  • n задач: вставить ячейки, используя рендер ячеек
  • n задач: вставить обработчики mouseenter and mouseleave на каждую строку для добавления hover-эффекта
  • n задач: удалить старые строки

Так что если вы прокрутили таблицу, чтобы увидеть 10 новых строк, у вас появляется 50 с лишним задач. Каждая прокрутка, создание строки, создание ячеек — все это отдельные задачи.

Библиотека использует кадры анимации (или таймауты, если браузер не поддерживает кадры) для выполнения задач в определенном порядке. Порядок такой:

  • Сперва прокрутка: максимальные усилия прилагаются к тому, чтобы держать закрепленные секции на своих местах.
  • Затем вставка контейнеров строк: первое, что увидит пользователь — границы строк.
  • Ячейки отрисовываются по порядку настолько быстро, насколько позволяет браузер.
  • Потом удаляются старые строки, поскольку это никак визуально не отображается.
  • Если происходит еще прокрутка, очередь задач перестраивается в пользу новых задач над старыми.
  • Старые задачи отменяются, если их результат больше не понадобится после новой прокрутки.

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

Быстрые браузеры вроде Chrome могут сделать все необходимое в одном кадре без видимой визуальной задержки. Медленным браузерам вроде IE может потребоваться 10 и более кадров для выполнения всех задач. Внешне это выглядит, как поступенчатая отрисовка, что гораздо лучше блокирования UI и отрисовки всего в один момент.

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

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

Упорядочивание строк

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

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

Однако компромисс возможен. Обычно библиотека не сортирует строки. Если пользователь хочет поддерживать порядок строк, он может использовать свойство ensureDomOrder=true. Таблица отображается немного медленнее, но тогда она совместима с программами для чтения с экрана.

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


ag-Grid — библиотека для отображения больших объемов данных в браузере, внешне похожая на Excel и написанная на JS. Она хорошо работает даже в IE и на больших объемах данных. Сегодня мы расскажем о том, какие оптимизации мы используем, чтобы все работало быстро.

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

Виртуализация строк

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

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

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

Виртуализация колонок

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

Виртуализация колонок позволяет отображать большое количество колонок без деградации производительности.

Распространение событий

Проблема: регистрация обработчиков событий

Библиотека обрабатывает клики и нажатия клавиш для каждой ячейки, так что для каждой ячейки мы вынуждены регистрировать обработчики событий. Всего мы используем восемь событий: click, dblclick, mousedown, contextmenu, mouseover, mouseout, mouseenter and mouseleave.

Добавление обработчиков событий в DOM несколько влияет на производительность. Для таблицы в 20 видимых колонок и 50 видимых строк количество обработчиков равно 20 колонок * 50 строк * 8 событий = 8000 обработчиков событий. По мере прокрутки начинает работать виртуализация, и обработчики постоянно снимаются и регистрируются, создавая тормоза при прокрутке.

Решение: распространение событий

Шесть из восьми событий распространяемы, кроме mouseenter and mouseleave. Так что вместо добавления обработчиков на каждую ячейку мы добавляем обработчик для контейнера, содержащего все ячейки. Таким образом мы добавляем обработчик при инициализации таблицы, а не индивидуально для каждой ячейки.

Вопрос в том, как определить, для какой ячейки вызвано событие?

Вероятно, вы заметили, что мы добавляем атрибуты __col и __row к элементам и думаете, безопасно ли это? Я надеюсь, что да, так как ag-Grid используется в приложении контроля авиатрафика над Австралией, насколько мне известно. Иными словами, библиотека работает так уже давно, и таким образом протестирована в боевой обстановке.

Это похоже на то, как работает React’s Synthetic Events. React использует делегирование событий и обрабатывает события в корне приложения, при этом отслеживая, какие ноды имеют обработчики. В React реализована собственная система событий, которая в итоге вызывает нужные обработчики.

Отбросьте DOM

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

Этот прием работает так: если вы удаляете элемент из DOM (например ячейку), но вы знаете, что родительский элемент (например строка) тоже подлежат удалению, вам нет необходимости удалять ячейки по одной.

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

Используйте innerHTML, где это возможно

Какой самый быстрый способ добавить кучу ячеек и строк в браузер? Стоит ли использовать JavaScript(document.createElement()) для создания каждого элемента, обновления атрибутов и сборки элементов воедино с помощью appendChild()? Или вам стоит работать с фрагментами документа? Или может лучше собрать все в большой кусок HTML и вставить в DOM с помощью innerHTML?

Мы проверили все это. Ответ: используйте innerHTML.

Так что мы выигрываем в скорости с innertHTML, собирая большой HTML и вставляя его в DOM с помощью element.insertAdjacentHTML(). Мы обнаружили, что insertAdjacentHTML() добавляет контент, в то время как innerHTML() заменяет его.

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

Рендеры ячеек — отдельный тип компонентов. Сама идея компонентов хороша для приложений, они как строительные блоки для больших приложений, когда мелкие элементы (компоненты) собираются воедино в большие элементы. Однако в ag-Grid мы делаем ставку на скорость, так что лучше избегать рендеров ячеек в пользу быстрого рендеринга строк с innerHTML.

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

Объединение событий прокрутки

Когда вы прокручиваете таблицу в ag-Grid, виртуализация влечет за собой удаление элементов DOM. Удаление занимает время, и если оно вызывается внутри обработчика события, это пагубно влияет на ощущения от прокрутки.

Чтобы избежать этого, библиотека объединяет несколько близких событий прокрутки с кадрами анимации. Это привычный трюк для достижения плавной прокрутки и он хорошо объясняется в статье Leaner, Meaner, Faster Animations with RequestAnimationFrame. Я не буду повторно объяснять его принцип тут. Достаточно сказать, что мы обнаружили, что этот трюк хорошо поднимает производительность.

Кадры анимации

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

Так что следующий трюк — разбиение отрисовки строк по кадрам анимации. Когда пользователь прокручивает таблицу вертикально, чтобы посмотреть другие строки, вот что происходит внутри:

  • 1 задача: прокрутка к закрепленной панели, если пользователь ее закрепляет
  • n задач: вставить контейнеры со строками (в результате строки раскрашены в нужные цвета)
  • n задач: вставить ячейки, используя innertHTML
  • n задач: вставить ячейки, используя рендер ячеек
  • n задач: вставить обработчики mouseenter and mouseleave на каждую строку для добавления hover-эффекта
  • n задач: удалить старые строки

Так что если вы прокрутили таблицу, чтобы увидеть 10 новых строк, у вас появляется 50 с лишним задач. Каждая прокрутка, создание строки, создание ячеек — все это отдельные задачи.

Библиотека использует кадры анимации (или таймауты, если браузер не поддерживает кадры) для выполнения задач в определенном порядке. Порядок такой:

  • Сперва прокрутка: максимальные усилия прилагаются к тому, чтобы держать закрепленные секции на своих местах.
  • Затем вставка контейнеров строк: первое, что увидит пользователь — границы строк.
  • Ячейки отрисовываются по порядку настолько быстро, насколько позволяет браузер.
  • Потом удаляются старые строки, поскольку это никак визуально не отображается.
  • Если происходит еще прокрутка, очередь задач перестраивается в пользу новых задач над старыми.
  • Старые задачи отменяются, если их результат больше не понадобится после новой прокрутки.

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

Быстрые браузеры вроде Chrome могут сделать все необходимое в одном кадре без видимой визуальной задержки. Медленным браузерам вроде IE может потребоваться 10 и более кадров для выполнения всех задач. Внешне это выглядит, как поступенчатая отрисовка, что гораздо лучше блокирования UI и отрисовки всего в один момент.

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

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

Упорядочивание строк

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

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

Однако компромисс возможен. Обычно библиотека не сортирует строки. Если пользователь хочет поддерживать порядок строк, он может использовать свойство ensureDomOrder=true. Таблица отображается немного медленнее, но тогда она совместима с программами для чтения с экрана.

Браузеры снова на тропе войны

О соревновании разработчиков браузеров за нашу с вами привязанность принято говорить не иначе как о «войне», хотя после бесславной гибели Netscape реальных «боевых действий» фактически не было — так, мелкие стычки. Даже успешная «вылазка» Opera и прошлогоднее принуждение Microsoft к реализации специального окна выбора браузеров в Европе принципиально ничего не изменили, все процессы продолжили развиваться согласно текущим трендам. Однако нынешняя весна, пожалуй, сделала военную риторику более оправданной — достаточно лишь совсем коротко вспомнить, сколько всего интересного произошло за март-апрель:

  • Microsoft выпустила Internet Explorer 9, а меньше чем через месяц представила Internet Explorer 10 Preview;
  • Apple обновила Safari до 5.04 и почти сразу же до 5.05;
  • Google выпустила Chrome 10, а практически через месяц и Chrome 11;
  • вышел Firefox 4, Firefox 5 обещан в конце июня;
  • Opera 11.10 выпущена менее чем через месяц после начала публичного бета-тестирования.

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

Формально за такую «гонку вооружений» мы должны благодарить Google, которая штампует очередные версии, невзирая на реальное количество новшеств в них. Вообще говоря, практика сомнительная, не слишком осведомленного пользователя подобная игра цифрами может ввести в заблуждение. С другой стороны, на цифры можно и вовсе не обращать внимания — тот же Chrome обновляется автоматически, практически незаметно, а отсутствие больших отличий — возможно, даже благо для неопытных пользователей. И тем не менее, ускоренная «накрутка» версий, судя по всему, приносит Google свои плоды. Статистика Net Applications недвусмысленно демонстрирует, что последнее время именно Chrome отбирает долю мирового рынка и у Internet Explorer, и даже у Firefox. Да-да, популярность последнего начала снижаться, и, вероятнее всего, именно потому, что его разработчики слишком долго выводили новую большую версию. Если более внимательно всмотреться в упомянутую статистику, то нетрудно заметить, что также рост, хотя и гораздо более скромный, показывает Safari. Тенденция эта очевидно связана с успехами устройств на iOS. На сегодня это третья по распространенности операционная система, и влияет она на популяризацию браузера Apple как напрямую, так и опосредованно — многие предпочитают пользоваться на всех своих компьютерах, больших и малых, одним и тем же браузером, ради максимально предсказуемых результатов.

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

Интерфейс

Если отвлечься от некоторых оформительских деталей, то все новейшие браузеры — близнецы-братья, поскольку так или иначе эксплуатируют сходные идеи. Вкладки для отдельных веб-страниц — одна из наиболее известных и старых, хотя каждая реализация и отличается какими-то нюансами. Последнее веяние — упрощение пользовательского интерфейса ради максимального освобождения экранного пространства для рабочей поверхности. Тенденция не вполне однозначная. Она обусловлена популяризацией устройств с малыми форм-факторами, начиная от нетбуков и заканчивая новомодными планшетами. То, что среди последних почти единолично правит бал iPad (хотя Safari парадоксальным образом остался единственным браузером, окно которого украшено строкой заголовка) — явление временное. На подходе легион устройств на Andro >

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

К исключениям можно отнести разве что модернизацию адресной строки, теперь одновременно играющей роль и поисковой, а также развитие экспресс-панели, которая всё в большей степени приобретает самостоятельную функциональную роль, обеспечивая оперативный доступ к часто посещаемым сайтам, специальным инструментам и пр. В Opera 11.10, к примеру, такая панель называется Speed Dial, пользователь может гибко управлять эскизами страниц на ней, а разработчики — превращать их в своеобразные «информеры» (аналоги виджетов).

HTML5

Сегодня, пожалуй, новой версии стандарта HTML уделяется чрезмерное внимание. Безусловно, HTML5 нужен и важен уже хотя бы потому, что основные его новации направлены на расширенную поддержку веб-приложений. Однако в разработке (инициированной создателями браузеров) он находится с 2004 г., а W3C официально подключился к процессу только в 2007 г. На текущий момент все спецификации еще находятся в черновиках, одни более стабильны, другие менее, но текущая распространенность браузеров прежнего поколения говорит о том, что скорой повальной миграции Веба на HTML5 ждать не следует.

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

Результаты теста www.html5test.com

Браузер Баллы (из 400 возможных) Бонусы
Chrome 11 293 13
Firefox 4 255 9
Internet Explorer 9 130 5
Opera 11.10 258 7
Safari 5.05 187

Как видно из таблицы, текущий уровень поддержки HTML5 заметно различается. Однако надо учитывать следующее: во-первых, подобные тесты никогда не охватывают весь стандарт; во-вторых, баллы начисляются за отдельные функции, которых для одних объектов может быть больше, чем для других (что само по себе не говорит ни о важности, ни о сложности реализации); в-третьих, часть спецификаций, причем довольно сложных в функциональном плане, все еще находится на стадии обсуждения, и номинальная их поддержка мало о чем говорит. Microsoft, к примеру, некоторые API, вроде WebSockets или FileAPI, предпочитает разрабатывать и распространять отдельно. А результаты Safari 5.05 хуже, чем у версии 5.04 (228 и 7 бонусов). По-видимому, для его разработчиков стабильность функционирования оказалась важнее поддержки сырых спецификаций.

На самом деле, существуют более подробные тесты, где результаты и лидеры могут быть совершено иными. Но, повторимся, на нынешнем этапе это мало о чем говорит. Тем не менее, приятно отметить, что наиболее интересные с точки зрения пользователя части HTML5, как то: теги audio, video, canvas или специальный кэш Web Storage и Geolocation API — уже в достаточной мере поддерживаются всеми браузерами, т. е. никто не будет обделен (как говорит Microsoft) «всеми красотами Интернета». Правда, кое-какие казусы все-таки случаются: так, если Internet Explorer и Safari для встроенного аудио и видео поддерживают форматы AAC, MP3 и H.264, то все прочие ратуют за свободные от лицензионных отчислений Ogg Theora, Vorbis и WebM VP8. Впрочем, опять же, в конечном итоге все должно быть хорошо: Google пообещала помочь пользователям Internet Explorer с WebM, а Microsoft, в свою очередь, не оставит без внимания Chrome и Firefox, благо теги audio и video позволяют одновременно описывать различные варианты своего содержимого.

JavaScript

Качество поддержки скриптов также становится все важнее по мере движения в сторону веб-приложений, поэтому неудивительно, что старт гонке JavaScript-машин дала Google. За последнюю пару лет их производительность выросла в разы, и данный процесс далек от завершения. Тем более, что производительность — понятие довольно относительное и адекватной оценке поддается с большим трудом. Проиллюстрируем это на нескольких популярных тестах:

Тесты производительности JavaScript

Браузер Браузер SunSpider 0.9.1, мс
(меньше лучше)
V8 Benchmark (v6)
(больше лучше)
Kraken, мс
(меньше лучше)
Futeremark Peacekeeper
(больше лучше)
Chrome 11 552 4262 12609 3563
Firefox 4 512 2063 15714 2566
Internet Explorer 9 427 1354 28011 2625
Opera 11.10 545 2054 29199 4618
Safari 5.05 685 1473 н/д 2716

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

Полагаясь же на нынешние тесты, как видим, однозначные выводы сделать нельзя. Более того, во многих случаях результаты зависят от таких нюансов, о которых обычному пользователю даже сложно догадаться. К примеру, в интернете нередко можно встретить результаты указанных здесь тестов, в которых Internet Explorer демонстрирует в несколько раз худшую производительность. Они проводятся на 64-разрядной Windows и именно здесь-то и кроется подвох — Microsoft вовсе не случайно предлагает использовать в ней 32-разрядный браузер, а, казалось бы, логичный переход на «родную» разрядность является ошибкой. Оказывается, в 64-разрядном Internet Explorer 9 отсутствует JIT-компилятор JavaScript, так что производительность его остается на уровне голого интерпретатора. Причина же такого явления в том, что 64-разрядный браузер сегодня развивается Microsoft по остаточному принципу, так как популярность его растет недостаточно быстро, в первую очередь из-за медленной миграции плагинов.

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

Браузер Время выполнения теста, с Относительно IE10
(больше хуже)
Chrome 10.0.648.205 2.801 4.9
Firefox 4.0.1 0.956 1.7
IE 9.0.8112.16421 1.159 2.0
IE 10.0.1000.16394 0.562 1.0
Opera 11.10 1.106 1.9
Safari 5.0.5 0.984 1.7

Картина снова отличается от предыдущих, так что окончательные выводы делайте сами.

Графика

Однако не скриптами едиными определяется производительность браузера, большую роль играет также собственно рендеринг элементов страниц. Причем именно сейчас, в силу повышенного внимания к HTML5, этот аспект приобретает особое звучание. Действительно, работа с видео и насыщенной графикой — а HTML5 позволяет создавать даже несложные игры, например старый добрый Pacman, — требует немалых вычислительных ресурсов. В обычных приложениях для этих целей стараются задействовать аппаратные возможности графических акселераторов, и вполне логично перенести эту же практику на Веб (обратите внимание, что браузеры при этом начинают играть такую же платформенную роль, как ОС).

Локомотивом данного движения стала Microsoft, которая, впрочем, в некотором смысле находится в более выгодном положении, чем конкуренты — в отличие от них ей не нужно обеспечивать кроссплатформенность своих решений, так что в Windows она может выжать максимум. Этим же объясняется, почему не выпущен Internet Explorer 9 для Windows XP — старая ОС, кроме всего прочего, не поддерживает Direct2D, а следовательно, требует отдельной реализации. Сегодня уже все разработчики браузеров так или иначе заявляют о поддержке аппаратного ускорения графики, но реальное представление о текущем положении дел дает следующая таблица с результатами тестов:

Браузер Mozilla Hardware Acceleration Stress Test, fps Microsoft Fishbowl Benchmark, fps
Chrome 11 9 3
Firefox 4 55 29
Internet Explorer 9 60 60
Opera 11.10 11 2
Safari 5.05 3 2

Тут ситуация абсолютно прозрачная, и нет никаких сомнений, кто лидирует. На сайте ie.microsoft.com имеется большое число других демонстрационных приложений, которые можно использовать в качестве тестов, но результаты во всех будут аналогичны. Справедливости ради скажем, что все разработчики браузеров, кроме, естественно, Microsoft, также трудятся над поддержкой WebGL — спецификации аппаратного ускорения рендеринга HTML5 индустриального консорциума Khronos. В современных Chrome и Firefox она уже присутствует в достаточной мере, Opera и Safari ее пока тестируют в предварительных сборках.

Браузер Khronos WebGL Particles, FPS Google WebGL Aquarium, FPS
Chrome 11 55 27
Firefox 4.0 50 22

Безопасность

Эта характеристика сколь важна, столь и сложна в оценке. К сожалению, здесь нет четких критериев, а каждое исследование вызывает подозрения со стороны как пользователей, так и экспертов. Расхожее мнение к более безопасным относит открытые разработки, хотя формальные подсчеты числа обнаруженных уязвимостей и средней скорости исправления никогда не показывали их реального превосходства. Правда, с Internet Explorer (обычно с устаревшими версиями) было связано несколько довольно громких инцидентов, что существенно подпортило его репутацию. Хотя, с другой стороны, с точки зрения защищенности от социальных атак лучшим неоднократно признавался именно браузер Microsoft.

Неплохим аргументом, пожалуй, являются результаты ежегодных хакерских соревнований Pwn2Own, на которых предлагается взламывать браузеры. Первым всякий раз капитулирует Safari (причем на Mac OS X) и вовсе не только из-за привлекательности приза, каковым является ноутбук с предустановленной испытуемой системой. Эксперты по безопасности свидетельствуют, что в WebKit имеется достаточно уязвимостей, чтобы найти подходящую к каждому соревнованию. С другой стороны, Chrome, использующий тот же веб-движок, два года кряду остается неуязвимым, несмотря на то, что Google назначает дополнительный солидный приз. В этом заслуга очень эффективной «песочницы» Chrome, которая не позволяет атакующему коду добраться до ОС. Остается добавить, что Internet Explorer взламывается регулярно, Firefox также довольно часто, нередко через плагины. Opera, к сожалению, не участвует в этих соревнованиях, ввиду малой распространенности в мировом масштабе.

Но работы над совершенствованием различных аспектов безопасности браузеров не прекращаются, и новые решения появляются практически в каждой очередной версии. В частности, все современные браузеры поддерживают приватный режим функционирования, в котором не сохраняются следы посещенных веб-сайтов. В Internet Explorer 9, кроме того, реализован механизм Tracking Protection, блокирующий на веб-страницах элементы, следящие за перемещением пользователя. Работает он по принципу черного списка, который может формироваться браузером автоматически или загружаться из внешних источников. В Firefox 4 появилась похожая функция, но она основана на необязательной поддержке со стороны самих веб-сайтов, т. е. значительно менее эффективна.

В Internet Explorer 9 также появилась блокировка ActiveX — она активируется глобально, затем ее можно отключать для отдельных сайтов либо для конкретных элементов. Впрочем, рассматривать это а качестве преимущества браузера Microsoft нельзя, так как речь идет о закрытой частной технологии, как раз и ставшей источником уязвимостей.

Полезная новинка в Opera — автоматическое упрощение URL в том случае, когда реальное имя сайта назначения передается (как правило, злонамеренно) в качестве параметра.

Синхронизация

Значение синхронизации трудно переоценить, поскольку браузеры используются на всё большем разнообразии устройств, включая планшеты, смартфоны, электронные книги и пр. Долгое время соответствующая функциональность реализовывалась плагинами и специальными сервисами, но сегодня уже стала фактически стандартной. И понятно почему: встроенная синхронизация является мощным инструментом конкурентной борьбы, ведь привязавшись к конкретному браузеру на одной платформе или устройстве, пользователь с большой вероятностью воспользуется таким же и на другой. По этой же причине постоянно расширяется и список синхронизируемых объектов — к закладкам уже добавились пароли, данные форм, информация о вкладках и пр.

Пожалуй, лучше всего синхронизация реализована в Chrome: в частности, удобно сделана возможность шифрования данных по обычному паролю Gmail. Хотя с точки зрения безопасности это, возможно, и не самое удачное решение, но если речь не идет ни о чем суперсекретном, а сам пароль достаточно сложен, то вполне допустимое. Тем более на фоне реализации Firefox 4, который обязательно шифрует синхронизируемую информацию, но при подключении новых устройств вместе с обычными регистрационными данными требует ввести довольно сложный ключ. Его, конечно, можно сохранить или распечатать, но, учитывая забывчивость даже подготовленных пользователей, можно представить себе количество будущих рекламаций — ведь после генерации нового ключа прежняя информация пропадает (о чем разработчики честно предупреждают). В Safari и Internet Explorer синхронизация обеспечивается внешними инструментами — MobileMe и Windows Live Mesh соответственно. Они гораздо скромнее с точки зрения поддержки именно браузера, но тот же Windows Live Mesh представляет самостоятельную ценность, благодаря синхронизации файлов, использованию хранилища SkyDrive, удаленному управлению подключенными компьютерами.

Частности

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

Chrome 11, как уже говорилось выше, пожалуй, наиболее защищенный и безопасный от прямых атак через Веб, что обеспечивается в том числе и его внутренней архитектурой: в отдельных процессах запускаются не только каждая вкладка, но и экземпляры JavaScript-машины, и даже наиболее тяжелые плагины (к примеру, Adobe Flash). Хотя с другой стороны, это приводит к повышенному потреблению памяти. Основные доработки 10-й версии были направлены на улучшение производительности и исправление ошибок, плюс небольшие изменения в интерфейсе (HTML-страница с опциями), в 11-й появился голосовой ввод на базе HTML5 (проверить можно на Google Translate, пока только для английского языка), который, впрочем, требует определенной работы от создателей сайтов. И все же главное достоинство Chrome — максимально гладкая работа с сервисами самой Google, как на десктопах, так и на Andro >

Firefox продолжает оставаться вторым по популярности браузером после Internet Explorer, хотя в последнее время его доля стабилизировалась и даже несколько уменьшается. Тем не менее, по последним данным, Firefox 4, доступный и для Windows XP, загрузили как минимум вдвое больше пользователей, чем Internet Explorer 9, хотя последний появился раньше. Кроме тех новинок, что упоминались в общих разделах, в Firefox 4 улучшена работа с вкладками веб-страниц. Во-первых, теперь применяется «гибридная» схема, когда ярлычки по мере открытия новых кладок уменьшаются, как в Chrome и Opera, но только до определенного предела, после чего «лишние» прячутся и пролистываются, как в Internet Explorer. Во-вторых, вкладки можно объединять в группы — впрочем, реализация этой функции понравится далеко не всем. Наконец, в-третьих, появились так называемые App Tabs — автоматически открываемые вкладки, ярлычки которых постоянно закреплены в левой части окна. Кроме того, был заметно переработан менеджер плагинов, широкое разнообразие которых является одним из главных козырей Firefox. Впрочем, с плагинами же нередко связываются и претензии — с каждым новым релизом браузера начинается эпопея с их совместимостью, и похоже, что именно из-за них в Firefox частенько случаются утечки памяти. К плюсам последней версии можно также отнести всестороннюю поддержку аппаратного ускорения рендеринга HTML5, наиболее широкую среди всех браузеров.

Internet Explorer 9 появился после большой задержки, и по многим пунктам Microsoft оказалась в роли догоняющего. Так, к примеру, трудно отнести к преимуществам встроенный менеджер загрузок, поскольку во всех прочих браузерах он появился давным давно. Злую шутку с корпорацией также сыграло прежнее игнорирование стандартов, теперь приходится поддерживать режимы совместимости и всячески открещиваться от Internet Explorer 6. К недостаткам Internet Explorer традиционно относят моноплатформенность, однако для большинства пользователей это совершено не критично. Зато новый браузер Microsoft обеспечивает лучшую поддержку интерфейсных функций Windows 7: к примеру, сайты можно закреплять на панели задач, а их разработчики могут даже сформировать для них специальное меню (так называемый jump list), так что веб-приложения станут практически неотличимы от обычных. Аналогично, Microsoft обеспечивает пока лучшую поддержку аппаратного ускорения рендеринга HTML5. К другим достоинствам можно отнести также удачную реализацию инструментов работы с плагинами (в частности, отключение наиболее долго загружаемых) и защиты от социальных атак.

Opera 11.10. Нынешнее обновление Opera не такое существенное, как у других участников, тем не менее в норвежском браузере появилось несколько интересных новинок. Одна из них — поддержка нового графического формата WebP и его использование в функции Turbo (вместо JPEG), обеспечивающей загрузку компрессированных веб-страниц через сервер Opera. Ожидается, что WebP сделает ее еще эффективнее, по информации самих разработчиков — до полутора раз на отдельных сайтах. Opera, несмотря на свою небольшую распространенность в мире (феномен ее популярности в СНГ заслуживает отдельного изучения), является своего рода законодателем мод: достаточно вспомнить, что именно этот браузер дал путевку в жизнь вкладкам, без которых работа с Вебом сегодня уже немыслима. Сегодня любимым детищем разработчиков явно стала панель Speed Dial, эскизы на которой могут служить не только кнопками запуска сайтов, но и своеобразными «информерами» для них. Пожалуй, именно дополнительные функции (среди которых, кроме Turbo, и встроенный почтовый клиент, и многое другое) и являются главным козырем десктопной Opera, хотя не всем пользователям они нужны в равной мере. Кроме того, это по-прежнему самый компактный и легковесный браузер, хотя и несколько нестабильный.

Обновление Safari до версии 5.05 еще менее значительно, фактически это только исправление ошибок. До пятой версии аргументов для использования Safari в Windows практически не было. Затем появился механизм расширений, была улучшена производительность и пр. Главный интерес к Safari, конечно, исходит от пользователей продукции Apple, прежде всего смартфонов и планшетов, в том числе разработчиков мобильных веб-приложений. К достоинствам браузера можно отнести вполне передовой движок рендеринга (который в свое время был выбран Google для Chrome), но только если не касаться вопросов безопасности, а также некоторые вспомогательные функции, вроде Reader, который умеет «очищать» основную статью веб-страницы от лишних деталей и даже объединять ее из нескольких фрагментов. Отметим также, что десктопный Safari доступен только для Windows (в том числе XP) и Mac OS X. И кстати, Safari — единственный из альтернативных браузеров по умолчанию показывает эскизы отдельных вкладок в панели задач Windows 7, в остальных нужно искать соответствующие настройки.

Оптимизация выполнения JavaScript

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

  • Не используйте функции setTimeout или setInterval для внесения визуальных изменений; вместо этого всегда пользуйтесь функцией requestAnimationFrame .
  • Перемещайте скрипты JavaScript, которые выполняются долго, за пределы основного потока в рабочие веб-процессы Web Worker.
  • Для внесения изменений в DOM-элементы за несколько кадров используйте микрозадачи.
  • Для оценки влияния JavaScript используйте шкалу времени и средство профилирования JavaScript из Chrome DevTools.

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

Note: Если вы хотите посмотреть JIT в работе, рекомендуем инструмент IRHydra 2 разработки Вячеслава Егорова. Этот образец демонстрирует промежуточное состояние кода JavaScript, когда его оптимизирует движок JavaScript браузера Chrome (V8).

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

Используйте функцию requestAnimationFrame для внесения визуальных изменений

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

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

Скажу больше, на сегодня для animate jQuery по умолчанию использует setTimeout ! Можно установить исправление, чтобы использовалась функция requestAnimationFrame , что настоятельно рекомендуется сделать.

Снижайте сложность или используйте рабочие веб-процессы Web Worker

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

Следует тактически грамотно выбирать время и продолжительность выполнения JavaScript. Например, если выполняется такая анимация, как прокрутка, идеальным будет выполнение JavaScript в течение первых 3–4 мс. Чуть дольше – и вы рискуете занять слишком много времени. Если же в данный момент никаких действий не выполняется, то за временем работы можно позволить себе следить не так строго.

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

Не вся работа годится для этой модели: у рабочих веб-процессов Web Worker нет доступа к DOM. Когда работу необходимо выполнять в основном потоке, подумайте об использовании пакетов, когда крупные задачи разбиваются на несколько микрозадач, каждая из которых занимает лишь несколько миллисекунд и выполняется внутри обработчиков requestAnimationFrame в каждом кадре.

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

Знайте, как ваш код JavaScript влияет на кадры

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

Лучше всего определять затраты на выполнение кода JavaScript и его профиль производительности с помощью Chrome DevTools. Обычно программа выдает не очень подробные записи следующего вида:

Если оказалось, что код JavaScript выполняется долго, в верхней части пользовательского интерфейса DevTools можно будет включить средство профилирования JavaScript:

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

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

Избегайте микрооптимизации кода JavaScript

Возможно, это круто ― знать, что браузер может выполнить одну версию кода в 100 раз быстрее, чем другую, например, что запросы или offsetTop элемента быстрее, чем вычисление getBoundingClientRect() . Однако почти всегда верно, что такие функции вызываются лишь несколько раз за кадр, поэтому уделять этой стороне работы JavaScript основное внимание – это просто пустая трата времени. Сэкономить удастся лишь доли миллисекунды.

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

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

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

3 главные ошибки, которые вредят производительности JavaScript

10’008 подписчиков
4’187 просмотров на пост

Настоящий клондайк для frontend-разработчиков.

Детальная рекламная статистика будет доступна после прохождения простой процедуры регистрации

  • Детальная аналитика 70’046 каналов
  • Доступ к 28’004’146 рекламных постов
  • Поиск по 112’332’059 постам
  • Отдача с каждой купленной рекламы
  • Графики динамики изменения показателей канала
  • Где и как размещался канал
  • Детальная статистика по подпискам и отпискам

Найдено 1152 поста

Design Patterns Game — игра на знание распространённых паттернов проектирования, реализованных на JavaScript

PSD landing pages

ТОП-13 крутых идей веб-проектов для прокачки навыков.

Причуды CSS Grid и абсолютного позиционирования.

Сегодня хочу порекомендовать вам канал @itlibrary с бесплатными IT книгами и журналами.

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

Читайте только нужную и актуальную IT литературу
➡️ https://t.me/itlibrary

Главное руководство по Flexbox — обучение на примерах.

​​Разберем React от «А» до «Я».

Составим актуальный план изучения React.js в 2к19. От знакомства с библиотекой до продвинутого использования совместно с Redux.

Подробнее о занятии:
— разберём, что такое React и для чего нужна эта библиотека
— составим план изучения React с конкретными темами
— вместе с преподавателем попрактикуемся в прямом эфире

Gooey loader. Приятный «жидкий» прелоадер для сайта.

hub — это расширение для git из командной строки, которое помогает вам выполнять повседневные задачи GitHub, даже не выходя из терминала.

DisplayJS — крошечный фреймворк, упрощающий синхронизацию данных с DOM. Вместо того, чтобы вручную устанавливать и обновлять содержимое страницы, с помощью DisplayJS вы можете просто сопоставлять (мапить) переменные JavaScript с определенными элементами HTML, аналогично тому, как работают шаблоны React или Vue.js.

YSlow — проведёт небольшой анализ загрузки не только страницы, но и отдельных составляющих сайта. Сервис проверяет вынесение заголовков, использование компрессии, а также вынесение скриптов в индивидуальные файлы, после чего предоставляет информацию по улучшению проекта. За основу берутся исследования Yahoo. Сервис предоставляется в виде расширения для всех топовых браузеров.

Web Code Tools — продвинутый инструмент работы с разными элементами CSS. Кроме того, можно генерировать код на HTML, JSON и ещё делать много разных интересностей.

​​Интересуетесь Data Science? С 2012 по 2020 годы количество вакансий специалистов в этой области выросло в 19 раз.

В онлайн-школе SkillFactory открылось целое направление «Специализация Data Scientist» → https://clck.ru/Ffmhw с полной комплексной программой, которую разработали при содействии практиков отрасли, чтобы дать студентам именно те навыки, которые ожидают видеть работодатели у начинающих data scientist.

Курсы Skillfactory известны упором на практику. В рамках специализации вы сможете закрепить и отработать все составляющие профессии Data Science: Python, классическое машинное обучение, нейросети и deep learning, основы Big Data и Data engineering.

Дополняет программу специально разработанный курс математики и статистики для Data Science и модуль менеджмента, который познакомит студентов с реалиями продакшена.
Успейте забронировать место на курсе со скидкой 20%

Мистический inline-flex
и что он делает.

Повышение эффективности ручного тестирования на Vue.js.

​​Неочевидный способ как Веб-разработчику зарабатывать больше.

Уже через неделю сможешь обеспечить себе дополнительный источник дохода!����

Разрабатываешь шаблоны один раз, а потом получаешь за них деньги.

Приходи на онлайн-занятие, на котором расскажу подробности.

Будем разбирать следующие вопросы:

��Создание шаблонов сайтов и их продажа
��Где найти покупателей на свои шаблоны
��Площадки для продажи шаблонов
��Как делать шаблоны, если нет навыков веб-дизайна
��Сколько можно заработать на шаблонах

Что такое JavaScript и чем он опасен?

JavaScript — специальный язык программирования, разработанный для использования в браузерах.

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

JavaScript — это специальный язык программирования, разработанный для использования в браузерах. Впервые он появился ещё в 1995 году в браузере Netscape Navigator и с тех пор его поддержка является международным стандартом для всех приличных браузеров (кроме, разве что, пожалуй, мобильных). JavaScript используется для написания небольших программ — скриптов, которые могут реагировать определённым образом на действия пользователей, открывших ту или иную web-страницу. Хорошей иллюстрацией использования JavaScript будут выпадающие меню, которые используются для навигации на многих сайтах во Всемирной паутине.

На самом деле использование JavaScript может быть куда шире, чем только для web-страниц. С помощью этого языка программирования можно создавать скрипты, автоматизирующие какие-либо рутинные операции, которые можно не выполнять вручную, а переложить на плечи программы.

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

Стоит отметить, что JavaScript является не единственным в своём роде языком программирования, применяемым для повышения интерактивности web-страниц. Internet Explorer поддерживает JScript, очень похожий на JavaScript, но всё-таки несколько отличный от него в некоторых деталях, а также совершенно отдельный язык VBScript. Однако, поскольку VBScript не поддерживается другими распространёнными браузерами, то и разработчики web-страниц используют его намного реже, чем JavaScript.

3 главные ошибки, которые вредят производительности JavaScript

Периодически натыкаясь на статьи, посвященные оптимизации кода на JS (вот одна из популярных) я ловил себя на мысли, что информации в них катастрофически мало. Перечислены 2–3 конструкции, 1–2 браузера и все на этом.

Как говорится, если хочешь сделать что-то хорошо, сделай это сам.

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

Ну и раз уж результаты получены, почему бы выложить их для всеобщего пользования?

Введение

Итак, машина для тестирования — P4 3GHz (двухядерный), 1,5Gb RAM, Vista 32-bit.

Набор браузеров — FF3, Opera 9.62, Chrome 1.0, IE7, IE8b2

Скажу сразу, что IE8 — не оригинальный, а запущенный через программу IETester

Насколько он соответствует оригинальному я не знаю, но, по крайней мере, от IE7 результаты отличаются довольно сильно, причем в различные стороны.

Если кто-то хочет протестировать IE6 или любой другой браузер — собственно, welcome )

Методология тестирования

Все нижеописанные языковые конструкции тестировались путем повторения 1 миллион раз в цикле. Данное действие повторялось несколько раз в каждом браузере, дабы выявить некий средний результат (он обычно колеблется в пределах +-2–5% в зависимости от текущей загрузки системы). Средний результат (в миллисекундах) записывался в таблицу.

Везде (где явно не указано другое) использовался инвертированный цикл for(var i=1000000; i—;) как наиболее быстрый.

Переходим к делу. Циклы

Тесты/Браузеры FF3 Opera Chrome IE7 IE8b2
Циклы
Классический цикл 71 100 16 238 218
Инвертированный цикл 34 34 7 70 118
while-цикл 30 33 7 70 118

Итак, для начала я решил протестировать сами циклы (просто пустые циклы без выполняемого кода внутри). Т.к. сказать основу нашего тестирования )

Про циклы уже было написано довольно много, так что результаты вполне предсказуемы.

Как видно, инвертированный цикл for(var i=1000000; i—;) как минимум вдвое быстрее классического for(var i=0; i , поэтому именно он использовался в дальнейшем тестировании.

Также можно заметить, что while цикл практически не отличается по скорости от инвертированного for , видимо потому что это фактически одна и та же конструкция (по логике работы).

Работа с массивами и объектами

Тесты/Браузеры FF3 Opera Chrome IE7 IE8b2
Перебор массивов и объектов
Получение значений большого массива (1M) по индексу (полный перебор в обратном порядке) 430 170 18 790 1020
Получение значения маленького массива (100) по индексу 124 146 18 428 515
For-in цикл по объекту (1M) 2020 2160 385 39400 35400
Перебор объекта (1M) через инвертированный цикл 390 170 18 745 746
Заполнение массивов и объектов
Заполнение (1M) массива через array.length 190 485 82 2640 865
Заполнение (1M) массива в прямом порядке через значение шага цикла (классический цикл) 200 432 75 2500 760
Заполнение (1M) массива в обратном порядке через значение шага цикла (инвертированный цикл) 1180 310 124 2270 2260
Заполнение (1M) массива через push() 176 1120 98 4450 1186
Заполнение объекта (1M) в прямом порядке через значение шага цикла (классический цикл) 1080 368 74 2400 2205

Эта часть посвящена работе с массивами и объектами-заменителями. Под объектом-заменителем в данном тесте имеется в виду объект (типа Object), использующийся исключительно как замена массиву (т.е. не содержащий никаких свойств, кроме элементов как бы массива). Интересовала скорость работы таких заменителей.

Массив (или объект) 1M — имеется в виду массив (или его заменитель) с кол-вом элементом равным 1000000, ну и индексами (ключами) соответственно от нуля до миллиона (точнее, 999999).

В первом тесте мы полностью перебираем такой массив в инвертированном цикле, т.е. примерно вот так:

Во втором тесте мы также делаем миллион итераций цикла, но на каждом шаге получаем одно и то же значение из маленького массива (размером 100 элементов). Этот тест я сделал для проверки того, насколько размер массива влияет на скорость получения из него значений.

Как показал тест, во всех браузерах кроме Chrome время поиска значения в массиве может значительно возрасти с ростом кол-ва его элементов.


В третьем тесте делается полный for-in цикл по объекту-заменителю массива.

Хорошо видно, что цикл for-in является очень медленным во всех браузерах (по сравнению с инвертированным for ), и ОЧЕНЬ медленным в IE для больших объемов данных. Никогда не используйте его для перебора массивов или объектов, где можно обойтись циклом for (т.е. ключи числовые и упорядоченные).

Четвертый тест — полный аналог первого теста, кроме того что big_array является не массивом, а объектом.

Заметно, что скорость перебора через цикл слабо зависит от того, массив у нас или объект-заменитель. Ощутимая разница только в IE8, но это еще бета, так что все может измениться.

Также стоит заметить, что если перед нами стоит задача выбрать диапазон элементов массива то использование метода array.slice() в любом браузере в несколько раз быстрее, чем просто перебор массива в цикле с выборкой нужных элементов по условию. Разница настолько очевидна, что я даже не стал включать это в тест.

Помимо перебора массивов, часто приходится их заполнять, поэтому следующие 5 тестов как раз об этом.

В принципе, из таблицы все должно быть понятно:

  • Заполнение массива через метод push значительно медленнее во всех браузерах, кроме FF, по сравнению с заполнением через array[array.length]=value . (Разработчики огнелиса видимо единственные поняли, что это полное безобразие, когда вместо родного метода используется громоздкая конструкция.)
  • В некоторых браузерах бывает важно, заполняете ли вы массив в прямом или обратном порядке.
  • Заполнение объекта-заменителя значительно медленнее в FF и IE8, видимо потому что операция заполнения массива специально оптимизирована, а заполнения объекта нет (что и понятно, потому что объект не должен использоваться вместо массива для хранения больших объемов однородных данных).

Функции, объекты, переменные

Тесты/Браузеры FF3 Opera Chrome IE7 IE8b2
Функции, объекты, переменные
Вызов пустой функции с передачей ей текущего значения цикла 129 270 17 3100 860
Создание объекта (создание 2 методов и одного свойства через конструктор) 2460 1900 593 18600 11700
Создание объекта (создание 2 методов из прототипа и одного свойства через конструктор) 1260 636 64 7830 4210
Получение свойства объекта (собственное свойство) 84 142 16 406 412
Получение свойства объекта (свойство прототипа) 90 147 29 474 474
Получение свойства объекта (метод-геттер приватного var свойства) 260 354 33 3430 1160
Вызов инкрементного метода объекта (увеличивает собственное свойство через this) 326 460 60 3810 1520
Вызов инкрементного метода объекта (увеличивает собственное свойство через явное указание объекта) 356 520 65 3985 1633
Вызов инкрементного метода объекта (увеличивает приватное var свойство) 412 370 38 3530 1320

В первую очередь, я протестировал вызов пустой функции в цикле.

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

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

Отмечу, что медленный вызов функции как таковой отрицательно влияет и на другие тесты, связанные с вызовом функций (например, создание объекта или вызов метода), поэтому время их выполнения в IE еще сильнее увеличивается.

Следующие 2 теста посвящены созданию миллиона объектов, в одном случае все методы создаются через конструктор, в другом — через прототип.

Разница, я думаю, очевидна.

Три следующих теста вызывают свойство объекта: собственное свойство (созданное через this.prop=value ), свойство прототипа и приватное свойство (созданное через замыкание из функции конструктора). Очевидно, что последний вариант получаем через геттер.

Результат, в общем, предсказуем — собственное свойство объекта можно получить значительно быстрее.

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

Наглядно видно, что в данном случае скорость изменения приватного свойства выше везде, кроме Firefox, однако нужно помнить, что такое свойство является общим для всех однотипных объектов и имеет худшее время чтения снаружи (через геттер).

Ветви

Тесты/Браузеры FF3 Opera Chrome IE7 IE8b2
Ветви
Выбор ветви из 8 возможных через if 800 500 60 1500 1460
Выбор ветви из 8 возможных через switch 315 334 54 868 1039
Выбор ветви из 8 возможных через хэш функций 620 400 86 4520 1820

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

Хэш функций — это объект, эмулирующий своим поведением switch.

Например, у нас есть такой кусок кода:

Тогда хэш функций будет выглядеть так:

И использоваться так b=hash[a]();

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

Общий вывод по браузерам

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

Заключение

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

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

С другой стороны, тот метод, который сегодня вызывается сто раз, завтра может вызываться уже десять тысяч раз, так что совсем уж махать рукой на это дело не стоит. И если что-то где-то начало тормозить, будет хотя бы понимание, в какую сторону следует «копать» ).

Повышаем производительность клиентской части веб-приложения

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

Области видимости

Объяснять, что глобальные переменные — это зло, не надо — это и так понятно. Но почему зло и насколько оно большое, мы попробуем разобраться. Возьмем для примера простой код, совершающий обход массива и производящий с каждым элементом какое-нибудь простое действие. Создадим массив из 100 000 элементов и запишем в каждый из них случайное число.

Здесь в функции осуществляется обход массива, находящегося в глобальной области видимости. Интерпретатор, увидев в условии arr.length, начинает поиск переменной arr. Первым делом он ищет в локальной области видимости, то есть внутри функции. Однако внутри функции переменная arr не объявлена. Тогда интерпретатор переходит в цепочке областей видимости на уровень выше (в нашем случае, к счастью, — сразу в глобальную область, хотя могло быть и хуже) и осуществляет поиск там. Тут он наконец находит переменную arr и ищет у содержащегося в ней объекта свойство length. Поиск по каждой области видимости занимает драгоценное время. Попробуем переписать функцию так, чтобы ей не приходилось на каждой итерации цикла обращаться в другие области видимости.

Такая, казалось бы, мелкая оптимизация дает в Chrome удивительный прирост производительности — в 2,5 раза (35 мс вместо 81). В Firefox прирост менее ощутим, но тоже есть: 54 мс вместо 60, то есть на 10%. В Opera 12 время выполнения сокращается еще менее значительно: с 99 до 95 мс.

Что касается работы с массивом, то мы можем дополнительно оптимизировать тело цикла, использовав вместо обращения к каждому конкретному элементу массива метод push:

Методы встроенных объектов благодаря низкоуровневым оптимизациям в движках почти всегда работают быстрее, чем вручную написанные на JavaScript аналоги. Особенно разница в производительности между встроенными методами и собственноручно написанными аналогами заметна в Firefox, Opera, Safari и IE. В V8 (Chrome) большая часть встроенных JavaScript-методов написана на том же JavaScript, поэтому прирост скорости работы не так велик.

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

лучше написать такой:

А еще лучше — сделать так, чтобы даже для получения объекта document функции не приходилось искать в глобальном пространстве имен:

Здесь мы передали объект document в анонимную функцию в качестве аргумента, таким образом перенесли его в локальное для этой функции пространство имен. Этот же паттерн принято использовать в плагинах jQuery:

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

Время доступа к различным областям видимости в разных браузерах, мс

Хакер #182. Все о Bitcoin

Циклы

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

Простой и очень красивый прием сокращения времени работы цикла состоит в том, чтобы изменить направление обхода на противоположное, то есть вместо

Применив эту оптимизацию к предыдущему примеру, получаем:

В Chrome этот прием в данном случае дает прирост производительности в 10% (с 32 до 29 мс), в Opera 12 время выполнения практически не меняется (923 и 939), однако в Firefox и IE оно сокращается в два раза: c 1030 до 525 мс для Firefox и с 1705 до 812 для IE. Чтобы разобраться в причинах такого эффекта, разберем все операции, которые производит интерпретатор на каждой итерации цикла.

В первом случае последовательность действий будет такой:

    Вычислить значение булева выражения i Время работы цикла в разных браузерах, мс

Функции и методы

Когда одна и та же функция вызывается неоднократно, полезно будет использовать прием «мемоизации» или, говоря проще, кеширования возвращаемого значения. Особенно этот прием полезен в том случае, если функция выполняет какие-то длительные операции. Рассмотрим его на примере вычисления факториала числа. Классическая рекурсивная функция вычисления факториала выглядит так:

Она выполняется достаточно быстро сама по себе, однако на ее примере можно красиво продемонстрировать прием мемоизации.

Кеш значений доступен через замыкание, это исключает его непреднамеренное изменение — доступ к нему имеет только функция factorial. Допустим, нам нужно последовательно вычислить факториалы 100, 101 и 102. При использовании классической рекурсивной функции мы сначала вычислим факториал числа 100 (100! = 100 * 99 * 98 . * 1 или 100 * 99!), затем — числа 101 (101! = 101 * 100 * 99 . * 1 или 101 * 100!), а затем — факториал числа 102 (102! = 102 * 101 * 100 . * 1 или 102 * 101!). Таким образом, факториал числа 101 вычислится дважды, а числа 100 — аж трижды. Мемоизация значений позволяет этого избежать. При использовании кеширования результатов мы сначала вычисляем значение 100!, а при вычислении 101! повторные вычисления производиться не будут. Вместо этого из кеша будет извлечено уже вычисленное значение 100, умножено на 101 и возвращено. Таким образом мы избегаем огромного количества необязательных вычислений. Особенно ярко эффект мемоизации заметен при выполнении медленных, ресурсоемких операций (например, работы с DOM-деревом). Однако при использовании этого приема нужно быть уверенным в том, что при каждом последующем вызове функции с одними и теми же аргументами возвращаемый ею результат должен быть тем же, что и в предыдущий раз. Поэтому кеширование не подходит для обработки динамически изменяющихся данных.

Работа с DOM

Операции с DOM-деревом — одни из самых медленных в JavaScript. Джон Хрватин из Microsoft сравнил DOM и JavaScript с двумя островами, связанными мостом с платным проездом. Платить, конечно же, приходится производительностью. Поэтому для того, чтобы увеличить скорость работы клиентской части приложения, стоит минимизировать количество пересечений этого моста. Самое простое и очевидное — сохранять многократно используемые HTML-элементы в переменные.

Однако и это еще не все. Столь же долго, как и операции получения элемента DOM, выполняются операции перерисовывания страницы. Рендеринг страницы происходит каждый раз, когда ты изменяешь форму элементов: изменяешь в блоках текст, добавляешь новые блоки в layout страницы, изменяешь стили элементов. Чтобы минимизировать время, которое браузер тратит на перерисовывание страницы, необходимо объединять несколько идущих друг за другом операций, меняющих вид документа, в одну везде, где это возможно.

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

Заключение

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

Измерение времени работы скрипта

Простейший способ измерить время работы:

Больше возможностей предоставляет библиотека YUI — в нее включен мощный модуль профилирования. Также инструменты профилирования, позволяющие количественно измерить производительность, имеются в «Инструментах разработчика» любого современного браузера. Подробное описание работы с ними можно найти в книге Николаса Закаса «JavaScript: Оптимизация производительности» или, как и многое другое, в официальной документации к браузеру.

Браузеры снова на тропе войны

О соревновании разработчиков браузеров за нашу с вами привязанность принято говорить не иначе как о «войне», хотя после бесславной гибели Netscape реальных «боевых действий» фактически не было — так, мелкие стычки. Даже успешная «вылазка» Opera и прошлогоднее принуждение Microsoft к реализации специального окна выбора браузеров в Европе принципиально ничего не изменили, все процессы продолжили развиваться согласно текущим трендам. Однако нынешняя весна, пожалуй, сделала военную риторику более оправданной — достаточно лишь совсем коротко вспомнить, сколько всего интересного произошло за март-апрель:

  • Microsoft выпустила Internet Explorer 9, а меньше чем через месяц представила Internet Explorer 10 Preview;
  • Apple обновила Safari до 5.04 и почти сразу же до 5.05;
  • Google выпустила Chrome 10, а практически через месяц и Chrome 11;
  • вышел Firefox 4, Firefox 5 обещан в конце июня;
  • Opera 11.10 выпущена менее чем через месяц после начала публичного бета-тестирования.

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

Формально за такую «гонку вооружений» мы должны благодарить Google, которая штампует очередные версии, невзирая на реальное количество новшеств в них. Вообще говоря, практика сомнительная, не слишком осведомленного пользователя подобная игра цифрами может ввести в заблуждение. С другой стороны, на цифры можно и вовсе не обращать внимания — тот же Chrome обновляется автоматически, практически незаметно, а отсутствие больших отличий — возможно, даже благо для неопытных пользователей. И тем не менее, ускоренная «накрутка» версий, судя по всему, приносит Google свои плоды. Статистика Net Applications недвусмысленно демонстрирует, что последнее время именно Chrome отбирает долю мирового рынка и у Internet Explorer, и даже у Firefox. Да-да, популярность последнего начала снижаться, и, вероятнее всего, именно потому, что его разработчики слишком долго выводили новую большую версию. Если более внимательно всмотреться в упомянутую статистику, то нетрудно заметить, что также рост, хотя и гораздо более скромный, показывает Safari. Тенденция эта очевидно связана с успехами устройств на iOS. На сегодня это третья по распространенности операционная система, и влияет она на популяризацию браузера Apple как напрямую, так и опосредованно — многие предпочитают пользоваться на всех своих компьютерах, больших и малых, одним и тем же браузером, ради максимально предсказуемых результатов.

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

Интерфейс

Если отвлечься от некоторых оформительских деталей, то все новейшие браузеры — близнецы-братья, поскольку так или иначе эксплуатируют сходные идеи. Вкладки для отдельных веб-страниц — одна из наиболее известных и старых, хотя каждая реализация и отличается какими-то нюансами. Последнее веяние — упрощение пользовательского интерфейса ради максимального освобождения экранного пространства для рабочей поверхности. Тенденция не вполне однозначная. Она обусловлена популяризацией устройств с малыми форм-факторами, начиная от нетбуков и заканчивая новомодными планшетами. То, что среди последних почти единолично правит бал iPad (хотя Safari парадоксальным образом остался единственным браузером, окно которого украшено строкой заголовка) — явление временное. На подходе легион устройств на Andro >

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

К исключениям можно отнести разве что модернизацию адресной строки, теперь одновременно играющей роль и поисковой, а также развитие экспресс-панели, которая всё в большей степени приобретает самостоятельную функциональную роль, обеспечивая оперативный доступ к часто посещаемым сайтам, специальным инструментам и пр. В Opera 11.10, к примеру, такая панель называется Speed Dial, пользователь может гибко управлять эскизами страниц на ней, а разработчики — превращать их в своеобразные «информеры» (аналоги виджетов).

HTML5

Сегодня, пожалуй, новой версии стандарта HTML уделяется чрезмерное внимание. Безусловно, HTML5 нужен и важен уже хотя бы потому, что основные его новации направлены на расширенную поддержку веб-приложений. Однако в разработке (инициированной создателями браузеров) он находится с 2004 г., а W3C официально подключился к процессу только в 2007 г. На текущий момент все спецификации еще находятся в черновиках, одни более стабильны, другие менее, но текущая распространенность браузеров прежнего поколения говорит о том, что скорой повальной миграции Веба на HTML5 ждать не следует.

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

Результаты теста www.html5test.com

Браузер Баллы (из 400 возможных) Бонусы
Chrome 11 293 13
Firefox 4 255 9
Internet Explorer 9 130 5
Opera 11.10 258 7
Safari 5.05 187

Как видно из таблицы, текущий уровень поддержки HTML5 заметно различается. Однако надо учитывать следующее: во-первых, подобные тесты никогда не охватывают весь стандарт; во-вторых, баллы начисляются за отдельные функции, которых для одних объектов может быть больше, чем для других (что само по себе не говорит ни о важности, ни о сложности реализации); в-третьих, часть спецификаций, причем довольно сложных в функциональном плане, все еще находится на стадии обсуждения, и номинальная их поддержка мало о чем говорит. Microsoft, к примеру, некоторые API, вроде WebSockets или FileAPI, предпочитает разрабатывать и распространять отдельно. А результаты Safari 5.05 хуже, чем у версии 5.04 (228 и 7 бонусов). По-видимому, для его разработчиков стабильность функционирования оказалась важнее поддержки сырых спецификаций.

На самом деле, существуют более подробные тесты, где результаты и лидеры могут быть совершено иными. Но, повторимся, на нынешнем этапе это мало о чем говорит. Тем не менее, приятно отметить, что наиболее интересные с точки зрения пользователя части HTML5, как то: теги audio, video, canvas или специальный кэш Web Storage и Geolocation API — уже в достаточной мере поддерживаются всеми браузерами, т. е. никто не будет обделен (как говорит Microsoft) «всеми красотами Интернета». Правда, кое-какие казусы все-таки случаются: так, если Internet Explorer и Safari для встроенного аудио и видео поддерживают форматы AAC, MP3 и H.264, то все прочие ратуют за свободные от лицензионных отчислений Ogg Theora, Vorbis и WebM VP8. Впрочем, опять же, в конечном итоге все должно быть хорошо: Google пообещала помочь пользователям Internet Explorer с WebM, а Microsoft, в свою очередь, не оставит без внимания Chrome и Firefox, благо теги audio и video позволяют одновременно описывать различные варианты своего содержимого.

JavaScript

Качество поддержки скриптов также становится все важнее по мере движения в сторону веб-приложений, поэтому неудивительно, что старт гонке JavaScript-машин дала Google. За последнюю пару лет их производительность выросла в разы, и данный процесс далек от завершения. Тем более, что производительность — понятие довольно относительное и адекватной оценке поддается с большим трудом. Проиллюстрируем это на нескольких популярных тестах:

Тесты производительности JavaScript

Браузер Браузер SunSpider 0.9.1, мс
(меньше лучше)
V8 Benchmark (v6)
(больше лучше)
Kraken, мс
(меньше лучше)
Futeremark Peacekeeper
(больше лучше)
Chrome 11 552 4262 12609 3563
Firefox 4 512 2063 15714 2566
Internet Explorer 9 427 1354 28011 2625
Opera 11.10 545 2054 29199 4618
Safari 5.05 685 1473 н/д 2716

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

Полагаясь же на нынешние тесты, как видим, однозначные выводы сделать нельзя. Более того, во многих случаях результаты зависят от таких нюансов, о которых обычному пользователю даже сложно догадаться. К примеру, в интернете нередко можно встретить результаты указанных здесь тестов, в которых Internet Explorer демонстрирует в несколько раз худшую производительность. Они проводятся на 64-разрядной Windows и именно здесь-то и кроется подвох — Microsoft вовсе не случайно предлагает использовать в ней 32-разрядный браузер, а, казалось бы, логичный переход на «родную» разрядность является ошибкой. Оказывается, в 64-разрядном Internet Explorer 9 отсутствует JIT-компилятор JavaScript, так что производительность его остается на уровне голого интерпретатора. Причина же такого явления в том, что 64-разрядный браузер сегодня развивается Microsoft по остаточному принципу, так как популярность его растет недостаточно быстро, в первую очередь из-за медленной миграции плагинов.

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

Браузер Время выполнения теста, с Относительно IE10
(больше хуже)
Chrome 10.0.648.205 2.801 4.9
Firefox 4.0.1 0.956 1.7
IE 9.0.8112.16421 1.159 2.0
IE 10.0.1000.16394 0.562 1.0
Opera 11.10 1.106 1.9
Safari 5.0.5 0.984 1.7

Картина снова отличается от предыдущих, так что окончательные выводы делайте сами.

Графика

Однако не скриптами едиными определяется производительность браузера, большую роль играет также собственно рендеринг элементов страниц. Причем именно сейчас, в силу повышенного внимания к HTML5, этот аспект приобретает особое звучание. Действительно, работа с видео и насыщенной графикой — а HTML5 позволяет создавать даже несложные игры, например старый добрый Pacman, — требует немалых вычислительных ресурсов. В обычных приложениях для этих целей стараются задействовать аппаратные возможности графических акселераторов, и вполне логично перенести эту же практику на Веб (обратите внимание, что браузеры при этом начинают играть такую же платформенную роль, как ОС).

Локомотивом данного движения стала Microsoft, которая, впрочем, в некотором смысле находится в более выгодном положении, чем конкуренты — в отличие от них ей не нужно обеспечивать кроссплатформенность своих решений, так что в Windows она может выжать максимум. Этим же объясняется, почему не выпущен Internet Explorer 9 для Windows XP — старая ОС, кроме всего прочего, не поддерживает Direct2D, а следовательно, требует отдельной реализации. Сегодня уже все разработчики браузеров так или иначе заявляют о поддержке аппаратного ускорения графики, но реальное представление о текущем положении дел дает следующая таблица с результатами тестов:

Браузер Mozilla Hardware Acceleration Stress Test, fps Microsoft Fishbowl Benchmark, fps
Chrome 11 9 3
Firefox 4 55 29
Internet Explorer 9 60 60
Opera 11.10 11 2
Safari 5.05 3 2

Тут ситуация абсолютно прозрачная, и нет никаких сомнений, кто лидирует. На сайте ie.microsoft.com имеется большое число других демонстрационных приложений, которые можно использовать в качестве тестов, но результаты во всех будут аналогичны. Справедливости ради скажем, что все разработчики браузеров, кроме, естественно, Microsoft, также трудятся над поддержкой WebGL — спецификации аппаратного ускорения рендеринга HTML5 индустриального консорциума Khronos. В современных Chrome и Firefox она уже присутствует в достаточной мере, Opera и Safari ее пока тестируют в предварительных сборках.

Браузер Khronos WebGL Particles, FPS Google WebGL Aquarium, FPS
Chrome 11 55 27
Firefox 4.0 50 22

Безопасность

Эта характеристика сколь важна, столь и сложна в оценке. К сожалению, здесь нет четких критериев, а каждое исследование вызывает подозрения со стороны как пользователей, так и экспертов. Расхожее мнение к более безопасным относит открытые разработки, хотя формальные подсчеты числа обнаруженных уязвимостей и средней скорости исправления никогда не показывали их реального превосходства. Правда, с Internet Explorer (обычно с устаревшими версиями) было связано несколько довольно громких инцидентов, что существенно подпортило его репутацию. Хотя, с другой стороны, с точки зрения защищенности от социальных атак лучшим неоднократно признавался именно браузер Microsoft.

Неплохим аргументом, пожалуй, являются результаты ежегодных хакерских соревнований Pwn2Own, на которых предлагается взламывать браузеры. Первым всякий раз капитулирует Safari (причем на Mac OS X) и вовсе не только из-за привлекательности приза, каковым является ноутбук с предустановленной испытуемой системой. Эксперты по безопасности свидетельствуют, что в WebKit имеется достаточно уязвимостей, чтобы найти подходящую к каждому соревнованию. С другой стороны, Chrome, использующий тот же веб-движок, два года кряду остается неуязвимым, несмотря на то, что Google назначает дополнительный солидный приз. В этом заслуга очень эффективной «песочницы» Chrome, которая не позволяет атакующему коду добраться до ОС. Остается добавить, что Internet Explorer взламывается регулярно, Firefox также довольно часто, нередко через плагины. Opera, к сожалению, не участвует в этих соревнованиях, ввиду малой распространенности в мировом масштабе.

Но работы над совершенствованием различных аспектов безопасности браузеров не прекращаются, и новые решения появляются практически в каждой очередной версии. В частности, все современные браузеры поддерживают приватный режим функционирования, в котором не сохраняются следы посещенных веб-сайтов. В Internet Explorer 9, кроме того, реализован механизм Tracking Protection, блокирующий на веб-страницах элементы, следящие за перемещением пользователя. Работает он по принципу черного списка, который может формироваться браузером автоматически или загружаться из внешних источников. В Firefox 4 появилась похожая функция, но она основана на необязательной поддержке со стороны самих веб-сайтов, т. е. значительно менее эффективна.

В Internet Explorer 9 также появилась блокировка ActiveX — она активируется глобально, затем ее можно отключать для отдельных сайтов либо для конкретных элементов. Впрочем, рассматривать это а качестве преимущества браузера Microsoft нельзя, так как речь идет о закрытой частной технологии, как раз и ставшей источником уязвимостей.

Полезная новинка в Opera — автоматическое упрощение URL в том случае, когда реальное имя сайта назначения передается (как правило, злонамеренно) в качестве параметра.

Синхронизация

Значение синхронизации трудно переоценить, поскольку браузеры используются на всё большем разнообразии устройств, включая планшеты, смартфоны, электронные книги и пр. Долгое время соответствующая функциональность реализовывалась плагинами и специальными сервисами, но сегодня уже стала фактически стандартной. И понятно почему: встроенная синхронизация является мощным инструментом конкурентной борьбы, ведь привязавшись к конкретному браузеру на одной платформе или устройстве, пользователь с большой вероятностью воспользуется таким же и на другой. По этой же причине постоянно расширяется и список синхронизируемых объектов — к закладкам уже добавились пароли, данные форм, информация о вкладках и пр.

Пожалуй, лучше всего синхронизация реализована в Chrome: в частности, удобно сделана возможность шифрования данных по обычному паролю Gmail. Хотя с точки зрения безопасности это, возможно, и не самое удачное решение, но если речь не идет ни о чем суперсекретном, а сам пароль достаточно сложен, то вполне допустимое. Тем более на фоне реализации Firefox 4, который обязательно шифрует синхронизируемую информацию, но при подключении новых устройств вместе с обычными регистрационными данными требует ввести довольно сложный ключ. Его, конечно, можно сохранить или распечатать, но, учитывая забывчивость даже подготовленных пользователей, можно представить себе количество будущих рекламаций — ведь после генерации нового ключа прежняя информация пропадает (о чем разработчики честно предупреждают). В Safari и Internet Explorer синхронизация обеспечивается внешними инструментами — MobileMe и Windows Live Mesh соответственно. Они гораздо скромнее с точки зрения поддержки именно браузера, но тот же Windows Live Mesh представляет самостоятельную ценность, благодаря синхронизации файлов, использованию хранилища SkyDrive, удаленному управлению подключенными компьютерами.

Частности

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

Chrome 11, как уже говорилось выше, пожалуй, наиболее защищенный и безопасный от прямых атак через Веб, что обеспечивается в том числе и его внутренней архитектурой: в отдельных процессах запускаются не только каждая вкладка, но и экземпляры JavaScript-машины, и даже наиболее тяжелые плагины (к примеру, Adobe Flash). Хотя с другой стороны, это приводит к повышенному потреблению памяти. Основные доработки 10-й версии были направлены на улучшение производительности и исправление ошибок, плюс небольшие изменения в интерфейсе (HTML-страница с опциями), в 11-й появился голосовой ввод на базе HTML5 (проверить можно на Google Translate, пока только для английского языка), который, впрочем, требует определенной работы от создателей сайтов. И все же главное достоинство Chrome — максимально гладкая работа с сервисами самой Google, как на десктопах, так и на Andro >

Firefox продолжает оставаться вторым по популярности браузером после Internet Explorer, хотя в последнее время его доля стабилизировалась и даже несколько уменьшается. Тем не менее, по последним данным, Firefox 4, доступный и для Windows XP, загрузили как минимум вдвое больше пользователей, чем Internet Explorer 9, хотя последний появился раньше. Кроме тех новинок, что упоминались в общих разделах, в Firefox 4 улучшена работа с вкладками веб-страниц. Во-первых, теперь применяется «гибридная» схема, когда ярлычки по мере открытия новых кладок уменьшаются, как в Chrome и Opera, но только до определенного предела, после чего «лишние» прячутся и пролистываются, как в Internet Explorer. Во-вторых, вкладки можно объединять в группы — впрочем, реализация этой функции понравится далеко не всем. Наконец, в-третьих, появились так называемые App Tabs — автоматически открываемые вкладки, ярлычки которых постоянно закреплены в левой части окна. Кроме того, был заметно переработан менеджер плагинов, широкое разнообразие которых является одним из главных козырей Firefox. Впрочем, с плагинами же нередко связываются и претензии — с каждым новым релизом браузера начинается эпопея с их совместимостью, и похоже, что именно из-за них в Firefox частенько случаются утечки памяти. К плюсам последней версии можно также отнести всестороннюю поддержку аппаратного ускорения рендеринга HTML5, наиболее широкую среди всех браузеров.

Internet Explorer 9 появился после большой задержки, и по многим пунктам Microsoft оказалась в роли догоняющего. Так, к примеру, трудно отнести к преимуществам встроенный менеджер загрузок, поскольку во всех прочих браузерах он появился давным давно. Злую шутку с корпорацией также сыграло прежнее игнорирование стандартов, теперь приходится поддерживать режимы совместимости и всячески открещиваться от Internet Explorer 6. К недостаткам Internet Explorer традиционно относят моноплатформенность, однако для большинства пользователей это совершено не критично. Зато новый браузер Microsoft обеспечивает лучшую поддержку интерфейсных функций Windows 7: к примеру, сайты можно закреплять на панели задач, а их разработчики могут даже сформировать для них специальное меню (так называемый jump list), так что веб-приложения станут практически неотличимы от обычных. Аналогично, Microsoft обеспечивает пока лучшую поддержку аппаратного ускорения рендеринга HTML5. К другим достоинствам можно отнести также удачную реализацию инструментов работы с плагинами (в частности, отключение наиболее долго загружаемых) и защиты от социальных атак.

Opera 11.10. Нынешнее обновление Opera не такое существенное, как у других участников, тем не менее в норвежском браузере появилось несколько интересных новинок. Одна из них — поддержка нового графического формата WebP и его использование в функции Turbo (вместо JPEG), обеспечивающей загрузку компрессированных веб-страниц через сервер Opera. Ожидается, что WebP сделает ее еще эффективнее, по информации самих разработчиков — до полутора раз на отдельных сайтах. Opera, несмотря на свою небольшую распространенность в мире (феномен ее популярности в СНГ заслуживает отдельного изучения), является своего рода законодателем мод: достаточно вспомнить, что именно этот браузер дал путевку в жизнь вкладкам, без которых работа с Вебом сегодня уже немыслима. Сегодня любимым детищем разработчиков явно стала панель Speed Dial, эскизы на которой могут служить не только кнопками запуска сайтов, но и своеобразными «информерами» для них. Пожалуй, именно дополнительные функции (среди которых, кроме Turbo, и встроенный почтовый клиент, и многое другое) и являются главным козырем десктопной Opera, хотя не всем пользователям они нужны в равной мере. Кроме того, это по-прежнему самый компактный и легковесный браузер, хотя и несколько нестабильный.

Обновление Safari до версии 5.05 еще менее значительно, фактически это только исправление ошибок. До пятой версии аргументов для использования Safari в Windows практически не было. Затем появился механизм расширений, была улучшена производительность и пр. Главный интерес к Safari, конечно, исходит от пользователей продукции Apple, прежде всего смартфонов и планшетов, в том числе разработчиков мобильных веб-приложений. К достоинствам браузера можно отнести вполне передовой движок рендеринга (который в свое время был выбран Google для Chrome), но только если не касаться вопросов безопасности, а также некоторые вспомогательные функции, вроде Reader, который умеет «очищать» основную статью веб-страницы от лишних деталей и даже объединять ее из нескольких фрагментов. Отметим также, что десктопный Safari доступен только для Windows (в том числе XP) и Mac OS X. И кстати, Safari — единственный из альтернативных браузеров по умолчанию показывает эскизы отдельных вкладок в панели задач Windows 7, в остальных нужно искать соответствующие настройки.

Мастер Йода рекомендует:  6 бесплатных ресурсов для обучения разработке
Добавить комментарий