Как стать автором
Обновить

Комментарии 32

спасибо, интересно + узнал пару новых фич

Спасибо за комментарий :)

Какой принцип работы автокеширования?
cron?
Кроме W3 Total Cache

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

Это решается другими плагинами? Если да, то как

Также укажем значения «Максимальное время жизни кэшированых объектов» и «Период удаления устаревшего кэша»

Как это реализовано?

Тем не менее вторую проблему (долгая загрузка страниц в период обновления кеша) решить невозможно

Он что, сначала удаляет кеш, а потом заполняет?

чтобы кеш обновлялся не по таймеру, а только при внесении изменений

Как это реализовано?

Какой принцип работы автокеширования?

Любой из представленных плагинов позволит организовать автокеширование как на хитах (WP CRON), так и через планировщик (CRONJOB). При настройке, каждый может выбрать для себя наиболее удобный вариант. При тестировании я пробовал как WP CRON, так и CRONJOB. Если на сайте есть хоть какой-то более-менее адекватный трафик, разница заметна не будет

Это решается другими плагинами? Если да, то как

Swift perfomance пытаются сделать это с помощью "Умного кеширования", но пока у них это получается не особо. Решение, по факту, здесь только одно - увеличивать скорость автокеширования. W3 Total я бы не рекомендовал для таких целей, особенно на сайтах с большим числом страниц, здесь лучше подойдет WP Fastest Cache - он позволит обновить файлы кеша в режиме автокеширования довольно быстро, при этом не очищая кеш-файлы сразу, т.е. у кончечных пользователей сайт будет грузиться быстро всегда.

Как это реализовано?

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

  • Если пользователь открыл страницу где "Максимальное время жизни кэшированых объектов" уже истекло, но "Период удаления устаревшего кэша" еще не закончился - кеш файл буедт удален в момент загрузки этой страницы

  • Когда "Период удаления устаревшего кэша" завершился - кеш-файлы будут удалены автоматически (и без визита пользователей на эти страницы)

Он что, сначала удаляет кеш, а потом заполняет?

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

Как это реализовано?

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

nginx пробовали?

Пробовали, замеры как раз проводились на сервере с nginx + apache. Только вот, к сожалению, наличие nginx не позволяет сократить число запросов к БД при загрузке страницы сайта на базе WordPress, на котором отсутствует плагин кеширования.

Nginx, действительно, позволит значительно сократить общую скорость загрузки веб-сайта, но на TTFB (основная метрика, о которой идет речь в статье) он практически не повлияет.

Позволяет, советую разобраться в кешировании в целом, а не в плагинах вордпресса

Спасибо. Классно разобрано. Про get запросы не задумывался даже.

Я когда смотрю американские обзоры, там WP rocket прям обожают и в бенчмарках он чемпион.

Вы его просто обошли стороной.

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

Мне тоже по первости понравился 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 Rocket есть безусловно крутая фишка из коробки - prefetch. У других плагинов кеширования я этого не встречал. Prefetch позволяет при наведении на ту или иную ссылку на сайте загрузить в фоне страницу и сохранить её в кеш. При этом, когда пользователь попытается перейти по этой ссылке - страница будет загружена моментально. Возможно, именно эта фишка добавляет плагину "очков" в различных обзорах и сравнениях.

Но всё-таки это не относится к кешированию, ровно как оптимизация HTML/CSS/JS, поэтому я не стал добавлять это в статью. А при необходимости prefetch можно реализовать с помощью вот этого плагина: https://wordpress.org/plugins/pre-party-browser-hints/

Вопрос про Pre* Party Resource Hints: он влияет на оценку скорости со стороны поисковиков? Или только улучшает user experience?

Спасибо. Потестил его. Действительно при обходе вешает сайт.

GET запросы можно там пропатчить. У них на сайте есть аддон.

Спасибо за обзор.

Что насчёт NitroPack?

Не натыкался на такое решение. Спасибо, изучу. Если что - дополню статью

Для случаев когда вызывается не кешированная страница рекомендую Docket Cache

https://wordpress.org/plugins/docket-cache/

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

