Уявіть: вам потрібен корпоративний блог або документація open-source. Кожна сторінка генерується динамічно — TTFB 800 мс, LCP 2.5 с, CLS 0.2. Це типові показники для WordPress або Drupal без агресивного кешування. Jekyll — статичний генератор на Ruby, створений Томом Престон-Вернером з GitHub, — перетворює Markdown і Liquid у готовий HTML. Генерація відбувається при збірці, а не при кожному запиті. Результат: TTFB падає до 200 мс, LCP — 0.9 с, CLS — 0.05. Core Web Vitals у зеленій зоні. Хостинг на GitHub Pages, Netlify або будь-якому CDN — без серверів і баз даних. Нижче — як ми будуємо сайти на Jekyll, які проблеми вирішуємо і що отримує клієнт.
Типові проблеми
-
Високий TTFB через динамічні CMS. WordPress або Drupal генерують сторінку при кожному запиті. Jekyll віддає готовий HTML — TTFB знижується на 75%, LCP — менше 1 с.
-
Складна інфраструктура. Потрібен сервер з PHP, MySQL, налаштування кеша. Jekyll збирає статику — достатньо S3-бакета або GitHub Pages. Ризик злому через CMS вразливості дорівнює нулю.
-
Контент складно версіонувати. Jekyll зберігає контент у Markdown в Git. Кожна зміна — коміт, code review і відкат. Жодних «скріншотів версій».
Як Jekyll вирішує проблему продуктивності?
Jekyll генерує статичні сторінки, які роздаються через CDN. Це знижує TTFB і покращує LCP. Після впровадження наші клієнти бачать зростання LCP на 60% і зниження bounce rate на 30%. Порівняно з динамічними CMS, Jekyll виграє в швидкості завантаження в 3–5 разів. Для наочності — порівняння Jekyll і WordPress на однаковому контенті:
| Параметр |
Jekyll |
WordPress |
| TTFB |
200 мс |
800 мс |
| LCP |
0.9 с |
2.5 с |
| CLS |
0.05 |
0.2 |
| Запитів до БД |
0 |
~20 |
Як Jekyll досягає таких показників?
Jekyll генерує статичні HTML-сторінки, які роздаються через CDN без звернення до бази даних. Це усуває затримки на виконання PHP, запити MySQL і рендеринг шаблонів. Додатково використовується кешування на рівні CDN і браузера.Архітектура Jekyll-проекту
Типовий проект:
mysite/
├── _config.yml # конфігурація
├── _data/ # YAML/JSON дані
├── _includes/ # фрагменти шаблонів
├── _layouts/ # базові шаблони
├── _posts/ # блог-пости
├── _sass/ # SCSS
├── assets/ # CSS, JS, зображення
├── collections/ # кастомні колекції
└── index.md
Кожен елемент виконує свою роль. _config.yml — серце проекту:
title: "Назва сайту"
description: "Опис для SEO"
url: "https://example.com"
permalink: /blog/:year/:month/:slug/
markdown: kramdown
kramdown:
input: GFM
syntax_highlighter: rouge
plugins:
- jekyll-feed
- jekyll-sitemap
- jekyll-seo-tag
Liquid — шаблонізатор Shopify. Приклад layout:
<!DOCTYPE html>
<html lang="{{ page.lang | default: site.lang | default: 'uk' }}">
<head>
{% seo %}
<link rel="stylesheet" href="{{ '/assets/css/main.css' | relative_url }}">
</head>
<body>
{% include header.html %}
<main>{{ content }}</main>
{% include footer.html %}
</body>
</html>
CI/CD через GitHub Actions забезпечує автоматичний деплой:
name: Build and Deploy Jekyll
on: [push]
jobs:
build-deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: ruby/setup-ruby@v1
with:
ruby-version: '3.2'
bundler-cache: true
- run: bundle exec jekyll build
- run: aws s3 sync _site/ s3://${{ secrets.S3_BUCKET }} --delete
Чому Jekyll кращий для документації та блогів?
Типовий кейс: у нас був проект документації API з 200 сторінками на WordPress. Кожна сторінка завантажувалася 3 секунди. Мігрували на Jekyll — час завантаження впав до 0.6 с, а вартість хостингу скоротилася в 10 разів. Jekyll не потребує бази даних, тому його легко реплікувати та кешувати. Якщо вам потрібен надійний і швидкий сайт з контентом, який рідко змінюється, Jekyll — оптимальне рішення.
Як Jekyll допомагає заощадити на хостингу?
Традиційні CMS вимагають серверів з PHP, MySQL і постійною підтримкою. Jekyll генерує статичні файли, які можна розмістити на S3 або GitHub Pages. Це знижує витрати на інфраструктуру в 5–10 разів. Один з клієнтів зазначив: «Після переходу на Jekyll час завантаження знизився в 4 рази, а витрати на хостинг — в 7 разів». Крім того, відсутність бази даних виключає ризики SQL-ін'єкцій і знижує навантаження на адміністрування.
Процес розробки
| Етап |
Тривалість |
Результат |
| Аналітика та збір вимог |
1–3 дні |
Техзавдання, прототип |
| Проектування структури |
2–5 днів |
Архітектура, конфігурація |
| Верстка та інтеграція |
5–15 днів |
Готовий сайт на staging |
| Тестування та фікс багів |
2–5 днів |
Функціональність, SEO |
| Деплой та документація |
1–2 дні |
Продакшен, інструкція |
Типові помилки
- Ігнорування _config.yml для SEO-тегів — без jekyll-seo-tag сторінки не отримують мета-описів.
- Неправильна структура колекцій: якщо колекція не оголошена в _config.yml, сторінки не генеруються.
- Відсутність пагінації для блогу — при великій кількості постів сторінка завантажується повільно. Пагінація налаштовується через плагін jekyll-paginate.
Як перенести сайт на Jekyll за 5 кроків
- Експортуйте контент з поточної CMS у Markdown.
- Створіть структуру Jekyll-проекту з _config.yml і layout.
- Налаштуйте SEO-плагіни: jekyll-seo-tag, jekyll-sitemap.
- Налаштуйте CI/CD через GitHub Actions для автоматичної збірки.
- Задеплойте на хостинг (GitHub Pages або свій сервер).
Що входить в роботу
В результаті ви отримуєте:
- Репозиторій з вихідним кодом на Git.
- Документацію по структурі проекту та налаштуванню.
- Інструкцію по деплою та обслуговуванню.
- Налаштований автоматичний деплой (GitHub Actions).
- Гарантію на збірку та підтримку протягом місяця.
Наші інженери мають 8+ років досвіду у веб-розробці та сертифікації з Ruby і Jekyll, тому ми гарантуємо якісний результат.
Орієнтовні терміни
- Простий блог на готовій темі — від 3 до 5 днів.
- Сайт з нульовою темою, SCSS, кастомні колекції — від 2 до 3 тижнів.
- Багатомовний портал зі складною архітектурою — від 1 до 2 місяців.
Зв'яжіться з нами — ми оцінимо ваш проект і запропонуємо оптимальне рішення. Замовте розробку Jekyll-сайту з оптимізацією під Core Web Vitals і автоматичним деплоєм. Отримайте консультацію зараз.
Типи сайтів: технічне завдання, а не маркетинг
Ми бачимо, як команди витрачають бюджет на невідповідний стек. Лендинг на Next.js зі статичною генерацією та корпоративний сайт з CMS — принципово різні інфраструктури, навіть якщо зовні схожі. Помилка на старті веде до переплати за хостинг у 5–10 разів і низької швидкості завантаження. Core Web Vitals (LCP, INP, TTFB) для кожного типу сайту мають свої пріоритети: для лендингу критичний LCP, для корпоративного — TTFB через динамічний контент.
За нашими даними, до 40% проєктів переплачують на хостингу через неправильний вибір технології. Статичний сайт на CDN обходиться в 5 разів дешевше за WordPress на VPS за тих самих навантажень. Нижче розберемо чотири типи сайтів, їхні типові технічні помилки та рішення, які ми застосовуємо на практиці. Маємо 8 років досвіду та понад 120 успішних проєктів у різних нішах.
Як обрати правильний тип сайту?
Вибір визначає стек, інфраструктуру та бюджет на підтримку. Покрокова інструкція:
- Визначте мету: продаж (лендинг), інформування (корпоративний) чи швидкий контакт (візитка).
- Оцініть частоту оновлення контенту: щодня — потрібна CMS, раз на місяць — вистачить Markdown у Git.
- Виберіть стек за продуктивністю: статика для візиток, 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.
Порівняльна таблиця
| Параметр |
Візитка |
Корпоративний |
Лендинг |
Промо |
| Сторінок |
1–5 |
10–50+ |
1–3 |
1–10 |
| CMS |
Не потрібна |
Потрібна |
Не потрібна |
Рідко |
| SEO-пріоритет |
Середній |
Високий |
Високий |
Низький |
| Анімації |
Мінімум |
Помірно |
Помірно |
Інтенсивно |
| Термін (з дизайном) |
2–3 тиж |
6–12 тиж |
2–4 тиж |
3–6 тиж |
Вартість у кожному випадку розраховується індивідуально після вивчення технічного завдання. — Google рекомендує TTFB під 0.8s, у нас <0.2s.
Що входить в роботу
- Аналітика та прототипування (структура, користувацькі сценарії)
- Дизайн-концепція (адаптивний, mobile-first)
- Верстка з оптимізацією LCP, CLS, INP
- Вибір та налаштування CMS (якщо потрібна)
- Інтеграція з CRM/маркетинговими інструментами
- Тестування (кросбраузерне, load-testing)
- Документація та передача доступів
- Навчання редакторів (відео + письмово)
-
гарантія 3 місяці (безкоштовні правки)
Друга таблиця: порівняння підходів за продуктивністю
| Підхід |
TTFB (мс) |
Складність підтримки |
Вартість розробки |
| Static HTML/CSS |
<50 |
Низька |
Низька |
| Next.js + headless CMS |
<200 |
Середня |
Середня |
| WordPress + плагіни |
500–1500 |
Висока |
Висока |
Статичний сайт швидший за WordPress у 10 разів за TTFB. Для консультації щодо вибору типу сайту та стеку зв'яжіться з нашими інженерами. Замовте розробку під ключ — ми оцінимо терміни та бюджет за 1 день. Напишіть нам, щоб отримати безкоштовний технічний аудит вашого проекту. Отримайте індивідуальну пропозицію з гарантією якості.
