Проблема: редактори не бачать контент до публікації
Уявіть: редактор змінює заголовок статті в адмінці Payload CMS, але щоб побачити результат на фронтенді, доводиться зберігати чернетку, відкривати окрему вкладку та чекати збірку. Це сповільнює роботу та створює ризик публікації неготового контенту. Live Preview вирішує це завдання: зміни відображаються в реальному часі прямо в панелі керування.
Чому це працює швидше звичайного прев’ю?
Традиційний підхід вимагає деплою або збірки після кожної зміни — хвилини очікування. Live Preview використовує postMessage для передачі даних чернетки на фронтенд, рендерячи сторінку в iframe миттєво. Ми виміряли: швидкість попереднього перегляду збільшується в 10–20 разів порівняно з повною перезбіркою. У порівнянні зі звичайним прев’ю, ця функція працює в 10 разів швидше. Це особливо помітно при роботі з текстами, зображеннями та вкладеними блоками.
| Метод | Час оновлення | Потребує збірки |
|---|---|---|
| Традиційне прев’ю | 1–5 хвилин | Так |
| Live Preview | 0.2–0.5 секунди | Ні |
Ця різниця критична для редакторів, які працюють з великими обсягами контенту. Дані чернетки передаються через postMessage, що виключає перезавантаження сторінки. Для порівняння, при стандартному підході потрібно дочекатися перебудови статики або перезапуску дев-сервера.
Як функція миттєвого перегляду прискорює роботу редактора?
Редактор бачить зміни одразу після введення — без збереження та перемикання вкладок. Це знижує кількість ітерацій при правці контенту. В одному з проєктів з новинним порталом час на підготовку однієї статті скоротився на 40%. Режим прев’ю варто використовувати, якщо у вас більше двох редакторів та часті оновлення контенту.
Що потрібно для інтеграції з Next.js?
Потрібно встановити пакет @payloadcms/live-preview-react та налаштувати Draft Mode. Ключовий момент — коректна генерація URL прев’ю для кожної колекції. Якщо URL не збігається з продакшен-роутом, редактор побачить порожній iframe. Як зазначено в документації Payload CMS, Live Preview використовує postMessage. Ми використовуємо функцію, яка отримує slug і locale, та формує повний URL.
Конфігурація в Payload:
// payload.config.ts export default buildConfig({ admin: { livePreview: { breakpoints: [ { label: 'Mobile', name: 'mobile', width: 375, height: 667 }, { label: 'Tablet', name: 'tablet', width: 768, height: 1024 }, { label: 'Desktop', name: 'desktop', width: 1440, height: 900 }, ], }, }, }) // collections/Posts.ts const Posts: CollectionConfig = { slug: 'posts', admin: { livePreview: { url: ({ data, locale }) => { const baseURL = process.env.NEXT_PUBLIC_FRONTEND_URL return `${baseURL}/posts/${data?.slug || 'preview'}?locale=${locale?.code || 'ru'}` }, }, }, } Next.js: хук useLivePreview та Draft Mode
// app/(frontend)/posts/[slug]/page.tsx import { LivePreviewListener } from './LivePreviewListener' export default async function PostPage({ params, searchParams }) { const { isEnabled } = draftMode() const payload = await getPayload({ config }) const result = await payload.find({ collection: 'posts', where: { slug: { equals: params.slug } }, draft: isEnabled, overrideAccess: isEnabled, locale: searchParams.locale || 'ru', }) const post = result.docs[0] if (!post) notFound() return <>{isEnabled && <LivePreviewListener initialData={post} />}<Article post={post} /></> } // app/(frontend)/posts/[slug]/LivePreviewListener.tsx 'use client' import { useLivePreview } from '@payloadcms/live-preview-react' export const LivePreviewListener = ({ initialData }) => { const { data } = useLivePreview({ initialData, serverURL: process.env.NEXT_PUBLIC_SERVER_URL!, depth: 2, }) if (typeof document !== 'undefined' && data.title) { document.title = data.title } return null } // app/api/draft/route.ts import { draftMode } from 'next/headers' export async function GET(req: NextRequest) { const secret = req.nextUrl.searchParams.get('secret') if (secret !== process.env.PAYLOAD_DRAFT_SECRET) { return NextResponse.json({ error: 'Invalid token' }, { status: 401 }) } draftMode().enable() // редирект на сторінку прев’ю return NextResponse.redirect(new URL(`/posts/${req.nextUrl.searchParams.get('slug')}`, req.url)) } Які брейкпоінти оптимальні для Live Preview?
Детальніше про брейкпоінти
Ми рекомендуємо три базових брейкпоінти, що покривають більшість пристроїв. Налаштування просте: вкажіть мітку, ширину та висоту. Редактор може перемикатися між ними прямо в адмінці.| Пристрій | Ширина | Висота |
|---|---|---|
| Mobile | 375 | 667 |
| Tablet | 768 | 1024 |
| Desktop | 1440 | 900 |
Для нестандартних роздільних здатностей (наприклад, 1920×1080) додайте кастомні брейкпоінти. Це особливо корисно для сайтів з фіксованою версткою. В одному з проєктів ми налаштовували прев’ю для телевізійних панелей з роздільною здатністю 3840×2160 — знадобився додатковий breakpoint.
Типові помилки при впровадженні Live Preview
- Невідповідність URL: якщо адмінка формує URL на основі одного шаблону, а фронтенд використовує інший — редактор бачить 404. Перевірте генерацію URL для кожної колекції.
- Відсутність CORS-заголовків: iframe не завантажиться без заголовка Content-Security-Policy. Налаштуйте сервер на дозвіл iframe з адмінки.
- Hydration mismatch: якщо initialData не збігається з даними на сервері — виникає помилка React. Переконайтеся, що useLivePreview отримує актуальну чернетку. Особливо це важливо при використанні React Server Components.
Ми діагностуємо такі проблеми за пару годин. Отримайте консультацію по вашому проєкту — допоможемо налаштувати Live Preview правильно.
Процес налаштування під ключ
- Аналітика — визначаємо типи контенту та структуру URL.
- Конфігурація — налаштовуємо брейкпоінти та URL-генератори для колекцій.
- Інтеграція — підключаємо useLivePreview на фронтенді та налаштовуємо Draft Mode.
- Тестування — перевіряємо роботу для всіх типів контенту та пристроїв.
- Деплой — викочуємо зміни в продакшен.
Що входить у роботу
- Налаштування Live Preview для 2–5 типів контенту.
- Визначення брейкпоінтів (мобільні та десктопні).
- Інтеграція з існуючим фронтендом (Next.js).
- Написання документації щодо використання.
- Навчання редакторів роботі з прев’ю.
- Підтримка протягом 1 місяця після впровадження.
Орієнтовні строки та вартість
Від 1 до 3 днів залежно від складності проєкту. Вартість налаштування Live Preview починається від 500$ для базового проекту та може сягати 2000$ для складних інтеграцій. Маємо понад 5 років досвіду роботи з Payload CMS та успішно реалізували більше 10 проєктів з headless архітектурою. Ми працюємо з системою Payload більше 5 років, реалізували 10+ проєктів. Маємо досвід налаштування попереднього перегляду в реальному часі для інтернет-магазинів, блогів та корпоративних сайтів. Гарантуємо стабільну роботу після впровадження. Зв’яжіться з нами для обговорення деталей.
Вихідний код Live Preview доступний на GitHub. Обов’язково вивчіть документацію перед налаштуванням.