Если честно, такой задачи передо мной никогда не стояло, но здесь я могу предложить такой вариант - если URL страниц содержит, например, год публикации (example.com/blog/2007/artcle-title) с помощью большинства плагинов можно исключить такие страницы с помощью правил кеширвания. Например, в WP Super Cache это будет выглядеть так: http://ipic.su/img/img7/fs/000.1629699642.png
Большинство плагинов кеширования используют диск, в память умеют кешировать лишь единицы, поэтому платная подписка на расширенный функционал здесь более чем оправдана. Тем не менее, каждый должен четко выбирать для себя приоритеты. Кеширование в память дает сильный прирост производительности в сравнении с кешированием на диск. Но если сравнить разницу в скорости кеширования на диск и кеширования в память, с кешированием на диск и отсутствием кеширования как такового - этот прирост в скорости загрузки будет не столь заметным.
Я лично остановился именно на варианте с кешированием на диск, т.к. есть еще множество моментов которые стоит улучшить - это и географическое расположение сервера/хостинга, оптимизация статичного контента на сайте (изображения, скрипты, таблицы стилей), Lazy Loading, Prefetch.
Подскажите, а как вам удалось запустить WP Rocket без добавления правил в .htaccess? Подобной настройки в плагине я не заметил, Google тоже не помог.
Если удалить правила из .htaccess, действительно, WP Rocket начинает работать в PHP-based режиме и произвольный PHP-код из корневого index.php или advanced-cache.php будет выполнен. Но при следующем же обновлении настроек (и я подозреваю, обновлении плагина) правила опять будут добавлены в .htaccess
Autoptimize - это немного не про то кеширование :)
Autoptimize позволяет сжимать и объединять HTML/CSS/JS файлы, удалять комментарии, реализовать Lazy Loading и отложенную загрузку некоторых объектов. Autoptimize, безусловно, позволяет увеличить общую скорость загрузки сайта, но вот на TTFB он не повлияет.
Многие плагины кеширования (такие как W3 Total Cache, платная версия WP Fastest Cache, Swift perfomance, WP Rocket и другие) тоже предлагают подобный функционал, но статья оказалось и так довольно обширной и слишком долгой для чтения, поэтому обзор плагинов для оптимизации я решил оставить на потом.
Autoptimize крайне неплохо может работать в паре с плагином кеширования, который не умеет в оптимизацию (WP Super Cache или бесплатная версия WP Fastest Cache). Попробуйте дополнительно установить один из представленных плагинов помимо Autoptimize - скорость загрузки сайта значительно увеличится!
У WP Rocket есть безусловно крутая фишка из коробки - prefetch. У других плагинов кеширования я этого не встречал. Prefetch позволяет при наведении на ту или иную ссылку на сайте загрузить в фоне страницу и сохранить её в кеш. При этом, когда пользователь попытается перейти по этой ссылке - страница будет загружена моментально. Возможно, именно эта фишка добавляет плагину "очков" в различных обзорах и сравнениях.
Но всё-таки это не относится к кешированию, ровно как оптимизация HTML/CSS/JS, поэтому я не стал добавлять это в статью. А при необходимости prefetch можно реализовать с помощью вот этого плагина: https://wordpress.org/plugins/pre-party-browser-hints/
Попробовал. Если честно, большого прироста к скорости загрузки сайта не заметил. Возможно, конечно, этот плагин позволит снизить нагрузку на сервер - возможности сейчас это проверить нет, т.к. тесты провожу на отдельном VDS, где никакого трафика и нагрузки особо нет.
Но вот с точки зрения объектного кеширования (если по какой-то причине невозможно реализовать кеширование в HTML-страницы), мне очень понравился W3 Total Cache. Даже исключительно с объектным кешированием, он даёт довольно ощутимый прирост к скорости загрузки страниц.
К сожалению, у меня не получилось в полной мере воспользоваться таким подходом. При использовании WP Rocket нет особой разницы куда пихать свой PHP-код в "advanced-cache.php" или в корневой "index.php" - результат будет одинаковым.
Полноценно использовать PHP с WP Rocket нельзя, т.к. согласно правилу в .htaccess, которое добавляет WP Rocket, если в директории /wp-content/cache/wp-rocket/ присутствует кеш-копия искомой страницы будет загружена именно она.
Для проверки можно в начало файла "advanced-cache.php" добавить следующий код
Если страница закеширована не была - код исполнится и в log.txt будет добавлена информация с запрашиваемым URL, если же страница закеширована - ничего добавлено не будет.
Также, WP Rocket при изменении файла .htaccess добавляет и исключения для запросов - запросы содержащие feed, wp-login, wp-admin, wp-json, wp-cron и т.д. - не кешируются и в данном случае PHP-код из "advanced-cache.php" выполнен будет. Поэтому в log.txt, при открытии закешированной страницы можно увидеть что-нибудь навроде /wp-json/contact-form-7/v1/contact-forms/4385/refill, если используется Contact Form 7.
Подобное решение, по крайней мере для меня не подойдет. Как я уже писал в статье, для получения корректной аналитики по заявкам, я использую следующий подход: в момент визита пользователя на веб-сайт, в PHP-сессию сохраняется вспомогательная информация (страница входа, реферер и т.д.), а в момент отправки заявки - эта информация передается в CRM вместе с самой заявкой. И если страницу входа еще можно получить (как реферер к запросу /wp-json/contact-form-7/v1/contact-forms/4385/refill), то вот откуда человек пришел (реальный реферер) получить уже не получится. При этом, на странице, к которой пользователь обратился изначально может и не существовать AJAX-запросов wp-json (например, нет контактной формы) - в этом случае мы получим либо некорректную информацию о визите, либо вовсе её не получим. Поэтому, в данном случае, помогают плагины, которые позволяют реализовать кеширование без вмешательства в .htaccess (имеющие PHP-based режим, такие как WP Super Cache или W3 Total Cache), либо плагины, поддающиеся доработке (как в примере с WP Fastest Cache).
Мне тоже по первости понравился WP Rocket. Удобный интерфейс, простая настройка. Но по крайней мере в моём случае, на нескольких сайтах с совершенно разным окружением (VDS слабый, VDS мощный, шаред-хостинг) он повёл себя нестабильно.
Есть у меня один клиент, которому крайне важен аптайм, при этом сайт небольшой (страниц 100-150), трафик тоже не особо (~1 000 визитов в сутки). Под сайт выделена неслабая виртуалка в дедике (4 vCPU, 8G RAM, NVMe). Именно клиент настоял на таком конфиге, как минимум потому что у него есть такая возможность (дедик). Так вот, даже на таком сервере WP Rocket повёл себя также как и на других (более слабых) серверах/хостинге - в момент ручного создания кеша (Cache Preloading) для всех страниц создавалась огромная нагрузка на сервер (отваливался MySQL, страницы у сторонних пользователей не загружались, иногда это было временно, иногда приходилось вручную перезагружать сервер).
Предзагрузка кеша часто зависает. Например, нажимаю вручную "Начать кеширование" и WP Rocket зависает на на какой-то определенной странице (зачастую, не закешировав и четверти страниц) и сколько бы не пришлось ждать - до истечения срока жизни кеша, указанного в настройках плагина, он не сдвигается с этой точки. При этом переключение WP CRON на CRONJOB никак не помогает.
Далее, если повезет и всё-таки WP Rocket сможет построить кеш (хотя бы части страниц), по неизвестной для меня причине он периодически "отваливается" как будто бы никакого кеша и не было построено.
Прямо сейчас, я специально развернул простенький сайт (29 старниц, 82 поста, и штук 50 тегов / рубрик и т.д.) на отдельном чистом VDS (1 vCPU, 2G RAM), естественно, трафика нет, выполнение задач - автоматически через планировщик (CRONJOB). Запустил Cache Preloading, Load Average тут же перевалил за 7 (удивительно как MySQL не отвалился), в этот момент страницы сайта начали грузиться не по 2 сек (как без какого-либо плагина кеширования), а по 20 (из-за высокой нагрузки). Построение кеша проводилось на основе Sitemap.XML, где более 160 записей. Через минуту после начала, WP Rocket остановился на 33-й странице и в течении получаса отказывался двигаться дальше. Запустил заново, на этот раз всё прошло хорошо - WP Rocket управился с предзагрузкой кеша всех страниц за 6 минут.
Ранее (на момент написания статьи), WP Rocket у меня стоял на нескольких сайтах в течении месяца, и основная претензия к нему была в том, что по какой-то причине, кеш "отваливался" задолго до истечения срока своей жизни. При этом, проявлялось это случайно - например, вижу, что в дешборде WP Rocket написано, что "Предзагрузка завершена" час назад, до истечения срока жизни кеш-файлов еще 11 часов, а половина страниц на сайте, по факту не закешированы.
WP Rocket не кеширует страницы с GET-параметрами, которые заранее не указаны. Не знаю, можно ли это назвать какой-то критичной проблемой, но хотелось бы иметь подобную настройку, чтобы разрешить или запретить кеширование подобных страниц, как это реализовано у WP Super Cache.
Также, стоит отметить, что CRON-задача "rocket_purge_time_event" очищает сразу все кеш-файлы с истекшим сроком жизни, а не формирует их последовательно. rocket_purge_time_event привязывается к моменту начала предзагрузки кеша и запускается через промежуток времени, указанный в настройках, а вот "rocket_preload_cron_interval" выполняется каждые 5 минут. Соответственно, даже на небольшом сайте мы можем получить следующую ситуацию: срок жизни кеша истек, кеш-файлы были удалены, rocket_preload_cron_interval еще не запустился и в течении 5 минут на сайте пользователи видят долгую загрузку, как будто бы никакого кеширования и нет, через 5 минут запускается формирование новых кеш-файлов и работает довольно продолжительное время (в моем случае 6 минут на 160 страниц) и в этот период пользователи видят еще более долгую загрузку страниц, значительно превышающую скорость загрузки страниц без каких-либо плагинов кеширования.
С точки зрения скорости загрузки уже закешированных страниц, безусловно, WP Rocket - один и самых шустрых. Но опять же, если вы готовы мириться с некоторыми особенностями функционала того или иного плагина, я бы рекомендовал выбрать W3 Total Cache - скорость загрузки закешированных страниц та же, но компромиссов на которые придется пойти значительно меньше.
ИТОГО:
В момент предзагрузки кеша, WP Rocket создает огромную нагрузку на сервер (пусть и кратковременную). Подобная нагрузка вполне может "положить" сервер, особенно если страниц на сайте довольно много.
Процессы предзагрузки и очистки кеша ведут себя нестабильно.
Автоматическое кеширование очищает сразу все просроченные кеш-файлы, а не заменяет их последовательно (как, например, это делает WP Fastest Cache), соответственно, существует промежуток времени, когда сайт у конечных пользователей работает критически медленно.
Нельзя разрешить кеширование страниц с GET-параметрами, которые не указаны в настройках
Невозможно исполнять PHP-логику на закешированных страницах
Любой из представленных плагинов позволит организовать автокеширование как на хитах (WP CRON), так и через планировщик (CRONJOB). При настройке, каждый может выбрать для себя наиболее удобный вариант. При тестировании я пробовал как WP CRON, так и CRONJOB. Если на сайте есть хоть какой-то более-менее адекватный трафик, разница заметна не будет
Это решается другими плагинами? Если да, то как
Swift perfomance пытаются сделать это с помощью "Умного кеширования", но пока у них это получается не особо. Решение, по факту, здесь только одно - увеличивать скорость автокеширования. W3 Total я бы не рекомендовал для таких целей, особенно на сайтах с большим числом страниц, здесь лучше подойдет WP Fastest Cache - он позволит обновить файлы кеша в режиме автокеширования довольно быстро, при этом не очищая кеш-файлы сразу, т.е. у кончечных пользователей сайт будет грузиться быстро всегда.
Как это реализовано?
Тут довольно всё очевидно "Максимальное время жизни кэшированых объектов" - сколько времени могут хранится кеш-файлы до того как будут удалены "Период удаления устаревшего кэша" - когда нужно запускать очистку кеш-файлов По факту, указывать разные значения особо смысла нет, резульат будет примерно одинаков
Если пользователь открыл страницу где "Максимальное время жизни кэшированых объектов" уже истекло, но "Период удаления устаревшего кэша" еще не закончился - кеш файл буедт удален в момент загрузки этой страницы
Когда "Период удаления устаревшего кэша" завершился - кеш-файлы будут удалены автоматически (и без визита пользователей на эти страницы)
Он что, сначала удаляет кеш, а потом заполняет?
Судя по всему, он в фоне пытается выполнить еще и другие операции, от чего конечный пользователь видит крайне долгую загрузку страницы
Как это реализовано?
Когда администратор сайта вносит какие-либо изменения, Swift perfomance запускает переобход страниц с целью обновления кеш-файлов автоматически, а не дожидается истечения срока жизни кеша.
Пробовали, замеры как раз проводились на сервере с nginx + apache. Только вот, к сожалению, наличие nginx не позволяет сократить число запросов к БД при загрузке страницы сайта на базе WordPress, на котором отсутствует плагин кеширования.
Nginx, действительно, позволит значительно сократить общую скорость загрузки веб-сайта, но на TTFB (основная метрика, о которой идет речь в статье) он практически не повлияет.
В разделе "Page cache", в блоке "Предзагрузка кеша" снимите галочку "Автоматическая загрузка кэша страницы", а в блоке "Дополнительно", установите значение "Интервал удаления просроченного кэша:" = 0
Если честно, такой задачи передо мной никогда не стояло, но здесь я могу предложить такой вариант - если URL страниц содержит, например, год публикации (example.com/blog/2007/artcle-title) с помощью большинства плагинов можно исключить такие страницы с помощью правил кеширвания. Например, в WP Super Cache это будет выглядеть так: http://ipic.su/img/img7/fs/000.1629699642.png
Большинство плагинов кеширования используют диск, в память умеют кешировать лишь единицы, поэтому платная подписка на расширенный функционал здесь более чем оправдана. Тем не менее, каждый должен четко выбирать для себя приоритеты. Кеширование в память дает сильный прирост производительности в сравнении с кешированием на диск. Но если сравнить разницу в скорости кеширования на диск и кеширования в память, с кешированием на диск и отсутствием кеширования как такового - этот прирост в скорости загрузки будет не столь заметным.
Я лично остановился именно на варианте с кешированием на диск, т.к. есть еще множество моментов которые стоит улучшить - это и географическое расположение сервера/хостинга, оптимизация статичного контента на сайте (изображения, скрипты, таблицы стилей), Lazy Loading, Prefetch.
Спасибо за информацию, Hyper Cache еще не пробовал - потестируем
Подскажите, а как вам удалось запустить WP Rocket без добавления правил в .htaccess? Подобной настройки в плагине я не заметил, Google тоже не помог.
Если удалить правила из .htaccess, действительно, WP Rocket начинает работать в PHP-based режиме и произвольный PHP-код из корневого index.php или advanced-cache.php будет выполнен. Но при следующем же обновлении настроек (и я подозреваю, обновлении плагина) правила опять будут добавлены в .htaccess
Autoptimize - это немного не про то кеширование :)
Autoptimize позволяет сжимать и объединять HTML/CSS/JS файлы, удалять комментарии, реализовать Lazy Loading и отложенную загрузку некоторых объектов. Autoptimize, безусловно, позволяет увеличить общую скорость загрузки сайта, но вот на TTFB он не повлияет.
Многие плагины кеширования (такие как W3 Total Cache, платная версия WP Fastest Cache, Swift perfomance, WP Rocket и другие) тоже предлагают подобный функционал, но статья оказалось и так довольно обширной и слишком долгой для чтения, поэтому обзор плагинов для оптимизации я решил оставить на потом.
Autoptimize крайне неплохо может работать в паре с плагином кеширования, который не умеет в оптимизацию (WP Super Cache или бесплатная версия WP Fastest Cache). Попробуйте дополнительно установить один из представленных плагинов помимо Autoptimize - скорость загрузки сайта значительно увеличится!
Спасибо за информацию, протестируем
У WP Rocket есть безусловно крутая фишка из коробки - prefetch. У других плагинов кеширования я этого не встречал. Prefetch позволяет при наведении на ту или иную ссылку на сайте загрузить в фоне страницу и сохранить её в кеш. При этом, когда пользователь попытается перейти по этой ссылке - страница будет загружена моментально. Возможно, именно эта фишка добавляет плагину "очков" в различных обзорах и сравнениях.
Но всё-таки это не относится к кешированию, ровно как оптимизация HTML/CSS/JS, поэтому я не стал добавлять это в статью. А при необходимости prefetch можно реализовать с помощью вот этого плагина: https://wordpress.org/plugins/pre-party-browser-hints/
Попробовал. Если честно, большого прироста к скорости загрузки сайта не заметил. Возможно, конечно, этот плагин позволит снизить нагрузку на сервер - возможности сейчас это проверить нет, т.к. тесты провожу на отдельном VDS, где никакого трафика и нагрузки особо нет.
Но вот с точки зрения объектного кеширования (если по какой-то причине невозможно реализовать кеширование в HTML-страницы), мне очень понравился W3 Total Cache. Даже исключительно с объектным кешированием, он даёт довольно ощутимый прирост к скорости загрузки страниц.
К сожалению, у меня не получилось в полной мере воспользоваться таким подходом. При использовании WP Rocket нет особой разницы куда пихать свой PHP-код в "advanced-cache.php" или в корневой "index.php" - результат будет одинаковым.
Полноценно использовать PHP с WP Rocket нельзя, т.к. согласно правилу в .htaccess, которое добавляет WP Rocket, если в директории /wp-content/cache/wp-rocket/ присутствует кеш-копия искомой страницы будет загружена именно она.
Для проверки можно в начало файла "advanced-cache.php" добавить следующий код
Если страница закеширована не была - код исполнится и в log.txt будет добавлена информация с запрашиваемым URL, если же страница закеширована - ничего добавлено не будет.
Также, WP Rocket при изменении файла .htaccess добавляет и исключения для запросов - запросы содержащие feed, wp-login, wp-admin, wp-json, wp-cron и т.д. - не кешируются и в данном случае PHP-код из "advanced-cache.php" выполнен будет. Поэтому в log.txt, при открытии закешированной страницы можно увидеть что-нибудь навроде /wp-json/contact-form-7/v1/contact-forms/4385/refill, если используется Contact Form 7.
Подобное решение, по крайней мере для меня не подойдет. Как я уже писал в статье, для получения корректной аналитики по заявкам, я использую следующий подход: в момент визита пользователя на веб-сайт, в PHP-сессию сохраняется вспомогательная информация (страница входа, реферер и т.д.), а в момент отправки заявки - эта информация передается в CRM вместе с самой заявкой. И если страницу входа еще можно получить (как реферер к запросу /wp-json/contact-form-7/v1/contact-forms/4385/refill), то вот откуда человек пришел (реальный реферер) получить уже не получится. При этом, на странице, к которой пользователь обратился изначально может и не существовать AJAX-запросов wp-json (например, нет контактной формы) - в этом случае мы получим либо некорректную информацию о визите, либо вовсе её не получим. Поэтому, в данном случае, помогают плагины, которые позволяют реализовать кеширование без вмешательства в .htaccess (имеющие PHP-based режим, такие как WP Super Cache или W3 Total Cache), либо плагины, поддающиеся доработке (как в примере с WP Fastest Cache).
Мне тоже по первости понравился WP Rocket. Удобный интерфейс, простая настройка. Но по крайней мере в моём случае, на нескольких сайтах с совершенно разным окружением (VDS слабый, VDS мощный, шаред-хостинг) он повёл себя нестабильно.
Есть у меня один клиент, которому крайне важен аптайм, при этом сайт небольшой (страниц 100-150), трафик тоже не особо (~1 000 визитов в сутки). Под сайт выделена неслабая виртуалка в дедике (4 vCPU, 8G RAM, NVMe). Именно клиент настоял на таком конфиге, как минимум потому что у него есть такая возможность (дедик). Так вот, даже на таком сервере WP Rocket повёл себя также как и на других (более слабых) серверах/хостинге - в момент ручного создания кеша (Cache Preloading) для всех страниц создавалась огромная нагрузка на сервер (отваливался MySQL, страницы у сторонних пользователей не загружались, иногда это было временно, иногда приходилось вручную перезагружать сервер).
Предзагрузка кеша часто зависает. Например, нажимаю вручную "Начать кеширование" и WP Rocket зависает на на какой-то определенной странице (зачастую, не закешировав и четверти страниц) и сколько бы не пришлось ждать - до истечения срока жизни кеша, указанного в настройках плагина, он не сдвигается с этой точки. При этом переключение WP CRON на CRONJOB никак не помогает.
Далее, если повезет и всё-таки WP Rocket сможет построить кеш (хотя бы части страниц), по неизвестной для меня причине он периодически "отваливается" как будто бы никакого кеша и не было построено.
Прямо сейчас, я специально развернул простенький сайт (29 старниц, 82 поста, и штук 50 тегов / рубрик и т.д.) на отдельном чистом VDS (1 vCPU, 2G RAM), естественно, трафика нет, выполнение задач - автоматически через планировщик (CRONJOB). Запустил Cache Preloading, Load Average тут же перевалил за 7 (удивительно как MySQL не отвалился), в этот момент страницы сайта начали грузиться не по 2 сек (как без какого-либо плагина кеширования), а по 20 (из-за высокой нагрузки). Построение кеша проводилось на основе Sitemap.XML, где более 160 записей. Через минуту после начала, WP Rocket остановился на 33-й странице и в течении получаса отказывался двигаться дальше. Запустил заново, на этот раз всё прошло хорошо - WP Rocket управился с предзагрузкой кеша всех страниц за 6 минут.
Ранее (на момент написания статьи), WP Rocket у меня стоял на нескольких сайтах в течении месяца, и основная претензия к нему была в том, что по какой-то причине, кеш "отваливался" задолго до истечения срока своей жизни. При этом, проявлялось это случайно - например, вижу, что в дешборде WP Rocket написано, что "Предзагрузка завершена" час назад, до истечения срока жизни кеш-файлов еще 11 часов, а половина страниц на сайте, по факту не закешированы.
WP Rocket не кеширует страницы с GET-параметрами, которые заранее не указаны. Не знаю, можно ли это назвать какой-то критичной проблемой, но хотелось бы иметь подобную настройку, чтобы разрешить или запретить кеширование подобных страниц, как это реализовано у WP Super Cache.
Также, стоит отметить, что CRON-задача "rocket_purge_time_event" очищает сразу все кеш-файлы с истекшим сроком жизни, а не формирует их последовательно. rocket_purge_time_event привязывается к моменту начала предзагрузки кеша и запускается через промежуток времени, указанный в настройках, а вот "rocket_preload_cron_interval" выполняется каждые 5 минут. Соответственно, даже на небольшом сайте мы можем получить следующую ситуацию: срок жизни кеша истек, кеш-файлы были удалены, rocket_preload_cron_interval еще не запустился и в течении 5 минут на сайте пользователи видят долгую загрузку, как будто бы никакого кеширования и нет, через 5 минут запускается формирование новых кеш-файлов и работает довольно продолжительное время (в моем случае 6 минут на 160 страниц) и в этот период пользователи видят еще более долгую загрузку страниц, значительно превышающую скорость загрузки страниц без каких-либо плагинов кеширования.
С точки зрения скорости загрузки уже закешированных страниц, безусловно, WP Rocket - один и самых шустрых. Но опять же, если вы готовы мириться с некоторыми особенностями функционала того или иного плагина, я бы рекомендовал выбрать W3 Total Cache - скорость загрузки закешированных страниц та же, но компромиссов на которые придется пойти значительно меньше.
ИТОГО:
В момент предзагрузки кеша, WP Rocket создает огромную нагрузку на сервер (пусть и кратковременную). Подобная нагрузка вполне может "положить" сервер, особенно если страниц на сайте довольно много.
Процессы предзагрузки и очистки кеша ведут себя нестабильно.
Автоматическое кеширование очищает сразу все просроченные кеш-файлы, а не заменяет их последовательно (как, например, это делает WP Fastest Cache), соответственно, существует промежуток времени, когда сайт у конечных пользователей работает критически медленно.
Нельзя разрешить кеширование страниц с GET-параметрами, которые не указаны в настройках
Невозможно исполнять PHP-логику на закешированных страницах
Не натыкался на такое решение. Спасибо, изучу. Если что - дополню статью
Спасибо за комментарий :)
Любой из представленных плагинов позволит организовать автокеширование как на хитах (WP CRON), так и через планировщик (CRONJOB). При настройке, каждый может выбрать для себя наиболее удобный вариант. При тестировании я пробовал как WP CRON, так и CRONJOB. Если на сайте есть хоть какой-то более-менее адекватный трафик, разница заметна не будет
Swift perfomance пытаются сделать это с помощью "Умного кеширования", но пока у них это получается не особо. Решение, по факту, здесь только одно - увеличивать скорость автокеширования. W3 Total я бы не рекомендовал для таких целей, особенно на сайтах с большим числом страниц, здесь лучше подойдет WP Fastest Cache - он позволит обновить файлы кеша в режиме автокеширования довольно быстро, при этом не очищая кеш-файлы сразу, т.е. у кончечных пользователей сайт будет грузиться быстро всегда.
Тут довольно всё очевидно "Максимальное время жизни кэшированых объектов" - сколько времени могут хранится кеш-файлы до того как будут удалены "Период удаления устаревшего кэша" - когда нужно запускать очистку кеш-файлов По факту, указывать разные значения особо смысла нет, резульат будет примерно одинаков
Если пользователь открыл страницу где "Максимальное время жизни кэшированых объектов" уже истекло, но "Период удаления устаревшего кэша" еще не закончился - кеш файл буедт удален в момент загрузки этой страницы
Когда "Период удаления устаревшего кэша" завершился - кеш-файлы будут удалены автоматически (и без визита пользователей на эти страницы)
Судя по всему, он в фоне пытается выполнить еще и другие операции, от чего конечный пользователь видит крайне долгую загрузку страницы
Когда администратор сайта вносит какие-либо изменения, Swift perfomance запускает переобход страниц с целью обновления кеш-файлов автоматически, а не дожидается истечения срока жизни кеша.
Пробовали, замеры как раз проводились на сервере с nginx + apache. Только вот, к сожалению, наличие nginx не позволяет сократить число запросов к БД при загрузке страницы сайта на базе WordPress, на котором отсутствует плагин кеширования.
Nginx, действительно, позволит значительно сократить общую скорость загрузки веб-сайта, но на TTFB (основная метрика, о которой идет речь в статье) он практически не повлияет.
Об этом в статье тоже есть :)
Для "тяжелых" сайтов я рекомендую использовать Laravel, Symphony или Yii2, но ведь и блоги тоже могут тормозить?