Помните времена, когда статический сайт был сайтом-визиткой на голом 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 делает это из коробки. 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;Быть быстрой — по умолчанию, без шаманства с кешами;
Дружить с динамикой — там, где она действительно нужна;
Не отнимать ресурсы на поддержку.
Если ваш сайт — это контент, а не приложение, статика уже сейчас решает ваши задачи. Просто вы ещё не проверяли.
Комментарии (24)
diakin
17.02.2026 16:10поправил опечатку = запустил полную пересборку. 10 тысяч страниц, 5–10 минут ожидания
Это как это? В какой странице опечатка - ту поправил и залил. Остальные зачем трогать?
pae174
17.02.2026 16:10Если 10_000 страниц по отдельным товарам собираются на основании одного шаблона и вот в этом шаблоне нашли ошибку, то да, в случае статического сайта придется исправить ошибку в 10_000 файлах с описаниями товаров. В случае динамической генерации страниц с товарами было бы достаточно исправить ошибку в шаблоне страницы и после этого инвалидировать кэш.
leveler
17.02.2026 16:10А если через старый добрый SSI (Server Side Includes) странички собирать? Или это уже не совсем статика получается?
pae174
17.02.2026 16:10Минусы SSI по сравнению с чистой статикой:
SSI не позволит использовать предварительное сжатие контента в Nginx. Предварительное сжатие статики здорово разгружает процессор по сравнению со сжатием на лету. Отсутсвие сжатия здорово увеличивает трафик на текстовом контенте.
SSI не позволит использовать sendfile() для отдачи статики. Использование sendfile() позволяет уменьшить количество системных вызовов, которые надо будет сделать для выпихивания контента в сеть. Системные вызовы обходятся дорого.
SSI будет тратить время на сканирование текста страницы в поисках директивы.
Плюсы SSI по сравнени с чистой статикой:
Удобнее вносить изменения такие, которые затрагивают шаблонную часть множества однотипных страниц.
Однотипные страницы занимают меньше места на диске просто за счет того, что шаблонная часть вынесена в отдельный файл а не дублируется во множетсве страниц.
В принципе всё. Вы можете выбирать.
cyber-jet
17.02.2026 16:10Или кешировать вывод отдельных компонентов как это обычно делается на php. А сборка страницы из кешированной статики 10-15 компонентов происходит очень быстро и не сильно затратно.
DennisP
17.02.2026 16:10а если просто поставить перед вордпрессом (к примеру) кеш с внешней инвалидацией (например по хуку из админки посре редактирования поста), это будет не то же самое?
pae174
17.02.2026 16:10Нет, это не будет то же самое т.к. в вашем случае WP остается в качестве уязвимой компоненты системы, то есть через него можно пытаться ломать сайт. В случае же статического сайта на сервере вообще нет ничего кроме какого-нибудь условного Nginx и никакие такие скрипты и БД не используются вообще.
pvzh
17.02.2026 16:10А ещё статические сайты легко копировать для просмотра оффлайн (через wget например). Крайне полезное свойство при нынешней моде на блокировки.
savostin
17.02.2026 16:10Какого года статья? Все можно делать на статике, кроме страниц, которые должны быть проиндексированы поисковиками (и то). Я вообще не понимаю кто и зачем сегодня делает сайты, которые на каждый запрос отдают страницу полностью. Новости, статьи, короче тупотекст - понимаю. Но
Статика не подойдёт, если:
Контент меняется каждую минуту (биржи, котировки, соцсети).
У каждого пользователя свой персональный кабинет.
Контент массово создают сами пользователи.
Требуется сложная бизнес-логика на бэкенде с длинными транзакциями
имхо статика + API fetch
sergodeem Автор
17.02.2026 16:10Спасибо за дополнение! Действительно, для личных кабинетов и случаев со сложной бизнес-логикой это не совсем уместно. Поправил статью.
vladf
17.02.2026 16:10кроме страниц, которые должны быть проиндексированы поисковиками
Поясните, пожалуйста. Как раз статику индексируют без проблем. Особенно по сравнению с динамикой, в которой параметры передаются в GET и есть множество способов получить одно и то же меняя эти параметры или их порядок.
savostin
17.02.2026 16:10Это я и имел в виду. Сервер должен генерить только тот html, который будет "потребляться" поисковиками. Ну и параноиками, конечно, у которых Javascript отключен.
SolidSnack
17.02.2026 16:10Раньше выбор был бинарным: либо полностью динамический сайт, либо полностью статический.
Ого, интересно как, хорошо что эти искусственные ограничения только в голове, видимо)
gun_dose
17.02.2026 16:10В статье в плане преимуществ SSG практически сплошное враньё.
Усталость от переусложнения. Типовой WordPress-сайт на десять статей в год тянет PHP, MySQL, Apache, кеширование, плагины безопасности и еженедельные обновления. Это рабочее решение, но задаёшься вопросом: не слишком ли тяжёлая артиллерия для такой задачи?
А пунктом выше:
Бэкенд не исчезает — он выносится в микросервисы и API.
Автор, если тебе LAMP-стек с вордпрессом тяжело, то куда тебе в микросервисы?
WordPress тянет за собой шлейф обязательств:
Обновлять ядро
А некст не надо обновлять? У них каждые полгода критическая уязвимость.
Статика — это папка с HTML-файлами на CDN или хостинге.
А бэкенд с микросервисами уже куда делся? Понятно, что можно тот же некст поставить на локальную машину, билдить оттуда и пушить. Но что это значит для бизнеса? Плюс один комп со строго настроенным окружением. Специалист, который умеет обращаться с консолью, умеет чинить сборку, когда она падает. А если он уволится? Или платить за каждый билд вебстудии? Так и вебстудии не вечные. А тот же вордпресс залил и пользуйся себе админкой. Захотел поменять того, кто обслуживает сайт - пожалуйста, всё лежит в одном месте.
А вообще, что такое SSG? Сначала появились реактивные фреймворки, потом людям захотелось SEO, поэтому придумали SSR. Но на деле это получился дико тормознутый монстр, который годами пытались ускорить, и в итоге сдались, добавив SSG. Но решили умолчать, что статика - это всего лишь фронтенд. А за этим ещё кроется огромный айсберг в виде инфраструктуры для сборки и хранения данных.
monochromer
А такие точно есть? Сейчас в документации Eleventy такая функциональность помечена как to-do.
sergodeem Автор
Да, у Eleventy сейчас есть флаг --incremental, но он не делает полноценную инкрементальную сборку страниц в CI/продакшене. Он ускоряет работу в режиме serve при разработке, пересобирая локально только изменённые файлы. Это действительно не то, о чем говорится в статье. Да, есть плагины которые улучают инкрементальное поведение в процессе разработки, но это всё тоже для прода не подходит. Действительно в этом моменте информация, которая может запутать. Спасибо, уберу это из статьи.