Wordpress для маркетологов или почему он не потянет серьезные проекты.

Устойчивость к кибератакам, к ботам и тд определяется: 
- админом хостинга или сервера в первую очередь
- настройками движка во вторую очередь.

Если иметь ввиду настройки WP:
- закрываем полностью доступ по IP к wp-admin, wp-login
- закрываем доступ полностью к исполняемым файлам wp-includes
- запрещаем исполнение файлов из директории где храним изображения
- запрещаем изменение файлов шаблона в wp-config
- запрещаем вывод ошибок в wp-config

У меня стоит запрет и на обновление, обновляю в ручном режиме раз в год. Но, при этом, настроена основная  защита по параметрам на сервере

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

Утрированно - ты можешь использовать любой двиг, не он определяет производительность.
Т.е в  90% случаев, при проектировании сайтов, можно спокойно ставить WP

Но используя тот же WP, если вы не настроили архитектуру сайта, он проигрывает всяким парсерам, которые у вас тянут контент. Поэтому  вы и проигрываете гонку в ПС. Но в данном случае, если вы спроектируете на более быстром двиге, все равно проиграете. 
Т.е не двиг определяет производительность сайта, а вы...

и правильная защита от ботов, в основном от бота Google

Почему тогда вбрасывается мнение что вордпрес только для простеньких сайтов?

Я раньше считал что там где два сеошника там три мнения, но в диспутах по программам почему нет консенсуса?

Вам зачем это, вы зачем в этой теме? Если вы не работаете с нагруженными сайтами, если вы даже не понимаете о чем речь? 

Ну и  любой вброс, любой совет и тд, всегда проверяйте на практике, прежде чем его использовать.
Мое мнение тоже🤣

PS По вопросу устойчивости к атакам, вам ответил конкретно по пунктам, изучайте, проверяйте на практике, применяйте. Ну и ИИ вам распишет более подробно как применить по этим пунктам.

К примеру,  два мнения для коммерческий сайтов:
Яндекс карты влияют на позиции сайта в выдаче? 
- Да
- Нет

Оба ответа правильные. Вы можете оба мнения проверить только на практике, и получить свой ответ.

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

Если ты не заметил - изначально разговор и шел про реальное время ответа сервера /сайта с  ВП против фреймворка. Твои кастомные заголовки никому не интересны - они ничего не показывают. 
Более того, я про кэширование писал несколько раз, но ты не смог прочитать. В твоем случае Claudflare работает именно как CDN. По итогу пользователь даже не доходит до ВП - ему отдается чистая статика - и об этом я говорил. А так же о том что вы этом случае можно забыть про динамический сайт, любой нормальный интерактив с пользователем. Решение для инфо, контентников а не для сервисов. Учи матчасть.

Не совсем так. При осмысленном подходе не все ж так "прямолинейно". У нас же не только черное/белое.

Даже если так что с того? Или ты рассматриваешь какие то очень узкие вопросы по отдельности, а не "подходит ли ВП конкретному проекту в целом"?

Совсем так.  Если на странице интерактив и ее содержимое будет меняться, например в зависимости от ответов пользователя. Как ты это будешь брать из статики? Такие страницы будут работать напрямую с ВП уже и тут во всей красе приедут его недостатки с ядром, ненужными плагинами и прочими плюшками. 

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

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

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

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

Вполне рабочее решение (существующее) отдаем статично страницу, а потом хоть отдельные элементы (которые протухли) обновляем.  Самое главное если это осмысленно принятое решение, а не уровня "в среднем по больнице это плохо(или хорошо) - значит не применяем (или применяем)".

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

Ты говоришь "ВП тормозит". И чё?   Можно было бы и попробовать опровергнуть, но как минимум надо внятые критерии иметь. Тормозит по сравнению с чем? (только не нужны адекватные сравнения, а не FastAPI - который абсолютно другой инструмент и для других целей)

Тормозит на каких задачах?

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

Поясни предлагаемый на замену вариант. Тормознутость есть смысл анализировать в сравнении. Ну и так же уточнение: остальные критерии по которым обычно выбирают инструменты тоже откидывать?

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

Для начала немного в сторону. Раз уж с первого поста фигурировало "Напишу в сравнении с FastAPI" то меня заинтересовало сравнение этого инструмента с миром PHP (именно с аналогичными инструментами). Сам проводить бенчи поленился (да я и не работал с этими инструментами - велик шанс накосячить и получить не очень корректные результаты) - спросил у ИИ собрать инфу:

FastAPI (Python + uvicorn): ~30,000-50,000 req/sec

PHP (Plain): ~80,000-120,000 req/sec

PHP + RoadRunner: ~150,000-200,000 req/sec

PHP + Swoole: ~180,000-250,000 req/sec

PHP + FrankenPHP: ~160,000-220,000 req/sec

Еще 

Simple JSON endpoint:

- FastAPI + uvicorn:     ~45,000 req/sec

- PHP 8.3 + FPM:         ~95,000 req/sec  

- PHP 8.3 + RoadRunner:  ~180,000 req/sec

- PHP 8.3 + Swoole:      ~210,000 req/sec

Database query endpoint:

- FastAPI + asyncpg:     ~8,000 req/sec

- PHP + PDO + FPM:       ~12,000 req/sec

- PHP + PDO + RoadRunner: ~25,000 req/sec

Т.е. просадка хорошая получается от запросов в БД и методы решения примерно одни и теже в этом плане. Не зависимо от инструмента. Если же для нас важна исключительно производительность - то как бы стоит оставаться в стане PHP.   

Возвращаясь к тормознутости ВП - допускаю, что  он генерит на старте много запросов в БД.  

Ну и ИИ про него нашел такое:

• Обычный WordPress: ~50-200 req/sec (зависит от плагинов)
• WordPress + Object Cache: ~300-500 req/sec
• Headless WordPress + отдельный API на RoadRunner: ~10,000+ req/sec

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

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