Какой плагин кеширования в Вордпрессе лучше других?

подтверждено реальными тестами, или на глаз?

lukoie, за годы реальная практика, любые плагины кеширования при первой загрузке страницы будет стандартный ответ сервера! Есть только некоторые плагины которые делают html копии страниц на сервере и подгружают сайт с нее (не помню название, но меня такие плагины не устраивают).
В итоге у меня получается добиться в интернет магазине с 40к товаров (woocomerce) - ответ сервера не дольше секунды. На лендосах и простых сайтах на 20-50 страниц в районе 150-200 млс, голый WP со стандартной темой где о 100-120 млс.

lukoie, еще из практики от версии к версии скачет немного скорость загрузки, потому иногда php 7.2 быстрее работает на 20%. Очень важная составляющая в этой связке это MariaDB, так как по сравнению с mySQL innoDB в разы быстрее работает.

lukoie, сервер БД и php-fpm только не забудь настроить. Дефолтные настройки не оптимальные.

lamer350,

Очень важная составляющая в этой связке это MariaDB, так как по сравнению с mySQL innoDB в разы быстрее работает.

Это миф на 90%. Кроме того вы путаете термины и понятия, MariaDB это тот же InnoDB :)

Игорь Воротнёв, я о реализации, это э отдельный форк от mySQL разработки, тестил лично mySQL (официальный форм, версия 8) VS MariaDB (форк, версия rock или myrock) - на локалхосте даже в 2 раза быстрее и это на голой инсталляции WP

lamer350, Начнем с того, что в MySQL 8 меняется формат хранения метаданных (internal data dictionary), в MariaDB - нет. С этого, вполне возможно, может начаться то, что они более не будут полностью совместимы. Раньше или позже это произойдет, это просто надо держать в голове. Далее, кроме Oracle еще есть Percona, которая очень и очень хороша.

Далее, дефолтные конфиги, равно как и дефолтная производительность на разных ОС у них разные. Плюс надо учитывать версии и брать полное соответствие. Включая весь фарш, который идет с конкретной сборкой. Какие версии вы тестировали? Дело в том, что MariaDB 10 до версии 10.2 включительно построена на базе MySQL 5.6/5.7. Версии 10.3 и 10.4 являются эволюцией 10.2 (а значит тоже построены на MySQL 5.7), но уже содержат тележку уникальных фич, которых нет в MySQL. Но ни одна из этих фич не используется в WordPress, поэтому можем об этом забыть.

Теперь что касается "в 2 раза быстрее" в целом. Мария в целом действительно немного шустрее, там достаточно много оптимизаций по сравнению с MySQL. Но это прирост в небольших процентах, точечно. Дает ли это ощутимый результат? Да, на больших данных. Да, на высонагруженных проектах. Есть ли заметный прирост в стоке на локальной машине на голой базе? Нет, и быть его не может. Если он у вас есть - значит вопрос в дефолтной конфигурации, не более.

Игорь Воротнёв, какой конфиг mySQL вы используете для WP? из дефолтных оптимизирую только пул сайз для inno и размер буфера и еще пару мелочей. В 2 раза там обратно, но в целом разброс нормальный, 70-100 млс (ответ сервера) на 10.3 MariaDB (php 7.2 + OPCache) vs 120-170 млс на mySQL 8.0 (с тем же конфигом php). Это на голой базе, на базе с 50к страниц разброс примерно такой же получается, особого прироста нет. Точнее не могу сказать версии, всегда использую mariaDB, а то было случайно установил mySQL 8 и офигел от скорости работы сайта, на локалке всегда быстрее было, а тут медленнее чем с сервера грузится...

Игорь Воротнёв, у меня по всей видимости была какая то версия mySQL 8 не стабильная, сейчас специально чтобы доказать свою правоту - установил версию из homebrew стабильную (8.0.13), даже чуток быстрее грузится. Скачет от 60 до 80 млс, так что по всей видимости так просто попалась версия в моих тестах, видимо разницы реально нет.

более идиотской связки придумать сложно. Это вообще к чему ответ?
nginx + php 7.3 + OPcache + MariaDB? --- почему не апач+муСКЛ?
Почему за такие ответы не банят.?

