Медленный WordPress

https://t.me/low_digital

Все знают, что хорошие* сайты на WordPress тормозят. Под хорошими я имею ввиду сайты, собранные на премиальных шаблонах, с качественным современным дизайном и широким функционалом. Понятное дело, что в личном блоге, запиленном на Twenty Twenty One лагать нечему.

Дак вот, используя бестселлеры с Themeforest или тот же Elementor ты обречен на 5-15 секунд TTFB (время ответа сайта) при загрузке КАЖДОЙ страницы. Естественно, что такая скорость попросту недопустима - понижение в поисковой выдаче, "отказы" посетителей, сливы бюджетов на рекламу и так далее. С этим нужно что-то делать, и здесь я расскажу о своих наблюдениях.

Еще раз повторю, что далее речь пойдет о корпоративных многостраничных сайтах, работающих на WordPress, собранных из премиальных шаблонов Envato либо на базе Elementor, использующих довольно большое количество плагинов.

Решение проблемы вроде как лежит на поверхности - используй кеширование. Зайди в Google, напиши "WordPress cache", найди статью где больше всего картинок, скачай упомянутый в статье плагин и выстави настройки, согласно скриншотам. При любом раскладе твой сайт сразу начнет работать в разы быстрей.

Но дьявол, как обычно, кроется в деталях. В целом, я никогда шибко с оптимизацией WordPress не парился, потому что в моей практике все сайты, которые действительно требуют космической скорости работы делали не на WordPress, а на Yii2 или Laravel. Для WP я использовал околодефолтные настройки плагина WP Super Cache подсмотренные у индусов на Stackoverflow.

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

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

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

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

Требования к функционалу

Автокеширование. Кеширование - это процесс создания уже отрендеренной копии страницы (HTML-файла), который позволяет пользователям быстро загружать страницы сайта, не задействуя при этом сложную PHP-логику и взаимодействие с БД. Обычно, кеш создается при посещении пользователем той или иной страницы, кеш-копия страницы при этом хранится определенное время (в зависимости от настроек) и отдается всем последующим пользователям, которые пытаются зайти на эту страницу ровно до истечения срока жизни кеш-файла, после этого опять кто-то должен зайти на эту страницу, чтобы опять создать файл кеша этой страницы.

В этом случае часть пользователей, ровно как и поисковых роботов будут видеть на сколько ужасно долго загружаются некоторые страницы твоего сайта. Дабы этого избежать, некоторые плагины предлагают механизм автоматического кеширования - в этом случае плагин самостоятельно производит обход сайта и сам создает закешированные копии страниц. Важно, чтобы этот механизм у плагина был и работал без сбоев.
Игнорирование части запросов URL-адреса. Большинство рекламщиков используют для отслеживания эффективности своих рекламных кампаний UTM-метки (ну или что-то на них похожее). В этом случае они добавляют в адрес страницы ряд запросов, которые никак не влияют на логику работы сайта. Например, у нас есть страница товара, который мы рекламируем: https://www.apple.com/huge-dildo-xr-pro/, но пользователь перешедший на неё из рекламы увидит адрес следующего формата: https://www.apple.com/huge-dildo-xr-pro/?utm_source=yandex&utm_medium=banner&utm_campaign=promo&utm_content=landing&utm_term=i-want-to-buy-anal-penetrator&yclid=93473892748392743473829.

Сайт, при этом, о существовании этой страницы даже не догадывается. Естественно, под неё кеш не существует и будет создан в момент перехода пользователя по этой длинной ссылке. Но даже если рекламщик не будет добавлять UTM-метки, Яндекс Директ, Google Ads, как и большинство иных рекламных площадок будут добавлять свои метки для отслеживания (такие как yclid, gclid и т.д.). Значения таких меток будут всегда разными, соответственно, сайт будет воспринимать их все как абсолютно разные страницы. В итоге мы получаем ситуацию, что каждый пользователь, привлеченный с помощью рекламы видит на сколько медленно работает твой сайт, а хранилище кеша пухнет от кучи мусорных файлов, которые никогда больше задействованы не будут.

Поэтому, плагин кеширования должен учитывать тот факт, что существуют некоторые GET-параметры, которые необходимо исключать из URL-адреса страницы, при попытке найти подходящий кеш-файл или же создать новый.
Возможность использования PHP-функций. Не смотря на то, что звучит это крайне странно (ведь ранее мы говорили о том, что кеширование должно предотвращать исполнение PHP-скриптов или работу с БД) - это крайне нужная вещь.

Например, мы используем кастомный трекинг для реализации аналитики полученных заявок. Использование разнообразных систем аналитики (таких как Яндекс Метирка или Google Analytics) не позволяет производить оценку эффективности рекламных кампаний в полном объеме. Та же Метрика попросту не видит части заявок, данные отображает в максимально обезличенном виде, да еще и с задержкой, каждый второй научился устанавливать AdBlock, который вырезает Метрику и прочие скрипты с сайтов. Более того, как оказалось, у довольно большой части пользователей попросту не работает JavaScript, который необходим для корректной работы Метрики. Как итог, мы имеем статистику с погрешностью более 30%.

В прошлом году я решил навсегда поставить точку в этом вопросе и реализовал сервис, который позволит исключить любые упущения систем аналитики, т.к. он работает абсолютно невидимо для пользователя. Настоятельно рекомендую ознакомиться: https://analytics.linkodium.com/

