Короткий ответ: статический сайт (SSG) отдаёт готовый HTML за 50–200 мс, динамический — за 300–2500 мс. Это разница в 5–15 раз. Для коммерческого сайта без сложной логики (лендинг, корпоративный сайт, каталог, блог) статика — однозначно правильный выбор: быстрее, дешевле в хостинге (от 200 ₽/мес), безопаснее (нет серверного кода для взлома). Динамика оправдана только там, где есть личные кабинеты, корзина с реальным временем, авторизация — и то всё чаще это делается гибридно: статика для контента, динамика только для интерактивных частей.
Как работает статический сайт — простая схема
Статический сайт — это набор готовых HTML, CSS, JavaScript и медиафайлов на сервере. Когда пользователь запрашивает страницу:
- Браузер отправляет запрос на сервер
- Веб-сервер (nginx, Apache, CDN) берёт готовый HTML-файл с диска
- Отправляет его в браузер
Никакой логики, никаких запросов в базу, никакого исполнения PHP/Node.js. Просто отдача файла. Время на сервере — 5–30 мс.
Если сайт раздаётся через CDN (Cloudflare, BunnyCDN, Selectel CDN), HTML кэшируется ближе к пользователю, и время до первого байта (TTFB) падает до 30–80 мс независимо от страны посетителя.
SSG (Static Site Generation) — это автоматизированный способ собирать такой сайт. Вы пишете компоненты на React (или Vue, Svelte), берёте данные из JSON, CMS или Markdown, а на этапе деплоя инструмент (Vite, Next.js, Astro, Hugo) генерирует HTML для каждой страницы. Результат — папка с тысячами готовых файлов, готовых к раздаче.
Как работает динамический сайт — где теряется время
Динамический сайт (WordPress, Bitrix, классический Drupal, MODX) собирает HTML на каждый запрос пользователя. Цикл такой:
- Браузер отправляет запрос
- Веб-сервер передаёт запрос интерпретатору (PHP-FPM, Python WSGI, Node.js)
- Интерпретатор запускает код CMS
- CMS делает 20–100 запросов в базу данных (MySQL, PostgreSQL)
- Получает данные, обрабатывает плагины, шаблоны
- Собирает HTML-строку
- Отдаёт серверу, который отправляет в браузер
Каждый шаг — это время. На дешёвом shared-хостинге всё вместе занимает 800–2500 мс. На VPS с оптимизацией — 200–600 мс. С кэшированием через WP Rocket или Redis — 100–300 мс (но за счёт усложнения архитектуры и риска показать устаревший контент).
Главная проблема: пиковые нагрузки. Если на сайт зашло 100 человек одновременно, интерпретатор начинает «душить». TTFB взлетает до 3–6 секунд, сайт может вообще упасть (HTTP 503). Статический сайт это не волнует — он раздаёт файлы с той же скоростью при 1 посетителе и при 10 000.
Сравнительная таблица: статика вс динамика по 12 параметрам
| Параметр | Статический сайт (SSG) | Динамический (WordPress, Bitrix) | Победитель |
|---|---|---|---|
| TTFB | 50–200 мс | 300–2500 мс | SSG ×5–×15 |
| LCP | 0.5–1.0 с | 2.0–4.5 с | SSG ×3–×5 |
| PageSpeed mobile | 92–100 | 45–75 | SSG |
| Стоимость хостинга | 200–500 ₽/мес (CDN) | 800–5000 ₽/мес (VPS) | SSG |
| Безопасность | Нечего взламывать | 1500+ CVE в ядре и плагинах | SSG |
| Стойкость к ДДоС | Очень высокая (CDN) | Низкая без защиты | SSG |
| Масштабируемость | Бесконечная (CDN) | Ограничена сервером | SSG |
| Сложность разработки | Средняя (React/Vite) | Низкая (WordPress) | Dynamic |
| Обновление контента | Через Git или headless CMS | Через веб-интерфейс CMS | Dynamic (для не-разработчиков) |
| Динамический контент | Через API и JS | Из коробки | Dynamic |
| SEO из коробки | Отличный | Слабый без плагинов | SSG |
| GEO (AI-цитирование) | Отличный | Средний | SSG |
Итог: из 12 параметров SSG выигрывает в 9, динамика — в 3 (и все три решаются либо гибридами, либо headless CMS). Это объясняет, почему в 2024–2026 годах большинство новых бизнес-сайтов в коммерческом сегменте делаются на статике.
Core Web Vitals: измеримая разница в числах
Сравним типичный лендинг на двух платформах. Контент идентичный — главный экран, 5 секций с услугами, отзывы, FAQ, форма.
WordPress (Avada тема + WP Rocket + VPS 1 ядро/2 ГБ за 400 ₽/мес):
- TTFB: 650 мс (с кэшем), 1850 мс (без кэша)
- FCP (First Contentful Paint): 1.4 с
- LCP (Largest Contentful Paint): 2.4 с
- CLS (Cumulative Layout Shift): 0.08
- INP (Interaction to Next Paint): 180 мс
- Размер HTML: 380 КБ
- PageSpeed mobile: 62
React + SSG (Vite, тот же VPS):
- TTFB: 90 мс
- FCP: 0.4 с
- LCP: 0.7 с
- CLS: 0.01
- INP: 45 мс
- Размер HTML: 22 КБ
- PageSpeed mobile: 96
Разница в TTFB — в 7–20 раз. В LCP — в 3 раза. В размере HTML — в 17 раз. PageSpeed +34 балла.
По данным Backlinko 2025 года, каждый дополнительный балл PageSpeed выше 70 даёт в среднем +0.4% к органическому трафику. Переход с 62 на 96 — это +13% трафика только за счёт скорости, без изменения контента.
Как Google и Яндекс оценивают скорость
С 2021 года Google официально включил Core Web Vitals как фактор ранжирования. Метрики:
- LCP — менее 2.5 с (хорошо), 2.5–4 с (требует улучшения), более 4 с (плохо)
- CLS — менее 0.1 (хорошо), 0.1–0.25 (требует улучшения), более 0.25 (плохо)
- INP (заменил FID в 2024) — менее 200 мс (хорошо), 200–500 мс (требует улучшения)
Сайт, у которого 75% страниц проходят все три метрики «хорошо», получает положительный ранжирующий сигнал. С 2024 года Яндекс также явно учитывает Core Web Vitals в своём алгоритме «качество сайта».
Статический сайт на SSG из коробки проходит все три метрики на 95–100% страниц. WordPress с типовой настройкой — на 40–60% страниц. Это создаёт системное преимущество статики в ранжировании.
AI-краулеры: почему статика = больше цитирований
AI-краулеры (OAI-SearchBot, PerplexityBot, YandexGPTBot) экономят бюджет. Они не ждут медленные сайты. Если TTFB больше 1500 мс — запрос прерывается, сайт помечается как «медленный» и приоритет понижается.
Дополнительно: AI-краулеры не исполняют JavaScript (за редким исключением OAI-SearchBot в особых случаях). Если на странице важный контент рендерится JS — для AI его не существует.
Статический сайт решает обе проблемы сразу: мгновенный TTFB и весь контент в HTML с первого запроса. По нашим данным, статические сайты цитируются в YandexGPT и Perplexity в 3–5 раз чаще, чем сопоставимые WordPress-сайты в той же нише.
Когда динамика оправдана: интернет-магазины, личные кабинеты
Динамический сайт необходим там, где контент действительно меняется на каждый запрос:
- Личный кабинет с авторизацией — у каждого пользователя свой контент
- Корзина и оплата — состояние корзины меняется в реальном времени
- Поиск с фильтрами по большому каталогу — 10 000+ товаров с десятками комбинаций фильтров
- Чаты, дашборды, админки — интерактивность критична
- Сложная редакторская работа — десятки авторов, расписания, модерация
Для большинства бизнес-сайтов ничего из этого нет. Лендинг, корпоративный сайт, каталог услуг, блог — это контент, который меняется раз в день или раз в неделю. Идеальный кандидат на статику.
Безопасность: почему статику практически невозможно взломать
Динамический сайт — это миллион строк PHP/JS/Python-кода, который выполняется на вашем сервере. Каждая строка — потенциальный вектор атаки. По статистике Wordfence за 2025 год, в Ядре WordPress было обнаружено 43 критических уязвимости, в популярных плагинах (Elementor, WPBakery, RankMath) — ещё 1500+. Средний WordPress-сайт взламывается раз в 18–24 месяцев, если вовремя не обновлять плагины.
Статический сайт на СДН — это папка с файлами HTML/CSS/JS. Никакого серверного кода, никакой базы данных, никакой админки. Взлом в классическом смысле невозможен. Единственный вектор атаки — взлом вашего Git-репозитория или панели СДН, но обе защищены 2FA и сложными паролями.
Отдельный бонус — защита от ДДоС. Статический сайт через Cloudflare или BunnyCDN выдерживает атаки 100+ Gbps без ваших усилий. Динамический сайт на VPS за 800 ₽/мес «упадает» при атаке в 5–10 Gbps и требует сложных настроек fail2ban и специальных anti-DDoS сервисов.
Гибридные подходы: лучшее из двух миров
В 2026 году чаще всего используется гибридный подход: статика для контента + динамика для интерактивных частей через API.
Примеры:
- Интернет-магазин: каталог и карточки товаров — SSG; корзина и оплата — React-компонент с обращением к API
- Блог с комментариями: статьи — SSG; комментарии загружаются через JS из стороннего сервиса (Disqus, Hyvor Talk)
- Корпоративный сайт с формами: контент — SSG; форма заявки отправляется на API endpoint (PHP-скрипт или serverless function)
- Сайт с поиском: страницы — SSG; поиск через Algolia или Meilisearch
Это даёт скорость статики и интерактивность динамики. Большинство современных сайтов на React/Vue делаются именно так.
Таблица: что выбрать для каких задач
Краткий гид по выбору архитектуры:
- Лендинг (1–3 страницы) → SSG. Скорость критична, динамика не нужна.
- Сайт-визитка (5–15 страниц) → SSG. Аналогично.
- Корпоративный сайт (20–80 страниц) → SSG. Особенно если важно SEO.
- Блог → SSG. Комментарии — через сторонний сервис.
- Каталог услуг с GEO-страницами (50–500 страниц) → SSG. Автогенерация на этапе сборки.
- Интернет-магазин до 1000 товаров → гибрид: SSG для каталога, API для корзины.
- Интернет-магазин 10 000+ товаров с фильтрами → SSR или ISR (Incremental Static Regeneration), как в Next.js.
- SaaS с личным кабинетом → SPA + SSR для маркетинговых страниц.
- Медиа с десятками авторов и сотнями статей в месяц → CMS (WordPress headless с фронтом на React/Next.js).
- Социальная сеть, маркетплейс, биржа → SSR + SPA для динамических разделов.
Типичные возражения против статики и ответы
«На статике нельзя редактировать контент без разработчика». Неправда. Современные headless CMS (Strapi, Sanity, Contentful, Decap, Tina) дают полноценный веб-интерфейс редактора. Сохранение вызывает пересборку сайта через webhook — обновление публикуется за 1–3 минуты. Для врача или юриста это неразличимо от WordPress.
«На статике не сделать поиск по сайту». Неправда. Сервисы Algolia, Meilisearch, FuseJS, Pagefind дают мгновенный поиск по тысячам страниц без сервера. Pagefind вообще работает на стороне браузера — индекс собирается на этапе сборки и выгружается как JSON.
«Статика не подходит для персонализации контента». Частично правда, но персонализация решается через JavaScript на стороне клиента: HTML отдаётся общий, а персональные блоки подгружаются через API. Поисковики видят общий HTML, пользователи — персональный опыт.
«Нужны обычные веб-мастера, а не верстальщики». Правда, но это одноразовые инвестиции на этапе разработки. После запуска редактор работает в CMS без веб-разработчика. Стоимость входа в React + SSG выше, чем WordPress, но вход был высоким всегда — разработчики, умеющие делать быстрые и красивые сайты на WordPress, исторически были в меньшинстве.
SSG-инструменты в 2026: что выбрать
Рынок SSG-фреймворков в 2026 году очень разнообразен. Кратко про топ-7:
- Vite — наш выбор. Лёгкий, максимально быстрый в разработке, не вяжет к конкретному хостингу. Плюс puppeteer-prerender для генерации HTML — идеально для коммерческих сайтов.
- Next.js (export mode) — мощный, но более тяжёлый. Подходит для проектов, где в будущем может понадобиться SSR или ISR.
- Astro — ориентирован на контентные сайты и блоги. Отлично работает с Markdown, поддерживает React/Vue/Svelte одновременно. Меньше JS в выходе.
- Hugo — самый быстрый в сборке (на Go), подходит для больших блогов. Сборка 10 000 страниц за 30 секунд. Но Go-шаблоны не всем удобны.
- Eleventy (11ty) — минималистичный SSG на Node.js. Нет React/Vue «по умолчанию», самый «чистый» HTML на выходе.
- Gatsby — раньше был лидером, в 2026 теряет позиции. Избыточность GraphQL и медленные сборки — главные причины падения популярности.
- Jekyll — «ветеран», встроен в GitHub Pages. Подходит для документации и простых блогов. На Ruby.
Для бизнес-сайтов на русском языке рекомендуем Vite + React или Astro. Это свежие инструменты с хорошей экосистемой, поддерживаются большинством статических хостингов (Cloudflare Pages, Netlify, Vercel, BunnyCDN).
Кейс миграции с WordPress на SSG
Один из наших клиентов — клининговая компания в Краснодаре. Был сайт на WordPress: 18 страниц, тема BeTheme, плагины WP Rocket и Yoast SEO. Хостинг — VPS за 800 ₽/мес.
Состояние до миграции (январь 2025):
- PageSpeed mobile: 51
- TTFB: 1200 мс
- LCP: 3.4 с
- Органический трафик: 290 уников/мес
- Заявок в месяц: 12
- Стоимость владения: 800 ₽ хостинг + 1500 ₽ обновления безопасности
Миграция на React + SSG (3 недели работы):
- PageSpeed mobile: 98
- TTFB: 85 мс
- LCP: 0.6 с
- Через 4 месяца органический трафик: 1 240 уников/мес (+327%)
- Заявок в месяц: 47 (+292%)
- Стоимость владения: 200 ₽ хостинг (статика на BunnyCDN)
Окупаемость миграции — 4.5 месяца за счёт роста заявок и снижения стоимости хостинга. Это типичный кейс — мы наблюдаем такую динамику на большинстве проектов миграции. Подробнее о процессе — на странице разработки сайта, или прочитайте смежные статьи: React vs WordPress SEO, SSG vs SPA.
Стоимость владения за 3 года: статика vs динамика
Один из самых сильных аргументов в пользу статических сайтов — экономия на эксплуатации. Динамический сайт требует не только хостинга, но и регулярного обслуживания: обновления CMS, патчи безопасности, защита от ботов, бэкапы базы данных. Сравним суммарную стоимость владения корпоративным сайтом-визиткой на 50 страниц за три года.
| Статья расходов | WordPress / Bitrix | React SSG |
|---|---|---|
| Хостинг VPS / CDN | 54 000 ₽ (1 500 ₽/мес) | 7 200 ₽ (200 ₽/мес) |
| SSL-сертификат | 0 ₽ (Let's Encrypt) | 0 ₽ (CDN включает) |
| Обновления и патчи | 36 000 ₽ (1 000 ₽/мес) | 0 ₽ |
| Резервные копии БД | 18 000 ₽ (500 ₽/мес) | 0 ₽ (Git история) |
| Защита от ботов / WAF | 21 600 ₽ (Cloudflare Pro) | 0 ₽ (атаковать нечего) |
| Аварийный ремонт после взлома | ~30 000 ₽ (среднее) | 0 ₽ |
| Итого за 3 года | 159 600 ₽ | 7 200 ₽ |
Разница в 22 раза при сопоставимом функционале. Конечно, для интернет-магазина с тысячами товаров эти цифры не работают — там нужна динамика. Но для сайта-визитки, лендинга, портфолио, корпоративного сайта услуг — статика выигрывает не только в скорости, но и в эксплуатационных расходах. Калькуляцию для вашего проекта сделаем на странице цен.
Когда не стоит мигрировать на статику
Несмотря на все преимущества, статические сайты подходят не для каждого случая. Перечислим ситуации, когда миграция нецелесообразна или преждевременна:
- Сложный личный кабинет пользователя — если у вас тысячи зарегистрированных клиентов с индивидуальными данными, заказами, балансом, переход на статику потребует полной переработки архитектуры с выносом всей логики в API и SPA-слой. Часто проще оставить динамику.
- Каталог свыше 10 000 SKU с частыми изменениями цен — на сборку 10к страниц современный сборщик тратит 5-15 минут. Если цены меняются каждый час, а товары добавляются ежедневно — статика становится узким местом. Здесь лучше ISR (Next.js) или гибридная архитектура.
- Пользовательский контент в реальном времени — форумы, чаты, комментарии, отзывы с мгновенной публикацией. Чисто статические решения для этого не предназначены. Можно решить через сторонние сервисы (Disqus, Cusdis), но это компромисс.
- A/B-тесты с динамическим контентом — если вы постоянно подменяете тексты, изображения, CTA на основе сегментов аудитории, проще делать это на серверной стороне. На статике придётся делать клиентский JS-вариант, который негативно влияет на CLS и LCP.
- Закрытые корпоративные системы — внутренние порталы, CRM, ERP — это домен веб-приложений, а не сайтов. Статика тут просто не нужна.
В остальных 80% случаев — сайты услуг, визитки, лендинги, информационные ресурсы, блоги, портфолио, каталоги до 5 000 страниц — статика выигрывает по всем метрикам. Если сомневаетесь, какая архитектура подойдёт именно вашему проекту, оставьте заявку на странице контактов — проведём бесплатный технический аудит и предложим оптимальный стек.