Jamstack сайт - это архитектура, где фронтенд собирается заранее в статику или рендерится на границе сети, а вся динамика (формы, оплата, личный кабинет) идет через отдельные API. Я перевожу на эту схему проекты клиентов последние года три, чаще всего на Next.js, и в этой статье разберу без маркетинговых обещаний, что это дает бизнесу и где схема не оправдывает себя.
Что такое Jamstack-архитектура простыми словами
Аббревиатура расшифровывается как JavaScript, API, Markup. Суть в разделении: контент и разметка генерируются заранее (build time) или на edge-сервере, а всё, что требует базы данных или логики - платежи, авторизация, отправка формы - вынесено в отдельные API-эндпоинты. Классическая CMS вроде WordPress на каждый запрос поднимает PHP, идет в базу MySQL, собирает страницу и отдает её пользователю. Jamstack-подход отдает уже готовый HTML из CDN, а к серверу обращается только тогда, когда это реально нужно.
На практике это выглядит так: страницы каталога и статьи блога генерируются заранее и лежат на CDN как обычные файлы, а корзина, расчет доставки через СДЭК или прием оплаты идут через serverless-функции, которые запускаются по запросу. Пользователь не ждет, пока сервер соберет страницу - он получает её мгновенно, а динамика подгружается точечно.
Next.js как фреймворк для Jamstack-проекта
Next.js я выбираю не потому что это модно, а потому что он закрывает главный минус классического Jamstack - полностью статичную сборку, которая не годится для каталога из тысяч товаров или ленты новостей с ежедневными обновлениями. У Next.js есть три режима рендеринга, и в реальном проекте они обычно смешиваются:
- Static Site Generation (SSG) - страницы собираются один раз при билде, подходит для лендинга, статей, документации;
- Incremental Static Regeneration (ISR) - страница пересобирается по таймеру или по вебхуку, без пересборки всего сайта;
- Server-Side Rendering (SSR) - рендер на каждый запрос, нужен для персонализированного контента и личных кабинетов.
ISR - это как раз то, что превращает Jamstack из «сайта-визитки без обновлений» в рабочий инструмент для интернет-магазина. Товар обновили в CMS - прилетел вебхук на Next.js, конкретная страница пересобралась за секунды, остальные тысячи страниц не тронуты. Вот так обычно выглядит эндпоинт для ревалидации по вебхуку из CMS или из сценария n8n:
// app/api/revalidate/route.js
export async function POST(request) {
const { secret, path } = await request.json();
if (secret !== process.env.REVALIDATE_SECRET) {
return Response.json({ message: 'Invalid token' }, { status: 401 });
}
revalidatePath(path);
return Response.json({ revalidated: true, path });
}
Такой вебхук я обычно подключаю к CMS напрямую или прогоняю через сценарий в n8n, если нужно заодно уведомить менеджера в Telegram или обновить данные в другой системе.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Скорость и SEO: что реально получает бизнес
Отдача статики с CDN означает, что сайт открывается за 200-400 мс вместо 1,5-3 секунд, характерных для WordPress на среднем хостинге без кэширующих плагинов. Для бизнеса это не абстрактная метрика - Core Web Vitals напрямую влияют на позиции в Google и Яндексе, а с 2021 года это подтвержденный фактор ранжирования.
Из проектов, что я вел: интернет-магазин на WordPress с WooCommerce после переноса каталога на Next.js с ISR сократил время загрузки первой страницы с 2,8 до 0,6 секунды - просто за счет того, что PHP и MySQL перестали участвовать в отдаче каждой страницы. Конверсия из органического трафика выросла не мгновенно, но за три месяца показатель отказов на мобильных упал примерно на 15%. Это не гарантия для любого проекта, но направление стабильно повторяется.
Второй плюс - устойчивость к нагрузке. Статику CDN раздает без нагрузки на сервер, поэтому всплеск трафика после рекламной кампании или упоминания в СМИ не кладет сайт, как это регулярно случается с WordPress на бюджетном хостинге.
Jamstack, WordPress и Tilda: что выбрать под задачу
Сравнение честное, без перекоса в сторону Next.js - у каждого варианта своя ниша.
| Критерий | Jamstack / Next.js | WordPress | Tilda |
|---|---|---|---|
| Скорость отдачи | Высокая, статика + CDN | Средняя, зависит от хостинга | Средняя |
| Гибкость логики | Максимальная, любая интеграция через API | Высокая через плагины | Ограничена конструктором |
| Скорость запуска | 3-6 недель под сложный проект | 1-3 недели | Несколько дней |
| Правки контента без разработчика | Нужна headless CMS | Да, из коробки | Да, из коробки |
| Стоимость входа | от 80 000 ₽ (лендинг) | от 60 000 ₽ | от 30 000 ₽ |
Для быстрого лендинга под рекламную кампанию я честно рекомендую Tilda - там же можно навесить кастомный скрипт для интеграции с CRM или эквайрингом, если конструктора не хватает. Для интернет-магазина среднего размера с частыми правками контента без участия разработчика WordPress с WooCommerce всё ещё разумный выбор, особенно если нужна интеграция с эквайрингом Т‑Банка «из коробки» через готовый плагин. Jamstack на Next.js оправдан, когда важна скорость, SEO-трафик в больших объемах и проект будет расти - каталог на десятки тысяч товаров, мультирегиональность, сложная логика личного кабинета.
Где Jamstack не подходит и какие есть ограничения
Я не продаю Jamstack как решение для всех - у подхода есть реальные минусы, которые важно проговорить до старта:
- Контент-менеджеру без техфона сложнее - нужна headless CMS (Strapi, Sanity, Contentful) с отдельным интерфейсом, а не привычная админка WordPress;
- Динамический контент требует дополнительного проектирования - расчет доставки через API СДЭК, персональные цены, остатки на складе не ложатся в статику напрямую, их нужно выносить в API-роуты или SSR;
- Билд большого каталога (десятки тысяч страниц) может занимать минуты даже с ISR, если не продумать инкрементальную генерацию заранее;
- Порог входа для команды выше - нужен разработчик, который понимает и фронтенд, и работу с API, а не просто верстальщик.
Если у бизнеса нет команды, готовой поддерживать такую архитектуру, и контент меняется руками нетехнического человека каждый день, я обычно советую остаться на WordPress или Tilda - плюс к скорости от Jamstack тут не окупит рост сложности эксплуатации.
Сколько стоит разработка Jamstack-сайта на Next.js
Цена зависит от того, что стоит за фронтендом. Лендинг на Next.js без сложной логики - от 80 000 ₽, это статика с формами и интеграцией аналитики. Как только в проекте появляется каталог, личный кабинет, платежи или связка с внешними сервисами вроде СДЭК или эквайринга, проект переходит в категорию веб-сервиса - от 150 000 ₽, потому что кроме фронтенда нужен отдельный backend, часто на Laravel (от 100 000 ₽ отдельной услугой, если backend делается независимо от фронта).
Автоматизацию вокруг сайта - пересборку страниц по вебхукам, синхронизацию каталога с 1С или CRM, уведомления в Telegram при новом заказе - я обычно закрываю сценариями в n8n, это отдельная услуга от 25 000 ₽. Готовые куски таких интеграций для типовых задач - вебхуки ревалидации, синхронизация с СДЭК, оповещения через aiogram-бота - можно посмотреть в библиотеке готовых скриптов, часть из них адаптируется под конкретный стек быстрее, чем писать с нуля.
Для сравнения: на рынке студийная разработка похожего Jamstack-проекта с headless CMS и кастомным backend стартует у крупных агентств от 300 000 ₽ и уходит за миллион в зависимости от масштаба - это ориентир по рынку, не мои расценки.
Быстрый SEO-лендинг под продукт
Лендинг на Next.js
от 80 000 ₽
Подробнее →Частые вопросы
Чем jamstack сайт отличается от обычного сайта на WordPress?
Основная разница - в том, кто и когда собирает страницу. WordPress собирает HTML на лету при каждом запросе через PHP и MySQL. Jamstack-сайт отдает уже готовую статику из CDN, а к серверу или базе обращается только для динамических частей - форм, оплаты, авторизации. Это дает более высокую скорость и устойчивость к нагрузке ценой более сложной архитектуры на старте.
Можно ли перенести существующий сайт на WordPress на Jamstack без потери SEO?
Можно, но это отдельный проект, а не просто «пересборка». Нужно сохранить структуру URL, настроить 301-редиректы для изменившихся адресов, перенести метатеги и микроразметку, а после запуска какое-то время следить за индексацией в Search Console. На моей практике при аккуратном переносе просадки трафика не было - наоборот, скорость загрузки почти всегда подтягивала позиции вверх в течение 1-2 месяцев.
Нужна ли для jamstack сайта отдельная CMS для контента?
Если контент меняется редко и это делает разработчик - можно обойтись без CMS, храня данные в коде или в простой базе. Если правки вносит менеджер или маркетолог без технических навыков, нужна headless CMS вроде Strapi или Sanity - она дает привычный интерфейс редактирования, но отдает данные через API, а не рендерит страницы сама, как это делает WordPress.
Подходит ли Jamstack на Next.js для интернет-магазина с оплатой и доставкой?
Да, но с оговоркой: каталог и статические страницы собираются как обычный Jamstack-проект, а корзина, расчет доставки через API СДЭК и прием платежей (например, через эквайринг Т‑Банка) реализуются отдельными API-роутами или через SSR. Я делаю такие проекты по цене от 150 000 ₽, потому что кроме фронтенда нужен полноценный backend, а не просто статическая сборка.