Пожалейте ваш процессор! Быстрый gzip для nginx и apache

В этих Интернетах почему-то бытует мнение, что включение gzip означает большую нагрузку на процессор, как явление, сопутствующее пониженному потреблению интернет-трафика. Скажу честно, это утверждение не является справедливым. Даже для apache, хотя в nginx это делается куда проще. Есть рекомендации снижать степень сжатия, чтобы разгрузить ваш процессор. Бред!

Давайте сделаем самый эффективный gzip.

Быстрый веб-сервер nginx располагает замечательным модулем gzip_static. Суть в том, что на сервере хранятся одновременно две версии файла: одна – несжатый файл, другая – файл, пожатый с максимальной степенью сжатия. Базовый синтаксис для включения gzip_static таков:

        location /lib {
                root /home/vashserver.com/public_html;
                expires 30d;
                gzip_static on;
        }

Так мы даем понять, что каталог /lib надо искать в каталоге /home/vashserver.com/public_html, что при возможности отдать готовые сжатые файлы - нужно их отдавать; а также о том, что результат запроса следует кэшировать в течение 30 дней.

Подготовка gzip файлов

В Интернетах в последнее время дофига фанатов всяких питонов и PHP. Но самый простой и понятный, наверное, большинству способ для подготовки файлов - это простенький shell-скрипт:

#!/bin/sh
for i in *.js *.css; do
        cat $i | gzip -9 > $i.gz
        chown --reference=$i $i.gz
        touch -r $i $i.gz
done

Скрипт проходит по всем .js и .css файлам, записывая их сжатую копию в файл с дополнительным расширением .gz: например, в дополнение к файлу example.css будет создан файл example.css.gz. Файл создается с максимальным сжатием: да, если у нас есть возможноть выкроить 10 байт, эту возможность стоит использовать! При посещаемости 1000 уников в день, мы выиграем: 1000 * 10 * 365 = 3.65 Мбайта. А если это портал с сотней тысяч уников в день, мы экономим уже треть гигабайта. Вообразите только, какую экономию это дает, например, таким гигантам как Google.

Для того, чтобы nginx не "сходил с ума", мы также устанавливаем файлам того же владельца и дату изменения, что и у оригинального файла.

Как я уже говорил, подобный метод можно использовать и в Apache. Конфигурация сервера будет примерно такой:

<IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteCond %{HTTP:Accept-encoding} gzip
 RewriteCond %{REQUEST_FILENAME}.gz -f
 RewriteRule ^(.*)\.(css|js)$ $1.$2.gz [QSA,L]
 <FilesMatch  \.css\.gz$>
  ForceType text/css
 </FilesMatch>
 <FilesMatch  \.js\.gz$>
  ForceType text/javascript
 </FilesMatch>
</IfModule>
<IfModule mod_mime.c>
 AddEncoding gzip .gz
</IfModule>

Если браузер обращается к файлу .css или .js, мы пересылаем его на файл .css.gz или .js.gz, говорим, что MIME-тип этого файла - такой же, как у его несжатого собрата. А Content-Encoding выставляем в gzip.

Если хостер казёл, или используем только mod_rewrite:

<IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteCond %{HTTP:Accept-encoding} gzip
 RewriteCond %{REQUEST_FILENAME}.gz -f
 RewriteRule ^(.*)\.(css|js)$ $1.$2.gz [QSA]
 RewriteRule \.css\.gz$  - [T=text/css]
 RewriteRule \.js\.gz$   - [T=text/javascript]
</ifmodule>

Вероятно, это должно работать помедленнее, но все-таки должно :-). Впрочем, бенчмарков не делал - your mileage may vary. Apache на наших серверах не используем - примеры не обязательно жизнеспособны. Возможно, придется чуть "допилить" их под свои нужды.

Если хостер казёл и не дает ssh, можно подготовить файлы и локально, просто выполните в командной строке такую команду:

for /f %f in ('dir /b *.css *.js') do copy %f %f.bak && gzip %f && move %f.bak %f

Вам потребуется файл gzip.exe, его нужно положить в каталог с Windows или любой другой каталог, присуттвующий в %PATH%. Скачать можно, например, с моего сайта: http://baron.su/downloads/gzip.exe. Не забудьте потом его положить в %WINDIR% (каталог, куда установлена Windows).

Вопросы, ошибки, предложения? Не стесняемся, пишем в комменты.

Если статья вам помогла, пожалуйста, добавьте ее в социальные закладки: или просто расскажите друзьям.