Когда я перешёл на статику

Лет десять я ставил клиентам WordPress на каждый чих. Это казалось очевидным выбором — экосистема, плагины, админка из коробки. Сначала всё работало, а потом начались обновления, конфликты плагинов, дыры в безопасности, и каждое утро я открывал терминал и проверял что ночью никого не сломали.

Переломный момент — когда у меня стало больше десяти сайтов на сопровождении. Я понял что трачу на администрирование больше времени, чем на саму разработку. И что половина этого времени — про вещи, которые на статике просто не существуют.

Что я понял за пять лет на статике

Меньше attack surface. Не нужно следить за версиями WP-ядра и плагинов. Нулевой runtime — нет PHP-FPM, нет MySQL, нет очередей. TTFB не зависит от нагрузки — что один посетитель, что тысяча, время отдачи одно. Кэширование тривиальное — отдаём файлы с диска.

Минусы тоже есть, и я их не скрываю. Поиск нужно делать через внешний сервис или индексировать на этапе сборки. Формы — это отдельный мини-сервис, не часть сайта. Ревизия контента — git-операция, что подходит не каждой команде.

Как у меня устроен пайплайн

Данные в YAML и Markdown. Рендер — Python-скрипт build.py, детерминированный (один и тот же input даёт побайтово идентичный output). Деплой — paramiko-скрипт с pre/post MD5-verify. Кэш на CDN — длинный, purge при деплое.

data/
├── pages.yaml         # карта страниц
├── content/*.md       # тексты
└── shared/            # справочники

build.py             # render: data → dist/
deploy.py            # bundle + upload + verify

Когда статика перестаёт работать

Граница — десятки тысяч страниц с фасетной фильтрацией, или авторская среда где десять редакторов работают одновременно. На этом масштабе сборка становится длиннее, чем приемлемое окно деплоя, а git-workflow ломается на конфликтах слияния.

В этой точке я перехожу к гибриду: статический shell для шаблонной части + динамический endpoint для фильтров и поиска. Но это уже не про SMB-сайты, это уже про продукт.