Payload в Next.js приложении и кэш
Если вы используете Payload CMS вместе с Next.js, по-умолчанию, после редактирования контента в админке на фронтенде не обновляются данные. Это происходит из-за кеширования страниц, что абсолютно нормально. Вместо того чтобы отключать кеширование (и тем самым снижать производительность), правильный подход — это on-demand revalidation.
Оставляем кеш, но сбрасываем его точечно после изменений сущностей в самой CMS.
Next.js кэширует страницы
Если вы используете SSG или ISR (а вы почти точно используете), часть страниц отдаётся из статического кеша.
Это даёт скорость, стабильность и предсказуемость.
Докмунтация Next.js в этом случае советует ISR + on-demand revalidation.
Архитектура решения
- В Payload пользователь редактирует документ.
- После
saveилиdeletePayload вызывает внутренний endpoint реинвалидации. - Endpoint выполняет
revalidatePath(...)только для нужных URL. - Следующий запрос получает уже свежую версию.
Вы получите лучшее из двух миров: статическую производительность + мгновенное обновление контента.
Реализация
1. Создаём закрытый endpoint /api/revalidate
- принимает список путей для сброса;
- проверяет секрет (
REVALIDATE_SECRETилиPAYLOAD_SECRET); - вызывает
revalidatePath()для каждого пути; - возвращает понятный JSON-ответ.
2. Хуки в Payload
Используем afterChange и afterDelete. Давайте разберем на примере.
Для posts
Инвалидируем:
/blog/blog/{slug}/(если есть блок “последние посты”)/sitemap.xml
Для pages
- конкретную страницу (
/about,/pricing,/) /sitemap.xml
Для navigation и site-settings
Это уже layout-уровень:
path='/'+type='layout'/robots.txt/sitemap.xml
На что обратить внимание в продакшене
- Всегда задавайте
REVALIDATE_SECRET. - Логируйте ошибки реинвалидации.
- Учитывайте работу за reverse proxy (x-forwarded-host, x-forwarded-proto).
- Если вдруг проект вырастает — можно перейти на tag-based стратегию (
revalidateTag).
Заключение
Связка Next.js + Payload CMS отлично работает с кешированием.
Главное — выстроить правильную стратегию реинвалидаци.