Статическая генерация сайта: JAMstack, время сборки, CDN и SEO

Четыре шага JAMstack и ключевые метрики сборки и SEO

Статическая генерация сайта: JAMstack, время сборки, CDN и SEO

Сначала вывод: Суть JAMstack не в “статике”, а в том, что страницы генерируются на этапе сборки, раздаются через CDN, а динамика добавляется через API. Сайт до 500 страниц на Hugo или Eleventy собирается в чистые статические файлы, размещается на Cloudflare Pages или Netlify, LCP стабильно держится в пределах 1,5 секунды, а расходы на сервер близки к нулю. Контринтуитивный момент: дружелюбность статики к SEO объясняется не мнимым отсутствием базы данных, а тем, что поисковый робот получает полный HTML уже при первом запросе — TTFB ниже 100 миллисекунд, быстрее любого SPA.

Первый вопрос: какую задачу решает JAMstack

Три буквы JAMstack означают JavaScript, API и Markup. В традиционной архитектуре запрос пользователя запускает запрос к базе данных на сервере, затем рендеринг HTML и только потом ответ — каждый шаг занимает время. JAMstack выполняет все три шага заранее, на этапе сборки, а готовые HTML-файлы при деплое попадают на глобальный CDN. Когда пользователь открывает страницу, CDN отдаёт файл напрямую, без обращения к бэкенду.

Контринтуитивный вывод: главная выгода JAMstack не в безопасности и не в экономии, а в SEO и скорости первой отрисовки. У страниц, которые генерирует база данных, TTFB обычно составляет от 300 до 800 миллисекунд, да ещё нужно дождаться загрузки и выполнения JavaScript. Статический HTML отдаётся CDN напрямую, TTFB часто ниже 100 миллисекунд, и робот получает полностью отрендеренный контент. Как измерять Core Web Vitals, читайте в Оптимизация Core Web Vitals.

Но статика не значит “неподвижность”. Интерактивные блоки страницы — форма заявки, остатки на складе, конвертация валют — работают на JavaScript через API прямо в браузере и не мешают статической раздаче HTML. В этом и смысл принципа “динамика через API”. Как выбрать CDN, читайте в Глобальное ускорение CDN.

Тип архитектуры	TTFB	Что получает робот	Расходы на сервер (в месяц)	Подходящие типы страниц
Статический HTML + CDN	50–100 миллисекунд	Полностью отрендеренный HTML	0–50 юаней	Статьи, карточки товаров, страница About
SSG + ISR (Next.js)	100–300 миллисекунд	Полный HTML	200–800 юаней	Статьи и списки, которые нужно регулярно обновлять
Динамический рендеринг SSR	300–800 миллисекунд	Нужно ждать рендеринга	1000–5000 юаней	Персонализация и страницы с данными в реальном времени
Чисто фронтенд-рендеринг SPA	20–50 миллисекунд (пустая оболочка)	Пустой HTML + JS	0–200 юаней	Админ-панели, не подходит для маркетинговых страниц

Второй вопрос: время сборки — первое узкое место при росте числа страниц

Когда страниц мало, время сборки не проблема: 50 страниц Hugo собирает за пару секунд. Но после 500 страниц разрыв между фреймворками становится заметным: Hugo по-прежнему укладывается в 30 секунд, Next.js может собираться 3–5 минут, а Gatsby — больше 10 минут. Время сборки влияет на две вещи: сколько ждать публикации контента и сколько терпеть при каждой правке опечатки.

Сценарий первый: B2B-блог на Next.js, за два года накопилось 300 статей. Меняешь заголовок одной статьи — полная сборка занимает 4 минуты, и команда начинает избегать частых правок. Решение — включить инкрементную статическую регенерацию (ISR) в Next.js или кэширование контентного слоя: пересобираются только затронутые пути, и время сборки падает с 4 минут до 20 секунд.

Сценарий второй: каталог товаров на 2000 SKU, у каждого SKU своя страница. Полная сборка Next.js занимает 12 минут и запускается раз в день. При таком объёме лучше сразу перейти на Hugo или Eleventy — сборка уложится в минуту. Как пакетно сжимать изображения, читайте в разделе SEO для изображений и WebP.

Объём страниц	Время сборки Hugo	Время сборки Next.js SSG	Рекомендация
Менее 100 страниц	2–5 секунд	30–60 секунд	Любой вариант, разница незаметна
100–500 страниц	5–20 секунд	1–3 минуты	Next.js подходит, включите инкрементную сборку
500–2000 страниц	20–60 секунд	3–8 минут	Лучше Hugo, Next.js требует серьёзной оптимизации
Более 2000 страниц	1–3 минуты	Более 10 минут	Только Hugo или шардированная сборка

