Помните времена, когда статический сайт был сайтом-визиткой на голом HTML, а любой серьёзный проект требовал CMS?

Мы привыкли считать нормальным сайт на WordPress, «Битриксе» или хотя бы самописном Django. Статика же оставалась уделом гиков, документации и страниц о скором запуске.

В 2025 году статические сайты вернулись. Не в качестве альтернативы для бедных, а как зрелая архитектура, которая решает 90% задач быстрее, дешевле и безопаснее, чем тяжёлый бэкенд.

Просто мы не сразу заметили, как они научились тому, чего раньше не умели.

Что такое статический сайт и чем он отличается от динамического

Разница — в моменте сборки. Динамический сайт собирает страницу в момент запроса. Пришёл пользователь — бэкенд сходил в базу, натянул данные на шаблон, отдал HTML.

Статический сайт собирает страницу до запроса. Один раз, на этапе билда. На выходе — папка с готовыми HTML-файлами. Их остаётся только положить на хостинг.

В нулевых это называлось «сделать HTML-ки и залить по FTP». Сейчас это называется SSG и «инкрементальная сборка». Но суть та же: никакого рантайма на сервере.

Почему статика ушла в тень и что изменилось

Долгое время статика проигрывала динамике по трём причинам:

• первая: CMS давали удобную админку. Зашёл, написал пост, сохранил. Бизнесу не нужен Git, а визуальный редактор.

• вторая: статика требовала пересборки всего сайта при правке одной запятой. Десять тысяч страниц = десять минут ожидания.

• третья: формы, комментарии, поиск: на статике приходилось писать велосипеды или обходиться без них.

А потом случилось три сдвига, которые многие пропустили.

• Инфраструктура. Появились Netlify, Vercel, Cloudflare Pages. Билд, хостинг, SSL, инвалидация кеша за ноль рублей и пять минут настройки.

• Архитектура. Jamstack объяснил: статика не равна мёртвому сайту. Бэкенд не исчезает — он выносится в микросервисы и API.

• Усталость от переусложнения. Типовой WordPress-сайт на десять статей в год тянет PHP, MySQL, Apache, кеширование, плагины безопасности и еженедельные обновления. Это рабочее решение, но задаёшься вопросом: не слишком ли тяжёлая артиллерия для такой задачи?

Когда статический подход неэффективен

Без честного раздела ограничений не обойтись. Статика не подойдёт, если:

• Контент меняется каждую минуту (биржи, котировки, соцсети).

• У каждого пользователя свой персональный кабинет.

• Контент массово создают сами пользователи.

• Требуется сложная бизнес-логика на бэкенде с длинными транзакциями.

Но важно другое: коробка допустимых сценариев за пять лет расширилась в разы. То, что раньше требовало самописного бэкенда, сегодня собирается из коробки фреймворка для бэкенда.

Чему научилась статика. Три главных урока

1. Дружить с динамикой

Раньше выбор был бинарным: либо полностью динамический сайт, либо полностью статический.

Сейчас это не выбор, а композиция.

• Комментарии? Disqus, Isso или GitHub Issues как бэкенд.

• Формы? Netlify Forms, Formspree, самописная лямбда.

• Поиск? Lunr.js, Algolia, Pagefind.

• Аутентификация? Auth0, Supabase, Firebase.

Пользователь видит интерфейс, кликает, отправляет данные и не догадывается, что серверной части у сайта нет. Потому что она аккуратно вынесена в API. Статика перестала означать «мёртвый сайт».

2. Обновляться мгновенно

Главная боль статики десятилетней давности: поправил опечатку = запустил полную пересборку. 10 тысяч страниц, 5–10 минут ожидания, сброс кеша CDN, ещё пара минут на инвалидацию.

Сейчас эту проблему решили инкрементальной сборкой. Пересобирается только изменившаяся страница.

Next.js делает это из коробки. Eleventy — через плагины. Hugo — на уровне архитектуры. Netlify и Vercel научились пересобирать только то, что реально изменилось. Пуш в main и через 10–15 секунд правка в проде. 

3. Не требовать отдельной команды поддержки

Динамический сайт — это не только разработка, но и эксплуатация.

WordPress тянет за собой шлейф обязательств:

• Обновлять ядро;

• Обновлять плагины;

• Чистить последствия взломов;

• Платить за хостинг с поддержкой PHP.

Статика — это папка с HTML-файлами на CDN или хостинге.

Не потому что статический сайт невозможно взломать. Возможно, например, получить доступ к репозиторию, но масштаб ущерба принципиально иной. Нет админки = нет брутфорса. Нет базы данных = нет SQL-инъекций. Нет исполняемого кода на сервере — нет удалённого выполнения команд.

Безопасность на статике — не энтерпрайз-уровень с SIEM и пентестами. Она просто перестаёт быть задачей, которую нужно решать отдельно.

Кратко про инструменты

Hugo — если нужна скорость сборки. Один бинарник, никаких зависимостей. Ставится за 10 секунд, собирает тысячу страниц за пару мгновений.

Eleventy — если хотите контролировать каждый угол. Написан на Node, но генерит чистый HTML. Никакого клиентского JS, если вы его сами не добавили.

Jekyll — если живёте в GitHub Pages и не хотите думать об инфраструктуре. Староват, но работу делает.

Next.js — если вам нужна статика, но вы привыкли к React и компонентному подходу. Тяжеловат для простого блога, но для сложных интерфейсов — стандарт индустрии.

Чеклист: когда переходить на статику

Честный способ принять решение — задать себе три вопроса.

Если хотя бы на два вопроса вы ответили в пользу статики — имеет смысл попробовать пилотный проект.

Итог

Возвращение статических сайтов — это отказ от лишнего. Мы десять лет навешивали бэкенд туда, где достаточно HTML, потому что так принято и все используют WordPress.

Статика научилась:

• Быть гибкой — через композицию с API;

• Быть быстрой — по умолчанию, без шаманства с кешами;

• Дружить с динамикой — там, где она действительно нужна;

• Не отнимать ресурсы на поддержку.

Если ваш сайт — это контент, а не приложение, статика уже сейчас решает ваши задачи. Просто вы ещё не проверяли.