Производительность 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 для более продуктивной работы веб-разработчиков, создающих новое поколение веб-сайтов.

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

«В каждом из языков программирования есть оптимизационный оператор. В C++ это ‘//’ »

– с конференции O’Reilly’s Velocity Conference, июнь 2008

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

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

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

Как создать быстрый обозреватель

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

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

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

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

Обратите внимание, что при навигации по сайтам Top 100 системы подвергались типичным тестам 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 от утечек памяти между нашими 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 мы добавили поддержку RFC 2397’s 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