WP SUPER CACHE НАСТРОИКА ПЛАГИНА

В этой части я подробно рассмотрю принцип работы каждого плагина, о которых говорил в первой части, а также приведу код с доработками для закрытия проблем плагинов. Кратко все преимущества и недостатки, основные выводы я уже сделал в первой части статьи.

Напомню, что я определял для себя следующие требования к плагинам:

1. Умение исключать GET-параметры и рекламные метки при кешировании
2. Возможность использования PHP-функций на сайте

WP Super Cache

На сегодняшний день — это самый популярный плагин для кеширования WordPress. Его я выбрал в самом начале своих потуг в оптимизации WordPress.

В процессе эксплуатации выявлялись разные «косяки» в его работе, и я периодически правил настройки, чтобы подобрать оптимальные. На текущий момент у тех сайтов, где я использую этот плагин, настройки выглядят следующим образом:

Почему именно так? И почему многие настройки отличаются от рекомендованных разработчиком и рекомендаций со StackOverflow.

• Метод доставки кеша: «Простой». Эта настройка отвечает за то, кто будет обрабатывать доставку кеша. При простом методе этим будет заниматься сам WordPress с помощью PHP, а при режиме «Эксперт» все правила будут записаны в файл .htaccess, и при попытке зайти на страницу, Apache отдаст уже готовый HTML-файл, если он существует. Действительно, на цифрах второй способ работает процентов на 10-20% быстрее. Но это, если сравнивать доставку с помощью PHP (положим, TTFB: 80 мс) и доставку с помощью mod_rewrite (положим, TTFB: 60 мс). Если же сравнивать с загрузкой страницы без применения кеширования (положим, TTFB: 6 000 мс) — разница получается не столь велика. При этом, выбрав первый («простой») способ доставки кеша, код, который мы можем разместить в корневом index.php, будет исполнен. Это позволит нам реализовать свой кастомный трекинг и другую нестандартную логику. Если же нет необходимости в исполнении каких-либо PHP-скриптов на сайте, то нужно выбирать вторую настройку «Эксперт».
• Отключить кеширование для авторизованных пользователей. ( Рекомендовано).
  Это позволит редакторам и контент-менеджерам, которые работают с сайтом регулярно, не нажимать «Удалить весь кеш», чтобы посмотреть внесенные ими изменения на страницах.
• Отключить «Сжимать файлы кэша чтобы ускорить работу (Рекомендовано)». W P Super Cache создает 3 файла: HTML-копию страницы, GZIP-архив с этой страницей (чтобы браузер мог быстрее её получить, распаковать локально на ПК пользователя и быстрее её отобразить), а также php-файл, содержащий тот же самый HTML в случае, если кеш был создан не автоматически. Именно последний php-файл и будет отдаваться пользователям, пришедшим по рекламе, при этом для PHP-файла GZIP-архив не создается. Если же мы хотим, чтобы абсолютно всем пользователям (включая привлеченных с помощью рекламы) страница отдавалась в сжатом виде, то это лучше реализовать с помощью конфига Apache. В этом случае веб-сервер самостоятельно будет сжимать с помощью GZIP любую страницу вне зависимости от типа кеширования и в случае, если кеш-файл создан вообще не был. С помощью этой настройки мы просто сэкономим место на хостинге, которое выделяется под хранение GZIP-архивов с кешем.
• Авто перестройка кэша. Гости блога увидят устаревшие версии страниц кэша пока новые будут генерироваться. ( Рекомендовано). Эта настройка позволит отдавать всем пользователям всегда закешированные страницы, даже если срок жизни кеша уже истёк (в то время, пока новый кеш только создается).
• Отключить «Дополнительная сверка кэша (очень редко может нарушить работу кэширования). ( Рекомендовано)». Если функция будет включена, наша кастомная логика из index.php будет постоянно ломать кеш, и он будет постоянно пересоздаваться, принуждая пользователей видеть долгую загрузку.
• Отключить «Создать список страниц в кэше (выводится на этой странице)». Нам это не нужно, список страниц всегда можно обновить и посмотреть в разделе «Состояние кеша».

Отключаем таймаут кеширования. Позже мы включим автокеширование, которое не позволит очищать автоматически созданные файлы, при этом созданные кеш-файлы по заходам пользователей из рекламы будут удаляться по таймауту. Но нам это не нужно, эти файлы будут удалены при следующем запуске автокеширования, а если мы укажем таймаут меньше, чем интервал запуска автокеширования — они попросту удаляться раньше, чем нужно. Поэтому устанавливаем значение: «0», при этом не стоит переживать за накопление мусора, при запуске автокеширования ВЕСЬ мусор будет удален.

Далее переходим на вкладку «Общий кеш», где реализуем автокеширование.

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

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

Да, WP Super Cache самостоятельно обновит кеш страницы при внесении в неё изменений, НО он не будет обновлять другие страницы, где может присутствовать эта запись (например, на главной, в подвале или в сайдбаре).

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

В общем, если на сайте активно публикуются новости или статьи, стоит указать промежуток от 1 до 2 часов. Если же сайт по большей части статичный, и на нём редко что-либо публикуется или редактируется, спокойно можно выставить интервал в 24 часа.

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

На этом настройка плагина завершена.

Проблемы WP Super Cache

Единственная (но критичная) проблема WP Super Cache заключается в том, что он не умеет вычленять из URL необходимые GET-параметры, и все страницы с UTM-метками и прочими аналитическими параметрами считает за уникальные.

Разработчики плагина как будто бы знали о такой проблеме, потому что предусмотрели настройку «Не кешировать страницы с параметрами GET (?x=y в конце URL)». Тем не менее, она ничего не даёт, кроме экономии места на диске, потому что кеш не будет создаваться для страниц с GET-параметрами.

Единственный способ избежать этой проблемы — это «колхозить» плагин. Колхоз и допилы чужих решений — это то, за что я проклинаю всех разработчиков, потому что так делать нельзя (как минимум, после обновления плагина — все твои изменения будут отменены).

Ничего умнее я не смог придумать, как добавить в файл wp-content/plugins/wp-super-cache/wp-cache-phase1.php
следующий код:

function removeGetParameter($url, $varname) {
	return preg_replace('#\\?$#', '', preg_replace('/([?&])'.$varname.'=[^&]+(&|$)/','$1',$url));
}
$wp_cache_request_uri = removeGetParameter($wp_cache_request_uri, "utm_source");
$wp_cache_request_uri = removeGetParameter($wp_cache_request_uri, "utm_medium");
$wp_cache_request_uri = removeGetParameter($wp_cache_request_uri, "utm_campaign");
$wp_cache_request_uri = removeGetParameter($wp_cache_request_uri, "utm_content");
$wp_cache_request_uri = removeGetParameter($wp_cache_request_uri, "utm_term");
$wp_cache_request_uri = removeGetParameter($wp_cache_request_uri, "gclid");
$wp_cache_request_uri = removeGetParameter($wp_cache_request_uri, "yclid");

