Если мы не можем адекватно использовать нормальные форматы (PNG, GIF) для представления favicon.ico, то почему бы не задействовать gzip-сжатие для ее выдачи клиентскому браузеру? Можно. И все актуальные браузеры это понимают. Размер при этом составляет порядка 300 байтов (уменьшается в 3 раза по сравнению с исходным).
Повторюсь, речь идет о возможностях для уменьшения favicon.ico в целом, а не об абсолютных цифрах. Если у вас на сервере уже используется сжатие, просто добавьте туда компрессию для image/x-icon и забудьте о ней.
В качестве технологии экстремальной оптимизации можно рассмотреть возможность включения favicon.ico по протоколу data:URI (подробнее о нем написано в четвертой главе), чтобы отобразить страницу в клиентском браузере после первого запроса на сервер (подразумевается, что с сервера уйдет один-единственный HTML-файл, содержащий все необходимые составляющие в себе).
Однако для рядовых сайтов такой подход совершенно бессмысленнен, потому что процедура каждый раз будет отдавать пользователю лишние байты. Самым логичным его применением будут рекламные страницы, которые пользователь должен увидеть только один раз.
Одним из наиболее спорных моментов в презентации Yahoo! было заявление о том, что favicon.ico «мешается» при загрузке страницы. Как можно судить по логам сервера при загрузке страницы, этот файл действительно запрашивается где-то в середине общего процесса загрузки, ориентировочно после CSS-файлов и до фоновых изображений, поэтому его оптимизация может оказаться одним из ключевых моментов для ускорения загрузки сайта в момент первого посещения (с пустым кэшем).
Также ради простого уважения к пользователям (зачем им загружать лишние 10 Кб кода, который отрисуется у них в области 16x16 пикселей?) не стоит раздувать его размер без особой необходимости. Уважайте своих посетителей.
В качестве заключительного аккорда при рассмотрении уменьшения количества передаваемых данных между сервером и клиентом нужно обязательно упомянуть cookie.
Cookie являются одним из HTTP-заголовков, которые браузер посылает на сервер, а сервер вправе им ответить (если копнуть глубже, то существует пара заголовков: Cookie и Set-Cookie — но в данном случае это не так существенно). Общий размер HTTP-заголовков обычно не превосходит 500–1000 байтов, однако cookie могут существенно его увеличить (так как на них накладывается ограничение в 4 Кб).
При объемах полезной информации в несколько Кб размер cookie может оказать критичное воздействие на скорость передачи данных. Давайте рассмотрим, какие существуют способы уменьшения этих издержек.
Оптимизируем размер, зону и время действия
В большинстве случаев пользователю просто не нужно пересылать огромные массивы данных каждый раз — для него вполне возможно ограничиться только сессионным ключом. Исходя из этого стоит пересмотреть логику использования заголовков cookie и оставить только действительно необходимые.
Как вариант, можно устанавливать cookie только для определенных разделов на сайте либо ограничиваться только текущей сессией пользователя на сайте (которая не будет сохраняться при повторном заходе).
Также у cookie можно варьировать срок действия, что будет несколько нивелировать их влияние, если пользователь будет заходить на сайт достаточно редко: с каждым новым заходом cookie из браузера пересылаться не будут, однако их будет отправлять сервер. Поэтому данная мера производительность особо не повысит.
Хостинг для компонентов без cookie
Для высоконагруженных проектов, которые активно используют cookie и стремятся минимизировать издержки от них, стоит рассмотреть вынос статических ресурсов на отдельный хост, для которого cookie вообще не будут устанавливаться.
В данном случае можно рассмотреть использование поддомена (что может оказаться бесполезным, если cookie выставляются на *.domain.ru) или домена верхнего уровня (в таком случае придется регистрировать отдельный домен для хранения статических ресурсов). Однако в обоих случаях возможны проблемы с локальными прокси-серверами: они могут отказаться кэшировать файлы с физически разных доменов.
