Производительность IE8

Добрый день! Меня зовут Кристиан Стоквелл (Christian Stockwell) и в команде IE я занимаюсь вопросами производительности Internet Explorer.

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

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

Как Дин упоминал на MIX08, компания Google прокомментировала наши достижения в IE8 Beta 1, а с того момента IE8 стал еще шустрее: "Некоторые из выполненных нами тестов показали, что чистая производительность JScript выросла в 2.5 раза. Мы также видим значительный прирост производительности (по сравнению с IE7) при выполнении стандартных операций в Gmail: загрузки папки Inbox (34%), открытие окна Google Talk (45%) и открытие переписки (27%)".

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


Производительность и продуктивность

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

В IE8 наше понимание этой задачи очевидно прослеживается во многих новых функциях. Хорошим примером такой функции, которая увеличивает продуктивность пользователей, является Web Slices. Только представьте, как возрастает продуктивность ваших действий, когда вы делегируете Web Slices обязанности проверять обновления важной для вас информации. От использования данной функции выигрывают и пользователи и разработчики. Для пользователей наличие этой возможностей упрощает процедуру просмотра обновлений какой-либо информации. Разработчикам становится проще реализовать легковесные Web Slices вместо того, что тратить дни/часы/недели на оптимизацию сайтов таким образом, чтобы пользователи могли с легкостью отыскивать новую информацию по интересующей их теме.

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


Как создать быстрый браузер
Когда мы начинали планирование IE8, мы приняли осознанное решение изменить в лучшую сторону способ использования пользователями Интернета. Среди тех областей, в которых мы запланировали изменения, следует отметить время запуска браузера, скорость навигации и взаимодействия пользователей со страницами (включая работу с AJAX-объектами).

В частности мы уделили серьезное внимание таким функциям, как Web Slices, поскольку в некоторых случаях самым быстрым может считаться тот браузер, которому для доступа к информации не требуется загружать страницу. Кроме того, мы постоянно совершенствуем IE как веб-платформу.

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

После проведенного анализа мы обнаружили, что если направить все наши усилия на оптимизацию обработки JScript, в большинстве случаев это незначительно обогатит опыт пользователей. Ниже располагается табличка с информацией о количестве циклов CPU, используемых при навигации по сайтам из рейтинга Top 100 различными подсистемами IE8 Beta 1:

Обратите внимание, что при навигации системы подвергались типичным тестам JScript/DOM (в частности SunSpider) в течение менее 10% общего времени навигации. В дополнение к этому мы проанализировали несколько распространенных AJAX-приложений, получив достаточно интересные результаты:

Даже на типичном AJAX-сайте (любой крупный почтовый сайт) подсистемы JScript и DOM потебляют менее трети от общего компьютерного времени.

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

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

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


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

Новый механизм обработки JScript, входящий в состав IE8, увеличивает производительность во многих сценариях. Мы в значительной степени усовершенствовали часто используемые функции JScript. Мы внесли изменения в архитектуру, чтобы снизить число обращений функций, время создания объектов и оптимизировать lookup-схемы для переменных, ограниченных окнами или объектами.

Некоторые из внесенных изменений вызваны существующими узкими местами в коде. Ранее больные для разработчиков темы - функция String и Array - теперь значительно быстрей по сравнению с предыдущими инкарнациями. Это значит, что разработчикам больше не требуется дополнительное время и труд с целью избежать узкие места IE при обработке JScript. Более того, внесенные нами изменения отразились в результатах SunSpider: результат IE8 оказался выше результатов IE7 на 400%.

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


Изменения в системе управления памятью
Кроме того, особое внимание было уделено потреблению памяти. К текущему моменту мы исправили около 400 отдельных утечек памяти в Internet Explorer. Мы также поработали над фрагментацией динамической памяти и использованием памяти на AJAX-страницах. Для пользователей эти изменения выльются в сокращение потребляемой IE памятью, увеличение скорости загрузки браузера, ускорение навигации по страницам и увеличение стабильности IE. В дополнение к вышеперечисленному проделанная нами работа должна облегчить работу разработчиков.

В частности, мы попытались избавить IE от утечек памяти между нашими JScript и DOM. В предыдущих версиях IE временем жизни объектов JScript управлял так называемый JScript garbage collector (GC), однако, DOM-оюъекты ему не подчинялись. В результате GC не мог разрывать круговые связи между DOM- и JScript-объектами, что приводило к возникновению утечек памяти. На сложных AJAX-сайтах устранить такую проблему было достаточно сложно и требовало немало времени.

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

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


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

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

