Розробка кастомного шаблону Umbraco
Клієнт приходить із завданням: «Потрібен сайт на Umbraco, але готові теми не підходять — потрібна розробка кастомного шаблону Umbraco під нестандартну структуру». Ми не беремо шаблон з маркетплейсу: пишемо Razor-в'юхи, контролери та View Components з нуля під конкретний Document Type. Жодної зайвої розмітки, жодних костилів — тільки те, що потрібно проєкту. Кастомний шаблон дозволяє завантажувати сторінки на 40% швидше готового рішення за рахунок мінімізації запитів та bundle splitting.
Як кастомізувати шаблон без втрати продуктивності?
Перший крок — розібратися з Layout. Кожна сторінка успадковує загальний макет, але якщо в нього зашити надто багато логіки, постраждає TTFB. Ми виносимо статичні частини (шапка, підвал) в окремі partials, а динамічні — через @await Component.InvokeAsync(). Це дає кешування по частинах і знижує навантаження на базу. Наприклад, на одному з проєктів LCP впав з 2,8 с до 1,1 с після рефакторингу Layout.
Згідно з рекомендаціями Google Core Web Vitals, LCP має бути менше 2.5 секунд.
Базовий макет:
@* Views/Shared/_Layout.cshtml *@
@using Umbraco.Cms.Web.Common.PublishedModels
@inject IPublishedValueFallback PublishedValueFallback
<!DOCTYPE html>
<html lang="@System.Threading.Thread.CurrentThread.CurrentCulture.TwoLetterISOLanguageName">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>@ViewData["Title"] – @ViewBag.SiteName</title>
<meta name="description" content="@ViewData["Description"]">
<link rel="stylesheet" href="~/css/app.css" asp-append-version="true">
</head>
<body class="@ViewData["BodyClass"]">
@await Html.PartialAsync("_Navigation")
<main>@RenderBody()</main>
@await Html.PartialAsync("_Footer")
<script src="~/js/app.js" asp-append-version="true" defer></script>
@RenderSection("scripts", required: false)
</body>
</html>
Зустрічається ситуація: клієнт хоче, щоб на кожній сторінці був свій заголовок h1 та SEO-опис. Вирішується strongly-typed моделлю, яка маппиться з IPublishedContent. Ми використовуємо Umbraco Mapper для автоматизації перетворень (детальніше в документації Umbraco).
Приклад контролера статті на C#:
public class ArticleController : RenderController
{
private readonly IUmbracoMapper _mapper;
private readonly IRelatedContentService _relatedService;
public ArticleController(ILogger<ArticleController> logger,
ICompositeViewEngine viewEngine,
IUmbracoContextAccessor umbracoContextAccessor,
IUmbracoMapper mapper,
IRelatedContentService relatedService)
: base(logger, viewEngine, umbracoContextAccessor)
{
_mapper = mapper;
_relatedService = relatedService;
}
public override IActionResult Index()
{
if (CurrentPage is not Article article) return NotFound();
var model = new ArticleViewModel
{
Title = article.Title,
BodyHtml = article.Body?.ToString(),
PublishDate = article.PublishDate,
SeoTitle = article.SeoTitle,
SeoDescription = article.SeoDescription,
CoverImage = article.CoverImage?.First() as IPublishedContent,
Category = article.ArticleCategory?.First() as IPublishedContent,
RelatedArticles = _relatedService.GetRelated(article, 3),
};
return CurrentTemplate(model);
}
}
Чому варто обирати кастомні шаблони Umbraco замість готових рішень?
| Критерій |
Готовий шаблон |
Кастомний шаблон |
| Продуктивність |
Часто перевантажений непотрібними скриптами |
Мінімум запитів, оптимізовані Partial View |
| SEO-структура |
Розмітка фіксована, складно змінювати |
Повний контроль над HTML, заголовками, мікророзміткою |
| Швидкість завантаження |
LCP може бути > 2.5 с через бандли |
Bundle splitting, lazy images через ImageSharp, WebP |
| Розширюваність |
Будь-яка доробка — костилі та патчі |
Чиста архітектура, Repository pattern, легко додавати блоки |
З таблиці видно, що кастомний шаблон виграє за всіма ключовими метриками. Додатково, економія на ліцензіях та підтримці може становити до 30% порівняно з готовим рішенням. Вартість кастомного шаблону нижча, ніж покупка та постійні доробки готового. Терміни розробки прозорі та фіксуються в ТЗ.
Процес кастомізації шаблону Umbraco
- Аналітика: вивчаємо Document Types, структуру контенту, вимоги до продуктивності.
- Проєктування Layout: створюємо макет, визначаємо зони для Partial View.
- Розробка контролерів: пишемо strongly-typed ViewModel з впровадженням залежностей для кожного Document Type.
- Реалізація блоків: налаштовуємо Block List / Block Grid з кастомними partials, підключаємо ImageSharp для адаптивних зображень.
- Тестування: перевіряємо Core Web Vitals, усуваємо N+1 запити, налаштовуємо кешування.
- Деплой: передаємо код, документацію та доступ.
Етапи розробки та терміни
| Етап |
Тривалість |
| Аналітика та аудит |
1–2 дня |
| Проєктування Layout |
1–2 дня |
| Розробка контролерів |
2–4 дня |
| Реалізація блоків |
3–5 днів |
| Тестування та оптимізація |
1–2 дня |
| Деплой та документація |
1 день |
Типові помилки при кастомізації шаблонів Umbraco
N+1 запит — кожен блок Hero незалежно завантажує зображення. Рішення: інжектимо сервіс зображень в контролер та передаємо готові URL.
Hydration mismatch — при кешуванні часткових в'юх втрачається актуальність даних. Використовуємо [OutputCache(NoStore = true)] на динамічних компонентах.
Дублювання навігації — багаторівневе меню з окремими шаблонами для кожного рівня. Натомість застосовуємо єдиний рекурсивний partial _Navigation.
Приклад рекурсивної навігації
@* Views/Partials/_Navigation.cshtml *@
@using Umbraco.Cms.Web.Common.UmbracoContext
@inject IUmbracoContextAccessor UmbracoContextAccessor
@{
var ctx = UmbracoContextAccessor.GetRequiredUmbracoContext();
var root = ctx.Content?.GetAtRoot().FirstOrDefault();
var nav = root?.Children.Where(n => n.Value<bool>("showInNav"));
}
<nav class="main-nav">
@foreach (var item in nav ?? [])
{
<a href="@item.Url()"
class="@(item.IsAncestorOrSelf(ctx.PublishedRequest?.PublishedContent) ? "active" : "")">
@item.Name
</a>
}
</nav>
Що входить в роботу
- Розробка Layout та Partial View (навігація, підвал, попапи)
- Strongly-typed моделі ViewModel для кожного Document Type
- Контролери на C# з впровадженням залежностей
- Блочний редактор (Block List / Block Grid) з кастомними partials
- View Components для макросів (хлібні крихти, меню, віджети)
- Адаптивні зображення з WebP та srcset
- Мінімальна верстка Umbraco на Tailwind або CSS Grid — за погодженням
- Документація та доступ (адмінка, FTP, репозиторій)
Терміни та вартість
Терміни залежать від кількості типів сторінок та складності блоків. Орієнтуємося на діапазон:
- Базовий комплект (Layout + 5–6 типів сторінок + блоки): 2–3 тижні.
- Один складний шаблон з кастомним контролером та кешуванням: 3–5 днів.
Вартість розраховується індивідуально після аудиту поточної структури. Ми не називаємо ціну наосліп — спочатку знайомимося з проєктом. Оцінимо ваш проєкт за 1 робочий день, дамо точний кошторис та терміни. Наш досвід 7+ років та 50+ проєктів на Umbraco дозволяють гарантувати передбачуваний результат. Зв'яжіться з нами, щоб обговорити деталі — отримайте консультацію безкоштовно. Замовте розробку кастомного шаблону Umbraco — отримайте продуктивність, заточену під ваш проєкт.
Headless CMS: Strapi, Directus, Sanity, Contentful, Drupal
Традиційна CMS хороша до моменту, коли дизайнер каже «хочу анімацію при скролі з parallax», фронтенд — «нам потрібен React», а SEO-спеціаліст — «чому TTFB 3.4 секунди». У цей момент монолітна архітектура починає заважати всім одразу. Я стикався з цим десятки разів: сайт на WordPress з ACF розростається до 47 плагінів, адмінка гальмує, а кожен редизайн перетворюється на переписування шаблонів.
Headless CMS відокремлює управління контентом від його представлення. Редактори працюють у зручному інтерфейсі, розробники отримують дані через API і будують фронтенд на будь-якому стеку. Звучить просто. На практиці — вибір CMS, моделювання даних і налаштування API займають значну частину проєкту. За понад 5 років ми провели понад 50 впроваджень — розповім, як не наступити на типові граблі.
Чому headless CMS вигідніша за моноліт?
Монолітна CMS (WordPress, Joomla, Drupal у класичному режимі) змішує бекенд і фронтенд. Будь-яка зміна верстки — це зміна шаблонів, часто з ризиком зламати адмінку. Headless дає свободу: фронтенд на React, Vue або Svelte, а контент живе окремо. Результат — швидкість завантаження (LCP часто падає з 4–6 с до 1–1,5 с), безпека (нема публічного доступу до адмін-панелі), масштабування (контент віддається через CDN без навантаження на сервер). Плюс можливість перевикористовувати контент у мобільних додатках, кіосках, email-розсилках через єдиний API. На одному проєкті це заощадило 80 годин переробок і $4000 бюджету.
Яку 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). Поріг входу високий, для складних державних або корпоративних порталів альтернатив мало. Ми використовуємо його тільки коли потрібна строга ієрархія ролей та аудит доступу.
| CMS |
Хостинг |
API |
Найкращий сценарій |
| Strapi |
Self-hosted / Cloud |
REST, GraphQL |
Стартапи, кастомізація |
| Directus |
Self-hosted / Cloud |
REST, GraphQL |
Обгортка над existing DB |
| Sanity |
Хмара |
GROQ, GraphQL |
Медіа, складний контент |
| Contentful |
Хмара |
REST, GraphQL |
Enterprise, локалізація |
| Drupal |
Self-hosted |
JSON:API, GraphQL |
Держсектор, складні права |
Які наслідки неправильного моделювання контенту?
Моделювання контенту — критичний етап. Помилка на цьому етапі коштує дорого. Типова проблема: поле body типу rich text для всього. Через пів року контент-менеджер хоче вставити відео між абзацами, додати pull quote з кастомним стилем, вбудувати інтерактивну таблицю. Rich text це не дозволяє. Рішення — Portable Text (Sanity) або кастомні компоненти в Strapi/Directus через Dynamic Zone. Ми завжди закладаємо на етапі проєктування 2–3 ітерації з замовником, щоб схема покривала 90% майбутніх кейсів. На одному проєкті це заощадило 80 годин переробок — бюджет на моделювання окупився втричі, а економія склала понад $4000.
Як ми будуємо проєкти на 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 плагінів. Вартість хостингу знизилася на $200 на місяць — це економія $2400 на рік.
Для розуміння headless CMS та TTFB рекомендую базові статті, зокрема офіційну документацію Strapi та Wikipedia.
Процес впровадження розбитий на етапи:
- Аудит контентних потреб — збираємо всі типи контенту, зв'язки, вимоги до локалізації, інтеграції.
- Проєктування схеми даних — створюємо моделі, поля, валідацію, ролі доступу. Документуємо в Swagger/OpenAPI.
- Налаштування CMS та API — розгортаємо обрану CMS, налаштовуємо REST/GraphQL endpoints, плагіни, webhooks.
- Розробка фронтенду — підключаємо Next.js/Nuxt, налаштовуємо ISR/SSR, компоненти секцій, роутинг.
- Міграція контенту (якщо є legacy) — автоматичне завантаження через API або скрипти.
- Тестування — перевірка API endpoints, регресія, навантажувальне тестування, Core Web Vitals.
- Деплой — налаштування CDN, SSL, CI/CD, моніторинг.
Скільки часу займає впровадження?
Стандартний шлях включає всі етапи. Міграція з WordPress на headless CMS займає стільки ж часу, скільки сам проєкт — часто більше. Особливо якщо в WordPress накопичені кастомні поля через ACF з нестандартною структурою. Наші середні терміни:
| Тип проєкту |
Термін |
| Простий сайт на Strapi + Next.js |
4–8 тижнів |
| Багатомовний корпоративний сайт |
8–16 тижнів |
| Міграція з WordPress на headless |
+4–8 тижнів до основного |
| Drupal enterprise-портал |
3–6 місяців |
Вартість розраховується індивідуально після брифу. Економія на хостингу за рахунок статичної генерації — до 40% на місяць.
Неочевидні моменти при виборі headless CMS
- Перевірте, чи підтримує CMS мультисайтинг — якщо плануєте кілька доменів, багато open-source рішень не вміють розділяти контент за доменами без костилів.
- Уточніть формат історії змін — Strapi зберігає drafts тільки для publish-версій, а Directus — повний аудит всіх змін.
- Протестуйте швидкість роботи admin panel на слабкому інтернеті — Sanity працює в реальному часі через WebSocket, що може бути проблемою при поганому з'єднанні.
- Оцініть складність кастомних полів — у Contentful додавання нового поля вимагає деплою, у Strapi — тільки перезапуску сервера.
- Дізнайтеся про ліцензійні обмеження — Strapi v5 перейшов на Elastic License, що може вплинути на комерційне використання.
Що входить в роботу
- Документація схеми даних та API (Swagger/OpenAPI)
- Налаштована адмін-панель з правами доступу
- Навчання редакторів (2-годинна сесія)
- Тестовий стенд на час розробки
- Гарантія 1 місяць на баги після запуску
- Підтримка після релізу (включаючи хотфікси 24/7)
Headless CMS розробка — це не просто заміна інструменту, а зміна парадигми роботи з контентом. Ми допомагаємо зробити цей перехід без простоїв та втрати даних. Отримайте консультацію та попередню оцінку — залиште заявку на сайті. Замовте впровадження headless CMS з гарантією результату.
