2.7. Режем cookie
В качестве заключительного аккорда при рассмотрении уменьшения количества передаваемых данных между сервером и клиентом нужно обязательно упомянуть cookie.
Cookie являются одним из HTTP-заголовков, которые браузер посылает на сервер, а сервер вправе им ответить (если копнуть глубже, то существует пара заголовков: Cookie и Set-Cookie — но в данном случае это не так существенно). Общий размер HTTP-заголовков обычно не превосходит 500–1000 байтов, однако cookie могут существенно его увеличить (так как на них накладывается ограничение в 4 Кб).
При объемах полезной информации в несколько Кб размер cookie может оказать критичное воздействие на скорость передачи данных. Давайте рассмотрим, какие существуют способы уменьшения этих издержек.
Оптимизируем размер, зону и время действия
В большинстве случаев пользователю просто не нужно пересылать огромные массивы данных каждый раз — для него вполне возможно ограничиться только сессионным ключом. Исходя из этого стоит пересмотреть логику использования заголовков cookie и оставить только действительно необходимые.
Как вариант, можно устанавливать cookie только для определенных разделов на сайте либо ограничиваться только текущей сессией пользователя на сайте (которая не будет сохраняться при повторном заходе).
Также у cookie можно варьировать срок действия, что будет несколько нивелировать их влияние, если пользователь будет заходить на сайт достаточно редко: с каждым новым заходом cookie из браузера пересылаться не будут, однако их будет отправлять сервер. Поэтому данная мера производительность особо не повысит.
Хостинг для компонентов без cookie
Для высоконагруженных проектов, которые активно используют cookie и стремятся минимизировать издержки от них, стоит рассмотреть вынос статических ресурсов на отдельный хост, для которого cookie вообще не будут устанавливаться.
В данном случае можно рассмотреть использование поддомена (что может оказаться бесполезным, если cookie выставляются на *.domain.ru) или домена верхнего уровня (в таком случае придется регистрировать отдельный домен для хранения статических ресурсов). Однако в обоих случаях возможны проблемы с локальными прокси-серверами: они могут отказаться кэшировать файлы с физически разных доменов.
Глава 3. Кэширование
3.1. Expires, Cache-Control и сброс кэша
Кэширование играет одну из основных ролей в быстродействии сайтов и сравнительно просто настраивается на стороне сервера. Веб-разработчики часто сталкиваются с кэшированием, ибо браузеры и проксирующие серверы, пытаясь ускорить работу сайтов для пользователя, очень часто стараются сохранить у себя максимально большое количество документов в локальном кэше.
При открытии страницы сайта в браузере (если эта страница была не первой на нем или если вы уже заходили на этот сайт в недалеком прошлом) браузер возьмет все (или почти все) ресурсы, необходимые для отображения страницы из кэша, чем весьма сильно может ускорить загрузку страницы. Однако при этом может потеряться актуальность представляемых данных, поэтому политика кэширования во всех браузерах реализована немного по-разному: каждый из них по-своему добивается компромисса между целостностью и актуальностью данных.
В качестве базовой настройки обычно используется инструкция браузеру от сервера для бессрочного кэширования каждого URL. Чтобы дать серверу понять, что файл был изменен, требуется использовать другое имя файла. На больших веб-сайтах обычно устанавливается такой процесс изменения этих файлов, что номер каждой новой версии добавляется к имени файла (например, common.v1.css становится common.v2.css). Соответственно, ссылки на эти файлы тоже должны быть программно обновлены, и это не зависит от языка программирования или системы шаблонов.
Настройка заголовка HTTP Expires
Заголовок Expires является частью спецификации HTTP 1.0. Когда HTTP-сервер отправляет ресурс (например, HTML-страницу или изображение) браузеру, он может дополнительно с ответом отправить этот заголовок с меткой времени. Браузеры обычно хранят ресурс вместе с информацией об истечении его срока действия в локальном кэше. При последующих пользовательских запросах к одному и тому же ресурсу браузер может сравнить текущее время и метку времени у закэшированного ресурса. Если метка времени указывает на дату в будущем, то браузер может просто загрузить ресурс из кэша, вместо того чтобы запрашивать его с сервера.