В IE8 Beta 1 мы увеличили число соединений с сервером с 2 до 6. В IE7 можно было, к примеру, в любой момент времени можно было осуществлять лишь две загрузки с выбранного сервера. Увеличение этого лимита до 6 позволит загружать за то же самое время в три раза больше контента, то есть при наличии свободной полосы пропускания страницы будут загружаться гораздо быстрее.


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

В Beta 1 стандартный движок визуализации оказался гораздо медленнее движка, используемого нами в IE7. В последние несколько месяцев мы проделали большую работу и в Beta 2 наш движок визуализации, работающий по стандартам W3C, по производительности перестал уступать предыдущей реализации. Мы и дальше намерены наращивать производительность движка визуализации и надеемся, что к моменту релиза IE8 разработчикам не придется принимать сложных для себя решений: разработка под наш браузер позволит создавать сайты, работающие достаточно быстро на любом из существующих браузеров.

Комбинация вышеперечисленных изменений означает, что многие сайты в IE8 будут работать быстрее, позволив пользователям быть продуктивнее, чем когда-либо. В то же самое время мы избавили браузер от многих преследовавших его бед, облегчив жизнь разработчиков. И в IE8 Beta 2 получат в свое распоряжение новые инструменты, которые позволят создавать быстрые как молния сайты.


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

• Data URI
  Устали писать код для использования технологии CSS spriting с целью минимизировать сетевую нагрузку за счет использования маленьких изображений? Если да, то эта функция специально для вас. В IE8 мы добавили поддержку Data URI. Вместо использования URL-ссылки для указания на файл изображения можно использовать Data URI, позволяющие обращаться к информации напрямую.
  
  Вот, к примеру, Data URI, описывающая голубую точку размером 10x10:
  
  

  data:image/png;base64,
  
  iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKAQMAAAC3/
  
  F3+AAAACXBIWXMAAA7DAAAOwwHHb6hkAAAAAXNSR
  
  0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAgY0hSTQAA
  
  eiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLp
  
  RPAAAAANQTFRFALfvPEv6TAAAAAtJREFUCB1jYMAHAAA
  
  eAAEBGNlaAAAAAElFTkSuQmCC

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

• Selector API
  В дополнение к поддержке Data URI в IE8 добавлена поддержка Selector API querySelector и querySelectorAll, которые позволят отыскивать селекторы в очередях JScript быстрее, чем при раньше. В неофициальных тестах заметно сокращение времени поиска с нескольких секунд до милисекунд при сравнении нашей реализацией с реализациями из других инфраструктур. За более подробной информацией о Selectors API обращайтесь к официальной документации по Selectors API.
  
• JSON
  Последней из наиболее интересных новинок в IE8 для разработчиков является поддержка JSON, заявленная в одной из предыдущих публикаций.
  Разработчики AJAX-сайтов часто используют JavaScript Object Notation (JSON) для передачи данных между компонентами своих сайтов. В предыдущих версиях IE разработчики были вынуждены внедрять JSON-строки в объекты JScript, что является весьма небезопасным. Более безопасные сайты для обеспечения "дезинфекции" JSON использовали более защищенный, но и более требовательный к ресурсам парсер JSON. В обоих случаях страдали и пользователи и разработчики.
  Чтобы облегчить жизнь и тем, и другим, в JScript-движке IE8 Beta 2 мы реализовали методы ECMAScript 3.1 JSON JSON.stringify и JSON.parse, являющиеся быстрым и безопасным решением для широкораспространенных проблем разработчиков.
  
• Другое
  Это были на мой взгляд наиболее интересные нововведения IE8, призванные в значительной степени облегчить работу разработчиков. Конечно, что интересно мне, может быть неинтересно вам. Поддержка DOM-хранилищ (10МБ на сайт), XDomainRequest (безопасное кросс-доменное взаимодействие без прокси -сервера) и Connectivity Events (теперь скрипт может показать, подключен ли пользователь к Интернету) также являются мощными инструментами, которые могут быть использованы разработчиками для создания быстрых сайтов. Более того, я уверен, что наши инвестиции в инструменты для разработчиков сделают процесс создания сайтов в IE8 станет более простым и прозрачным, чем в предыдущих версиях браузера.

Надеюсь, что эта статья помогла вам понять нашу работу по увеличению производительности Internet Explorer. Многие для оценки производительности применяют различные тестовые пакеты, но всегда лучше посмотреть на общую картину. Мы понимаем, что ожидания пользователей относительно нашей работы достаточно высоки. Однако спешу вас обрадовать, что в IE8 у нас запланирована огромная работа по увеличению производительности. И попробовав вторую бета-версию Internet Explorer, вы увидите наши успехи.

Кристиан Стоквелл
Программный менеджер Internet Explorer


Источник: http://blogs.msdn.com/ie
Перевод: deeper2k