после строчки $wp_cache_request_uri

Это позволяет указать плагину на то, какую страницу мы хотим достать из кеша, при этом не перенаправляя никуда пользователя (в адресной строке UTM-метки у пользователя останутся).

В итоге, проблема устранена, но не до конца. Даже если страница https://www.site.com/landing-page/ была ранее уже закеширована, при попытке зайти по ссылке https://www.site.com/landing-page/?utm_source=yandex&utm_medium=cpc&utm_campaign=promo&utm_content=banner&utm_term=i-wan-to-buy-something&yclid=93473892748392743473829 рядом создается еще один файл кеша (естественно страница грузится медленно). В разделе «Статистика кеша» на странице плагина мы увидим 2 идентичных элемента: https://www.site.com/landing-page/  в разделе «WP Super Cached Files» и точно такую же https://www.site.com/landing-page/ в разделе «WP Fresh Cached Files». Тем не менее, до момента истечения срока жизни кеша, при попытке обратиться с любым набором из описанных GET-параметров, который мы «приколхозили» с любым их значением (например, https://www.site.com/landing-page/?gclid=666), пользователю уже будет отдаваться кешированная версия (т.е. страница загрузится быстро).

Перелопатив тысячи строк кода, я так и не нашел способ это победить. Поэтому для себя, пока что, я нашел очень «костыльный», но всё же работающий способ решить эту проблему:

1. Пишем PHP-скрипт, который поштучно обходит файл sitemap.xml и дёргает за раз по 10 ссылок (поочередно)
2. Добавляем к каждой ссылке «/?utm_source=test» и с помощью file_get_contents «открываем» эти страницы
3. Вешаем этот скрипт на CRON с запуском каждую минуту

10 хитов в минуту — это не слишком много, а при условии, что по большей части будет отдаваться уже существующей кеш, то ощутимой нагрузки это не создаст. Тем не менее, WP Super Cache создаст кеш-файлы для всех страниц сайта, которые могут игнорировать указанные нами GET-параметры.

WP Rocket

В попытках найти более элегантный способ для реализации кеширования с GET-параметрами, я решил попробовать другой плагин — WP Rocket. И это полный провал. Несмотря на то, что плагин распространяется исключительно платно (по подписке), имеет красивый интерфейс и кучу настроек — все они бесполезны!

Во-первых, возможности выбора метода доставки кеша (mod_rewrite или PHP) нет, он работает исключительно через mod_rewrite, поэтому реализовать кастомный трекинг (как и любую другю PHP-логику) невозможно.

Во-вторых, автокеширование даже сравнительно небольшого сайта (~100 страниц) убивает напрочь сервер, на котором он крутится (скорее всего WP Rocket пытается осуществить обход всех страниц разом).

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

В общем, я даже не стал тратить время на доработки этого плагина.

W3 Total Cache

Следующим на очереди у меня был W3 Total Cache. Он хорошо себя показал, и имеет право на жизнь. Он имеет настройку, которая позволяет игнорировать указанные GET-параметры, и это работает без «костылей», как с WP Super Cache. Также W3 Total Cache имеет возможность работать через PHP (выбрав в разделе «Page Cache» настройку хранилища «Disk: Basic», код, размещенный в корневом index.php, будет исполнен, а скорость загрузки закешированных страниц будет высокая, сопоставимая с результатами WP Super Cache). В целом, функционал W3 Total Cache значительно превосходит WP Super Cache. Помимо множества вариантов более сложного кеширования (Memcached, APC, Zend OPcache, Redis), он из коробки умеет объединять и сжимать HTML, CSS и JS, а также выполнять Lazy Loading изображений.

Тем не менее для меня критичными оказались 2 проблемы:

1. Вторая очень болезненная проблема — это процесс обновления кеша. W3 Total Cache конечно имеет функцию пребилда, т.е. он автоматически с заданным интервалом обходит сайт согласно sitemap.xml для создания кеш-файлов. При этом обход он осуществляет непрерывно, но пересоздает кеш-файлы лишь в тот момент времени, когда кеш уже устарел. В итоге получается следующая ситуация — в момент, когда время жизни кеша истекло, W3 Total Cache не успевает быстро обойти весь сайт, чтобы обновить кеш-файлы, и когда пользователь пытается зайти на страницу, с большой вероятностью она окажется с просроченным кешем и будет грузиться медленно. Ротация обхода тоже вряд ли совпадет с датами истечения кеша страниц, потому что обход запускается не в какой-то определенный момент времени, а работает непрерывно. И если страница была закеширована в 21:00, то далеко не факт, что после истечения срока жизни кеша (например, 1 час) эта страница попадет в обход ровно в 22:00.

В итоге имеем ситуацию:

• Сайт 100 страниц
• Время жизни кеша: 1 час
• TTFB без кеширования: 5-6 сек (5 000 – 6 000 мс)
• Обход: 1 раз в минуту по 10 страниц (за указанный промежуток времени больше 10 страниц при таких характеристиках лучше не обходить, т.к. если страницы не будут успевать кешироваться, то будет забиваться Cron и расти нагрузка на сервер. Меньше 1 раза в минуту указать нельзя, т.к. минута — это минимальный интервал Cron-а WordPress).

В этом случае каждый час у нас будет промежуток в +/- 10 минут, когда пользователь может попасть на страницу, кеш которой истек, а новый кеш будет создаваться во время загрузки страницы для этого пользователя. Пользователь увидит долгую загрузку страницы (чего мы пытаемся избежать).

Увеличивать время жизни кеша не хочется. Да, при обновлении страниц или новостей кеш для них автоматически будет обновлен, но на других страницах, куда могут быть подгружены эти записи, например, на главную, кеш обновлен не будет, а соответственно, добавленная или измененная запись там не появятся ровно до тех пор, пока не истечет время жизни предыдущего кеша.

Тем не менее в случае, если нет желания дорабатывать WP Super Cache, то W3 Total Cache вполне себе альтернатива. Также W3 Total Cache отлично подойдет для статичных сайтов, где можно обновлять кеш раз в сутки — запустил один раз ночью, и пусть он всё обновляет пока на сайте трафика мало. Либо вообще не использовать функцию автокеширования и обновлять кеш вручную при изменении сайта.

