Сравнение WordPress и FSE с акцентом на технические аспекты и ограничения - Курилка

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

Sly32 · 2026-06-04T19:39:34.0000000Z

По мотивам спора собрал краткую шпаргалку фанатам Wordpress . Возможно прочитаете и уже угомонитесь пихать его всюду. Напишу в сравнении со своим любимым FastApi. И даже начну с его плюсов. WordPress (и FSE в частности) выигрывает там, где сайтом будут управлять не-программисты, и где скорость запуска и гибкость редактирования важнее, чем чистая производительность «из коробки». Главный плюс - простое управление контентом и админка из коробки. Плюсом добавлю неплохую экосистему : SEO-оптимизация, мультиязычность, интеграция со службами доставки, прием платежей в WordPress это ставится в два клика. В FastAPI все это нужно кодить и поддерживать самостоятельно. На этом с плюсами все. Если хотите хорошее приложение - ВП не ваш путь, почему? 1. Время ответа сервера (TTFB) FastAPI + Jinja: FastAPI написан на Python с использованием асинхронности (ASGI) и библиотеки Starlette. Он компилирует шаблоны Jinja в память практически мгновенно. Время ответа сервера (TTFB) на пустой странице составляет 25 миллисекунд . WordPress (FSE): Даже с самым быстрым FSE, WordPress это тяжелая монолитная система на синхронном PHP. При каждом запросе (без плагинов кэширования) движок инициализирует ядро, проверяет права пользователя, подгружает хуки, плагины и только потом парсит FSE-блоки. Время ответа сервера составит в лучшем случае 100350 миллисекунд . Это в 50100 раз медленнее, чем FastAPI. 2. Работа с базой данных FastAPI + Jinja: Вы сами полностью контролируете базу через ORM (например, SQLAlchemy) или чистый SQL. Если вам нужно вывести страницу, вы делаете строго 12 оптимизированных запроса в конкретные таблицы. WordPress: Под капотом у WordPress находится старая реляционная структура, спроектированная более 20 лет назад. Даже для вывода простой страницы FSE-темы «голый» WordPress делает от 20 до 50 запросов в БД (настройка опций, проверка локализации, проверка канонических URL, получение меню, мета-полей и т.д.). Да, FSE склеивает шаблон за один запрос, но общее число запросов самого движка остается большим. 3. Потребление памяти (RAM) FastAPI: Асинхронное приложение держится в памяти постоянно (внутри Uvicorn/Gunicorn). Ему не нужно инициализироваться заново для каждого посетителя. Потребление ресурсов минимально. WordPress: Для каждого нового посетителя запускается отдельный изолированный PHP-процесс, который с нуля поднимает весь WordPress в памяти (съедая от 30 до 90 МБ RAM на один чих), выполняет скрипт и умирает. При высокой нагрузке без кэширования сервер быстро упрется в лимиты процессора и памяти. Стек FastAPI дает фундаментальные преимущества, которые WordPress не сможет перекрыть архитектурно: Асинхронность из коробки: async/await позволяет FastAPI обрабатывать тысячи конкурентных запросов на одном ядре процессора, пока WordPress блокирует PHP-процесс на каждом тяжелом действии. Гибкость работы с данными: FastAPI идеально дружит с NoSQL (MongoDB, Couchbase) и Redis на уровне нативных асинхронных драйверов. WordPress намертво привязан к старой реляционной структуре MySQL с ее тяжелыми JOIN-запросами и таблицей wp_posts , где всё свалено в кучу. Скорость шаблонизации: Компиляция шаблонов Jinja2 на Python происходит в разы быстрее, чем парсинг HTML-комментариев FSE внутри PHP. Арбнет - ты теперь понимаешь, почему твоя идея с парсингом страницы из тэгов - тупик? WordPress FSE «ляжет» там, где FastAPI даже не заметит нагрузки: 4. Архитектура процессов (Конкурентность) В WordPress: Модель «один запрос один синхронный процесс OS/PHP-FPM». Если у вас 8-ядерный процессор и пул в 50 воркеров PHP, то 51-й одновременный пользователь встанет в очередь. Если в этот момент пойдет тяжелый запрос к БД (например, поиск по мета-полям через FSE-блок), весь воркер заблокируется. В FastAPI: Асинхронный event loop (через uvicorn / gunicorn ). Пока приложение ждет ответа от базы данных или внешнего API, поток мгновенно переключается на обработку сотен других сетевых запросов. На том же железе FastAPI держит на порядок больше RPS. 5. Мусорная структура БД и "EAV" (Entity-Attribute-Value) Самый главный тормоз WordPress при нагрузках это структура данных: Все сущности (страницы, посты, медиафайлы, а теперь и FSE-шаблоны , и части шаблонов) лежат в одной гигантской таблице wp_posts . Все их свойства, мета-поля, кастомные атрибуты лежат в wp_postmeta . Чтобы выстроить сложную динамическую страницу, WP вынужден делать тяжелейшие JOIN запросы к одной и той же таблице wp_postmeta . Индексировать это под высокую нагрузку ад для DBA. В FastAPI вы проектируете чистые нормализованные таблицы в PostgreSQL или используете нативный асинхронный драйвер для MongoDB, где данные лежат в оптимальном для чтения виде. 6. Накладные расходы на инициализацию (Bootstrap) Даже если FSE-шаблон скомпилирован идеально, перед его сборкой WordPress выполняет гигантский процесс инициализации: Подключает сотни файлов ядра. Запускает десятки плагинов (каждый из которых вешает свои хуки и фильтры через add_action ). Проверяет права, сессии, таксономии. Этот "bootstrap" происходит на каждый чих пользователя. FastAPI запускается один раз в память при старте сервера, выполняет роутинг по хэш-таблице за микросекунды и сразу переходит к бизнес-логике. Как-то так. Для подготовки ответа, структуризации использовался Джемини, я не писатель. Есть желающие предметно поспорить?

