Медленный WordPress (часть 2)

https://t.me/low_digital

Это продолжение статьи "Медленный WordPress", первая часть доступна по ссылке: https://telegra.ph/Medlennyj-WordPress-02-17

Swift performance

Очередной плагин, распространяющийся исключительно по подписке (но вы же не глупенькие и знаете, что означает слово "nulled").

По началу, я отнесся к нему крайне скептически - очередной "миллион-в-одном-плагин" со свистелками и перделками, но он смог меня удивить.

Человеческая настройка исключения GET-параметров из URL-адресов, которая работает без колхоза, возможность работы без mod_rewrite (что позволяет исполнять кастомную PHP-логику), умное автокеширование. Инструменты оптимизации контента (html/js/css minify, lazy loading, генерация WebP-изображений). И всё это чудо работает без танцев с бубном.

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

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

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

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

Настройка Swift perfomance

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

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

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

Раздел Media -> Images отключаем функции "Generate WebP" и "Lazyload Images", так как, повторюсь, мы сейчас работаем именно с кешированием, а не с оптимизацией контента на сайте.
Раздел Optimization -> General отключаем "Fix Invalid HTML" (всё по той же причине, что и выше)
Раздел Caching -> General оставляем значение параметра "Caching Mode" = "Disk Cache with PHP", чтобы иметь возможность выполнять свои PHP-скрипты в корневом index.php или же выбираем "Disk Cache with Rewrites", чтобы слегка увеличить скорость загрузки сайта.
Раздел Caching -> General устанавливаем значение параметра "Cache Expiry Mode" = "Action based mode" (почему - писал выше).
Раздел Caching -> Tweaks в разделе "Ignore GET Params" указываем перечень наших GET-параметров для исключения из обработки URL при кешировании и отдачи кеш-файлов.

Раздел Caching -> Warmup включаем "Prebuild Cache Automatically" как раз для автокеширования, скорость выбираем согласно рекомендациям (Moderate для shared-хостинга, Multi thread - если сайт крутится на своей VDS), а также включаем опцию "Discover New Pages", чтобы плагин искал и кешировал новые страницы также автоматически.

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

WP Fastest Cache

WP Fastest Cache - это еще один крайне популярный плагин для кеширования WordPress. Так как у меня еще нет полной уверенности в механизме работы "Action based mode" у Swift perfomance, а также у Свифта есть пара (пусть и крайне не значительных) косячков - я решил опробовать еще один плагин.

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

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

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

Готово

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

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

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

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

Во-первых, не довели разработчики до ума функционал игнорирования GET-параметров. Да, UTM-метрик и gclid работают без проблем - закешированная версия страницы загружается быстро. Но, к сожалению, разработчики видать не знают Яндекс :( и наличие метки yclid всё ломает - страницы с такой меткой грузятся медленно. Раз уж мы начали с колхоза, дак колхозом и закончим!

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

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

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

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

# BEGIN LKDM cache injection
<IfModule mod_rewrite.c>
RewriteEngine On
   RewriteBase /
   RewriteCond %{REQUEST_METHOD} !POST
   RewriteCond %{HTTP:Cookie} !PHPSESSID
RewriteCond %{HTTP_USER_AGENT} !^WP\sFastest\sCache\sPreload\sBot
   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>
# END LKDM cache injection

Что тут написано? Мы проверяем, что запрос был совершен без POST-параметров (т.е. это не отправка какой-то формы, логику работы который мы не хотим нарушать), у пользователя отсутствует кука PHPSESSID отвечающая за хранение информации о сессии пользователя, а также User-agent не равен "WP Fastest Cache Preload Bot" (чтобы не нарушать работу автокеширования). В этом случае мы проверяем существует ли кеш-файл для страницы, которую пользователь пытается открыть, если да - то мы отдаем пользователю файл 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");

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

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

Заключение

На сегодняшний день, мой выбор остается за WP Fastest Cache. Не смотря на необходимость "колхозинга" он работает без каких-либо нареканий. По итогу, все, описанные в начале статьи, требования были выполнены.

Если в ближайшее время мое мнение не поменяется - я подготовлю плагин, который самостоятельно будет вносить изменения в ".htaccess" и "/wp-content/plugins/wp-fastest-cache/inc/cache.php" при необходимости, тем самым исключив ручное вмешательство в эти файлы и человеческий фактор.

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

PS

После подготовки этой статьи я продолжил мониторить стабильность работы WP Fastest Cache и Swift perfomance на нескольких сайтах и могу поделиться еще одной небольшой заметкой, которая уже точно расставит все точки над ї: https://telegra.ph/Medlennyj-WordPress-chast-3-02-18

Также, я подготовил страничку со сравнением плагинов, которые лучше всего показали себя. Там я попытался указать кратко плюсы и минусы каждого из плагинов: https://telegra.ph/Medlennyj-WordPress-itogi-02-19