Спор о статичных сайтах и CMS обычно крутят вокруг скорости и безопасности, хотя решает третье: процесс редактирования. Страница из одного файла грузится десятки миллисекунд, не имеет админки и базы, которые можно взломать, и хостится почти бесплатно. Ровно до того момента, когда страниц становится пятьдесят, а в шапке каждой нужно поменять номер телефона. С этой минуты выбор технологии перестаёт быть вопросом вкуса и становится вопросом того, кто и как часто будет менять контент. Разбор ниже отвечает на этот вопрос по шагам: сначала честные сценарии под каждый подход, потом ловушки роста и разумные границы применения.
Сценарии, где статичный HTML выигрывает у админки
Статика честно берёт своё на коротких дистанциях. Лендинг под рекламную кампанию, промо-сайт к запуску продукта, страница мероприятия, техническая документация, архивный микросайт - эти проекты объединяет одно: структура не меняется, страниц немного, а правки редки и предсказуемы. Здесь файловый сайт даёт максимум отдачи: минимальный Time to First Byte без обращений к базе, хостинг около нуля на Cloudflare Pages, Netlify или Vercel, полный контроль над каждой строкой кода и предсказуемое поведение под нагрузкой, потому что отдавать статике может даже простой веб-сервер без PHP.
Отдельный плюс - предсказуемость под рекламным трафиком. Посадочная, которая грузится мгновенно, дешевле в продвижении: скорость страницы учитывается в опыте использования, а значит и в оценке рекламных кампаний Google. Для коротких кампаний, где счёт идёт на дни, потерянное время на настройку CMS не окупается, а статичный лендинг правится за час силами одного фронтендера.
Второй честный сценарий - требования безопасности. У статичного сайта нет страницы входа, нет уязвимых расширений, нет форм, через которые в базу попадает вредоносный код: чтобы проникнуть на такой сайт, нужно захватить сам сервер или репозиторий, а это несравнимо дороже. Для финансовых, юридических и медицинских проектов минимальная уязвимая поверхность иногда важнее удобства редакторов. Git при этом заменяет историю изменений: каждая правка зафиксирована с автором и временем, откат делается одним действием, и случайно стёртый абзац возвращается за минуту.
Что происходит со ста страницами, написанными руками
Классика жанра: маркетинг просит поменять телефон в шапке. В CMS это поле в настройках и одна минута. На ста файлах - вечер скучной работы и гарантированные две-три страницы, где телефон всё-таки забыли. Проблема не в лени исполнителя, а в механике: ручная однотипная работа ошибается по определению.
Обратная сторона масштабируется линейно. Правка в файловом сайте означает столько ручных операций, сколько файлов затрагивает: сотня страниц - это сто правок шапки при смене логотипа. Копипаст разъезжается по файлам: у половины страниц обновлённый футер, у другой половины старый, и никто не помнит почему. Переименование одного файла ломает внутренние ссылки в десяти других, и проверять это приходится вручную. Мета-теги пишутся без валидатора: опечатка в canonical, забытый description, задвоенный title - типовые находки аудита большого статичного проекта.
Дальше хуже. Карта сайта не соберётся сама, редиректы не появятся из истории: при переносе структуры старые адреса пропадают молча, вместе с накопленными позициями. Проект держится на одном человеке, который писал вёрстку, и его отпуск превращается в заморозку изменений. SEO-специалист, получивший такой сайт, тратит первые часы не на оптимизацию, а на то, чтобы просто найти и вычитать все мета-теги по файлам. Чем больше страниц, тем дороже каждая правка и тем выше вероятность, что к следующему кварталу половина из них разъедется с шаблоном. Добавьте вторую языковую версию - и объём ручной работы удваивается: мета-теги каждой страницы нужно синхронизировать между языками, а опечатка в hreflang на статичном сайте живёт в файле, пока кто-нибудь не решит проверить. Команда, унаследовавшая такой проект, обычно начинает с недели инвентаризации: какие страницы существуют, что в них написано и где ссылки ведут в никуда.
Скорость, стоимость и безопасность в сухих цифрах
Сравнение выглядит нагляднее на конкретных величинах. Отдача статичного файла с CDN укладывается в десятки миллисекунд, потому что серверу не нужно собирать страницу из запросов к базе. Страница популярной CMS без страничного кеша честно тратит 300-800 миллисекунд до первого байта, и это без учёта плагинов, каждый из которых добавляет свои запросы. С кешем разница сжимается почти до нуля, но кеш - это слой, который надо настроить, обслуживать и время от времени чинить. По времени разработки сравнение тоже честное: статичный сайт на десять страниц пишется быстрее, чем на него ставится CMS, а вот сайт на сто страниц с шаблонами - уже сравнимая работа. Генератор сокращает разрыв: типовая сборка Hugo обрабатывает тысячи страниц за секунды, поэтому пересборка после правок не тормозит процесс. По деньгам картина похожая, только вместо часов разработки считаются часы администрирования.
Деньги считаются так же прямолинейно. Хостинг статики на Cloudflare Pages, Netlify или Vercel для небольшого проекта вписывается в бесплатный тариф или первые доллары в месяц, а билд-минуты стоят копейки. Сайту на CMS нужен хостинг с PHP и MySQL от 5-10 долларов в месяц для старта, а по-настоящему - вдвое-втрое дороже, плюс время администратора на обновления: типичный сайт на WordPress держит два-три десятка плагинов, и у каждого свой график релизов и свой риск. По безопасности картина зеркальная: у статики нет формы входа, по которой боты долбят ежедневно, и нет админки, забытой под паролем из восьми символов.
Генераторы статических сайтов как компромисс без базы данных
Между чистой статикой и полноценной CMS давно живёт третий путь - генераторы статических сайтов. Hugo, Astro, Eleventy, Jekyll собирают готовые HTML-файлы из шаблонов и контента в Markdown: шапка описана один раз, сборка раскладывает её по всем страницам, а контент редактируют в текстовых файлах рядом с кодом. Скорость отдачи остаётся почти статичной, зато правка шаблона применяется ко всем страницам сразу, а карта сайта и канонические ссылки генерируются автоматически. Переводы и локализация в генераторах решаются файлами: контент разных языков лежит в одноимённых разделах с суффиксами вроде .de.md, а hreflang генератор собирает при билде. Для команды это знакомый Git-процесс: правка приходит запросом на слияние, просматривается, уходит в основную ветку и разворачивается автоматически. Каждая сборка воспроизводима, откат - это пересборка предыдущего коммита, а любые эксперименты живут в ветках и не трогают продакшн.
Сборка запускается одной командой:
hugo --minify --destination public
npx astro buildРедактирование при этом делают удобным двумя способами: репозиторий хостят с веб-интерфейсом, где правки вносятся в форму без знания Git, или подключают headless-CMS вроде Strapi, Directus или Contentful. Редактор работает в привычной админке, а сайт по-прежнему собирается в чистые файлы и раздаётся с CDN. Такой связкой собирают маркетинговые сайты SaaS-компаний и корпоративные ресурсы на сотни страниц, где нет корзины, личных кабинетов и форм с сохранением в базу. Это и есть рабочая середина: скорость статики плюс управляемость без развёртывания PHP и MySQL.
Слабые места CMS, которые всплывают после первого года работы
У CMS свои ловушки, и проявляются они не сразу. Первая - обслуживание: ядро и десятки расширений требуют обновлений, а отложенные обновления копятся в технический долг, который однажды превращается в неделю незапланированных работ. Вторая - безопасность: главная причина взломов сайтов на WordPress - уязвимости плагинов и тем, поэтому список расширений держат на строгой диете и не ставят всё подряд. Третья - производительность: страница без кеша делает десятки запросов к базе, и честные 300-800 миллисекунд ожидания на дешёвом хостинге - обычная история, невидимая владельцу и заметная покупателю.
С кешем - Redis, Varnish или CDN - популярные CMS закрывают разрыв со статикой почти полностью, но слои кеширования сами становятся источником багов: устаревшая страница после публикации, отданный посетителю черновик, конфликт плагина кеша с SEO-плагином из-за canonical. Добавьте зависимость совместимости расширений при каждом крупном обновлении ядра - и получится честная цена админки: удобство редактора оплачивает системный администратор. Для компании, у которой нет человека, который этим займётся, CMS - не упрощение, а новый регулярный расход.
Отдельный пласт - редакторские риски. В админке без плагина версионности случайно стёртый текст не восстановить, черновик публикуется по невнимательности, а категория, переименованная на минутку, меняет адрес страницы, не оставив следа старого URL. В статике с Git такое невозможно в принципе, зато там невозможна и быстрая правка контентом без разработчика. Это и есть настоящий размен, а не строчки в сравнительной таблице.
SEO-следствия выбора и контроль против автоматизации
В поисковой оптимизации статике соответствует полный ручной контроль, CMS - автоматизация. У файловой страницы каждый мета-тег пишется руками:
<head>
<meta charset="utf-8">
<title>Widget example</title>
<meta name="description" content="Widget spec sheet and price list">
<link rel="canonical" href="https://example.com/widget/">
<script type="application/ld+json">
{"@context":"https://schema.org","@type":"Product","name":"Widget","url":"https://example.com/widget/"}
</script>
</head>На пяти страницах это надёжнее любого плагина: нет лишних скриптов, нет неожиданных canonical, микроразметку можно выверить до символа. На двухстах страницах ручной контроль превращается в источник ошибок, а CMS выдаёт карту сайта, редиректы плагином, hreflang и шаблоны мета-тегов с переменными. Обратная цена автоматизации - поведение по умолчанию: SEO-плагин на нестандартной странице может поставить canonical не туда, и без проверки такое замечают только по просадке видимости. Компромисс, к которому приходят большие статичные проекты, - дисциплина сборки: мета-теги выносятся в переменные шаблона, а названия и описания живут в одном файле с контентом страницы. Тогда опечатка ловится на ревью запроса на слияние, а не через полгода в отчёте по индексированию. Разумная граница проста: чем больше страниц и чем реже они меняются, тем сильнее аргументы в пользу шаблонов и сборки.
Признаки, что пора переезжать со статики, и обратные случаи
Практический сигнал о смене подхода умещается в короткий чек-лист:
- контент правит второй человек, не знающий HTML и Git;
- правки появляются чаще одного раза в неделю;
- проекту нужен блог с регулярной публикацией;
- появились формы с сохранением заявок в базу;
- нужен интернет-магазин, личный кабинет или приём оплаты;
- сайт разросся за сотню страниц и продолжает расти;
- мета-тегами должен управлять маркетолог без разработчика.
Если совпало больше двух пунктов, чистый HTML работает против бизнеса, и смотреть стоит в сторону генератора статических сайтов с headless-CMS или полноценной платформы. Переезд при этом почти безболезненный: адреса сохраняются один в один, редиректы не нужны, достаточно до и после перехода прогнать краулер и сверить карту сайта. Если не совпал ни один - переезд на CMS станет лишним усложнением: за удобную админку придётся платить обновлениями, хостингом и вниманием администратора. Технология здесь не цель, а зеркало процессов компании: сначала честный ответ на вопрос, кто и как часто правит контент, потом выбор инструмента.
На практике между полюсами живут гибриды. Сначала сайт собирают на генераторе, редактору ставят headless-CMS, а корзину, когда она понадобится, подключают внешним сервисом или отдельным приложением на поддомене. Каждый следующий слой добавляют, когда процесс требует, а не заранее: лишняя админка без редактора - это та же лишняя CMS, только сбоку.