Разработка кастомной темы Ghost на Handlebars под ключ

Представьте: ваш медиаблог на Ghost тормозит при 5000 постах, страницы загружаются по 4 секунды, а Google считает LCP 4.2с. Типичная картина для тем, где Handlebars-шаблоны используют вложенные {{#get}} запросы без кэширования и не оптимизированы изображения. Мы решаем эту проблему переписыванием темы под Ghost 5 с кастомными настройками и правильным кэшированием.

В отличие от WordPress, Handlebars в Ghost не выполняет произвольный код, а только вызывает встроенные хелперы. Это плюс для безопасности, но минус для производительности, если не знать тонкостей. Наша команда с многолетним опытом разработки на Ghost (30+ проектов) создает темы, которые проходят gscan без предупреждений и набирают 90+ в Lighthouse. Расскажем, как это работает.

Проблемы, которые решаем

N+1 запросы через {{#get}}. Частая ошибка — получать данные для каждого поста отдельным запросом. Решение — использовать eager loading через параметр include в главном запросе, либо выносить данные в partials с мемоизацией.

Отсутствие адаптивных изображений. Без img_url с size и srcset тема грузит полные оригиналы: 3000px на мобильном. Это резко увеличивает LCP и CLS. Правильный подход — задать image_sizes в package.json и строить srcset для каждого изображения.

Пренебрежение кастомными настройками. Многие разработчики жёстко кодируют стили и функционал, которые редактор мог бы менять через Admin. Используем @custom в конфиге — это даёт контроль редактору без деплоя.

Как Handlebars влияет на производительность Ghost?

Handlebars позволяет создавать безопасные шаблоны без риска RCE, свойственного PHP-движкам. Ghost в версии 5.0+ стабильно поддерживает все хелперы для построения сложных интерфейсов: от пейджинга до Members. По сравнению с Nunjucks, Handlebars — родной язык, который даёт максимум контроля при минимуме возможностей для ошибки. Он в 2 раза быстрее, чем PHP-шаблонизаторы в WordPress, при равной нагрузке, благодаря отсутствию накладных расходов на выполнение кода.

Как мы это делаем: кейс оптимизации медиаблога

Клиент — медиа с 5000+ постов, тема на старом Bootstrap, LCP 4.2с, INP — 300ms. Задачи: сохранить дизайн, улучшить Core Web Vitals, добавить Members для премиум-контента.

Стек: Ghost 5.5, Handlebars, Node.js 18, Nginx, Cloudflare. Полностью переписали структуру шаблонов:

• Заменили вложенные {{#get}} на один запрос с include=tags,authors.
• Настроили image_sizes с четырьмя вариантами и добавили sizes атрибут.
• Внедрили lazy loading для изображений ниже фолда.
• Использовали @custom для выбора цветовой схемы и типа шапки.

Результат: LCP — 1.8с, CLS — 0.05, INP — 100ms. Сайт прошёл gscan без замечаний.

Почему стоит заказать кастомную тему Ghost?

Готовая тема не учитывает специфику контента и аудитории. Только кастомная разработка позволяет полностью контролировать вёрстку, настройки Members и производительность. Мы гарантируем gscan-валидацию и 30 дней поддержки после сдачи.

Процесс работы

1. Аналитика: аудит текущей темы, замер метрик, выявление узких мест.
2. Проектирование: создание макета структуры partials, схемы кастомных настроек, прототипирование Members-потоков.
3. Реализация: написание всех hbs-шаблонов, стилизация, конфигурация package.json, интеграция с Ghost API.
4. Тестирование: валидация gscan, проверка на всех устройствах, профилирование Lighthouse.
5. Деплой: загрузка через Admin или CI/CD, настройка кэширования на Nginx и Cloudflare, мониторинг метрик.

Сроки ориентировочно

Стоимость рассчитывается индивидуально. Оценим проект за 1 день.

Типичные ошибки в темах Ghost

Что входит в работу

• Исходный код темы с комментариями
• Документация по кастомным настройкам
• Настройка Members и Newsletter
• Валидация gscan с нулевыми предупреждениями
• Бесплатная поддержка в течение 30 дней после сдачи

Как реализовать Members-ограничения в кастомной теме?

Добавьте в post.hbs блок проверки доступа. Ghost предоставляет контекст {{#if access}} для платного контента и {{#unless @member}} для гостей. Пример:

{{#post}}
  {{#if access}}
    <div class="premium-content">{{content}}</div>
  {{else}}
    <div class="paywall">
      <h3>Эта статья для подписчиков</h3>
      {{#unless @member}}
        <a href="#/portal/signup">Подписаться</a>
      {{/unless}}
    </div>
  {{/if}}
{{/post}}

Для отображения планов используйте {{#get "tiers"}} и выводите название и цену.

Примеры шаблонов

Основные хелперы на примере index.hbs

{{! index.hbs — список постов}}
{{#foreach posts}}
  <article class="post-card {{post_class}}">
    {{#if feature_image}}
      <figure>
        <img srcset="{{img_url feature_image size="s"}} 300w,
                     {{img_url feature_image size="m"}} 600w,
                     {{img_url feature_image size="l"}} 1000w"
             sizes="(max-width: 768px) 100vw, 50vw"
             src="{{img_url feature_image size="m"}}"
             alt="{{title}} — кастомная тема Ghost">
      </figure>
    {{/if}}
    <div class="post-card-content">
      <header>
        {{#primary_tag}}
          <a href="{{url}}" class="post-tag">{{name}}</a>
        {{/primary_tag}}
        <h2><a href="{{url}}">{{title}}</a></h2>
      </header>
      {{#if excerpt}}
        <p>{{excerpt words="30"}}</p>
      {{/if}}
      <footer>
        {{#primary_author}}
          <img src="{{img_url profile_image size="xs"}}" alt="{{name}}">
          <a href="{{url}}">{{name}}</a>
        {{/primary_author}}
        <time datetime="{{date format="YYYY-MM-DD"}}">
          {{date format="DD MMM YYYY"}}
        </time>
        {{#if @custom.show_reading_time}}
          <span>{{reading_time}}</span>
        {{/if}}
      </footer>
    </div>
  </article>
{{/foreach}}
{{pagination}}

Динамические данные через {{#get}}

{{! Последние посты по тегу}}
{{#get "posts" limit="5" filter="tag:javascript" order="published_at desc"}}
  {{#foreach posts}}
    <a href="{{url}}">{{title}}</a>
  {{/foreach}}
{{/get}}

Обязательные файлы темы

my-theme/
├── package.json
├── index.hbs
├── post.hbs
├── page.hbs
├── error.hbs
├── tag.hbs (опционально)
├── author.hbs (опционально)
├── partials/
│   ├── header.hbs
│   ├── footer.hbs
│   └── post-card.hbs
└── assets/
    ├── css/screen.css
    └── js/main.js

{
  "name": "my-theme",
  "description": "Custom Ghost theme",
  "version": "1.0.0",
  "engines": { "ghost": ">=5.0.0", "ghost-api": "v5" },
  "license": "MIT",
  "config": {
    "posts_per_page": 12,
    "image_sizes": {
      "xs": { "width": 300 },
      "s": { "width": 600 },
      "m": { "width": 1200 },
      "l": { "width": 2000 }
    },
    "card_assets": true,
    "custom": {
      "header_style": {
        "type": "select",
        "options": ["Center", "Left", "Right"],
        "default": "Center"
      },
      "show_reading_time": {
        "type": "boolean",
        "default": true
      }
    }
  }
}

Свяжитесь с нами для оценки проекта. Закажите разработку кастомной темы Ghost — гарантируем качественный код, проходящий gscan без ошибок. Получите консультацию по вашему проекту — мы оценим сложность и сроки за 1 день.

Headless CMS: Strapi, Directus, Sanity, Contentful, Drupal

Традиционная CMS хороша до момента, когда дизайнер говорит «хочу анимацию при скролле с parallax», фронтенд — «нам нужен React», а SEO-специалист — «почему TTFB 3.4 секунды». В этот момент монолитная архитектура начинает мешать всем сразу. Я сталкивался с этим десятки раз: сайт на WordPress с ACF разрастается до 47 плагинов, админка тормозит, а каждый редизайн превращается в переписывание шаблонов.

Headless CMS отделяет управление контентом от его представления. Редакторы работают в удобном интерфейсе, разработчики получают данные через API и строят фронтенд на любом стеке. Звучит просто. На практике — выбор CMS, моделирование данных и настройка API занимают значительную часть проекта. За более чем 7 лет мы провели более 50 внедрений — расскажу, как не наступить на типичные грабли.

Почему headless CMS выгоднее монолита?

Монолитная CMS (WordPress, Joomla, Drupal в классическом режиме) смешивает бэкенд и фронтенд. Любое изменение вёрстки — это изменение шаблонов, часто с риском поломать админку. Headless даёт свободу: фронтенд на React, Vue или Svelte, а контент живёт отдельно. Результат — скорость загрузки (LCP часто падает с 4-6 с до 1-1,5 с), безопасность (нет публичного доступа к админ-панели), масштабирование (контент отдаётся через CDN без нагрузки на сервер). Плюс возможность переиспользовать контент в мобильных приложениях, киосках, email-рассылках через единый API.

Какую headless CMS выбрать под проект?

Нет универсального инструмента. Выбор зависит от команды, сложности контента и инфраструктуры. Разберём ключевые варианты.

Strapi — open-source, self-hosted, Node.js. Подходит командам, которым нужен контроль над данными и возможность кастомизации API. Плагинная архитектура позволяет добавлять кастомные маршруты, middleware, lifecycle hooks. REST и GraphQL из коробки. Разворачивается за час — в 3 раза быстрее Drupal. Слабое место — версии v4 и v5 несовместимы между собой, миграция болезненная. Наш опыт показывает: для стартапов и средних проектов Strapi — оптимальный баланс гибкости и скорости.

Directus — тоже open-source, но другой подход: не генерирует схему, а оборачивает существующую базу данных (PostgreSQL, MySQL, SQLite) в REST/GraphQL API. Если база данных уже есть — Directus подключается к ней без миграций. Удобно для проектов, где данные уже живут в PostgreSQL и нужен быстрый admin UI + API. Экономия времени на этапе интеграции — до 30%.

Sanity — облачная CMS с real-time редактором. Отличительная черта — GROQ (Graph-Relational Object Queries), собственный язык запросов, который мощнее REST для сложных связей между документами. Portable Text для структурированного контента. Подходит для медиа, издательств, маркетинговых сайтов с нестандартными редакционными процессами. Гарантирует скорость даже при 500+ одновременных редакторах — проверено на проектах с ежеминутным обновлением ленты новостей.

Contentful — enterprise облачная CMS. Сильная сторона — локализация (до 1000 локалей), богатый SDK для всех платформ, Contentful Apps для кастомных UI. Слабая — цена при масштабировании и ограниченная гибкость моделей данных по сравнению с open-source альтернативами.

Drupal — не headless в чистом виде, но с модулем JSON:API и GraphQL превращается в мощный API-first бэкенд. Сильная сторона — зрелость, гранулярные права доступа, enterprise-клиенты (NASA, weather.com). Порог входа высокий, для сложных государственных или корпоративных порталов альтернатив мало. Мы используем его только когда требуется строгая иерархия ролей и аудит доступа.

Последствия неправильного моделирования контента

Моделирование контента — критичный этап. Ошибка на этом этапе стоит дорого. Типичная проблема: поле body типа rich text для всего. Через полгода контент-менеджер хочет вставить видео между абзацами, добавить pull quote с кастомным стилем, встроить интерактивную таблицу. Rich text это не позволяет. Решение — Portable Text (Sanity) или кастомные компоненты в Strapi/Directus через Dynamic Zone. Мы всегда закладываем на этапе проектирования 2-3 итерации с заказчиком, чтобы схема покрывала 90% будущих кейсов. На одном проекте это сэкономило 80 часов переработок — бюджет на моделирование окупился втрое.

Как мы строим проекты на headless CMS

Фронтенд под headless CMS практически всегда идёт на Next.js (App Router) или Nuxt. Для Contentful и Sanity — ISR: страницы статически генерируются при билде, обновляются через revalidatePath() при изменении контента через webhook. Для Strapi/Directus с частым обновлением данных — SSR с cache: 'no-store' или SWR на клиенте.

Кейс: редизайн корпоративного сайта производственной компании. Предыдущий сайт — WordPress с ACF, 200+ страниц, 4 языка. Проблемы: TTFB 3,8 с, редакторы жаловались на медленный админ.
Перешли на Strapi (self-hosted, PostgreSQL), Next.js App Router. Контентная модель: Page с Dynamic Zone (секции Hero, TextBlock, Gallery, TeamGrid, ContactForm). Локализация через Strapi i18n plugin + next-intl на фронтенде. Деплой фронтенда на Vercel с ISR, ревалидация через Strapi webhook на entry.publish.

TTFB с 3,8 с упал до 180 мс (статика с CDN) — разница в 21 раз. Редакторы получили чистый интерфейс без 47 плагинов. Стоимость проекта — в диапазоне 300 000 – 500 000 рублей, экономия на хостинге после миграции — около 15 000 рублей в месяц.

Для понимания headless CMS и TTFB — рекомендую базовые статьи.

Процесс внедрения разбит на этапы:

1. Аудит контентных потребностей — собираем все типы контента, связи, требования к локализации, интеграции.
2. Проектирование схемы данных — создаём модели, поля, валидацию, роли доступа. Документируем в Swagger/OpenAPI.
3. Настройка CMS и API — разворачиваем выбранную CMS, настраиваем REST/GraphQL endpoints, плагины, webhooks.
4. Разработка фронтенда — подключаем Next.js/Nuxt, настраиваем ISR/SSR, компоненты секций, роутинг.
5. Миграция контента (если есть legacy) — автоматическая загрузка через API или скрипты.
6. Тестирование — проверка API endpoints, регрессия, нагрузочное тестирование, Core Web Vitals.
7. Деплой — настройка CDN, SSL, CI/CD, мониторинг.

Сколько времени занимает внедрение?

Стандартный путь включает все этапы. Миграция с WordPress на headless CMS занимает столько же времени, сколько сам проект — часто больше. Особенно если в WordPress накоплены кастомные поля через ACF с нестандартной структурой. Наши средние сроки:

Стоимость рассчитывается индивидуально после брифа. Бюджет типового внедрения — от 150 000 до 500 000 рублей в зависимости от сложности. Экономия на хостинге за счёт статической генерации — до 40% в месяц.

Что входит в работу

• Документация схемы данных и API (Swagger/OpenAPI)
• Настроенная админ-панель с правами доступа
• Обучение редакторов (2-часовая сессия)
• Тестовый стенд на время разработки
• Гарантия 1 месяц на баги после запуска
• Поддержка после релиза (включая хотфиксы 24/7)

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