Примечание: ниже находится перевод статьи "Performance Research, Part 5: iPhone Cacheability - Making it Stick" из блога производительности YUI. Авторы исследовали поведение iPhone при загрузке страницы и сделали некоторые интересные выводы по производительности веб-страниц для этого мобильного устройства. Мои комментарии далее курсивом.
Эта статья, написанная в соавторстве с Wayne Shea, пятая в серии, посвященной описанию экспериментов, которые направлены на исследование производительности веб-страниц (часть 1, часть 2, часть 3 и часть 4). Вы, наверное, удивлены, почему статьи по производительности находятся в блоге YUI (Yahoo! User Interface, пользовательских интерфейсов Yahoo!). Так получается, что программирование клиентской части, что, по сути, равносильно разработке и созданию пользовательских интерфейсов, оказывает наибольшее воздействие на производительность веб-страниц (в свете ведущей роли инженеров Yahoo! в изучении производительности клиентской части, наверное, более удивителен тот факт, что такие статьи все еще находятся в этом блоге, а не выделены в отдельное направление).
На MacWorld 2008 Steve Jobs анонсировал, что Apple уже продала на текущий момент 4 миллиона iPhone, что составляет по 20 тысяч iPhone каждый день. В докладе Net Applications говорится, что общая доля пользователей Интернета с iPhone поднялась до 0,12% в декабре 2007, обогнав, в совокупности, все браузеры для мобильных устройств, работающие под управлением Windows. iPhone от Apple изменил ситуацию для пользователей, выходящих в интернет через мобильные устройства. Веб-разработчики теперь могут создавать функционально богатые и весьма привлекательные приложения, которые работают на iPhone-версии браузера Safari для мобильных устройств. При этом сам iPhone как предоставляет новые и достаточно интересные возможности для разработчиков для мобильных устройств, так и обнаруживает ряд уникальных проблем в сфере производительности.
По поводу этого устройства на данный момент доступна только ограниченная информация, а понимание основ его алгоритмов кеширования существенно для создания высоко производительного веб-сайта. В более ранних статьях мы уже говорили о том, что ответственность за не менее 80% времени ответа веб-сайта для конечного пользователя лежит на стороне клиентской части, а также почему кеш имеет значение. В этом исследовании команда по исключительной производительности Yahoo! исследовала кеширующие свойства iPhone и установила, как на это воздействуют существующие правила для производительности. Мы были заинтересованы в следующих аспектах алгоритмов кеширования iPhone:
Мы провели свои эксперименты над кешом как для Apple iPhone, так и для iPod Touch. Результаты получились одинаковые.
Во второй части мы обсудили важность разделения пользовательского восприятия для просмотров страницы с пустым кешем и полным.
При запросе внешних компонентов (скриптов, таблиц стилей и картинок), которые используются на HTML-странице, браузер делает HTTP-запрос и сохраняет компонент в памяти, пока HTML-страница выводится на экран. Хотя при отображении на экране компоненты сохраняются в памяти браузера, они могут как сохраняться, так и не сохраняться в кеше браузера. В случае «мимо кеша» (cache miss) браузер игнорирует кеш и запрашивает компонент через сетевое соединение. «В кеше» (cache hit) означает, что компонент был найден в кеше и HTTP-запросы не отправляются.
Авторы умалчивают о тех случаях, когда браузер запрашивает какой-либо компонент, но получает ответ с кодом 304 (Not Modified). В таком случае компонент уже есть в кеше, однако, браузер решил его таки загрузить с сервера. Как показывает практика, производительность страницы при этом, практически, соответствует случаю «в кеше», потому что браузер при первичном отображении берет данные все равно из кеша, а по необходимости обновляет страницу в динамическом режиме при получении более свежей версии какого-либо компонента. Таким образом, в общем случае, это поведение может быть приравнено к случаю «в кеше», ибо такие дополнительные запросы не сказываются на времени открытия страницы.
Компоненты кешируются, когда ответ сервера для них включает либо заголовок Expires, либо Cache-control.
Expires: [Дата истечения срока давности в формате GMT] Cache-Control: max-age=[Срок давности в секундах]
Компоненты, у которых нет ни одного из этих заголовков, не должны кешироваться браузером (однако, Opera, по умолчанию, кеширует, практически, все). Для того, чтобы выяснить кеширующие возможности браузера в iPhone (установив попадание в кеш определенных файлов), мы настроили сервер для выдачи следующего заголовка:
Expires: Thu, 15 Apr 2010 20:00:00 GMT
В наших экспериментах мы изменяли размер различных компонентов (картинок, таблиц стилей и скриптов) для установления максимального размера для каждого компонента в отдельности. В результате было установлено, что если размер компонентов превышает 25 Кб, то браузер в iPhone не кеширует этот компонент. Поэтому веб-страницы, которые спроектированы специально для iPhone, должны уменьшить размер компонентов не более чем до 25 килобайтов, чтобы оптимизировать кеширующее поведение.
Хорошие новости заключаются в том, что если браузер загружает новый компонент, размер которого больше чем 25 KB, то это не влияет на компоненты, которые уже находятся в кеше. Закешированные компоненты заменяются более новыми, только если последние не превосходят 25 Кб. При этом применяется LRU-алгоритм (выбирается самый маленький из последних используемых, least recently used).
На вебсайте Apple указано, что существует предел в 10 Мб для индивидуальных компонентов. Этот предел зависит от способностей браузера хранить файлы в оперативной памяти (не на диске). Однако, реальный максимальный размер файлов, которые iPhone может обрабатывать, значительно меньше. Он зависит от текущей фрагментации памяти и других приложений, которые запущены параллельно с браузером. Компоненты, которые не поместились в кеш, запрашиваются браузером снова после закрытия текущей страницы.
Для того чтобы определить максимальный размер кеша iPhone для нескольких компонентов, мы увеличили число компонентов размером в 25, вызываемых на странице. После проведения тестирования для различных типов компонентов мы установили, что браузер в iPhone способен кешировать до 19 внешних файлов по 25 Кб. Соответственно, максимальный размер кеша для нескольких компонентов (или целой страницы со всеми необходимыми ей ресурсами) составляет 475 Кб – 500 Кб.
Мы также проанализировали, какое влияние на кеш оказывается передача компонентов в обычном или сжатом виде. Мы обнаружили, что предел кеша в 25 Кб на компонент не зависит от того, был ли он передан в архивированном виде. Safari в iPhone декодирует компонент до того, как он сохранится в кеше. Таким образом, значение имеет только несжатый размер файлов, что еще больше подчеркивает важность минимизации всех компонентов. Маленькое замечание: размер все же имеет значение, потому что влияет на время передачи по сети. Поэтому рекомендуется разбивать все ресурсы страницы на файлы по 25 Кб, а затем уже применять к ним сжатие. Насколько сжатие влияет на скорость передачи, можно проверить с помощью этого инструмента.
Иногда так случается, что пользователям iPhone или iPod Touch нужно перезагрузить систему, или, другими словами, выключить устройство и загрузить его заново. Для этого нужно удерживать кнопку sleep в течение пяти секунд, потом просмотреть небольшую заставку при выключении. Предположим, что пользователь просматривал ваш сайт как раз перед тем, как перезагрузиться. Сохраняться ли картинки и таблицы стилей в кеше браузера, ускорив загрузку вашего сайта, когда пользователь на него вернется? В результате исследования мы получили, что кеш браузера в iPhone не сохраняется после перезагрузки. Это означает, что кеш в Safari для iPhone получает часть системной памяти для создания там кешированных версий компонентов, однако, не сохраняет их в постоянном месте.
Yahoo! представила бета-версию главной страницы на Consumer Electronics Show (CES) в январе 2008. Если взглянуть с точки зрения производительности, то это было просто восхитительно. Интерфейс пользователя в iPhone захватывает дух, однако, он весьма ограничен небольшим по размеру кешем и медленным сетевым соединением. Загрузка больших компонентов по беспроводному соединению, используя технологию EDGE, медленнее, чем по DSL-соединению. Согласно опубликованным отчетам, типичная скорость загрузки данных колеблется от 82 Кбит/с до 150 Кбит/с. Хотя скорость передачи по WiFi является обычно более приемлемой, лучше дать пользователям сами выбрать, чем они будут пользоваться. Давайте рассмотрим кеширующие характеристики мобильной и обычной версий стартовой страницы Yahoo! в iPhone. Ниже на рисунке 1 показано различие между ними.
Рисунок 1. Стартовая страница Yahoo!, мобильная и обычная версия в iPhone
Обычная версия главной страницы Yahoo! приблизительно в 11 раз «тяжелее» по общему размеру данных, чем мобильная. В результате, Время ее загрузки в iPhone в 10 раз больше, чем для мобильной. В таблице 1 приведены сводные данные по общему размеру и числу HTTP-запросов для загрузки мобильной версии стартовой страницы Yahoo!. Загрузка этой страницы через EDGE-сеть занимает, в среднем, 2,2 секунды при пустом кеше и только 1,5 секунды с полным кешем. В таблице 2 приведены данные для обычной версии, загрузка которой занимает, в среднем, 25,4 секунды с пустым кешем и 19,9 секунд с полным. Загрузка мобильной версии с полным кешем на 32% быстрее, чем с пустым, при этом обычная версия с полным кешем загружается всего на 22% быстрее своего некешированного аналога. Таким образом, мобильная версия спроектирована для оптимизации кеширующего поведения, при этом обычная версия содержит множество компонентов, которые iPhone просто не кеширует.
| Пустой кеш | Полный кеш | |
|---|---|---|
| HTML/текст | 5Кб (23Кб*) | 5Кб (23Кб*) |
| Картинки | 14Кб | 5Кб |
| Общий размер | 19Кб (37Кб*) | 10Кб (28Кб*) |
| HTTP-запросов | 23 | 4 |
| Время загрузки | 2,2с | 1,5с |
| Пустой кеш | Полный кеш | |
|---|---|---|
| HTML/текст | 32Кб (121Кб*) | 32Кб (121Кб*) |
| Картинки | 117Кб | 32Кб |
| JS/CSS | 74Кб (278Кб*) | 73Кб (272Кб*) |
| Общий размер | 223Кб (517Кб*) | 137Кб (425Кб*) |
| HTTP-запросов | 30 | 4 |
| Время загрузки | 25,4с | 19,9с |
* размер компонентов в несжатом виде в Кб.
Если это требуется, то проектируйте сайты специально для пользователей iPhone. Кроме повышения удобства использования вы также сможете уменьшить общий размер страницы и улучшить клиентскую производительность. Группа по исключительной производительности в Yahoo! выделила 13 правил для ускорения загрузки страницы. Эксперимент с кешом iPhone предполагает формулировку еще одного специфического правила по производительности для сайтов, которые разрабатываются специально для iPhone:
Уменьшайте размер каждого из компонентов страницы до 25 Кб (или менее) для оптимизации кеширующего поведения.
Заданная ограниченная скорость сетевого беспроводного соединения в iPhone наряду с очисткой кеши в браузере при перезагрузке выводят на первый план важность уменьшения числа HTTP-запросов для повышения производительности. И это становится даже более важным, чем в случае загрузки страницы в обычном браузере. Для уменьшения числа HTTP-запросов, Safari в iPhone поддерживает Image Map, CSS Sprites, встроенные изображения и встроенные CSS изображения. Пользуйтесь преимуществами кеширования в браузере во всех возможных случаях. Если внешний компонент может быть использован на нескольких страницах сайта, стоит запомнить, что каждый отдельный файл не может быть больше 25 Кб, иначе он не будет кешироваться. Также максимальный размер кеша всех компонентов составляет около 475 – 500 Кб. Уменьшайте JavaScript, CSS и HTML. Для компонентов, которые не используются на нескольких страницах, стоит рассмотреть возможность их включения в HTML-код.
© 2016 ООО ВЕБО
