Headless CMS: попробовал Strapi и вернулся к WordPress

Термин «Headless CMS» я впервые услышал года два назад и подумал — очередная модная фигня для стартапов. Мол, отделяем бэкенд от фронтенда, API, микросервисы… У меня обычный блог на WordPress, зачем мне это?

Но в этом году я таки влез в эту тему. Знаете почему? Меня бесила скорость админки WordPress. Панель грузилась по 4-5 секунд, редактор Гутенберг тормозил, а плагины для кеширования только усугубляли ситуацию. Я начал гуглить альтернативы и наткнулся на Strapi и Directus.

Что я понял про Headless CMS

Поставил Strapi на тестовый сервер (VPS 2 ядра, 4GB RAM). Развернул за 10 минут через Docker. Админка — просто космос. Летает, React интерфейс, никаких тормозов. Контент создаётся через удобные формы, а на фронтенд данные отдаются через REST API или GraphQL. Всё чётко и быстро.

Но тут началось интересное. Для Headless CMS нужен отдельный фронтенд. Next.js, Nuxt, или хотя бы простой HTML + JS. Я попробовал Next.js — и выпал в осадок. Настроить роутинг, SSG, ISR, деплой на Vercel… Это не для блога, где я хочу просто писать тексты. Это для команды разработчиков.

WordPress в этом плане — монолит, который работает из коробки. Написал пост, нажал опубликовать — и он уже на сайте. Не надо собирать проект, деплоить, инвалидировать кеш.

Когда Headless CMS реально нужен

Я сделал вывод: если у вас несколько фронтендов (сайт, мобильное приложение, киоск) — Headless CMS рулит. Один бэкенд отдаёт данные куда угодно. Если сайт с высокой нагрузкой и SEO критично — Next.js + Headless дают отличную скорость.

Если же вы просто ведёте блог на WordPress — забейте. Разница в производительности не стоит тех танцев с бубном, которые придётся сделать. У меня на mysurik.ru WordPress грузится за 0.13с, и это без всякого Headless.

Вариант компромисса: использовать WordPress как Headless через WP REST API, а фронтенд на чём-то лёгком. Некоторые так делают, но лично мне проще оставить классику.

Итог

Headless CMS — крутая технология для сложных проектов. Для блога — оверкилл. Я потратил неделю на эксперименты и вернулся к обычному WordPress. Но опыт полезный — теперь хотя бы понимаю, о чём говорят разработчики на митапах.

Расскажу эту историю целиком, потому что моё знакомство с Headless CMS получилось неожиданно насыщенным. Неделя экспериментов, куча нового опыта и чёткое понимание, где эта технология нужна, а где — нет. Надеюсь, мой опыт поможет тебе сэкономить время на собственных экспериментах.

Всё началось с раздражения. WordPress у меня был быстрым на стороне посетителей — сайт грузился за долю секунды. Но админка! Панель управления грузилась по четыре-пять секунд, редактор Гутенберг подтормаживал, а попытки ускорить её плагинами только добавляли хаоса. Я начал искать альтернативы и наткнулся на разговоры про Headless CMS: мол, отделяешь бэкенд от фронтенда, контент живёт в API, а фронтенд — это отдельное приложение. Сначала я отнёсся к этому скептически, как к очередному модному тренду, но раздражение взяло верх, и я решил попробовать.

Выбор пал на Strapi. Почему именно он? Он популярный, у него хорошая документация, и он разворачивается через Docker за пару минут. Я поднял его на тестовом сервере — VPS на два ядра и четыре гигабайта памяти. Развернул за десять минут через Docker Compose, и первое впечатление было отличным. Админка Strapi — просто космос по сравнению с WordPress. Летает, React-интерфейс, никаких тормозов. Контент создаётся через удобные формы с настраиваемыми полями, а наружу данные отдаются через REST API или GraphQL. Всё чётко, быстро, современно.

Первое время я даже подумывал перевести блог на Strapi. Создал типы контента под статьи, настроил поля, поигрался с GraphQL. Ощущение, что я в будущем: контент отдельно, интерфейс отдельно, всё через API. Но потом началась другая часть — фронтенд. И вот тут-то и всплыла вся «плата» за современность.

Для Headless CMS нужен отдельный фронтенд. Нельзя просто «написать пост и увидеть его на сайте» — нужно приложение, которое тянет контент из API и рендерит его. Я попробовал Next.js, потому что это стандартный выбор для таких задач. И вот тут я выпал в осадок от сложности. Настроить роутинг, понять SSG и ISR, разобраться с деплоем на Vercel, прикрутить перегенерацию страниц при изменении контента — это целая вселенная. Для команды разработчиков это нормально, но для человека, который просто хочет писать тексты в блог, это катастрофический оверкилл.

Сравнение вышло наглядное. В WordPress я пишу пост, нажимаю «Опубликовать» — и он уже на сайте. Всё. Никакой сборки, деплоя, инвалидации кеша. В Headless-схеме каждое обновление контента — это цепочка: изменил в Strapi, фронтенд должен пересобрать страницу или дёрнуть ISR, потом задеплоить. И это надо всё настраивать, следить, чинить. Я неделю потратил на эксперименты и понял: для блога это не ускорение, а усложнение.