Леонид Батурин, главное чтоб не банили за идиотские комментарии к идиотским советам

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

lukoie, nginx просто имеет фичи которых нет у apache и это его плюс. Я где то в теме постил на таком конфиге скрины с pagespeed от гугла, 98 из 100 для ПК и 96 для моб версии показывало. Причем делалось год назад когда были чуть другие требования, и тогда было 100 из 100, единственный для ускорения плагин который использовался - это autooptimize для сбора css/js в единые файлы.
PS. Это не вам ответ, я просто дополнил)

Леонид Батурин,

более идиотской связки придумать сложно.

А обосновать вброс можете? Я вот искренне интересуюсь, что идиотского в этой связке?

Это вообще к чему ответ?

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

nginx + php 7.3 + OPcache + MariaDB? --- почему не апач+муСКЛ?

Потому что MariaDB это drop-in замена MySQL от Oracle, которая полностью бесплатная и разрабатывается веселее чем MySQL под руководством Oracle, разрабатывается с учетом ожиданий и потребностей более широкой аудитории веб-разработчиков, чем все тот же Oracle MySQL, целевой аудиторией которого является (очень крупный) Enterprise.

Почему не апач? Потому что если у вас не shared хостинг, где нужно дать возможность в каждой папке иметь свой автономный конфиг, то не существует ни одной другой причины использовать Apache для более-менее стандартного use case. Nginx, в первую очередь, быстрее и использует меньше памяти. Если углубляться, то есть еще тележка фич.

Почему за такие ответы не банят.?

Потому что ответ абсолютно адекватный.

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

Статья по ссылке бесполезная, даже вредная.

Игорь Воротнёв, обоснуйте.

EvgenyMorozov, завтра будет немного свободного времени, отпишусь.

EvgenyMorozov, Если кратко:
- спутаны между собой разные уровни кеширования, мухи и котлеты в одну кашу, про некоторые вообще ни слова
- используются не совсем корректные параметры замера (нечетко определенные Page load time вместо стандартных индексов TTI, TTFB и тп)
- Ударение на конкатенацию скриптов и стилей, ни слова об HTTP/2 (а тут уже HTTP/3 на подходе), мультиплексировании, server-push и тд
- Apache
- Результаты вообще не наглядны, какие-то проценты и условные циферки, сложно натянуть на real world scenario
- Многие плагины из списка не являются заменителями и сравнивать их в принципе некорректно вообще

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

Игорь Воротнёв, спасибо за развернутый ответ.

Игорь Воротнёв, уважаемый Игорь, спасибо за ответ.
Абсолютное большинство сайтиков на ВП это ГС, личные бложики или вукоммерс магазинчики. Комплекс мер для таких сайтов зачастую не проводят, потому что это затратно, и результат от дотягивания будет не адекватным затраченному времени и финансам. Потому таким сайтам с головой хватает обычного условного W3Кеша. То есть инструмента, который с полпинка даст достаточный результат.
Как мне видится, статья анализирует как раз такие инструменты.

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

Совсем кратко, без каких-либо статей с кучей непонятных тестов - самое быстрое кеширование для статического сайта - full page cache. В идеале - чтобы PHP даже не поднимался на запрос (то есть статика HTML), и в этом плане самый быстрый nginx fastcgi_cache. Есть user-friendly решения. Если этот метод не катит - используем Batcache, который реализует full page cache в памяти (memcached / redis). Если и это не вариант - тогда WP Super Cache или WP Rocket, а еще лучше - CloudFlare между пользователем и сайтом или адекватный специализированный хостинг типа Kinsta, где все это уже есть из коробки. Минимум настроек и головной боли, максимум эффекта. Все остальное можно не трогать и не экспериментировать.

Игорь Воротнёв, спасибо. но обоснуйте почему не трогать, к примеру, Breeze, WP Speed of Light или LiteSpeed Cache?

lukoie,
1. Breeze - сделан компанией Cloudways, в первую очередь под свои нужды. Например, тот же Varnish, которого с вероятностью 99.99% не будет у вашего предполагаемого блогера. Цитата, их же словами:

Breeze, by default, supports Varnish. It has been tested to be fully compatible with Cloudways Servers that come with Varnish pre-installed.

Исключения, кстати, в конфиг Varnish придется вручную вносить, из админки они не будут применяться.
Далее, они делают "оптимизацию базы данных" (на самом деле - контроль/очистку ревизий, спам-комментариев, удаление протухших transients). Плагин кеширования не должен этого делать, от слова совсем.
Еще - они впилили активную поддержку CDN из коробки, но при этом поддерживают только 3 провайдера -MaxCDN, KeyCDN и Amazon Cloudfront. Поддержки Push CDN - нету, только Pull CDN. Настройка CloudFlare требует определенного опыта, которого у нашего предполагаемого блоггера нет.
Плагин гзипит контент, и как я понял (не рылся уже глубоко в коде) - с помощью PHP. Это минус по производительности на этапе генерации кеша, к тому же при некоторых (думаю многих) конфигурациях nginx у нас будет двойной gzip. Бред. То же самое по минификации - она делается с помощью PHP, что есть не ок.
Код плагина, кстати, начался как форк WP Speed Of Light.

2. WP Speed of Light. Лично для меня плагин, который тащит в админку WP какой-то левый интерфейс со своими цветастыми градиентами, шрифтами и прочей мишурой - сразу в корзину и в черный список. Но закроем на это глаза и посмотрим на него по существу.
Те же проблемы с минификацией и gzip. Это не должно делаться с помощью PHP, тем более в runtime.
Опять "оптимизация" базы данных. Не более чем маркетинг. И это не должен делать плагин кеширования. Плюс, "оптимизация" transients часто может иметь нежелательные побочные эффекты, когда закешированы будут неактуальные данные или вообще данных не будет.
Вредный совет Remove Query strings - да, Google PageSpeed обрадуется, пользователи - наоборот. Привет, жалобам от посетителей клиенту, а дальше клиента разработчику (или если клиент сам ставил - в поддержку плагина). Классика жанра - "у меня все ок", а у тысяч людей по всем миру - старый код. Добавьте сверху еще CDN и привет полный.
Option to disable the WordPress REST API - серьезно? Ничего, что WP постепенно мигрирует с Ajax на REST, и отключать его не нужно? Да и "оптимизации" в этом ровно ноль. При чем здесь это вообще в плагине кеширования? И да, он вообще-то врет и совсем не дизейблит REST API - все что он делает это убирает ссылку на API из головы документа. Сама апишка как была, так и остается.
Option to disable the WordPress RSS feeds - при чем RSS фиды к кешированию?
Cache external resources such as scripts served from Google (served locally) - о, привет жалобам из отдела маркетинга, сломанным трекерам и ретаргетингу, нестыковкам в статистике и отчетах. Добавляем поверх этого Remove query strings и CDN - и полный привет.
Плагин весит 4.5Мб. Четыре с половиной мегабайта! Код - так себе. К примеру, используют свой собственный механизм переводов поверх нативного. В папочке js - jQuery UI который и так включен в WP.
В общем, это каша из категории "премиум-тем-1000-в-1". В топку.

3. LiteSpeed Cache - замечание по поводу кастомного дизайна внутри админки WP все то же. Сразу в бан. Но копнем все-таки плагин, для интереса. По перечню фич и подходу к реализации из этих 3х плагинов он, пожалуй, наиболее адекватен. Но:
Во-первых, полноценно может использоваться только с сервером LiteSpeed. Большой минус сразу. Наш среднестатистический блогер 100% впервые слышит что-либо кроме Apache, максимум Nginx.
Пытается оптимизировать картинки. Это не его задача.
Минификация и конкатенация скриптов и стилей. Опять же, во-первых не задача плагина кеширования. Во-вторых, не надо делать это на уровне PHP runtime.
Тулит свой Lazyload в нескольких вариациях. Если у нашего условного блоггера "премиум"-тема (а это скорее всего так), то там будет свой LL js, значит конфликты практически неизбежны.
Опять же, обещает чистить базу. Не его задача и пускать его туда нельзя.
Обещает еще "OPcode Cache". Это как?
Обещает HTTP/2 Push for CSS/JS, но делает его криво - пушит всегда, а не первый раз. К тому же, HTTP/2 фичи доступны только на коммерческом LiteSpeed, так что нашему блогеру это не светит все равно.
Есть глюки с корзинами WooCommerce (фиксится, но те кто не вчитывается во все доки просто пропустят этот нюанс и через некоторое время будут в панике искать фрилансера на апворке чтобы ему пофиксили неработающую корзину).
Исключения из кеша, работа с nonce, и много других фич требуют ковыряться в коде, пусть даже и минимально. Делать это после заполнения дюжины длиннющих форм в админке - ад.
Достаточно много конфликтов с другими плагинами.

