Кастомізація Jekyll-теми під ключ: стилі, шаблони, плагіни

Коли стандартна тема Jekyll не відповідає брендбуку, починається кастомізація. Ми налаштовуємо Jekyll-теми під ключ: від перевизначення шаблонів до впровадження кастомних SCSS-стилів та плагінів. За 5 років роботи з Jekyll ми виконали понад 20 проєктів — від простих блогів до багатосторінкових сайтів з 5000+ сторінками. Кастомізація економить до 40% часу в порівнянні зі створенням теми з нуля, а готовий сайт працює на 30% швидше типових рішень на CMS.

Основні способи поширення тем

Існує два підходи: gem-based (тема як Ruby gem) та remote theme (з GitHub). Gem-based теми встановлюються через Bundler, їх файли зберігаються в директорії Ruby gems. Remote theme копіюється напряму при збірці. Механізм кастомізації схожий: файли в корені проєкту перекривають файли теми. Однак є нюанси.

Для gem-based використовуємо команду bundle exec jekyll theme-files, щоб побачити всі файли теми, і копіюємо потрібні в проєкт. Як описано в Jekyll documentation.

Як перевизначити шаблони в Jekyll?

Для override скопіюйте файл з gem в корінь проєкту, зберігши структуру папок. Наприклад, скопіювати лейаут поста:

cp $(bundle info --path minima)/_layouts/post.html _layouts/post.html

Після цього редагуємо скопійований файл. Jekyll при збірці використовує файл з кореня проєкту, а не з gem. Це стандартний механізм для всіх шляхів: _layouts/, _includes/, _sass/.

Налаштування через _config.yml та кастомізація стилів

Більшість тем читають параметри з _config.yml. Приклад для Minimal Mistakes:

remote_theme: "mmistakes/[email protected]"
minimal_mistakes_skin: "air"
locale: "uk-UA"
title: "Назва сайту"
name: "Команда"
description: "Опис"
author:
  name: "Ім'я"
  avatar: "/assets/images/avatar.jpg"
  bio: "Короткий опис"
  links:
    - label: "Email"
      icon: "fas fa-fw fa-envelope-square"
navigation:
  - title: "Головна"
    url: /
  - title: "Блог"
    url: /blog/

Зверніть увагу: параметри тем часто описані в документації. Ми завжди перевіряємо актуальну версію теми.

Gem-теми зазвичай дозволяють додати кастомні стилі через assets/css/style.scss. Для Minima:

---
---
@import "minima";
:root {
  --base-font-size: 16px;
  --base-line-height: 1.7;
  --brand-color: #2563eb;
}
.site-header {
  border-top: 4px solid var(--brand-color);
  background: #fff;
  box-shadow: 0 1px 3px rgba(0,0,0,0.08);
}

Для Minimal Mistakes — через _sass/minimal-mistakes/_variables.scss (скопійований з gem). Такий підхід гарантує, що зміни не загубляться при оновленні теми (якщо не перезаписувати при оновленні).

Перевизначення шаблонів Liquid та управління навігацією

Приклад: додати таблицю змісту (TOC) в лейаут поста. Створюємо _layouts/post.html з умовою:

---
layout: default
---
<article>
  <header>...</header>
  {% if page.toc %}
  <aside class="toc">
    <h2>Зміст</h2>
    {% include toc.html html=content %}
  </aside>
  {% endif %}
  <div class="post-content">{{ content }}</div>
</article>

Для складних меню використовуємо _data/navigation.yml, де визначаємо ієрархію пунктів. В _includes/header.html виводимо їх через цикл з перевіркою на підпункти.

Кастомні компоненти та часті проблеми

Якщо тема не передбачає потрібний елемент (наприклад, CTA-банер), створюємо кастомний парціал в _includes/. Парціали приймають параметри і легко вставляються через {% include %}.

Як проходить процес кастомізації?

1. Аналіз — вивчаємо поточну тему та вимоги до кастомізації.
2. Проектування — обираємо стратегію: gem або remote theme.
3. Налаштування конфігу — прописуємо параметри теми.
4. Override шаблонів — копіюємо та редагуємо потрібні файли.
5. Кастомізація стилів — підключаємо кастомні SCSS/CSS.
6. Додавання компонентів — створюємо парціали для відсутніх елементів.
7. Тестування — перевіряємо локально та на CI.
8. Деплой — публікуємо на хостингу.

