Конфигурируем Apache

Тесты под Konqueror показали, что этот браузер не понимает архивированных файлов (CSS и JavaScript), поэтому чтобы уберечь десятую долю процента посетителей от сердечного приступа (когда они увидят сайт без соответствующих стилей), стоит добавить его в этот набор правил. Аналогично и «старым» браузерам (которые явно указывают, что не понимают архивов) отдается неархивированное содержание.

<IfModule mod_rewrite.c>

RewriteEngine On

# перенаправляем Konqueror и «старые браузеры»

RewriteCond %{HTTP:Accept‑encoding} !gzip [OR]

RewriteCond %{HTTP_USER_AGENT} Konqueror

RewriteRule ^(.*)\.(css|js)$ $1.nogzip.$2 [QSA,L]

</IfModule>

Вся вышеуказанная конструкция «обернута» условием наличия на сервере подключенного mod_rewrite. Если он отсутствует, то это сразу станет видно на заявленных браузерах (перестанут отображаться стили и отрабатывать скрипты). Иначе Apache просто не сможет запуститься, т. к. RewriteEngine не будет объявлен.

Дополнительно к заявленной логике необходимо выставить ряд заголовков для отдаваемых файлов. В частности, Vary и Cache‑control касаются локальных проксирующих серверов, которые не должны кэшировать эти файлы, а пропускать их дальше к пользователю, не обрезая при этом заголовок User‑Agent (иначе наш сервер никак не узнает, можно ли отдавать архивированную копию файла или нет).

<IfModule mod_headers.c>

Header append Vary User‑Agent

# выставляем для всех css/js файлов Content‑Encoding

<FilesMatch .*\.(js|css)$>

Header set Content‑Encoding: gzip

Header set Cache‑control: private

</FilesMatch>

# сбрасываем Content‑Encoding в том случае, если отдаем не архив

<FilesMatch .*\.nogzip\.(js|css)$>

Header unset Content‑Encoding

</FilesMatch>

</IfModule>

В итоге для всех файлов, которые мы отдаем как архивы, дополнительно объявляется Content‑Encoding, а для их неархивированных копий этот заголовок сбрасывается. Чем и достигается полная работоспособность данного решения.

Маленькие «но»

Единственное неудобство, которое может возникнуть: нужно иметь в разработке нормальные версии, а при публикации всех изменений – их архивировать и переименовывать. При промышленном подходе к разработке все эти действия автоматизируются, а при кустарном – трудозатраты не так существенны по сравнению с увеличением скорости загрузки сайта (если, конечно, не собирать проект прямо на боевом сайте, без конца архивируя один и тот же файл).

Итак, финальный алгоритм действий (при наличии на сервере mod_headers; иначе лучше воспользоваться конфигурацией, приведенной в восьмой главе) должен быть следующим:

Добавляем описанные выше инструкции (оба блока) в конфигурационный файл Apache или.htaccess

Пакуем файлы (с помощью 7‑zip или gzip) и кладем на место обычных (расширение у файлов должно остаться прежним, .css или .js). Например, если у нас есть файл anyname.css, то после упаковки получается файл anyname.css.gz; переименовываем его обратно в anyname.css и заливаем на сервер. Для gzip все немного проще:

gzip ‑c ‑9 ‑n anyname.css > anyname.css.gz

mv anyname.css anyname.nogzip.css

mv anyname.css.gz anyname.css

Рядом с сжатыми файлами кладутся файлы с расширением nogzip.css или nogzip.js, которые содержат неархивированные копии. Например, после заливки сжатого файла anyname.css нужно создать на сервере еще один файл anyname.nogzip.css, который является копией несжатого файла. Для gzip это копирование уже производится чуть выше второй строкой в листинге.