Сейчас держит еще хотяб минут 15?
По факту, можете посмотреть вот такой обзор: https://www.s-sols.com/wordpress-site-response-tim...
более идиотской связки придумать сложно.
Это вообще к чему ответ?
nginx + php 7.3 + OPcache + MariaDB? --- почему не апач+муСКЛ?
Почему за такие ответы не банят.?
Очень важная составляющая в этой связке это MariaDB, так как по сравнению с mySQL innoDB в разы быстрее работает.
1. Breeze - сделан компанией Cloudways, в первую очередь под свои нужды. Например, тот же Varnish, которого с вероятностью 99.99% не будет у вашего предполагаемого блогера. Цитата, их же словами:
Исключения, кстати, в конфиг 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. Вопрос - зачем их использовать, если есть проверенные, быстрые, эффективные плагины без всего этого мусора?