Кэширование

Позднее, если браузер хочет определить актуальность компонента, он передает заголовок If-None-Match для передачи ETag обратно на сервер. Если ETag совпадают, ответ от сервера приходит со статус-кодом 304, уменьшая, таким образом, объем передачи на 19145 байтов:

GET /b.png http/1.1
Host: i.webo.in
If-Modified-Since: Tue, 12 Dec 2008 03:03:59 GMT
If-None-Match: "10c24bc-4ab-457e1c1f"
http/1.1 304 Not Modified

Включить ETag для Apache можно, например, следующей директивой в конфигурации:

FileETag MTime Size

При этом ETag будет сформирован из даты изменения файла и его размера.

Синхронизация ETag и Last-Modified

Проблема ETag состоит в том, что обычно они используют атрибуты, специфичные в пределах одного сервера. ETag не совпадут, если браузер загрузит компонент страницы с одного сервера и попробует проверить его с другим сервером (у которого время изменения файла и(ли) номер блока на жестком диске для данного файла отличаются от первого) — ситуация очень распространенная, если вы используете кластер для обработки запросов. По умолчанию и Apache, и IIS включают в ETag такие данные, которые вряд ли дадут положительный результат при проверке на актуальность компонента на разных серверах.

Apache 1.3 и 2 генерирует ETag в формате inode-size-timestamp. Даже если один и тот же файл на разных серверах лежит в одной и той же папке, имеет те же права, размер и время, номер его иногда будет отличаться от сервера к серверу.

IIS 5.0 и 6.0 имеют похожий формат ETag: Filetimestamp:ChangeNumber. ChangeNumber — внутренняя переменная IIS для отслеживания изменений в конфигурации самого IIS, и нет гарантии, что эта переменная будет одинакова на всех серверах, обслуживающих веб-сайт.

В результате ETag, которые сгенерирует Apache или IIS для одного и того же файла, будут отличаться на разных серверах. Если ETag не будут совпадать, пользователь не будет получать маленький и быстрый ответа со статус-кодом 304 — собственно, ради чего ETag и разрабатывался. Взамен он будет получать стандартный код ответа 200 и далее весь запрошенный компонент.

Если сайт находится только на одном сервере, это не будет большой проблемой. Но если вы используете несколько серверов с Apache или IIS, устанавливающие ETag в соответствии с настройками по умолчанию, пользователи будут дольше загружать страницы, на серверах будет бoльшая загрузка, нежели могла бы, вы будете тратить больше трафика, а прокси-серверы не будут кэшировать этот контент так, как хотелось бы. Даже если заголовок Expires будет установлен в далекое будущее, вам все равно будет приходить условный GET-запрос, когда пользователь перезагрузит страницу.

Если вы не получаете всех преимуществ, которые предоставляет ETag, тогда лучше совсем отключить его. Тег Last-Modified позволяет проверять актуальность компонента на основании его времени изменения, а отключение ETag даст возможность уменьшить заголовки запроса и ответа. Если вы используете Apache, просто добавьте строку

FileETag none

в конфигурационный файл сервера.

Кэширование в iPhone

На MacWorld 2008 Steve Jobs анонсировал, что Apple уже продала на текущий момент 4 миллиона iPhone, что составляет по 20 тысяч iPhone каждый день. В докладе Net Applications говорится, что общая доля пользователей Интернета с iPhone поднялась до 0,12% в декабре 2007 года, обогнав, в совокупности, все браузеры для мобильных устройств, работающие под управлением Windows. iPhone от Apple изменил ситуацию для пользователей, выходящих в Интернет через мобильные устройства.

Веб-разработчики теперь могут создавать функциональные и привлекательные приложения, которые работают на iPhone-версии браузера Safari для мобильных устройств. Однако при этом сам iPhone не только предоставляет новые и достаточно интересные возможности для разработчиков мобильных устройств, но и обнаруживает ряд уникальных проблем в сфере производительности.

По поводу этого устройства на данный момент доступна только ограниченная информация, а понимание основ его алгоритмов кэширования является существенным для создания высокопроизводительного сайта. Команда по исключительной производительности Yahoo! рассмотрела кэширующие свойства iPhone. Основной акцент делался на исследовании следующих вещей:

• максимальный размер кэша для каждого компонента по отдельности;
• максимальный размер кэша для всех компонентов;
• эффект от gzip -сжатия для максимального размера кэша;
• остаются ли компоненты в кэше после перезагрузки iPhone.

Результаты экспериментов над кэшем как для Apple iPhone, так и для iPod Touch получились одинаковые.

Попадание в кэш

В результате исследования было установлено, что если размер компонентов превышает 25 Кб, то браузер в iPhone не кэширует этот компонент. Поэтому веб-страницы, которые спроектированы специально для iPhone, должны уменьшить размер компонентов не более чем до 25 Кб, чтобы оптимизировать кэширующее поведение.

Хорошие новости заключаются в том, что если браузер загружает новый компонент, размер которого больше чем 25 Кб, то это не влияет на компоненты, которые уже находятся в кэше. Закэшированные компоненты заменяются более новыми, только если последние не превосходят 25 Кб. При этом выбирается самый маленький из последних используемых.

На http://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 — рассказывается в следующей главе.