Примечание: ниже расположен перевод заметки "Browser Page Load Performance" от John Resig, в которой он рассматривает тестовое окружение от Steve Souders для анализа клиентской производительности браузеров. Мои комментарии далее курсивом.
Steve Souders много внес в улучшение производительности браузеров при загрузке страницы и клиентской оптимизации более, чем кто-либо. Во время своей работы в Yahoo! он отвечал за YSlow (великолепный инструмент для измерения производительности вашего сайта) и написал книгу, посвященной улучшению производительности веб-страниц — High Performance Web Sites. Сейчас он работает в Google, но по-прежнему занимается тем же самым: делает загрузку веб-страниц чуточку быстрее.
Я был восхищен выходом одного из его новых проектов — UA Profiler (проект стартовал достаточно давно, но хороших обзоров его работы пока не было). Этот инструмент можно запустить в вашем браузере, чтобы выяснить его текущие возможности касательно клиентской производительности, которые так или иначе ограничивают в нем скорость загрузки страниц.
Давайте взглянем на следующую таблицу:
на ней хорошо видно, что лидирует Firefox 3.1, имея 9 из 11 потенциальных возможностей для ускорения загрузки страницы. В Firefox 3, Chrome и Safari 4 присутствует всего 8 из этого списка. Firefox 2, Safari 3.1 и IE 8 являются следующими по списку с 7 выполненными тестами. Эти цифры могут помочь оценить общую производительность браузеров при загрузке страницы. Естественно, что все эти тесты не затрагивают особенностей рендеринга страницы или JavaScript-производительность: их козырной картой является производительность сетевого соединения (CSS-производительность была подробно рассмотрена ранее в соответствующем цикле статей, который привел к некоторым практическим аспектам ее применения).
Информация о качестве использования сетевого соединения важна по двум причинам:
Тесты могут быть разбиты на несколько категорий (Steve подробно объясняет такую классификацию в FAQ):
В основном, тестируются две вещи: число одновременных соединений к одному хосту (поддомены расцениваются как отдельные хосты) и сколько соединений можно открыть ко всем хостам одновременно. Эти числа являются хорошим индикатором, каково возможное число параллельных соединений (это обычно влияет на число одновременно загружаемых картинок).
Дополнительно проверяется, поддерживает ли браузер gzip-сжатие. Результаты не слишком впечатляют: все современные браузеры на данный момент поддерживают сжатие.
Все браузеры способны загружать изображения в параллельном режиме (несколько изображения загружаются одновременно) но что насчет других ресурсов (таких как стили и скрипты)?
К несчастью, добиться параллельной загрузки файлов скриптом и стилей гораздо сложнее, потому они могут очень сильно изменить содержание (и внешний вид) всей остальной страницы. Появление этих компонентов на странице происходит в несколько в этапов:
Поэтому загрузки этих файлов блокирует друг друга (напоминая игру в «камень-ножницы-бумага»): скрипты блокируют анализ и исполнение других скриптов, стили блокируют анализ и исполнение скриптов.
Для браузеров тяжело добиться параллельной загрузки скриптов, поскольку скрипты могут изменять содержание страницы и удалить или добавлять новые скрипты или таблицы стилей. Исходя из этих соображений, браузеры пытаются добиться лучшей производительности, предвосхищая ситуацию, анализируя документ и предварительно загружая стили и скрипты — даже если их реальное использование будет отложено.
Изменения в этой области позволят значительно улучшить клиентскую производительность. Можно смело сказать, что это по-прежнему самая нетронутая область для оптимизации (и именно она больше всего беспокоит сейчас фронт-енд архитекторов).
Хотя все современные браузеры поддерживают кэширование ресурсных файлов, кэширование редиректов распространено гораздо меньше. Например, представьте такой случай: пользователь набирает в браузере http://google.com/ — и Google перенаправляет его на страницу http://www.google.com/, но только пара браузеров способно закэшировать этот редирект, чтобы не делать дополнительного запроса в будущем.
Абсолютно то же самое происходит в случае кэширования статических файлов, например, таблиц стилей, картинок или скриптов. Поскольку такие редиректы происходят гораздо чаще (и один из аспектов оптимизации как раз связан с устранением таких редиректов), то со стороны браузеров кэширование любого производимого действия выглядит гораздо критичнее для производительности.
Пред-вызов является частью спецификации HTML 5 и позволяет определить ресурсы на странице, которые нужно загрузить «на будущее», поскольку они могут потребоваться при дальнейших действиях пользователя (распространенным примером будет динамическая смена изображений).
Хотя существует целая страниц, посвященная использованию данного подхода на сайте разработчиков Mozilla, но его применение гораздо проще, чем может сперва показаться. Это так же просто, как добавление новой ссылки наверх вашего сайта:
<link rel="prefetch" href="/images/big.jpeg">
И все необходимые ресурсы будут предварительно загружены (без использования JavaScript)!
В финале проверки всех возможностей браузеров идет тестирование на поддержку встроенных картинок, вставленных при помощи data: URL. Data:URL позволяет разработчикам включать бинарные данные прямо в саму страницу. Хотя это и экономит число HTTP-запросов, но нужно иметь в виду, что ресурсы, включенные таким образом, не кэшируются (точнее, кэшируются вместе с исходным документом или таблицей стилей). Использование этой техники может варьироваться от случая к случаю (по моему мнению, все небольшие фоновые изображения на странице должны быть выведены именно в таком формате, что значительно ускорит «визуальную» загрузку документа), но ее поддержка должна быть простоя обязательной (подробнее об альтернативной технологии mhtml и текущих методах обеспечения кроссбраузерности для data:URL).
Можно совершенно точно утверждать, что наличие таких публичных проектов, как UA Profiler будет поощрять создателей браузеров быстрее реагировать на изменения в клиентских технологиях и внедрять критический с точки зрения производительности функционал.
Как было замечено дальше в комментариях, Steve является автором еще Cuzilion — моделирования загрузки страницы при использовании различного количества различных файлов — и дополнения к Firefox Hammerhead — позволяющего замерять и запоминать время загрузки для выбранных сайтов.
© 2016 ООО ВЕБО
