На www.apple.comуказано, что существует предел в 10 Мб для индивидуальных компонентов. Этот предел зависит от способностей браузера хранить файлы в оперативной памяти (не на диске). Однако реальный максимальный размер файлов, которые iPhone может обрабатывать, значительно меньше. Он зависит от текущей фрагментации памяти и других приложений, которые запущены параллельно с браузером. Компоненты, которые не поместились в кэш, запрашиваются браузером снова после закрытия текущей страницы.
Было также установлено, что максимальный размер кэша для нескольких компонентов (или целой страницы со всеми необходимыми ей ресурсами) составляет 475-500 Кб.
Было проанализировано, какое влияние на кэш оказывает передача компонентов в обычном или сжатом виде. Предел кэша в 25 Кб на компонент не зависит от того, был ли он передан в архивированном виде. Safari в iPhone декодирует компонент до того, как он сохранится в кэше. Таким образом, значение имеет только несжатый размер файлов, что еще больше подчеркивает важность минимизации всех компонентов.
Однако размер все же имеет значение, потому что влияет на время передачи по сети. Поэтому рекомендуется разбивать все ресурсы страницы на файлы по 25 Кб, а затем уже применять к ним сжатие.
Иногда случается, что пользователям iPhone или iPod Touch нужно перезагрузить систему, или, другими словами, выключить устройство и загрузить его заново. Для этого нужно удерживать кнопку sleep в течение пяти секунд, потом просмотреть небольшую заставку при выключении. Предположим, что пользователь просматривал ваш сайт как раз перед тем, как перезагрузиться. Сохранятся ли картинки и таблицы стилей в кэше браузера, ускорив загрузку вашего сайта, когда пользователь на него вернется?
В результате исследования было получено, что кэш браузера в iPhone не сохраняется после перезагрузки. Это означает, что кэш в Safari для iPhone получает часть системной памяти для создания там кэшированных версий компонентов, однако не сохраняет их в постоянном месте.
В случае реальной необходимости сайты можно и нужно проектировать специально для iPhone. Кроме повышения удобства использования стоит также обратить внимание на уменьшение общего размера страницы и улучшение клиентской производительности. В данном случае нам нужно ограничить размер каждого из компонентов страницы 25 Кб для оптимизации кэширующего поведения.
Заданная ограниченная скорость сетевого беспроводного соединения в iPhone наряду с очисткой кэша в браузере при перезагрузке выводят на первый план важность уменьшения числа HTTP-запросов для повышения производительности. И это становится даже более важным, чем в случае загрузки страницы в обычном браузере. Подробнее об уменьшении числа запросов к серверу — техниках объединения файлов, использовании CSS Sprites и data:URI — рассказывается в следующей главе.
Глава 4. Уменьшение числа запросов
4.1. Объединение HTML- и CSS-файлов
Число запросов является наиболее узким местом при загрузке страницы. По последним исследованиям, порядка 40% времени загрузки уходит только на установление новых соединений с сервером. В этом свете любые методы, позволяющие уменьшить число запросов, выглядят весьма перспективно. Однако каждый такой метод, начиная с простого объединения стилей или скриптов и заканчивая data:URI, достаточно сложен в технологическом плане, поэтому в ряде случаев может просто не окупать затраченного времени.
Зачастую cookie выставляются на весь домен или даже на все поддомены, что означает их отправку браузером даже при запросе каждой картинки с вашего домена. В результате 400-байтный ответ с картинкой превратится в 1000 байтов или даже больше, в зависимости от добавленных заголовков cookie. Если на странице у вас много некэшируемых объектов и большие cookie на домен, то стоит рассмотреть возможность вынесения статичных ресурсов на другой домен (например, так поступил Яндекс, расположив статические файлы на домене yandex.net) и убедиться, что cookie там никогда не появятся.
В силу накладных расходов на передачу каждого объекта один большой файл загрузится быстрее, чем два более мелких, каждый в два раза меньше первого. Стоит потратить время на то, чтобы привести все вызываемые JavaScript-файлы к одному или двум, равно как и CSS-файлы. Если на вашем сайте их используется больше, попробуйте сделать специальные скрипты для публикации файлов на «боевом» сервере или уменьшите их количество. Если на странице в большом объеме располагаются десятки небольших GIF-файлов (для оформления границ или фона элементов), стоит рассмотреть ее преобразование в более простой CSS-дизайн (который не потребует такого большого числа картинок) и(ли) объединение в несколько больших ресурсных файлов.
Читать дальше