Настройка W3 Total Cache

После установки и активации плагина, нас встречает «Мастер настройки». Для каждого типа кеширования он проведет наглядные тесты и предложит на выбор разные параметры кеширования.

• На вкладке «Page Cache» выбираем «Диск: базовое», если хотим использовать кастомную PHP-логику. Если наличие такой возможности не критично, то выбираем «Диск: расширенное», в этом случае рулить доставкой кеша будет mod_rewrite, а скорость загрузки страниц будет немного выше.
• На вкладке «Кеш БД» выбираем «Отсутствует», т.к. у нас уже есть закешированные копии HTML-страниц. Кеширование БД нам потребуется только в том случае, если по какой-то причине кеширование страниц (Page Cache) отключено.
• На вкладке «Объектное кеширование» выбираем «Отсутствует», т.к. у нас уже есть закешированные копии HTML-страниц. Кеширование объектов нам потребуется только в том случае, если по какой-то причине кеширование страниц (Page Cache) отключено.
• На вкладке «Browser Cache» выбираем «Включено», это позволит сохранить на непродолжительное время копию страницы сайта в браузере пользователя. И, если он повторно попытается зайти на эту страницу, она мгновенно будет загружена браузером из локального хранилища устройства пользователя.
• «Lazy Load изображений» сейчас мы не включаем, это уже относится к оптимизации контента на сайте. Способы оптимизации HTML, JS, CSS и изображений можно рассмотреть в отдельной статье.

Далее переходим в админке в раздел «Perfomance» — «Page cache»

Включаем автокеширование («Автоматическая настройка кеша страницы»), указываем интервал обновления (минимум 60 секунд, т.к. W P Cron не умеет работать быстрее), указываем кол-во страниц в интервале — выбираем в зависимости от скорости загрузки страниц без применения кеширования (если без кеширующего плагина в среднем TTFB страниц ~5 сек., то стоит указать кол-во не более 12, чтобы не нагружать лишний раз сервер). Также необходимо указать путь к Sitemap. XML, на основе которого будет осуществляться обход сайта. Рекомендую использовать для построения Sitemap. XML плагин «Yoast SEO», т.к. для интеграции с Yoast SEO у W3 Total Cache есть отдельное расширение, а это значит, что сайтпамы, сгенерированные Yoast SEO будут поглощаться плагином W3 Total Cache без каких-либо ошибок.

Чтобы отключить автокеширование у плагина W3 Total Cache достаточно поставить 0 в интервале обновления.

Далее спускаемся к разделу «Advanced»:

В блоке «Принятые строки запроса» указываем те GET-параметры URL-адресов, которые мы не хотим кешировать отдельно. Также укажем значения «Максимальное время жизни кэшированых объектов» и «Период удаления устаревшего кэша» в зависимости от того как часто мы хотим обновлять кеш. Нажимаем «Сохранить настройки и очистить кэш». На этом настройка плагина завершена.

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

Тем не менее вторую проблему (долгая загрузка страниц в период обновления кеша) решить невозможно, т.к. это особенность логики работы плагина W3 Total Cache, поэтому я продолжаю свои изыскания.

Настройка Swift perfomance

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

После установки и активации плагина нас встречает вот такое меню:

Нажимаем «Manual configuration» и попадаем в консоль Swift perfomance, где сразу же нажимаем «Advanced view»:

Нажимаем «Save changes». На этом настройка плагина закончена.

Недостатки Swift perfomance

1. Он не умеет в кириллицу. Swift perfomance создает кеш ровно по тем адресам, которые имеют страницы сайта, т.е. если у нас URL страницы выглядит как https://example.com/контакты, он не будет переводить «контакты» в URL-encoded для создания кеша. Но браузер будет обращаться именно к https://example.com/%D0%BA%D0%BE%D0%BD%D1%82%D0%B0%D0%BA%D1%82%D1%8B, поэтому страницы, содержащие кириллицу, будут загружаться всегда медленно. Мелочь, но неприятно.
2. Скорость загрузки закешированных страниц с помощью Swift Perfomance всё же в 2-3 раза медленней, чем у WP Super Cache или у W3 Total Cache. Опять же, это не столь критично, когда при использовании кеширующего плагина скорость загрузки страницы упала с 8 000 мс до 300 мс, а не до 100 мс. Ведь не стоит забывать, что в этот момент пользователь всё равно не может пользоваться сайтом, т.к. страница должна отрендериться в браузере, должны загрузиться статичные файлы (css, js, картинки), а это явно не 100 и даже не 300 миллисекунд (если, конечно, сайт — это не черный текст на белом фоне).

3. Критичной стала проблема в работе «умного» кеширования в режиме «Action based mode». Разработчики заявляют, что при внесении изменений на сайте, запускается процесс обхода всех страниц сайта, при котором создаются новые кеш-копии файлов, а посетителям сайта продолжают отдаваться старые, пока новые не создадутся. В теории сайт всегда должен работать быстро, кеш перестраиваться максимально оперативно после обновления какой-либо информации на сайте, при этом нагрузка на сервер должна быть минимальной, т.к. процесс кеширования не происходит ровно до того момента, пока на сайте не были внесены изменения. По началу так и работает, но в какой-то момент всё ломается. На практике это «умное» автокеширование работает нестабильно. В какой-то момент созданные ранее кеш-файлы просто пропадают, плагин их удаляет или происходит какой-то рассинхрон, хотя новые копии под них ещё не были созданы, и сайт остаётся без какого-либо кеширования. Приходится запускать переобход вручную, а это ведёт к сильной нагрузке на сервер.

   Если же выбрать классический вариант обновления кеша (по таймауту) — «Time based mode» — проявятся все те же проблемы как у WP Rocket или W3 Total Cache — то отвалится автокеширование, то кеш-файлы будут удалены буквально через пару минут после их генерации. В общем, пользоваться Time based mode я не смог.

   Когда мы вручную обновляем весь кеш сайта, далеко не все страницы работают быстро. Через несколько минут после ручного запуска переобхода сайта, часть страниц уже имеют новый кеш (работают быстро), часть страниц еще отдаются со старым кешем (видим, что свежая новость в сайдбарах на этих страницах еще не появилась), но часть страниц (причем, немалая) грузится ужасно долго (8 – 12 сек. против 3-4 сек. без использования кеширования вообще).

В общем, я возлагал большие надежды на Swift Perfomance, но из-за нестабильной работы своего основного функционала, пришлось от него отказаться. На текущий момент я его не использую ни на одном из проектов.

WP Fastest Cache

WP Fastest Cache — это еще один популярный плагин для кеширования WordPress.