Позже появился даже плагин для WordPress, который позволяет реализовать сквозную аналитику быстрее, чем установить на сайт счетчик Метрики. И вот именно здесь появляются проблемы, когда большинство кеширующий плагинов не позволяют запустить при первом визите пользователя нужный PHP-код, который сохранит полную информацию об источнике и характеристиках визита.

Реализация

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

WP Super Cache

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

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

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

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

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

Далее переходим на вкладку "Общий кеш" - именно она нам позволит реализовать автокеширование.

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

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

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

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

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

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

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

Проблемы WP Super Cache

Единственная (но крайне критичная) проблема 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.apple.com/huge-dildo-xr-pro/ была ранее уже закеширована, при попытке зайти по ссылке https://www.apple.com/huge-dildo-xr-pro/?utm_source=yandex&utm_medium=banner&utm_campaign=promo&utm_content=landing&utm_term=i-want-to-buy-anal-penetrator&yclid=93473892748392743473829 рядом создается еще один файл кеша (естественно страница грузится медленно). В разделе "Статистика кеша" на странице плагина мы увидим 2 идентичных элемента https://www.apple.com/huge-dildo-xr-pro/ в разделе "WP Super Cached Files" и точно такую же https://www.apple.com/huge-dildo-xr-pro/ в разделе "WP Fresh Cached Files". Тем не менее, до момента истечения срока жизни кеша, при попытке обратиться с любым набором из описанных GET-параметров который мы "приколхохили" с любым их значением (например, https://www.apple.com/huge-dildo-xr-pro/?gclid=666 - обрати внимание, что в прошлой ссылке gclid даже не присутствовал) , пользователю уже будет отдаваться кешированная версия (т.е. страница загрузится быстро).

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

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

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

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

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

Да это тупо, но это, мать его, работает! Если кто-то найдет более элегантный способ подружить WP Super Cache с GET-параметрами - приглашаю в комментарии тизера этой статьи в наш Telegram-канал: https://t.me/low_digital

WP Rocket

В попытках найти более элегантный способ для реализации кеширования, я решил попробовать другой плагин - 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 проблемы:

По неведомой для меня причине, периодически страницы очень долго грузятся. При этом, на странице присутствует комментарий, что она была довольно давно закеширована (поэтому по идее отдаваться должна быстро, но этого не происходит). Чаще всего такое поведение замечается именно на втором клике визита (вне зависимости от того, какую страницу ты пытаешься открыть). Кеш таких страниц, в момент долгой загрузки при этом не обновляется - т.е. после перезагрузки такой страницы (или когда пытаемся открыть её с другого устройства) - комментарий содержащий информацию о времени кеширования остается неизменным. Решается эта проблема переключением обработчика на mod_rewrite (в настройках Page Cahe эта опция называется "Disk: Enhanced"). Но в моём случае это не применимо, т.к. нам требуется выполнение PHP-кода при посещении страниц.
Вторая очень болезненная проблема - это процесс обновления кеша. Да, W3 Total Cache имеет функцию пребилда - т.е. он автоматически в заданный с заданным интервалом обходит сайт согласно sitemap.xml, с целью создать кеш-файлы. При этом, обход он осуществляет непрерывно, но пересоздает кеш-файлы лишь в тот момент времени, когда кеш уже устарел. В итоге получается следующая ситуация - в момент, когда время жизни кеша истекло даже не небольших сайтах, W3 Total Cache не успевает быстро обойти весь сайт, чтобы обновить кеш-файлы. При этом, они уже истекли, и когда пользователь пытается зайти на ту или иную страницу - с крайне высокой долей вероятности она окажется с просроченным кешем, поэтому кеш для этой страницы будет создаваться заново, а такие страницы будут грузиться медленно. Ротация обхода тоже вряд ли совпадет с датами истечения кеша страниц, потому что обход запускается не в какой-то определенный момент времени, а работает непрерывно. И если страница была закеширована в 21:00, то далеко не факт, что после истечения срока жизни кеша (например, 1 час) эта старница попадет в обход именно в 22:00.

В итоге имеем ситуацию:
- Сайт 100 страниц
- Время жизни кеша: 1 час
- TTFB (по сути, время генерации страницы) без кеширования: 5-6 сек.
- Обход: 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 секунд, т.к. WP Cron не умеет работать быстрее), указываем кол-во страниц в интервале - выбираем в зависимости от скорости загрузки страниц без применения кеширования (если без кеширующего плагина в среднем TTFB страниц ~5 сек., то стоит указать кол-во не более 12, чтобы не нагружать лишний раз сервер). Также, необходимо указать путь к Sitemap.XML на основе которого будет осуществляться обход сайта. Рекомендую использовать для построения Sitemap.XML плагин "Yoast SEO", т.к. для интеграции с Yoast SEO у W3 Totack Cache есть отдельно расширение, а это значит, что сайтпамы, сгенерированные Yoast SEO явно будут поглощаться плагином W3 Total Cache без каких-либо ошибок.

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

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

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

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

LiteSpeed Cache

Еще один крайне популярный плагин для кеширования WordPres - это LiteSpeed Cache. Как оказалось - это тупо рекламный инструмент, вынуждающий пользователей использовать веб-сервер LiteSpeed вместо Apache или nginx, обещая при этом космическую скорость работы сайта (не смотря на то, что половина шаблонов и плагинов попросту не будут работать на LiteSpeed, т.к. не оптимизированы под него). Что вообще за зверь этот LiteSpeed лучше всего продемонстрируют комментарии на Хабре: https://qna.habr.com/q/5543

Фуфло, едем дальше.

Продолжение статьи: https://telegra.ph/Medlennyj-WordPress-chast-2-02-17