Вердикт - все 3 плагина являются аналогом "премиум"-тем 1000-в-1 - пытаются делать ВСЕ, в результате не делают хорошо ничего. Миллион настроек, кастомный "интерфейс" с говнодизайном, который кричит и выскакивает из интерфейса WP, требует использования сторонних ресурсов (LiteSpeed, ограничение по 3м CDN-провайдерам, Varnish итд), сомнительные фичи которые создают видимость оптимизации но абсолютно бесполезны (отключение RSS и REST API, якобы оптимизация базы данных итд), минификация-конкатенация на стороне PHP в runtime. Итого, что они делают? Много обещают. Дают какую-то оптимизацию если Cache HIT. Заметно замедляют, если Cache Miss. Вопрос - зачем их использовать, если есть проверенные, быстрые, эффективные плагины без всего этого мусора?

Игорь Воротнёв, Вот отличный ответ. Спасибо за Ваш анализ.

есть проверенные, быстрые, эффективные плагины без всего этого мусора

Игорь Воротнёв, огласите весь список, пожалуйста.

EvgenyMorozov,
Batcache - минималистичный, быстрый full page cache (если нет возможности/желания сделать руками Nginx fastcgi_cache).
WP Super Cache - то же, что и выше, только уже с минимально необходимыми настройками.
WP Rocket - полный фарш. Включая те же оптимизации на разных уровнях (хоть я и считаю что плагин кеширования не должен этим заниматься, но и WP Rocket перестали себя позиционировать как плагин кеширования, они теперь Performance plugin, а это уже другое дело).
Есть еще Perfmatters, это для тех кому надо поотключать всякие фичи и облегчить WP. С помощью данного плагина эффект реально есть.

Игорь Воротнёв, какие будут подводные камни при использовании fast_cgi cache?

EvgenyMorozov, fastcgi_cache это кеш на уровне самого Nginx. Плюс - очень высокая скорость и пропускная способность, так как запросы не доходят до PHP и MySQL вообще. В этом же и минус - никакой динамики, никакой логики даже на ранних этапах, нет инвалидации кеша (есть плагины-хелперы, но там свои нюансы).

Игорь Воротнёв, я на дев сервере его настроил по инструкции, вроде все гуд, поставил инвалидацию кеша в 1 минуту, все прям летает. Счетчик просмотра у статей не крутится, но через минуту обновляется как положено. Интересно, как он ведет себя с корзиной WooCommerce?

EvgenyMorozov,

все прям летает

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

Счетчик просмотра у статей не крутится, но через минуту обновляется как положено.

Так и должно быть. Он закешировал страницу в статический html, с определенным значением на счетчике. Через минуту, когда кеш перегенерируется, значение будет обновлено. Разумеется, если счетчик просмотров на js/ajax. Если он на PHP - то до него запросы не будут доходить, он будет считать только cache miss, то есть 1 просмотр в минуту.

Интересно, как он ведет себя с корзиной WooCommerce?

В принципе, он по умолчанию не будет работать с корзиной, ибо корзина динамична. Он закеширует корзину в том виде, в котором она будет по состоянию на первый cache miss. Это может быть чья-то корзина с товаром в ней. Так работает full page cache. Для обхода этих ограничений есть 2 пути:
1. Не кешировать запросы с куками, параметрами в get и тд - пропускать их на PHP и обрабатывать как динамику.
2. Динамические элементы переписывать на js/ajax. Тогда вся страница будет одинаковой для всех статикой, а там где динамические данные (та же корзина) - там скрипт подтянет динамически с сервера.