III. Развёртывание на CDN: сколько ждать от коммита до глобального запуска

Процесс развёртывания в JAMstack прост: git push → платформа собирает проект → генерирует статические файлы → раздаёт их по узлам CDN. Vercel и Netlify нативно поддерживают Next.js и Eleventy, Cloudflare Pages хорошо работает с Hugo и чистой статикой. От коммита до глобальной доступности обычно проходит от 30 секунд до 3 минут.

Здесь легко наступить на грабли: инвалидация кэша CDN. Если вы изменили цену товара и развернули проект заново, часть периферийных узлов может ещё отдавать старую версию — до 24 часов. Решение — после развёртывания вручную запустить полное обновление кэша CDN или добавить в URL хэш содержимого (имя файла с хэшем, например style.abc123.css): новый файл автоматически заменит старый. Как настроить кэширование, читайте в разделе Стратегия кэширования сайта.

Пример из практики: бренд светильников для зарубежных рынков использует Next.js SSG, полная сборка 200 страниц товаров занимает 3 минуты. Маркетолог поменял фото товара, отправил код — и пользователи видят новое фото только после 3 минут сборки и ещё 1 минуты на обновление CDN. Потом включили ISR с ревалидацией каждые 60 секунд: после правки фото пользователи видят новую версию максимум через 60 секунд, а сборка сократилась с 3 минут до 40 секунд.

Платформа развёртывания	Бесплатный лимит	Количество узлов по миру	Лимит времени сборки	Для чего подходит
Vercel	100 ГБ трафика/мес	300+	6 минут/раз	Проекты на Next.js, командная работа
Netlify	100 ГБ трафика/мес	100+	30 минут/раз	Hugo/Eleventy, формы
Cloudflare Pages	Безлимитный трафик	300+	Без жёсткого лимита	Много страниц, важна цена
Свой сервер + Cloudflare CDN	CDN бесплатно, сервер отдельно	300+	Полный контроль	Нужна своя сборка

4. Взгляд SEO: почему статические сайты выигрывают по определению

Googlebot теперь умеет выполнять JavaScript, но время и ресурсы на это ограничены. Статический HTML отдаёт весь контент уже на первом запросе: роботу не нужно ждать выполнения JS, и контент не потеряется, если JS не загрузится. Что это даёт для SEO: страницы быстрее попадают в индекс, меньше ошибок рендеринга, структурированные данные гарантированно считываются.

Ещё один плюс: sitemap и структуру URL можно сгенерировать один раз на этапе сборки, без запросов к базе данных. Имена файлов, уровни каталогов и canonical-теги прописываются прямо в скрипте сборки — не возникает типичной для динамических сайтов проблемы, когда страница тега и страница статьи дублируют друг друга. Как оптимизировать sitemap, читайте в статье Оптимизация XML sitemap.

Но есть контринтуитивный момент: статический сайт выигрывает не по всем SEO-показателям. Если контент обновляется часто (например, цены или остатки меняются каждый день), после статизации данные устаревают: пользователь открывает страницу и видит цену суточной давности, а показатель отказов растёт. Такие страницы нужно подгружать через клиентский API в реальном времени, а не вшивать в статический HTML.

Ещё одна практическая деталь: обработка изображений на статическом сайте. WordPress при загрузке картинки автоматически создаёт несколько размеров, а в Hugo и 11ty это нужно прописать в скрипте сборки. Если этого не сделать, пользователь скачает оригинал шириной 4000 пикселей и будет смотреть его на телефоне — LCP взлетит с 1,5 до 4 секунд. Как настроить сжатие и конвертацию форматов, читайте в статье SEO изображений и формат WebP.

Показатель SEO	Статический сайт	Динамический сайт	Причина разницы
Полнота контента на первом экране для робота	100 %	60–90% (зависит от выполнения JS)	Не нужно ждать рендеринга
TTFB	50–100 миллисекунд	300–800 миллисекунд	Нет запросов к базе данных
LCP	1,0–1,8 секунды	2,0–4,0 секунды	Отдача напрямую с CDN, без бэкенда
Актуальность контента	Низкая (снимок на момент сборки)	Высокая (свежие данные на каждый запрос)	Статика — палка о двух концах
Надёжность структурированных данных	100 %	80–95%	Записываются в HTML при сборке

FAQ: частые вопросы