Теперь про то, где Headless CMS действительно рулит. Я сделал для себя несколько выводов, которые, надеюсь, будут полезны и тебе. Первый: если у тебя несколько фронтендов — сайт, мобильное приложение, киоск, — Headless CMS идеален. Один бэкенд отдаёт контент куда угодно, и все платформы используют один источник данных. Это именно тот сценарий, ради которого технологию и создавали. Если у тебя один сайт — преимущество не работает.

Второй вывод: высокая нагрузка и критичный SEO. Связка Next.js с генерацией статики и Headless-бэкендом может дать отличную скорость и хорошие позиции. Но за это платишь сложностью инфраструктуры. Если сайт реально набирает миллионы просмотров — это оправдано. Для сайта с тысячным трафиком разница не стоит тех танцев с бубном, которые придётся сделать. Тут важно честно оценить свой масштаб, а не «понадеяться на рост».

Третий вывод — про кеширование и производительность. Мой WordPress на mysurik.ru грузится за 0.13 секунды, и это без всякого Headless. Просто нормальная настройка кеша и оптимизация. То есть тезис «Headless быстрее» не работает автоматически. Классический WordPress с правильными настройками может быть очень быстрым. Те, кто жалуется на тормоза WordPress, обычно не оптимизировали его как следует. Это важный момент: сначала выжми всё из того, что у тебя есть, а потом думай о смене архитектуры.

Четвёртый вывод — про компромиссный вариант. Есть возможность использовать WordPress как Headless: контент живёт в WordPress, а фронтенд — отдельное приложение, которое тянет данные через WP REST API. Некоторые так и делают: берут удобную админку WordPress и быстрый современный фронтенд. Это рабочий вариант для тех, кто хочет попробовать Headless-подход, не уходя от знакомой экосистемы. Но лично мне проще остаться на классике — для моего сценария это меньше всего боли.

Ещё один важный момент, который я вынес из эксперимента — это ценность готового решения. WordPress — это не только движок, но и целая экосистема: темы, плагины, хостинги, поддержка. Когда я развернул Strapi, я получил чистый бэкенд без фронтенда — а значит, без готовых тем, без плагинов под вёрстку, без всего, что WordPress даёт из коробки. Для сложных проектов это свобода, а для простых — лишняя работа. Не забывай считать не только скорость, но и стоимость владения.

Про то, чему я научился за эту неделю, скажу отдельно. Даже «провальный» эксперимент — это ценный опыт. Я теперь понимаю, как устроены Headless-системы, что такое REST API и GraphQL на практике, как работает Next.js. Это позволило мне лучше понимать, о чём говорят разработчики, и принимать более осознанные решения по своему проекту. Знания не пропали зря, даже если инструмент я не использую.

Что бы я посоветовал тому, кто тоже подумывает про Headless CMS. Сначала честно ответь себе на вопросы: сколько у тебя фронтендов? Какой трафик? Есть ли команда разработчиков? Если ответы «один сайт, небольшой трафик, я один» — Headless тебе не нужен, и это нормально. Не гонись за модой: выбирай инструмент под задачу. Если же задача реально требует нескольких фронтендов или огромного масштаба — тогда Headless оправдан, и Strapi или аналог станут хорошей основой.

Подведу итог. Headless CMS — это мощная и правильная технология для сложных проектов. Для блога — это оверкилл, и я в этом убедился на своём опыте. Я потратил неделю на эксперименты, вернулся к классическому WordPress и ни разу не пожалел. Но это была полезная неделя: я понял границы технологии и теперь уверенно говорю, где ей место, а где нет. Если твоя задача — просто вести блог — оставайся на классике и выжимай максимум из оптимизации. А Headless прибереги для того дня, когда он действительно понадобится.

Добавлю ещё несколько практических деталей из эксперимента, которые могут пригодиться. Первое — про ресурсы. Strapi на Node.js ест память заметно больше, чем WordPress на PHP. На моём тестовом VPS с четырьмя гигабайтами он жил нормально, но для продакшена я бы закладывал ресурсы с запасом. Если у тебя бюджетный сервер — учти, что Headless-стек с фронтендом на Next.js может потребовать в несколько раз больше памяти, чем классический WordPress.

Второе — про медиафайлы. В WordPress работа с картинками продумана: загрузил, обрезал, добавил в пост. В Strapi медиа — это отдельная сущность, и её интеграция с фронтендом требует настройки. Мне пришлось разбираться, как хранить и отдавать изображения, как подключать их к статьям. Это лишняя работа, которая в WordPress решается сама собой. Для блога с постоянным потоком картинок это заметный минус.

Третье — про обновления и поддержку. WordPress обновляется одним кликом, и у него огромное комьюнити. Strapi тоже развивается, но это моложе и специфичнее: обновления требуют внимания, а ответы на нестандартные вопросы в интернете встречаются реже. Для меня как для человека, который любит «поставил и забыл», это было существенное отличие в пользу WordPress.

И четвёртое — не думай, что я совсем против Headless. Для пет-проекта с командой или для сервиса, где контент должен идти в несколько мест, — это отличный выбор. Просто для конкретно моей задачи — одиночного блога — он не подошёл. Оценивай инструмент под свою задачу, а не наоборот. Это, пожалуй, главный урок всей моей недели экспериментов.