Інтеграція Sanity під ключ: схема, GROQ, Live Preview
Ви запускаєте новинний портал із 10 000 статей, редактори вимагають гнучкого редактора, а розробники — продуктивності. Sanity — headless CMS з повністю кастомізованим Studio, потужною мовою запитів GROQ та real-time оновленнями. Однак неправильне налаштування схеми призводить до N+1 запитів, гальмування Studio та проблем із Core Web Vitals. Наша команда інтегрувала Sanity для 15+ проєктів, від блогів до enterprise-порталів, і гарантує дотримання метрик продуктивності. Згідно з документацією Sanity, грамотна схема — основа швидкого редактора.
Проблеми, які ми вирішуємо
Складність схеми
Неправильна структура документів веде до дублювання даних і множинних запитів. Ми використовуємо Repository pattern та нормалізацію схеми, щоб кожен документ відповідав за одну сутність. Наприклад, для видавництва ми створили схему з 5 типів (стаття, автор, категорія, тег, медіа) з валідацією на рівні Studio — це скоротило кількість запитів на 60%. Неправильна схема може збільшити бюджет на доопрацювання на 50 000–100 000 ₴.
Продуктивність Studio
При великій кількості полів редактор зависає. Налаштування віртуалізації полів та групування у вкладки вирішує проблему. В одному проєкті з 40+ полями ми впровадили кастомні компоненти з debounce-валідацією — завантаження Studio прискорилося вдвічі.
Real-time оновлення
Без GROQ Streaming API редактори змушені оновлювати сторінку вручну. Налаштовуємо Live Preview через Server-Sent Events: зміни в Studio миттєво відображаються в прев'ю, без перезавантаження.
Медіа-ресурси
Неоптимізовані зображення збільшують LCP. Sanity Image URL Builder з параметрами auto=format, q=80 та fit=crop вирішує проблему. Ми також налаштовуємо за замовчуванням WebP з фолбеком на JPEG.
Як уникнути N+1 запитів у Sanity?
Основна причина N+1 — вибірка пов'язаних документів без проекції. Використовуйте GROX із join-синтаксисом:
// Замість двох запитів — один із проекцією *[_type == "article"] | order(publishedAt desc) [0..9] { title, "author": author->name, "categories": categories[]->title } Це зменшує кількість запитів до Content Lake з 10+ до 1. Для складних агрегацій застосовуйте references() та count(). Докладніше про синтаксис GROQ читайте в офіційній документації.
Що робити, якщо Studio гальмує на великих схемах?
Причина — рендеринг усіх полів одразу. Рішення:
- Групуйте поля у вкладки за допомогою
fieldsets. - Використовуйте
hiddenдля умовного відображення. - Впровадьте компоненти з
lazy-завантаженням. - Оптимізуйте валідацію: перенесіть складні правила на backend через webhooks.
Як ми це робимо: кейс видавництва
Стек: Next.js 14 (App Router), Sanity v3, GROQ, TypeScript, Tailwind. Розробили схему з 5 типами документів. Studio — з кастомними прев'ю статей, валідацією slug та інтеграцією з Unsplash. Налаштували RSC: дані завантажуються на сервері за допомогою client.fetch, що виключає hydration mismatch. Live Preview — через @sanity/preview-kit з SSE. Підсумок: TTFB знизився на 40%, INP залишився в зеленій зоні.
Процес роботи
- Аналітика — вивчаємо поточну CMS, вимоги редакторів, структуру контенту.
- Проєктування схеми — створюємо типи документів, зв'язки, валідацію.
- Налаштування Studio — кастомізація під бренд, плагіни, поля.
- Інтеграція з фронтендом — GROQ-запити, рендеринг Portable Text, Live Preview.
- Тестування — перевірка продуктивності, помилок, безпеки.
- Деплой — публікація Studio на Vercel або хостингу, налаштування CDN.
Що входить у роботу
- Повна схема даних (типи, поля, валідація).
- Кастомізована Sanity Studio.
- Відтворення Portable Text з підтримкою зображень і коду.
- Live Preview (опціонально).
- Webhooks для ревалідації кешу.
- Документація з GROQ та роботи зі Studio.
- Навчання редакторів (1 година).
- 1 місяць технічної підтримки.
| Етап | Термін | Результат |
|---|---|---|
| Аналітика та проєктування | 1-2 дні | Документ схеми, список полів |
| Розробка схеми та Studio | 1-2 дні | Типи, вкладки, валідація |
| Інтеграція з фронтендом | 1-2 дні | GROQ-запити, рендеринг, прев'ю |
| Тестування та налагодження | 1 день | Відсутність помилок, метрики |
| Деплой та документація | 0.5 дня | Працюючий проєкт |
Порівняння: Sanity vs WordPress (headless)
| Критерій | Sanity | WordPress (REST) |
|---|---|---|
| Швидкість редактора | Миттєво | 2-3 сек (AJAX) |
| Кастомізація схеми | Будь-яка | Обмежена ACF |
| Продуктивність API | <50ms | 200-400ms |
| Гнучкість типів контенту | Повна | Таксономії + CPT |
Вартість ліцензії WordPress з преміум-плагінами може перевищувати 100 000 ₴ на рік, тоді як Sanity безкоштовний до 20 000 документів.
Типові помилки
Часті проблеми при інтеграції Sanity
- Відсутність індексів — GROX без індексів гальмує на великих наборах. Використовуйте
order()за індексованими полями. - Сирі зображення — без auto=format і WebP LCP падає. Налаштуйте builder одноманітно.
- Неправильний підпис webhooks — перевіряйте секрет через
@sanity/webhook-toolkit, інакше зловмисник може перебудувати кеш. - Глибокі вкладені посилання — уникайте references глибше 2 рівнів, інакше зростає час запиту.
Терміни орієнтовно
Базова інтеграція (схема, Studio, GROQ, підключення до Next.js) — від 3 до 5 робочих днів. Live Preview, кастомні плагіни, webhooks — плюс 3–4 дні. Вартість розраховується індивідуально після аудиту проєкту.
Гарантії та досвід
Наша команда працює з headless CMS понад 5 років і реалізувала 15+ проєктів на Sanity. Ми гарантуємо дотримання Core Web Vitals і надаємо 1 місяць підтримки. Зв'яжіться з нами для безкоштовного аудиту вашого проєкту. Замовте інтеграцію Sanity та отримайте місяць підтримки в подарунок.