Забегая вперед, WP Fastest Cache вернул меня обратно к «колхозу». Но несмотря на это, на сегодня он попал в мои фавориты.

Настройка WP Fastest Cache

• Скачиваем и активируем плагин
• Ставим три галки как показано на скриншоте

Серьезно, ещё ни один плагин не настраивался так быстро!

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

Вот оно. Плагин, который не требует кучи параметров и просто работает. Плагин обходит сайт 1 раз в 5 минут (изменить в настройках время невозможно, но разработчики предусмотрели такую возможность через редактирование файла wp-config.php). Плагин кеширует указанное кол-во страниц (не более 12 шт. за раз, но с помощью wp-config.php можно указать любое количество). Пользователям отдаются кешированные файлы вне зависимости от их давности, а плагин в фоне (если установлена галочка «Restart After Completed») будет непрерывно обходить весь сайт для обновления файлов кеша.

Но почему я написал, что этот плагин вернул меня к «колхозу»?

Во-первых. Не довели разработчики до ума функционал игнорирования GET-параметров. U TM-метки и gclid работают без проблем — закешированная версия страницы загружается быстро. Но, к сожалению, разработчики не знают про Яндекс, и наличие метки yclid всё ломает, а страницы с такой меткой грузятся медленно. Раз уж мы начали с «колхоза», «колхозом» и закончим.

Открываем файл /wp-content/plugins/wp-fastest-cache/inc/cache.php и ищем «gclid»

после чего по тому же самому принципу добавляем недостающие GET-параметры, такие как yclid.

В-вторых, WP Fastest Cache работает исключительно с помощью mod_rewrite и выполнить свой PHP-код в момент конкретной загрузки страницы посетителем нельзя. Но и это решается с помощью доработки.

Открываем в корневой директории файл .htaccess и дописываем в начало следующий код:

<IfModule mod_rewrite.c>
RewriteEngine On
   RewriteBase /
   RewriteCond %{REQUEST_METHOD} !POST
   RewriteCond %{HTTP:Cookie} !PHPSESSID
   RewriteCond %{REQUEST_URI} !(\/){2}$
   RewriteCond %{REQUEST_URI} \/$
   RewriteCond %{QUERY_STRING} !.+
   RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/all/$1/index.html -f
   RewriteRule ^(.*) "lkdm-cache.php?$1" [L]
</IfModule>

Что тут написано? Мы проверяем, что запрос был совершен без POST-параметров (т.е. это не отправка какой-то формы, логику работы которой мы не хотим нарушать), а также у пользователя отсутствовала кука PHPSESSID, отвечающая за хранение информации о сессии пользователя. В этом случае мы проверяем существует ли кеш-файл для страницы, которую пользователь пытается открыть, если да, то мы отдаем пользователю файл lkdm-cache.php с GET-запросом пользователя (полный URL-адрес) и останавливаем исполнение условий, описанных в .htaccess. В иных случаях ничего не делаем, и обработкой запроса занимаются правила WP Fastest Cache, описанные ниже в файле .htaccess. При этом, если кеш-копии файла нет, то мы ничего не делаем, наш код будет выполнен уже из корневого index.php.

Теперь нам нужно исполнить свой код. Для этого создаем файл lkdm-cache.php в корневой директории WordPress, указываем в нём тот код, который нам необходимо исполнить, а после этого пишем следующее, чтобы отдать пользователю кеш-копию страницы:

echo file_get_contents("wp-content/cache/all".$_SERVER['REQUEST_URI']."index.html");

Стоит обратить внимание

1. После обновления плагина WP Fastest Cache всегда необходимо вносить изменения, связанные с GET-параметрами в файл /wp-content/plugins/wp-fastest-cache/inc/cache.php
2. После обновления настроек плагина WP Fastest Cache всегда необходимо переносить добавленный в .htaccess код в самое начало, т.к. ровно то же самое (перенос в начало) делает плагин при обновлении настроек. Соответственно, наш код из .htaccess исполнен не будет, если он находится ниже куска кода от WP Fastest Cache.

Заключение

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

Это переписанная и структурированная статья из моего телеграм-канала « digital на минималках», где я делюсь опытом в бизнесе, инструкциями, рассказываю, как удешевить свои вложения в digital, рассуждаю на небанальные темы, немного бомблю и делюсь мемчиками (осторожно, ненормативная лексика). Решил, что подобное объемное исследование будет интересно не только подписчикам моего канала.

Про кеширование сайтов

Кеширование в вебразработке — это очень важно. В WordPress особенно. Не то, чтобы Вордпресс такой плохой и тяжёлый, просто если можно ускорить загрузку страниц и одновременно снизить нагрузку на хостинг, а потратить на это пару минут, не воспользоваться этой возможностью было бы очень глупо. Итак, ближе к делу. Знакомьтесь с самым популярным плагином для кеширования страниц в вордпресс: WP Super Cache

До установки WP Super Cache

После установки WP Super Cache

То есть, вы сами видите грубый расчёт, без плагина страница генерируется 879 миллисекунд, а с плагином — 84 миллисекунды. Разница в 10 раз! Ещё остались сомнения в том, нужно ли его устанавливать?

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

Есть и противопоказания, но они больше условные: например, если ваш сайт почти не содержит постоянного содержимого, например предоставляет некоторый сервис, динамически изменяемые в php блоки и тому подобное. Правда, и тут можно найти выход, настроив тип кеширования Legacy или PHP и включив Enable dynamic caching в настройках. Так что, пути выхода есть 🙂 Однако, я лично думаю, что для таких сайтов лучше обходиться объектным кешированием, например, на основе W3 Total Cache, что тоже будет довольно эффективно.

Обзор плагина WP Super Cache

Принцип работы прост: плагин создаёт статичные html и php файлы – копии страниц WordPress и сохраняет их в кеш: /wp-content/cache/supercache/. Потом, при заходе пользователя на какую-либо страницу сайта, WordPress, вместо того, чтобы создать страницу с нуля, отдаёт браузеру заранее сохранённую копию html-страницы из кеша или собирает её максимально быстро из готовых php-файлов. Думаю, вполне очевидно, что такой вариант выходит экономнее по затратам ресурсов сервера и быстрее в плане скорости загрузки страницы.

Конечно, кеш отдаётся не всегда. При настройках по умолчанию, кеш не отдаётся для:

1. Залогиненных пользователей;
2. Пользователей, которые только что оставили комментарий на сайте;
3. Пользователей, которые просматривают защищённую паролем запись.

Но, так как доля этих пользователей незначительна, WP Super Cache является очень эффективным кеширующим инструментом.

