Типова задача: інтернет-магазин на Webflow з каталогом у 500 товарів, кожен товар має 15 характеристик, 3 категорії, 2 бренди та 5 тегів. Стандартна колекція впирається в ліміт 20 полів, а прості зв'язки не дають гнучкої фільтрації. Замість того щоб мігрувати на іншу платформу, ми проектуємо схему з кількох пов'язаних колекцій та реалізуємо просунуту фільтрацію через Finsweet CMS Filter. За 2–3 тижні отримуємо продуктивний каталог з AJAX-пагінацією та багатокритеріальним пошуком.
Ми розробляємо кастомні CMS-колекції Webflow під ключ. Наші інженери щодня вирішують завдання складних зв'язків, синхронізації з CRM та обходу обмежень платформи. У цій статті розберемо реальні кейси та технічні рішення.
Як пов'язати CMS-колекції між собою?
Зв'язки в Webflow реалізуються через поля Reference (один-до-одного) та Multi-Reference (один-до-багатьох). Наприклад, у блозі з авторами та тегами:
Collections:
Blog Posts
- title: Plain Text (required)
- slug: Plain Text (auto, unique)
- body: Rich Text
- published_at: Date
- author: Reference → Authors
- tags: Multi-Reference → Tags
- featured_image: Image
- seo_title: Plain Text
- seo_description: Plain Text
Authors
- name: Plain Text
- photo: Image
- bio: Rich Text
- linkedin: Link
Tags
- name: Plain Text
- color: Color
Зв'язок Many-to-Many через Multi-Reference працює лише в один бік: Post знає свої Tags, але Tag не знає свої Posts напряму. Для зворотної вибірки використовуйте фільтрацію Collection List за Reference полем.
Чому Webflow CMS краще за WordPress для структурованого контенту?
Webflow CMS швидше в розробці шаблонів — не потрібно верстати окремо адмінку та виведення записів. Кожен тип поля жорстко типізований, що виключає помилки на рівні даних. На відміну від довільних полів WordPress, Webflow дає чисту розмітку та передбачуваний рендеринг.
Що робити при перевищенні ліміту полів?
| Обмеження |
Обхід |
| Максимум 20 полів на колекцію |
Розбити на пов'язані колекції через Reference |
| Немає вкладених колекцій у Collection List |
Використовувати Finsweet Nested Lists |
| 100 елементів у Collection List на сторінці |
Finsweet CMS Load з пагінацією |
| Немає умовного рендерингу по Reference |
Visibility conditions через Switch-поле |
| Multi-Reference максимум 25 зв'язків |
Архітектурне рішення: join-колекція |
Як забезпечити продуктивність з Core Web Vitals?
Правильна архітектура CMS-колекцій напряму впливає на LCP та CLS. Уникайте N+1 запитів: при виведенні списку записів з Reference-полями Webflow генерує окремий запит для кожного зв'язку. Групуйте дані в одній колекції, якщо це можливо, або використовуйте Finsweet CMS Load для відкладеного завантаження пов'язаних елементів. Контролюйте розмір зображень через Webflow Image API — це знижує TTFB.
Динамічна фільтрація та сортування
У нативному Webflow фільтрація Collection List обмежена. Для просунутої фільтрації на стороні клієнта використовується Finsweet CMS Filter — бібліотека з data-атрибутами:
<!-- Фільтр за тегом -->
<div fs-cmsfilter-field="tag">Development</div>
<!-- Collection List з атрибутом -->
<div fs-cmsfilter-element="list">
<!-- Webflow Collection List items -->
</div>
Finsweet CMS Sort, CMS Load (пагінація через AJAX) — стандартний стек для складних лістингів без написання бекенду.
Webflow CMS API
Webflow надає REST API для управління колекціями. Основні ендпоінти:
GET /v2/collections/{collection_id}/items
POST /v2/collections/{collection_id}/items
PATCH /v2/collections/{collection_id}/items/{item_id}
DELETE /v2/collections/{collection_id}/items/{item_id}
Це відкриває можливість синхронізації даних із зовнішніх систем: CRM, ERP, PIM. Наприклад, автоматичне оновлення каталогу товарів з 1С через webhook + Node.js скрипт:
import { WebflowClient } from 'webflow-api';
const client = new WebflowClient({ accessToken: process.env.WEBFLOW_TOKEN });
async function syncProduct(product) {
await client.collections.items.createItem(COLLECTION_ID, {
fieldData: {
name: product.title,
slug: product.sku.toLowerCase(),
price: product.price,
'in-stock': product.quantity > 0,
},
isDraft: false,
isArchived: false,
});
}
Локалізація контенту
Webflow Localization дозволяє створювати перекладені версії CMS-записів. Налаштування:
- В Project Settings → Localization додати локалі (наприклад,
en, uk, de)
- Для кожної колекції включити локалізацію потрібних полів
- Перемикач локалі керує видимістю записів
Альтернатива — зберігати переклади в окремих колекціях з Reference-зв’язком до основної.
Орієнтовні терміни за типами проєктів
| Тип проєкту |
Терміни |
Особливості |
| Простий блог |
3–5 днів |
1 колекція, 5 полів |
| Каталог з фільтрами |
2–3 тижні |
3–5 колекцій, Multi-Reference, Finsweet |
| Багатомовний сайт |
3–4 тижні |
Локалізація, переклади |
| Інтеграція з CRM |
4–6 тижнів |
API-синхронізація, webhooks |
Що входить у роботу
- Проектування схеми даних колекцій
- Налаштування зв'язків (Reference / Multi-Reference)
- Розробка шаблонів Collection Page та Collection List
- Реалізація фільтрації та сортування (вбудована + Finsweet)
- Інтеграція із зовнішніми джерелами через Webflow API
- Документація щодо структури контенту
- Навчання команди роботі з CMS
- Гарантійна підтримка після здачі
Терміни та вартість
Вартість розраховується індивідуально. Наші інженери мають сертифікацію Webflow та 5+ років досвіду роботи з платформою. Гарантуємо підтримку після запуску.
Замовте аудит поточної CMS-структури — ми знайдемо вузькі місця та запропонуємо оптимізацію. Зв’яжіться з нами для оцінки вашого проєкту — ми підготуємо детальну пропозицію.
Типи сайтів: технічне завдання, а не маркетинг
Ми бачимо, як команди витрачають бюджет на невідповідний стек. Лендинг на 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 день. Напишіть нам, щоб отримати безкоштовний технічний аудит вашого проекту. Отримайте індивідуальну пропозицію з гарантією якості.