CSS и JavaScript в виде архивов

Теперь давайте рассмотрим, каким образом лучше всего будет отдавать CSS- и JavaScript- файлы в архивированном виде. Для обеспечения корректного архивирования, по- видимому, наиболее общий подход будет заключаться в выполнении по порядку следующих пунктов.

  • Проверить, умеет ли клиент принимать файлы в формате gzip-encoded.
  • Обеспечить соответствующий вывод на стороне сервера через gzip-функции либо организовать это непосредственно через веб-сервер (например, Apache).
  • Настроить конфигурационные файлы (или .htaccess), чтобы обеспечить корректный Content-Type.

В данном случае сжатие данных «на лету», возможно, не будет наиболее оптимальным решением, потому что файлы стилей и скриптов изменяются достаточно редко, а мы заставим сервер каждый раз их сжимать. Тем более что лучше самого сервера с архивацией файлов никто не справится.

Статическое архивирование в действии

Есть способ обойтись просто парой строчек в конфигурационном файле (httpd.conf или .htaccess, первое предпочтительнее), если потратить пару минут и самостоятельно заархивировать все необходимые файлы. Предположим, что у нас есть JavaScript- библиотека jquery.js на сервере. Заархивируем ее в jquery.js.gz (при помощи 7-zip или любой другой утилиты, если в работе используется Windows). В итоге, должен появиться файл jquery.js.gz. Его нужно положить в ту же директорию на сервере, что и исходный файл. Если работать прямо на сервере через командную строку, то достаточно выполнить следующую команду:

gzip jquery.js -c -n -9 > jquery.js.gz

Опция -c создаст новый файл (перенаправляем поток вывода в jquery.js.gz), -n исключит имя файла из архива (оно там только лишние байты занимает), а -9 заставит использовать максимальную степень сжатия. Таким образом, мы получим минимально возможный архив из искомого файла.

Проблемы для Safari

В ходе реализации данного решения возникла маленькая, но досадная неприятность. Safari не умеет правильно обрабатывать файлы с расширением .gz: для этого браузера стили и скрипты не могут иметь такого расширения. Как же нам быть? Выход достаточно простой и очевидный. Нам нужно именовать все архивы стандартным образом, но при этом иметь неархивированную версию для обратной совместимости (например, с дополнительным суффиксом nogzip). Поэтому для подготовки файлов нам будут нужны две команды (jquery здесь используется только в качестве примера):

cp $src/jquery.js $dst/jquery.nogzip.js

gzip $dst/jquery.nogzip.js -9 -n -c > $dst/jquery.js

где $src — директория, в которой хранятся исходные файлы, а $dst — финальная директория для публикации. Сначала мы копируем файл в финальное место дислокации, а потом его архивируем под «правильным» именем.

Конфигурируем 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, иначе лучше воспользоваться конфигурацией, приведенной в восьмой главе) должен быть следующим.

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

2. Пакуем файлы (с помощью 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

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

Два слова о nginx

Кто работал с этим сервером, наверное, уже подумали: есть же модуль ngx_http_gzip_static_module, который позволяет класть рядом с файлом его сжатую версию с дополнительным расширением .gz и забыть, практически, обо всех описанных проблемах (этот функционал присутствует и для Apache 1.3). К сожалению, минусом данного решения будет отключение сжатия для всех видов файлов у браузера, который не поддерживает хотя бы один (теряется гибкость настройки). Однако, на данный момент таких случаев доли процента, поэтому если у нас проект с низкой или средней посещаемостью, указанный модуль (в совокупности с ngx_http_gzip_module) позволит преодолеть почти все подводные камни. Подробная конфигурация для nginx и Apache приведена в восьмой главе. В третьей главе рассказывается, как данное решение можно расширить для сброса кэша на клиенте. Теперь же перейдет к более подробному рассмотрению методов сжатия CSS- и JavaScript-файлов — это ведь может быть не только архивирование.

Posted in Разгони свой сайт.