Как установить плагин WP Super Cachе

Здесь и далее заменяйте http://example.com в примерах на ваш адрес сайта

Если у вас свой виртуальный или выделенный сервер, обязательно выставите верные права доступа на распакованные файлы, каталоги, и /wp-content/, чтобы кеш смог записываться

Установка WP Super Cache

Сигналом об удачной установке будет надпись:

Настройка WP Super Cache

После установки плагин нужно настроить. Это не займёт много времени. Самые основные моменты я опишу сначала, про тонкую настройку — чуть дальше.

Итак, вы переходите по ссылке http://example.com/options-general.php?page=wpsupercache.

Теперь с ходу вас может огорошить сообщением

В нём говорится о потенциальных проблемах с безопасностью на сервере, но также это сообщение может выскочить при первой установке или сбросе настроек плагина. Так как мы только что установили плагин, спокойно пропускаем сообщение — Dismiss

И тут же чуть ниже проверяем

В принципе, всё, плагин работает и уже кеширует страницы 🙂

Но делает он в этом варианте не совсем эффективно. Приступим к тонкой настройке

Тонкая настройка кеширования

Статус кэширования

Включить кеширование

Отмечаем. Если снять галочку, кеширование выключится. То есть, грубо говоря, этот пункт включает и выключает кеширование, то есть делает то же самое, что и включение/отключение кеширования на странице http://example.com/wp-admin/options-general.php?page=wpsupercache&tab=easy

Метод доставки кеша

Тут есть 2 варианта на выбор:

Простой

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

Эксперт

Использовать mod_rewrite для обслуживания кешированных файлов. Выбираем этот пункт как наиболее быстрый и удобный для сервера.

Разное

Не кэшировать страницы для известных пользователей. ( Рекомендовано). Включать однозначно. Если отключить, для известных пользователей (их 3 типа, указывались выше) будет генерироваться отдельный кеш, который ещё и всплыть наружу может, если теоретически. Ещё вы не будете видеть тулбар админа на страницах, что очень неудобно, когда нужно отредактировать страницу, сбросить кеш или ещё что-то в этом духе. Не кешировать страницы с параметрами GET (?x=y в конце URL). Сжимать файлы кэша чтобы ускорить работу. ( Рекомендовано). Отключить. В дополнение к обычному html будет создавать сжатую в gzip копию. Если экономите дисковое пространство — отключайте. Если у вас сервер на чистом Apache, либо NGINX без gzip, что встречается довольно редко — включите. Можете включить и посмотреть, будет мешать — отключите. Будет глючить на вашем хостинге — отключите. Кеш HTTP заголовков с содержимым страницы. Отключить. Включать, если есть проблемы с отдачей HTTP-заголовков. Заголовками HTTP должен заведовать сервер, а не плагин кеширования. При включении кеш страницы будет создаваться не в виде одной единой HTML-страницы, а в виде двух php-файлов, один из которых содержит заголовки, а второй — HTML-копию сгенерированной страницы.

Ошибка 304. Данная ошибка возникает тогда, когда страница не была изменена со времени прошлого запроса. Включать обязательно. Будет отдавать 304 заголовок повторно зашедшему пользователю, если страница не изменилась, что означает, что его браузер не будет выкачивать страницу с сервера, а воспользуется сохранённой локально копией, что очень полезно и эффективно.

Если включен режим Эксперт, то есть в работе используется mod_rewrite, то этот пункт будет неактивным, ибо включен по умолчанию.

Считать известных пользователей анонимными, чтобы и им отдавать супер-кешированные файлы. Если отметить, все пользователи, о которых Worpdress знает (авторизованные, прокомментировавшие), будут считаться анонимными и получать данные из кеша наравне со всеми. Я считаю, что лучше отключить, как правило, их не так уж их и много, а проблемы могут возникать. Но если аудитория сайта состоит, в основном, из авторизованных пользователей, и таковой функционал понадобится, то лучше воспользоваться W3 Total Cache или чем-то более подходящим. Авто перестройка кэша. Гости блога увидят устаревшие версии страниц кэша пока новые будут генерироваться Включать, полезный функционал. Гордо заявить миру что ваш сервер может принять любую нагрузку (поместит сообщение в подвал сайта). Отключить. Промо плагина и её автора. Если сайт делается ради фана — включите, сделаете добро человеку. Если проект коммерческий, и лишние ссылки недопустимы, отключать без вариантов.

Расширенные

Включить динамическое кеширование. Требует «PHP» или упрощенного режима кеширования. ( Смотрите ЧаВо
или код примера в wp-super-cache/plugins/dynamic-cache-test.php). Отключать. Эта опция будет полезна тем, кто изменяет код шаблонов, вставляя в них динамическое содержимое. Он работает, исполняя динамический код на странице перед тем, как выдать её браузеру пользователя. На пример такого шаблона можно посмотреть тут /wp-content/plugins/wp-super-cache/plugins/dynamic-cache-test.php. Поддержка мобильных устройств. ( Требуется внешний плагин или тема. Смотрите ЧаВо для дополнительной информации). Отключить. В наш век адаптивного дизайна вопрос становится неактуальным. Включите, если же ваша тема подразумевает отдельную выдачу для мобильных, либо вы пользуетесь одним из следующих плагинов:

• Jetpack’s Mobile Theme Module
• WPTouch
• WordPress Mobile Edition
• WordPress Mobile Pack

Убрать поддержку UTF-8 из файла .htaccess. Требуется только если вы видите странные символы или пунктуация некорректна. Требует обновления правил rewrite. Отключить. Необходимо включать, только если вы видите странные символы или некорректные знаки пунктуации, что случается крайне редко. Очистить все файлы кеша при публикации или обновлении страницы или записи.. Очищает весь кеш, когда запись или страница публикуется или обновляется. Я отключил, так как не вижу смысла сбрасывать весь кеш из-за одной страницы. Вы смотрите по вашей ситуации. Дополнительная сверка кэша (очень редко может нарушить работу кэширования). Отключить. Обновлять страницу при добавлении нового комментария к ней. На ваше усмотрение .Создать список страниц в кэше (выводится на этой странице)

Модуль Mod Rewrite

Если вы выбрали способ кеширования mod_rewrite, то плагин потребует обновить .htaccess

Прокручиваем страницу вниз и обновляем

Просроченные страницы, Очистка мусора

Теперь нужно настроить правила очистки устаревшего кеша

