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

Question

[lukoie]

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

Answer 1

[Игорь Воротнёв]

Ох, опять эта тема :)

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

Далее, давайте мухи отдельно и котлеты отдельно. Есть object cache - у него свои задачи. Есть fragment cache - у него свои. Есть full page cache - это отдельная кухня. Есть кеширование на уровне сервера (nginx fastcgi_cache), все тот же full page cache но "навыворот". А еще Nginx умеет разговаривать с Memcached напрямую. И даже если сравнивать решения, которые делают одно и то же (например, тот же full page cache), разница в "эффекте" на разных серверах и даже на разных сайтах на одном сервере будет. Часто - существенная. Плюс, есть кеширование на многих уровнях на самом сервере - файловая система, кеши БД и тд. И все эти настройки будут влиять на поведение плагинов кеширования. Часто - существенно. Кеширование на стороне клиента - отдельная кухня, начиная с server push, prefetch и тд, выдача поддерживаемых форматов (brotli/gzip, woff/woff2/ttf, webp/jpg/png и тому подобное).

В общем, performance - это целый комплекс мер, решений и инструментов. Подходить к этому надо с умом и четким планом, полным пониманием всего процесса от инициации запроса клиентом и до... а нету точки Б, потому что там свои моменты.

А еще надо понимать, что ваш медленный DNS может убить всю экономию на PHP runtime. Или криво установленный SSL-сертификат. Или кеширование SSL-сессий, некорректно настроенное под специфику трафика конкретного проекта. Или канал на выходе перегруженный. Или далеко не оптимальный конфиг пула PHP. Или вообще Apache. Или I/O wait зашкаливает.

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

И еще. Силы надо тратить на то, чтобы динамический сайт был быстрым. То есть, без плагинов кеширования вообще. Если сайт у вас тупит, то попытка замаскировать это сверху плагином кеширования - не самое разумное решение. Временное - да, возможно. Но не решает проблему.

Answer 2

[lamer350]

nginx + php 7.3 + OPcache + MariaDB
и никакие плагины не нужны

Comments

[lukoie]

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

[lamer350]

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

[lamer350]

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

[Sanes]

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

[Игорь Воротнёв]

lamer350,

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

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

[lamer350]

Игорь Воротнёв, я о реализации, это э отдельный форк от 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. Но это прирост в небольших процентах, точечно. Дает ли это ощутимый результат? Да, на больших данных. Да, на высонагруженных проектах. Есть ли заметный прирост в стоке на локальной машине на голой базе? Нет, и быть его не может. Если он у вас есть - значит вопрос в дефолтной конфигурации, не более.

[lamer350]

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

[lamer350]

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

[Леонид]

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

[lamer350]

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

[lukoie]

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

[lamer350]

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, в первую очередь, быстрее и использует меньше памяти. Если углубляться, то есть еще тележка фич.

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

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

Answer 3

[EvgenyMorozov]

Сам использую WP Rocket.
Вот достаточно свежий обзор https://habr.com/ru/post/426835/

Comments

[Вова Дружаев]

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

[Игорь Воротнёв]

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

[EvgenyMorozov]

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

[Игорь Воротнёв]

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

[Игорь Воротнёв]

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

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

[EvgenyMorozov]

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

[lukoie]

Игорь Воротнёв, уважаемый Игорь, спасибо за ответ.
Абсолютное большинство сайтиков на ВП это ГС, личные бложики или вукоммерс магазинчики. Комплекс мер для таких сайтов зачастую не проводят, потому что это затратно, и результат от дотягивания будет не адекватным затраченному времени и финансам. Потому таким сайтам с головой хватает обычного условного 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, где все это уже есть из коробки. Минимум настроек и головной боли, максимум эффекта. Все остальное можно не трогать и не экспериментировать.

[lukoie]

Игорь Воротнёв, спасибо. но обоснуйте почему не трогать, к примеру, 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. Вопрос - зачем их использовать, если есть проверенные, быстрые, эффективные плагины без всего этого мусора?

[lukoie]

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

[EvgenyMorozov]

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

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

[Игорь Воротнёв]

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

[EvgenyMorozov]

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

[Игорь Воротнёв]

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

[EvgenyMorozov]

Игорь Воротнёв, я на дев сервере его настроил по инструкции, вроде все гуд, поставил инвалидацию кеша в 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. Тогда вся страница будет одинаковой для всех статикой, а там где динамические данные (та же корзина) - там скрипт подтянет динамически с сервера.

Answer 4

[Vladimir Zp]

Давно работаю с wordpress и не очень понимаю, чем могут принципиально отличаться плагины кэширования. Я всегда использую WP Super Cache. Он создает статичные html страницы, я их напрямую отдаю через nginx. Мне кажется, это максимальное быстродействие.

Comments

[lukoie]

вот и я давно, и я не понимал. Но начал понемногу узнавать что таки отличаются, потому и спросил тут, может кто уже изучал тему.
По факту, можете посмотреть вот такой обзор: https://www.s-sols.com/wordpress-site-response-tim...