144

master32

19 августа 2026, 16:09

#291

Сергей про е-ком #:

https://pagespeed.web.dev/analysis/https-ecomsite-ru-uslugi-semantika-rasshirennoe-semanticheskoe-yadro/pjc4io9tk2?form_factor=mobile

Прикола для вчера посидел часик. ВП, просто немного оптимизированный без обрезки ядра.

по идее для статического сайта можно совсем не трогать ВП, решается добавлением пары строчек в nginx, HIT/MISS)

392

Сергей про е-ком

19 августа 2026, 17:08

#292

master32 #:
по идее для статического сайта можно совсем не трогать ВП, решается добавлением пары строчек в nginx, HIT/MISS)

В том и интерес задачи. Вообще, на простом классическом WP это и так можно было сделать, но тут - FSE тема и желание сохранить интеграцию без кодовой визуализации всех элементов, которые живут в типа json. Хотя это тоже было ошибкой, мог создать нормальную таблицу стилей для проекта и доделывать лишь уникальные атомы, но это такое себе удовольствие и расширяет работу на пайплайном не давая бизнес-выгод.

1

https://ecomsite.ru/ - аутсорс сложных задач для SEO\SERM агентств и крупных команд, AI-автоматизация.

Cms Битрикс - оформление Поиск плагина для тегов Бот для генерации контента

151

Анти БОТ

19 августа 2026, 20:46

#293

Sly32 #:
Зачем ты разоряешь своих клиентов?

Это слишком дешевое (на уровне ясельной группы) отзеркаливание для "серьезного" кекса, для которого ВП это несерьезно (на нём не попилишь).

Защита сайта от поведенческих ботов, фильтрация ботов для Яндекс Директ - https://antibot24.ru

136

softerra

20 августа 2026, 08:09

#294

Сергей про е-ком #:

https://pagespeed.web.dev/analysis/https-ecomsite-ru-uslugi-semantika-rasshirennoe-semanticheskoe-yadro/pjc4io9tk2?form_factor=mobile

Прикола для вчера посидел часик. ВП, просто немного оптимизированный без обрезки ядра.

Страница пустая (медийного контента нет). Она должна показывать 101%. Зато главная жужжит, там бегущая строка процессор будоражит. Бегущая строка на сайтах - это дурь та еще ..

2

Маркетинг для шоколадной фабрики. На 34% выше средний чек

VK приобрела 70% в структуре компании-разработчика red_mad_robot

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