• Таймаут кэширования
  

  — выставляется время жизни кеша в секундах, сколько времени он остаётся актуальным. Хорошим тоном будет начать с 1 часа (3600 секунд). Вы подбирайте время, исходя из принципа, как часто обновляется контент на сайте: чем реже, тем большее число можно ставить. Например, в статейниках вполне можно оставлять 86400 секунд, что соответствует 24 часам.

  Также, вы можеет поставить 0, и тогда старый кеш не будет очищаться. Это может быть полезным, скажем, если Вы стремитесь к тому, чтобы дата создания страницы соответствовала дате создания её закешированной копии. Однако, помните, что если Вы вносите изменения в дизайн сайта, либо устанавливаете новый плагин, который вносит в изменения в дизайн страницы, изменения не будут приняты, пока кеш не будет очищен. Я лично рекомендую не обнулять очистку кеша, а ставить время жизни кеша побольше.

• Планировщик
  — как часто проверять устаревание кеша. Можно выбрать Таймер
  — тогда кеш будет проверяться постоянно с интервалом в указанное число секунд, а можно выбрать Часы
  — тут указывается чёткое время (час и минута) по UTC, в которое с регулярностью Интервал
  будет проходить проверка актуальности кеша.
• Электронные адреса для уведомлений
  — отсылать ли уведомления на email администратора сайта об очистке мусора.

Поисковые и другие боты

Чтобы запретить плагину кэшировать запросы от поисковых ботов и других сетевых роботов, введите их названия в поле ниже (по одному в строке). Если копия страницы уже существует в кэше Super Cache, то она все равно будет отправлена боту.

Стираем и оставляем поле пустым, сохраняем.

Остальные настройки

Несущественны, поэтому оставляете как есть.

Общий кеш

Этот раздел важен в свете того, что Google и другие поисковые системы теперь учитывают скорость загрузки страниц как один из факторов ранжирования сайта в поиске.

Обычно, WP Super Cache создаёт кеш только той страницы, которую кто-то посетил. И это, по сути, правильно. Но что, если этим кто-то является бот поисковика? Никакого положительного эффекта от кеширующего плагина он не увидит. И раздел настроек Общий кеш
позволяет избежать этого недоразумения, предсоздавая закешированные копии всех страниц сайта ещё до их посещения кем-либо.

Для любителей консоли SSH
есть возможность не использовать Общий кеш, а для разогрева кеша использовать wget:

  wget -r -l 3 -nd --wait=5 --delete-after http://example.com

Такую конструкцию можно отправить в cron:

1. В консоль пишем

     crontab -e

2. Конструкция ниже обходит сайт каждый час, поддерживая страничный кеш свежим:

     0 * * * * wget -r -l 3 -nd --wait=5 --delete-after http://example.com

Раздел хорошо описан на русском языке, поэтому распишу только основные настройки:

• Обновлять кеш каждые 120 минут
  — кеш будет считаться актуальным 2 часа. Вы ставите своё время. Чем реже обновляется сайт, тем большее время можно поставить.
• Предварительный режим (очистка мусора работает не полностью, опция рекомендована к включению.)
  — включить, в объяснении, думаю, не нуждается.
• Предзагрузка тегов, категорий и других таксономий.
  — включить. Будут предзагружены категории, теги и другие таксономии.

Теперь сохраняете данные или создаёте кеш прямо сейчас.

Общий объём кеша будет зависеть от количества записей, страниц, рубрик (категорий), меток (тегов). Дисковое пространство — это, как правило, самый дешёвый и легко масштабируемый ресурс на хостинге и сервере, и если у вас не сильно посещаемый проект (до 10-20 тысяч уникальных пользователей в сутки), а страничный кеш выходит большим, то вы вполне можете брать обычный дешёвый жёсткий диск hdd, на честном хостинге разницу с ssd вряд ли заметите, зато сэкономите бюджет. Если больше, hdd тоже будет хорошо себя показывать, но тут я бы порекомендовал посоветоваться с системными администраторами на предмет оптимизации сервера, либо написать мне в форму обратной связи.

На этом необходимый минимум по настройке WP Super Cache завершён. Далее будет идти информация для продвинутых вебмастеров и системных администраторов, а также некоторая информация, касаемо часто возникающих вопросов.

WP Super Cache и WooCommerce

Если у вас магазин на основе WooCommerce, и вы хотите использовать WP Super Cache, то вам нужно исключить следующие страницы из процесса кеширования:

• Корзина (Cart)
• Мой аккаунт (My Account)
• Оформление заказа (Checkout)

Такой вариант подойдёт, если у вас мало записей в Страницах. Если же их много, то лучше не отмечать Страницы (is_page), а добавить части адресов служебных страниц в раздел чуть ниже, как на примере

Добавляем служебные страницы WooCommerce в список исключений

Как проверить работу WP Super Cache самостоятельно

Вы можете самостоятельно проверить, как работает плагин, довольно просто.

Для начала, открываете браузер в режиме инкогнито или в приватном режиме. Для Firefox это делается с помощью Ctrl+ Shift
+ P, для Google Chrome или Яндекс Браузера— Ctrl+ Shift+ N.

Теперь откройте исходный код страницы ( Ctrl+ U) и посмотрите в самый конец, там вы увидите примерно следующее

  <!-- Dynamic page generated in 0.337 seconds.  -->
<!-- Cached page generated by WP-Super-Cache on 2016-11-21 01:47:08 -->

<!-- super cache -->

Это отметка, сколько времени собиралась страница и в какие дату и время это произошло.

Если вы заглянете в исходный код страницы под админом, то увидите что-то навроде

  <!-- Dynamic page generated in 0.389 seconds.  -->
<!-- Page not cached by WP Super Cache.  Check your settings page.  Not caching requests by known users.  ( See Advanced Settings page) -->

Тут есть только отметка, сколько времени генерировалась страница, и замечание, что для авторизованных пользователей страница отдаётся не из кеша, а создаётся на лету.

Если этих меток нет, значит вы сделали что-то не так, и плагин не работает. Вернитесь к началу настройки и пройдитесь по основным пунктам, возможно, вы что-то упустили.

Далее, если всё в порядке, и вам интересно, сколько времени занимает отклик от сервера до вашего браузера, вы можете воспользоваться консолью разработчика.

Для этого, жмёте F12, откроется консоль, там вы переходите в раздел Network— Docили Сеть — HTML и перезагружаете страницу ( Ctrl+ F5). По завершению, ищете верхнюю строчку и время отклика, оно должно занимать в норме 100-300 миллисекунд или 0.1-0.3 секунды. Может и больше, если ваш хостинг в США, а вы в России, континентальную удалённость нужно учитывать. Но вообще, чем меньше это значение, тем лучше.