В чём JAMstack выигрывает у классического WordPress по SEO?

Выигрыш не в абстрактном «быстрее», а в трёх конкретных вещах: робот получает полный HTML уже на первом запросе и не ждёт выполнения JavaScript; TTFB обычно ниже 100 миллисекунд — в 3–8 раз быстрее динамического сайта; структурированные данные вшиты в HTML при сборке и не теряются, если JS не загрузится. По метрике LCP в Google PageSpeed статический сайт обычно набирает больше 90 баллов, а динамический после оптимизации — лишь 70–85.

Что делать, если сборка идёт слишком долго: 500 страниц на Next.js собираются 8 минут?

Три шага оптимизации. Первый: включите компилятор SWC в Next.js вместо Terser — сборка ускорится в 2–3 раза. Второй: используйте next/image и кеширование на уровне контента, чтобы изображения не обрабатывались заново при каждой сборке. Третий: включите ISR (инкрементальную статическую регенерацию) — при правке статьи перестраивается только её путь и связанные страницы списков, а не весь сайт целиком. Если после оптимизации сборка всё ещё занимает больше 5 минут, подумайте о переходе на Hugo: обычно он собирает сайт за 30 секунд.

Как продвигать обновления контента статического сайта в CDN? Нужно ли вручную чистить кеш?

Популярные платформы (Vercel/Netlify/Cloudflare Pages) после успешного деплоя сами отправляют новую версию на граничные узлы — вручную чистить кеш не нужно. Но CDN хранит кеш старых файлов до 24 часов: это стандартный TTL. Если нужно, чтобы изменения вступили в силу немедленно, после деплоя вызовите API платформы для purge. Для статики (CSS/JS/изображения) используйте имена файлов с хешем: новое имя автоматически делает старый кеш недействительным.

Какие страницы не стоит делать статическими?

Три типа страниц не стоит делать полностью статическими: страницы с данными в реальном времени (наличие на складе, цены, курсы валют, отслеживание доставки), сильно персонализированные страницы (личный кабинет, статус заказа) и страницы с малым трафиком, но частыми обновлениями (внутренние отчёты). Для этих трёх типов используйте SSR или подгрузку данных через клиентский API. А вот статьи, карточки товаров, About, Contact и страницы со списком статей — контентные страницы, которые отлично подходят для статики.

Как выбрать между Hugo и Next.js SSG?

Смотрите на два параметра: количество страниц и сложность интерактива. Для сайтов от 500 страниц, где главное — контент, выбирайте Hugo: быстрая сборка, простой деплой, плавная кривая обучения. Для сайтов до 500 страниц, где нужны React-компоненты для интерактива (например, конфигуратор товара или переключатель языков), выбирайте Next.js SSG + ISR. Часто встречается и гибридный подход: на Next.js делают главную и маркетинговые страницы, на Hugo или 11ty — блог, а результат сборки разворачивают на CDN единым пакетом.

Стоит ли платить за деплой JAMstack на Cloudflare Pages?

Для частных разработчиков и небольших команд Cloudflare Pages в основном бесплатен: неограниченная пропускная способность, 500 сборок в месяц, 50 проектов. Сверх этого — оплата по факту использования, обычно 10–30 долларов в месяц. Для сравнения: бесплатный тариф Vercel даёт 100 ГБ трафика в месяц, а неограниченная пропускная способность Cloudflare выгоднее для сайтов с большим трафиком. Небольшой команде при посещаемости до 10 000 просмотров в месяц это практически ничего не стоит.

В заключение

JAMstack — не новая концепция. По сути это «сделать заранее всё, что можно сделать заранее». Для B2B-сайтов, где главное — контент, такая архитектура выигрывает сразу по трём параметрам: производительность, стоимость и SEO. Отказываться от неё почти нет причин. Единственный барьер — команде нужно принять сам принцип «генерации на этапе сборки»: после правки контента приходится ждать сборки, а не видеть результат сразу, как в WordPress.

Начните с малого: перенесите на статический сайт только блог с помощью Hugo или Eleventy, а основной сайт на WordPress пока не трогайте. Через месяц сравните LCP, скорость индексации и расходы на сервер до и после переезда. Если выгода очевидна, постепенно переносите страницы товаров и главную. Плюс поэтапного переезда в том, что откатиться можно в любой момент.

Запомните одну мысль: преимущество статического сайта не в том, что он “статический”, а в том, что поисковый робот и пользователь получают один и тот же полный контент в один и тот же момент. Во времена динамического рендеринга это, наоборот, редкость.