Также они отличаются, к примеру, возможностью удобно обнулить кеш, минифицировать/загзипить всё самостоятельно, сделать сервеный И браузерный кеш. Удобно устанавливать время жизни кеша. Ну и т.п. Отличаются они, отличаются.
Вот лайтспид, к примеру, у меня на хостинге выругался что хочет какой-то модуль установленный в пхп(я пока не лез ковырять какой и зачем, но вроде у них есть свой сервак, так что он не даст преимущества на ВП в обычном шаред хостинге).

На странице лайтспид кеша также есть такой графичек сравнения:

Сами найдите свой плагин.

ЗЫЖ я пока пользуюсь Breeze, пока только потому что он в обзоре второй после лайтспида. Всю жизнь был на W3 Total Cache, и тоже считал что от добра добра не ищут, и что все плагины одинаковые. Теперь я так не считаю.

[Vladimir Zp]

lukoie, так вы все в кучу смешали, как в той статье, на которую ссылаетесь - кэширование, оптимизация, объединение и минификация html, js, css, сжатие и т.д. Это все разные вещи. Оптимизация кода, js, css не имеют к кэшированию никакого отношения. Этим надо отдельно заниматься и желательно вручную, если хочется получить хорошую скорость начала рендеринга страницы. Нужно проследить и оптимизировать критичные для начального рендеринга страницы элементы, поместить их в самое начало загрузки тем или иным способом (включение в html, server push и т.д.).

Кэширование это другой процесс. Я все же убежден, что наиболее быстрый и эффективный способ кэширования - создание статических файлов и отдача их напрямую через nginx, вообще минуя ядро wordpress и php. Это умеет делать платный плагин MaxCache, это умеет WP Super Cache в режиме работы Эксперт. Возможно какие-то еще плагины, я не проверял. Как какой-то другой плагин может что-то еще ускорить, если отдача статики через nginx это и так максимальное быстродействие, на которое можно рассчитывать.

[lukoie]

Vladimir Zp, долго объяснять, просто ставьте лайк

[Игорь Воротнёв]

lukoie,

По факту, можете посмотреть вот такой обзор: https://www.s-sols.com/wordpress-site-response-tim...

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

[lukoie]

Игорь Воротнёв, спасибо, удалил. Системник выдернул из розетки,
клавиатуру продизенфицировал, монитор спалил.

[Игорь Воротнёв]

lukoie, вот монитор - зря! :)
а если по делу - в другой ветке комментов просили "обосновать" это мое утверждение про ту статью, завтра будет немного времени - напишу обоснование.

Answer 5

[Дмитрий]

ставь WP Super Cache
для ленивого новичка само то - минимум настроек и работает

Comments

[lukoie]

чувак, я с ВП работаю уже лет 15, с момента его появления
так что ни "ленивый" ни "новичок" ко мне аж никак не применимо
судя по комментарию, видимо тебя он устраивает, ну и хорошо
удачи, и спасибо за комментарий
я ожидаю более адекватных ответов, уж прости

[Дмитрий]

lukoie, ну если ты работаешь 15 лет и совсем не новичок, ты же понимаешь, что в разных условиях более оптимальным будут разные плагины?
и чтоб ожидать более оптимальных ответов стоит научится хоть немного, но конкретизировать вопросы?
типо: "у меня nginx+memcached+хочу шардить базу", или "у меня мультисайт и шаред хостинг", или "купленный премиум шаблон на выделенном серваке" или еще что другое.

но вообще как-то странно, 15 лет работать с WP и только сейчас осознать нужду в плагинах кэширования.

[lukoie]

Дмитрий, с чего ты решил будто я "только сейчас осознал нужду"? Я использую обычно разные связки, зачастую это кеширование языковых запросов, кеш бд и обычный w3 тотал кеш.
В то же время, множество плагинов для кеширования как бы намекает что их авторы пытаются не только конкурировать, и но придумывают какие-то новые финты, которые вполне можно было бы назвать киллер-фичей, почему Х лучше чем У в таких-то ситуациях, например при использовании мультиязычности, или пейджбилдеров, или еще как то.
К примеру, в теории они могут сами собирать жс и цсс в один файл, гзипить, сидиэнить всякие либы, и т.п.

Вот например, сейчас на проекте будет fastest cache
И мне придется самому проводить исследование чем он лучше чем, например, лайтспид кеш.

[lukoie]

Вот например как Лайтспид Кеш показывает на графичке что они лучше остальных.

[lamer350]

lukoie, ну с такой точки зрения если смотреть - то только тестить все индивидуально! Выше я писал комментарий исходя из своего опыта, сборкой всего фронта у меня занимается бранч, gzip генерит сервер сам исходя из изначальных настроек, opcache перезаписывается при синхронизации файлов с помощью трансмита и просто bash скрипта. Для меня это намного удобнее всех плагинов хотя бы потому что не нужно каждый раз сбрасывать кеш вручную. Тоисть я раз потратил время для настройки все под себя и так работаю, если конечно вы хотите управлять всем с помощью какого то интерфейса, чтобы не ковырять настройки сервера - то все нужно тестить, например на разных серверах эти плагины могут выдавать разные результаты. Потому я всегда заказчикам рекомендую хостинг либо беру голы сервер и ставлю все с нуля ибо в остальных случаях все может работать не так как хочется)