Ради интереса можете временно выключить WP Super Cache и сравнить значения до и после установки плагина.

После установки WP Super Cache

И ещё маленький совет — кеш браузера иногда будет путать вас, поэтому полностью сбрасывайте его с помощью Ctrl
+ F5, а лучше тестируйте работу плагина и сайта в режиме инкогнито браузера.

Настройка сервера для WP Super Cache

Итак, плагин у нас установлен и настроен правильно. Как проверить правильность работы рассказано выше, а теперь перейдём к настройке сервера. Это будет актуальным, если у вас собственный VDS/VPS или выделенный сервер.

Далее, в примерах будет происходить настройка под домен example.com
и его поддоменов. Вы должны самостоятельно заменить их на своё имя домена

htaccess (Apache) и WP Super Cache

Если вы дошли до этого пункта и выбрали в настройках плагина режим mod_rewrite, то по сути ничего делать и не нужно. Но, в целях оптимизации работы ( .htaccessзагружается каждый раз при загрузке сайта, apache2.conf только 1 раз во время рестарта сервера), или если обработка правил .htaccessна вашем сервере отключена, вы можете скопировать данные из .htaccess и перенести их в конфигурационный файл, где объявляются настройки вашего сайта (например, в Debian он может располагаться в /etc/apache2/vhosts/sheensay.ru.conf).

Далее, пример конфигурационного файла .htaccess

  # BEGIN WPSuperCache
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
#If you serve pages from behind a proxy you may want to change 'RewriteCond %{HTTPS} on' to something more sensible
AddDefaultCharset UTF-8
RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} !*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{HTTPS} on
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html.gz -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html.gz" [L]

RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} !*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{HTTPS} !on
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html.gz -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html.gz" [L]

RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} !*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTPS} on
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html" [L]

RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} !*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTPS} !on
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html" [L]
</IfModule>

# END WPSuperCache

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .  /index.php [L]
</IfModule>

# END WordPress

Пример конфигурационного файла Apache. Вы можете вставить в него код из .htaccess

 #user 'example' файл конфигурации виртуального хоста 'example.com'

 Имя сервера example.com
 Добавить по умолчаниюCharset UTF-8
 Пример использования AssignUserID
 DirectoryIndex index.html index.php
 DocumentRoot /var/www/example/data/www/example.com
 Администратор сервера  [электронная почта защищена] 

 ServerAlias ​​www.example.com
 
 Приложение SetHandler/x-httpd-php
 
 Приложение SetHandler/x-httpd-php-source
 
 php_admin_value sendmail_path "/usr/sbin/sendmail -t -i -f  [электронная почта защищена] 
"
 php_admin_value upload_tmp_dir "/var/www/example/data/mod-tmp"

 #php_admin_value session.save_path "/var/www/example/data/mod-tmp"
 php_admin_value session.save_handler "memcache"
 php_admin_value session.save_path "tcp://127.0.0.1:11211"


 php_admin_value open_basedir "/var/www/example/data:"
 CustomLog /var/www/httpd-logs/example.com.access.log вместе взятый
 Журнал ошибок /var/www/httpd-logs/example.com.error.log


 Двигатель php_admin_flag включен
 Опции -ExecCGI
 # После этой строки появляются данные из .htaccess

NGINX и WP Super Cache

Предполагается, что NGINX настроение по аналогичному примеру

Итак, у вас свой виртуальный или выделенный сервер, и вам хочется, чтобы WP Super Cache выжимал максимально. Но из коробки этот плагин предлагает настройки только под php и htaccess. И здесь я опишу, как можно настроить конфигурационный файл NGINX для оптимальной работы с WP Super Cache. Это может пригодиться, скажем, если у вас сервер собран в видео LEMP
(Linux, NGINX (EngineX), Mysql, PHP) и вместо Apache в бекенде php-fpm.

Хочу обратить внимание, что в данные конфигурации кеш NGINX включать не нужно, так как NGINX будет брать статические страницы из кеша WP Super Cache напрямую, минуя интерпретатор PHP. И, на мой взгляд, настроен именно этот вариант, так как управлять кешом из админпанели WordPress удобнее, чем из консоли кеша NGINX.

Если для сайта включен кеш NGINX, и отключить его нельзя, то подключить WP Super Cache лучше не использовать, так как увеличение производительности Вы не заметите, а двойное кеширование будет только мешать.

WooCommerce и другие подобные плагины, которые используют переменные GET в URL, требуют, чтобы при обработке PHP передавались параметры $args:

 try_files $wpsupercache $uri $uri/ /index.php?$args

Однако WP Super Cache может работать неправильно при использовании /index.php?$args
.

В таком случае можно посоветовать выбрать другой кеширующий плагин, например, W3 Total Cache.

В структуре будет 3 варианта конфигурации, в зависимости от режима работы WordPress: обычный сайт, WordPress Multisite с сайтами в подкаталогах и WordPress Multisite с сайтами на поддоменах. По умолчанию включен первый режим. Если у вас Miultisite, просто раскомментируйте нужные строчки.

Ниже пример конфигурационного файла NGINX+ php-fpm с найденным бекендом на Apache с комментариями:

 ### пользователь 'example' файл конфигурации виртуального хоста 'example.com'