Що входить в кастомізацію Jekyll-теми?

При замовленні кастомізації Jekyll-теми під ключ ми надаємо:

• аналіз поточної теми та список змін;
• налаштування _config.yml та Gemfile;
• перевизначення шаблонів (layout, includes);
• кастомізацію стилів (SCSS, CSS custom properties);
• додавання кастомних компонентів;
• інтеграцію аналітики та коментарів;
• тестування на всіх сторінках;
• інструкцію з оновлення теми;
• доступ до репозиторію проєкту.

Терміни та вартість

Терміни налаштування залежать від обсягу: просте налаштування через конфіг та CSS — від 1 до 2 днів. Override шаблонів та додавання кастомних компонентів — від 3 до 5 днів. Точну вартість розраховуємо індивідуально, виходячи зі складності теми та вимог. Зв'яжіться з нами — оцінимо проєкт безкоштовно.

Ми працюємо з Jekyll більше 5 років, виконали понад 20 проєктів на статичних сайтах. Гарантуємо результат: сайт відповідатиме вашим очікуванням та Core Web Vitals. Замовте кастомізацію Jekyll-теми під ключ — отримайте сучасний статичний сайт.

Для довідки: Jekyll — популярний генератор статичних сайтів, що використовується для блогів та документації.

Типи сайтів: технічне завдання, а не маркетинг

Ми бачимо, як команди витрачають бюджет на невідповідний стек. Лендинг на Next.js зі статичною генерацією та корпоративний сайт з CMS — принципово різні інфраструктури, навіть якщо зовні схожі. Помилка на старті веде до переплати за хостинг у 5–10 разів і низької швидкості завантаження. Core Web Vitals (LCP, INP, TTFB) для кожного типу сайту мають свої пріоритети: для лендингу критичний LCP, для корпоративного — TTFB через динамічний контент.

За нашими даними, до 40% проєктів переплачують на хостингу через неправильний вибір технології. Статичний сайт на CDN обходиться в 5 разів дешевше за WordPress на VPS за тих самих навантажень. Нижче розберемо чотири типи сайтів, їхні типові технічні помилки та рішення, які ми застосовуємо на практиці. Маємо 8 років досвіду та понад 120 успішних проєктів у різних нішах.

Як обрати правильний тип сайту?

Вибір визначає стек, інфраструктуру та бюджет на підтримку. Покрокова інструкція:

1. Визначте мету: продаж (лендинг), інформування (корпоративний) чи швидкий контакт (візитка).
2. Оцініть частоту оновлення контенту: щодня — потрібна CMS, раз на місяць — вистачить Markdown у Git.
3. Виберіть стек за продуктивністю: статика для візиток, Next.js з ISR для корпоративних, GSAP для промо.

Як не помилитися з вибором CMS?

Якщо редактори нетехнічні — WordPress з Gutenberg або ACF Pro закриває потреби. Для складних структур — headless CMS (Strapi, Directus) з фронтендом на Next.js. Якщо оновлення рідкі — Markdown в Git з Astro або Next.js, деплой по push в main. Ми використовуємо Repository pattern для уникнення N+1 запитів при роботі з ORM.

Сайт-візитка

Найкомпактніший формат: 1–5 сторінок, мінімум динаміки. Основне завдання — контактна інформація та перше враження. Технічно просто, але є типові помилки.

Занадто важкий стек. WordPress з 15 плагінами для 5 сторінок дає TTFB 800ms на shared хостингу. Ми пропонуємо статику: HTML/CSS/JS або Next.js з output: 'export', задеплоєне на Vercel або Cloudflare Pages. Жодного PHP, жодної бази даних — тільки CDN. TTFB < 50ms гарантовано. Економія на хостингу — до 70% на місяць.

Немає контактної форми з backend-валідацією. Форма лише з JS-валідацією — це декорація. Ми додаємо серверлесс endpoint (Netlify Functions або AWS Lambda) з rate-limiter та сповіщеннями.

Відсутність Schema.org розмітки. Google Knowledge Panel будується на LocalBusiness або Organization. Ми вбудовуємо розмітку в шаблон: адреса, телефон, години роботи.