Это объектный кеш, который сохраняет опции в файлы, а потом быстро отдаёт их движку.
Плюс он может работать со статическим кешем, у меня работает в пару с Hyper Cache, но думаю что и с вашим WP Fastest Cache тоже должен заработать.

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

Но вот с точки зрения объектного кеширования (если по какой-то причине невозможно реализовать кеширование в HTML-страницы), мне очень понравился W3 Total Cache. Даже исключительно с объектным кешированием, он даёт довольно ощутимый прирост к скорости загрузки страниц.

Для скорости загрузки - кеширование в статику. У меня это Hyper Cache, но так же может работать и WP Fastest Cache или W3 Total Cache.

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

Так что да, этот плагин позволит снизить нагрузку на сервер.

Для меня главное преимущество этого кеша в совместной работе с другим плагином кеширования.

Спасибо за информацию, Hyper Cache еще не пробовал - потестируем

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

В общем, там можно внедрить собственный php-код. Другое дело, что это не очень удобно. Суть в том, что сам плагин вызывается из вордпрессовского файла advanced-cache.php. Вот можно подсесть на экшн, который генерирует этот файл, и добавить туда вызов своего кода.

К сожалению, у меня не получилось в полной мере воспользоваться таким подходом. При использовании WP Rocket нет особой разницы куда пихать свой PHP-код в "advanced-cache.php" или в корневой "index.php" - результат будет одинаковым.

Полноценно использовать PHP с WP Rocket нельзя, т.к. согласно правилу в .htaccess, которое добавляет WP Rocket, если в директории /wp-content/cache/wp-rocket/ присутствует кеш-копия искомой страницы будет загружена именно она.

Для проверки можно в начало файла "advanced-cache.php" добавить следующий код

file_put_contents("log.txt", date("Y-m-d H:i:s")."\n".$_SERVER['REQUEST_URI']."\n\n", FILE_APPEND | LOCK_EX);

Если страница закеширована не была - код исполнится и в 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 может работать в разных режимах. Если честно, то я и не знал, что он может работать через правила в apache/nginx. Спасибо, изучу этот момент.

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

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

Подскажите, а как вам удалось запустить WP Rocket без добавления правил в .htaccess? Подобной настройки в плагине я не заметил, Google тоже не помог.

Если удалить правила из .htaccess, действительно, WP Rocket начинает работать в PHP-based режиме и произвольный PHP-код из корневого index.php или advanced-cache.php будет выполнен. Но при следующем же обновлении настроек (и я подозреваю, обновлении плагина) правила опять будут добавлены в .htaccess

есть еще довольно неплохой по результатам плагин Autoptimize https://wordpress.org/plugins/autoptimize/

но при переходе на моем тестовом сайте с него на W3 total cache показатели даже улучшились. gtmetrics при замерах из Лондона в полном восторге от сайта на elementor. а вот гугловые pagespeed весьма скептически показывает 52 для моб и 72 для десктопов. очень возможно, что гугл меряет откуда-то издалека.

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 - скорость загрузки сайта значительно увеличится!

Не плохо на самом деле, близкий к реальности обзор без маркетинга что ценно, batcache ещё можно попробовать кстати

Спасибо за информацию, протестируем

Оп, вторая часть подъехала, спасибо!

Если сайт типа новостного, где очень много страниц (несколько сотен тысяч), с предложенными настройками WP Super Cache очень быстро "забивает" Inodes. Как-нибудь можно вообще не кэшировать старые посты?

Если честно, такой задачи передо мной никогда не стояло, но здесь я могу предложить такой вариант - если URL страниц содержит, например, год публикации (example.com/blog/2007/artcle-title) с помощью большинства плагинов можно исключить такие страницы с помощью правил кеширвания. Например, в WP Super Cache это будет выглядеть так: http://ipic.su/img/img7/fs/000.1629699642.png

К сожалению URL вполне обычный (example.com/news/stol-dlya-kota).

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


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

Какие настройки там нужно задать, чтобы он так себя стал вести?

В разделе "Page cache", в блоке "Предзагрузка кеша" снимите галочку "Автоматическая загрузка кэша страницы", а в блоке "Дополнительно", установите значение "Интервал удаления просроченного кэша:" = 0

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