### http://sheensay.ru/?p=1915
сервер {

 ### Если многосайтовые поддомены, для сопоставления доменов замените надпись ниже: имя_сервера example.com *.example.com;
 имя_сервера example.com www.example.com;

 ### Если многосайтовые поддомены, раскомментируйте надпись ниже для сопоставления доменов.
 #server_name_in_redirect выключен;

 ### Если многосайтовые поддомены, для сопоставления доменов замените надпись ниже: Listen 80 default_server;
 слушайте 1.2.3.4:80; # Укажите вместо 1.2.3.4 IP своего сервера

 кодировка UTF-8;
 Disable_symlinks if_not_owner from=$root_path;
 индекс index.html index.php;
 корень $root_path;
 установите $root_path /var/www/example/data/www/example.com;
 access_log /var/log/example.com.access.log ;
 error_log /var/log/example.com.error.log предупреждение;
 #error_log /var/log/example.com.debug.error.log debug;

 включить /etc/nginx/vhosts-includes/*.conf;

 ### Если gzip не включен глобально, включим его тут
 # включение gzip;
 # gzip_disable "msie6";
 # gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;

 ### Разрешаем доступ для Let's Encrypt
 местоположение ~ /\.well-known {
 позволять все;
 }

 ### Запрещаем доступ к файлам и каталогам с точкой в ​​начале названия, например, .htaccess, .git
 местоположение ~ /\. {
 deny all; 
 }

 ### Запрещаем доступ к файлам с расширением .php в каталогах загрузок, например, /wp-content/uploads
 location ~* /(?:uploads|languages|files)/.*\.php$ {
 deny all;
 }


 ### Если Multisite в режиме подкаталогов, например http://example.com/wpsubsite/, просто раскоментируйте блок ниже ###
 
 #if (!-e $request_filename) {
 # rewrite /wp-admin$ $scheme://$host$uri/ permanent; 
 # rewrite ^(/[^/]+)?(/wp-.*) $2 last;
 # rewrite ^(/[^/]+)?(/.*\.php) $2 last;
 #}



 ### Устанавливаем новую переменную $cache_uri, которой присваиваем запрос из предустановленной переменной $request_uri
 set $cache_uri $request_uri;

 ### POST запросы не кешируются 
 if ($request_method = POST) {
 set $cache_uri 'null cache';
 } 

 ### Запросы с параметрами в URL не кешируются 
 if ($query_string != "") {
 set $cache_uri 'null cache';
 } 

 ### Не кешировать запросы URL, содержащие следующие части (как правило, админка и служебные, sitemap yoast)
 if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?xml|[a-z0-9_-]+-sitemap([0-9]+)?xml)") {
 set $cache_uri 'null cache';
 } 

 ### Не использовать кеш для авторизованных пользователей и последних комментаторов
 if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in") {
 set $cache_uri 'null cache';
 }

 ### фавикон не логировать
 location = /favicon.ico { log_not_found off; access_log off; }
 ### robots.txt может генерироваться движком WordPress
 location = /robots.txt { try_files $uri /index.php; }


 ### Определим расположение кеша
 # ${http_host}${cache_uri} может не содержать слеша, потому что ${cache_uri} уже может начинаться со слеша.  У вас может быть иначе.  Проверьте с помощью add_header
 set $wpsupercache /wp-content/cache/supercache/${http_host}/${cache_uri}/index.html;

 ### Ещё будем пробовать искать версию для https
 set $wpsupercache_ssl /wp-content/cache/supercache/${http_host}/${cache_uri}/index-https.html;

 ### Если у вас сайт на SSL/TLS, то есть, работает по HTTPS, то вместо index.html у вас будут генерироваться index-https.html
 if ( $scheme = 'https' ) {
 set $wpsupercache /wp-content/cache/supercache/${http_host}/${cache_uri}/index-https.html;
 }
 ### Проверочный заголовок, если раскомментируете, увидите, что располагается в переменной $wpsupercache
 #add_header X-wpsc "$wpsupercache" always;


 ### Можно отлавливать переменные в заголовках.  Подробнее http://sheensay.ru/nginx
 # add_header X-uri "$uri" always;
 # add_header X-cache-uri "$cache_uri" always;
 # add_header X-$http_host "$http_host" always;

 ### Переходим к работе с бекендом ###
 ### Ниже будут 2 варианта настройки, php5-fpm и Apache.   ####
 ### По умолчанию, всё настроено под первый вариант.  ###
 ### Чтобы включить Apache, закомментируйте всё, что идёт ниже до блока Apache ###

 ### 1.  P HP-FPM ###

 # Статичные файлы не логируем, выставляем http заголовок Expires на год
 location ~* ^.+\.(jpe?g|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf|ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
 expires 365d; log_not_found off; access_log off;
 }

 # Основной запрос, в котором мы пытаемся сначала получить закешированную версию страницы
 # Если кеша нет, тогда отправляемся к WordPress, чтобы он его нам создал
 location / {
 try_files $wpsupercache $wpsupercache_ssl $uri $uri/ /index.php?$args ;
 }


 # Наш бекенд - php-fpm
 location ~ \.php$ {

 try_files $uri =404; 
 include fastcgi_params;
 fastcgi_split_path_info ^(.+\.php)(/.+)$;
 fastcgi_index index.php;
 fastcgi_param SERVER_NAME $http_host;
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

 # Тут, в зависимости от того, как установлен FastCGI, выбирайте или TCP, или сокет

 # TCP
 #fastcgi_pass 127.0.0.1:9000;
 # Сокет
 fastcgi_pass unix:/var/www/php5-fpm/example.com.sock; # Тут укажите путь до сокета php-fpm конкретного пользователя или сайта

 }



 ### 2.  Apache. Если у вас в бекенде Apache, расскоментируйте всё, что ниже закомментировано одинарной решёткой, и закомментируйте всё, что выше до блока 1. PHP-FPM ###

 ### Статичные файлы не логируем, выставляем http заголовок Expires на год
 #location ~* ^.+\.(jpe?g|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf|ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
 # expires 365d; log_not_found off; access_log off;
 # try_files $uri $uri/ @apache ;
 #}

 #location / {
 # try_files $wpsupercache $uri @apache ;
 #}

 ### php скрипты отправляем сразу в бекенд
 #location ~ [^/]\.ph(p\d*|tml)$ {
 # try_files /does_not_exists @apache;
 #}

 ### Отправляем запросы к бекенду (Apache или php-fpm)
 ### Если у вас в бекенде Apache, раскомментируйте блок ниже
 #location @apache {
 ### Apache ###
 #proxy_pass http://127.0.0.1:8080;
 #proxy_redirect http://127.0.0.1:8080 /;
 #proxy_set_header Host $host;
 #proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 #proxy_set_header X-Forwarded-Proto $scheme;
 #}
}

Как проверить правильность URI файлов кеша WP Super Cache

Допустим, Вы хотите проверить страницу http://example.com/mypage, правильно ли видит NGINX её расположение в кеше. Для этого надо:

1. Раскомментировать строку с add_header, код будет примерно следующего содержания:

     set $wpsc /wp-content/cache/supercache/$http_host$cache_uri/index.html;
   if ( $scheme = 'https' ){
    set $wpsc /wp-content/cache/supercache/$http_host$cache_uri/index-https.html;
   }
   add_header X-$wpsc_uri $wpsc always;

2. Перезагрузить nginx:

     nginx -s reload

3. Открыть Хром в режиме инкогнито ( Ctrl+ Shift+ N) и открыть любую страницу сайта
4. Нажать F12, откроется консоль. Перезагрузить страницу F5
5. В консоли выбрать Network— Doc, затем кликнуть самый верхний пункт в списке (это наша страница mypage), раскроются подробности — в пункте Responce Headers видим наш URI.

   

   Как проверить заголовки в консоли F12 Googe Chrome

   В переменной X-$wpsc_uri
   должно находиться следующее: /wp-content/cache/supercache/example.com/mypage/index.html