Термін розробки: 2–3 тижні з дизайном.

Чому швидкість лендингу безпосередньо впливає на конверсію?

Лендинг — сторінка з однією метою: конверсія. Core Web Vitals критичні, оскільки платний трафік і Google використовує CWV у Quality Score.

Конкретний кейс: лендинг з hero-відео 8MB autoplay без preload="none" і три сторонні скрипти аналітики синхронно в <head>. LCP 9.4s, INP 780ms. Ми замінили відео на poster image з відкладеним завантаженням, скрипти перевели на async/defer і частково в Web Workers через Partytown. LCP став 1.8s, INP 140ms. Конверсія зросла на 23% тільки за рахунок швидкості.

A/B тестування — стандартна практика. Після закриття Google Optimize використовуємо open-source Growthbook або PostHog. Для Next.js застосовуємо edge middleware для розподілу трафіку на CDN без додаткового JS.

Термін: 2–4 тижні.

Корпоративний сайт

Корпоративний — CMS, багато сторінок, мультимовність, інтеграція з CRM. Ключове питання: хто редагує контент і як часто.

Якщо редактори нетехнічні — WordPress з Gutenberg або ACF Pro. Для складних структур — headless CMS (Strapi, Directus) з фронтендом на Next.js. Якщо оновлення рідкі — Markdown в Git з Astro або Next.js, деплой по push в main.

Продуктивність: сторінка "Про компанію" з 40 фото в оригіналі — LCP 12 секунд на мобільному. <Image> компонент Next.js з WebP і srcset вирішує без ручної роботи, знижуючи LCP до 2 секунд.

Багатомовність: Astrotomic Translatable на Laravel або next-intl. Структура URL — /uk/about, /en/about з hreflang.

Термін: 6–12 тижнів залежно від обсягу.

Промо-сайт

Промо — тимчасовий або постійний сайт під кампанію. Нестандартний дизайн, анімації. Стек: GSAP, Framer Motion, Three.js, Lottie.

Головна пастка — гальмівні анімації на мобільних. GPU-анімації через transform і opacity — нормально. box-shadow в анімації, filter: blur() на кожному кадрі, анімація width/height — 20fps на iPhone 12. will-change: transform допомагає точково.

prefers-reduced-motion — обов’язковий для accessibility.

Термін: 3–6 тижнів.

Як ми оптимізуємо продуктивність?

Для кожного проєкту проводимо аудит початкового стеку: аналізуємо TTFB, LCP, CLS, INP через Lighthouse та WebPageTest. Використовуємо tree-shake та bundle splitting для зменшення JS-бандла, для Next.js — React Server Components і Suspense для стрімінгу. Серверлесс функції дозволяють уникнути постійної вартості сервера — платите тільки за запити. Наприклад, корпоративний сайт на Next.js + Strapi дає TTFB <200ms, що у 5 разів менше ніж аналог на WordPress.

Автоматично конвертуємо зображення в WebP/AVIF, генеруємо srcset для всіх роздільних здатностей, використовуємо lazy loading з Intersection Observer. Для фонових зображень — техніка progressive loading.

Порівняльна таблиця

Вартість у кожному випадку розраховується індивідуально після вивчення технічного завдання. — Google рекомендує TTFB під 0.8s, у нас <0.2s.

Що входить в роботу

• Аналітика та прототипування (структура, користувацькі сценарії)
• Дизайн-концепція (адаптивний, mobile-first)
• Верстка з оптимізацією LCP, CLS, INP
• Вибір та налаштування CMS (якщо потрібна)
• Інтеграція з CRM/маркетинговими інструментами
• Тестування (кросбраузерне, load-testing)
• Документація та передача доступів
• Навчання редакторів (відео + письмово)
• гарантія 3 місяці (безкоштовні правки)

Друга таблиця: порівняння підходів за продуктивністю

Статичний сайт швидший за WordPress у 10 разів за TTFB. Для консультації щодо вибору типу сайту та стеку зв'яжіться з нашими інженерами. Замовте розробку під ключ — ми оцінимо терміни та бюджет за 1 день. Напишіть нам, щоб отримати безкоштовний технічний аудит вашого проекту. Отримайте індивідуальну пропозицію з гарантією якості.