Настройка NGINX для WP Super Cache на BitrixEnv

Приветствую всех извращенцев, которые установили WordPress на BitrixEnv. Расскажу как удалось ускорить этот далеко не шустрый движок блогов с помощью плагина WP Super Cache и правильной настройки nginx.

В одной из статей объяснял почему устанавливаю на все сервера BitrixEnv: Ускорить WordPress. Очевидно, Битрикс Окружение не приспосабливает сервер полностью под WordPress. Но с ним потребуется минимум усилий, чтобы довести дело до ума и сделать сайт на WordPress действительно быстрым.

WP Super Cache

WP Super Cache - это плагин для ускорения WordPress. При работе он создаёт скомпилированную html копию страницы. И отдаёт её при следующей загрузке. По-моему это самый простой и удобный в настройке плагин. Благодаря структуре хранения кеша, этот плагин может работать в паре с nginx.

Как хранится кеш в WP Super Cache

При первом обращении к странице плагин создаёт её кешированную копию: html файл. Плагин сам обновляет файл при появлении новых комментариев под записью и при обновлении содержания публикации. А ещё он раскладывает файлы кеша по папкам, которые соответствуют путям сайта. К примеру:

Этот файл соответствует записи в этом блоге с url: https://www.alexgur.ru/articles/1003/.

В зависимости от наличия шифрования файл может обзываться index.html или index-https.html.

Сжатие

Если в настройках плагина включена gzip компрессия, то файл будет заканчиваться на gz. Но у меня сжатие статики настроено на уровне nginx, поэтому в плагине отключена эта функция. Наверное лучше включить её, чтобы nginx не напрягался со сжатием "на лету".

Настройка nginx для WP Super Cache на BitrixEnv

На простом хостинге файл html кеша WP Super Cache раздаётся через php. Но благодаря правильной организации хранения html файлов кеша, есть возможность раздавать файлы кеша через nginx. Это значительно ускорит сайт.

Первым делом заходим в папку с nginx настройками сайта в BitrixEnv. У меня это путь:

/etc/nginx/bx/site_avaliable/bx_ext_ssl_alexgur.ru.conf

В нём есть подключение общих для всех сайтов битрикса параметров. Примерно на 30 строке:

# Include parameters common to all websites
include bx/conf/bitrix.conf;

Создадим общий файл настроек для wordpress. Для этого сделаем копию bitrix.conf и обзовём wordpress.conf. Затем добавим его подключение в bx_ext_ssl_alexgur.ru.conf, комментируя настройки для битрикса:

# Include parameters common to all websites
# include bx/conf/bitrix.conf;
include bx/conf/wordpress.conf;

Открываем wordpress.conf и начинаем разбираться с его устройством. Сам файл сделан для раздачи композитного кеша битрикса, поэтому его логика совпадает с нашей. Ведь мы же тоже хотим раздавать через nginx готовые html файлы.

Программируем отдачу html через nginx

Все страницы, которые надо раздавать через nginx для этого сайта оканчиваются на слеш /. Поэтому в свежем файле wordpress.conf находим условие в файле:

# directories page processing
location ~ /$ {

set $cache_file "bitrix/html_pages$general_key/index@$args.html";

# test file conditions
if (-f "$docroot/bitrix/html_pages/.enabled") { set $usecache "${usecache}B"; }
if (-f "$docroot/$cache_file") { set $usecache "${usecache}C"; }

# create rewrite if cache-file exists
if ($usecache = "ABC" ) { rewrite .* /$cache_file last; }

proxy_pass $proxyserver;

}

Как можно догадаться из этого кода, для того чтобы nginx отдал файл кеша, необходимо выполнить несколько условий:

1. Должен существовать файл .enabled
2. Должен существовать файл кеша по запрашиваемому пути

Тогда переменная $usecache примет значение "ABC" и пользователь получит html файл кеша.

Не будем разрушать логику работы, а только вставим необходимый путь. И не будем забывать, что скомпиллированный html кеш не должен выдаваться авторизованному пользователю. Иначе администратор сайта не будет видеть панель WordPress вверху экрана. После модификаций блок location ~ /$ в wordpress.conf примет такой вид:

# directories page processing
location ~ /$ {

set $cache_file "wp-content/cache/supercache/$host$general_key/index-https.html";
set $usecache "${usecache}B";

# test file conditions
if (-f "$docroot/$cache_file") { set $usecache "${usecache}C"; }

# Don't use the cache for logged in users
if ($http_cookie ~* "wp-postpass|wordpress_logged_in") {

set $usecache "${usecache}D";

}

# create rewrite if cache-file exists
if ($usecache = "ABC" ) { rewrite .* /$cache_file last; }

proxy_pass $proxyserver;

}

Изменения в логике минимальны. Начинаем с того, что $usecache всегда будет равен "AB". Если файл кеша существует, то к $usecache добавится "С". Если пользователь авторизован, то добавится "D". Но файл кеша вернётся только если $usecache = "ABC".

Если у пользователя в куках есть wp-postpass или wordpress_logged_in, то $usecache будет равно "ABCD" и перенаправления на файл кеша не произойдёт.

Путь к файлу кеша находится в переменной $cache_file и равен "wp-content/cache/supercache/$host$general_key/index-https.html" . Переменная $host равна "www.alexgur.ru". Переменная "$general_key" будет иметь вид типа: "/articles/1003". Поэтому слеш между $host и $general_key не нужен.

Протестируем раздачу кеша

После внесения изменений в файлы, необходимо перезапустить nginx. И попробовать загрузить страницу сайта. Если страница будет отдана с хидером:

x-powered-by: PHP/_._.___

или

wp-super-cache: Served supercache file from PHP

то файл кеша не вернулся: что-то пошло не так или файл создался на этом запросе (попробуйте перезагрузить страницу ещё раз). А если подобного заголовка нет, то nginx отдал файл html кеша верно.

Результаты

Судя по графикам в Google webmaster, скорость сайта увеличилась.

В последней трети графика (с июля 2017 г.) страницы отдаются через nginx. Среднее время на загрузку страницы стало ~750 мс (было 900 - 1 100 мс).

P.S.

Во время отладки nginx пользуйтесь выводом переменных в хидер: "Настройка NGINX. Вывод переменных"

P.P.S.

Подожду неделю и измерю скорость сайта по вебмастеру Google, как сделал это в публикации: "Что быстрее WordPress или Bitrix?".

Мне кажется, сервера CloudFlare тормозят. Возможно, стоит отказаться от этого сервиса. Надо будет протестировать скорость без него...