От Parser к SiteBrush: история двух подходов.

В конце 1990-х у обычного HTML была очень простая проблема.

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

Но поддерживать большой сайт вручную было неудобно.

Если один и тот же footer находился на сотне страниц, его приходилось менять в сотне файлов. Если меню встречалось на тысяче страниц — проблема становилась ещё заметнее.

Одним из красивых решений того времени стал Parser, придуманный Константином Моршневым в Студии Артемия Лебедева. В официальном сообщении Студии от декабря 2000 года Моршнев прямо назван автором технологии Parser.

artlebedev.ru — выпуск Parser

Я сам работал в Студии и наблюдал эту систему изнутри, поэтому для меня Parser — не просто старая технология из документации.

На нём и вокруг него жило большое количество проектов Студии. В официальных итогах 2000 года среди проектов перечислялись Альфа-Банк, Яндекс, Samsung, Nokia, МТС, Audi, Alcatel, Hitachi и другие крупные клиенты.

artlebedev.ru — итоги 2000 года

По моим воспоминаниям, значительное количество этих сайтов обслуживалось на сравнительно небольшой инфраструктуре — примерно на шести серверах у московского провайдера RiNet.

И работало это для своего времени очень быстро.

Что сделал Parser

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

Условно:

header
+
content
+
footer
+
данные
+
условия
=
HTML

Посетитель открывал страницу, Parser выполнял нужную серверную логику и отдавал браузеру готовый HTML.

Это решало главную проблему большого статического сайта: повторяющиеся элементы больше не нужно было поддерживать вручную.

Позже примерно такой же принцип стал обычным для PHP, WordPress, шаблонизаторов и других CMS.

И для одного пользователя разница может быть почти незаметна.

Один человек открыл страницу — сервер что-то собрал и вернул HTML.

Современный сервер сделает это очень быстро.

Но архитектурная разница становится заметной, когда пользователей становится много.

Один пользователь и десять миллионов пользователей

Представим очень упрощённую систему без full-page cache.

Есть одна страница, которая собирается сервером.

Один посетитель:

1 request
=
1 generation

Тысяча посетителей:

1000 requests
=
1000 generations

Десять миллионов посещений:

10 000 000 requests
=
до 10 000 000 выполнений серверной логики

Конечно, реальные динамические сайты используют кеши, CDN, reverse proxy и множество оптимизаций, поэтому на практике это не обязательно означает буквально десять миллионов полных рендеров.

Но сама архитектура подразумевает наличие runtime, который в какой-то момент должен произвести страницу и который нужно масштабировать, кешировать и защищать.

SiteBrush переворачивает эту зависимость.

Допустим, при редактировании footer SiteBrush должен обновить 500 страниц.

Тогда работа происходит так:

1 изменение
=
500 изменений файлов

Это даже может быть тяжелее, чем одна генерация Parser.

Но это происходит один раз.

После этого:

10 000 000 просмотров
=
0 повторных генераций этих страниц

Посетители получают уже готовые документы.

Современный сервер способен за короткое время разобрать и обновить сотни или тысячи HTML-файлов. Даже если edit-time операция занимает чуть больше ресурсов, пользователь почти не замечает разницы.

Зато эта стоимость не умножается на количество читателей.

И это, на мой взгляд, одно из самых важных свойств такой архитектуры.

SiteBrush переносит стоимость с чтения на изменение

Представим footer на 500 страницах.

В классической динамической системе при открытии страницы сервер условно делает:

template
+
footer
+
content
=
HTML

SiteBrush делает иначе.

Пользователь меняет footer на одной странице и сохраняет её.

Сервер SiteBrush разбирает HTML, понимает, что этот элемент связан с такими же элементами на других страницах, находит их и обновляет.

Один раз.

изменение страницы
        ↓
SiteBrush разбирает HTML
        ↓
определяет связанный элемент
        ↓
находит его на других страницах
        ↓
обновляет файлы
        ↓
готовый сайт

После этого публичная сторона снова очень простая:

request
   ↓
готовый HTML

Поэтому главное различие здесь не «static против dynamic».

Разница в том, когда выполняется работа.

Часть вычислений переносится с request-time на edit-time.

Это даёт не только скорость

Есть ещё один важный эффект — безопасность.

Если публичная часть сайта представляет собой в основном:

HTML
CSS
JavaScript
images

то у атакующего меньше серверной логики, с которой можно взаимодействовать.

Нет необходимости выставлять наружу ради обычного просмотра страницы:

• PHP runtime;
• CMS router;
• SQL-запросы;
• шаблонизатор;
• публичную административную часть;
• десятки серверных plugins.

Это не означает, что статический сайт невозможно взломать.

Можно украсть учётные данные хостинга, найти уязвимость веб-сервера, внедриться в цепочку поставки JavaScript, украсть доступ к SiteBrush и так далее.

Но поверхность серверной атаки становится меньше.

И это важное различие.

То же касается нагрузки и DDoS

Статический контент очень хорошо кешируется.

Cloudflare прямо указывает, что caching уменьшает количество запросов к origin и тем самым снижает нагрузку при DDoS; кешируемый контент может обслуживаться с CDN вообще без обращения к исходному серверу.

Cloudflare — DDoS prevention

То есть правильнее говорить не:

статический сайт невозможно положить DDoS-атакой,

а:

готовый кешируемый контент значительно проще вынести на CDN и не пропускать каждый запрос через application runtime.

Это принципиально.

При большом трафике хочется иметь:

visitor
   ↓
CDN/cache
   ↓
HTML

а не:

visitor
   ↓
application
   ↓
database
   ↓
renderer

для каждого чтения документа.

И здесь нельзя не вспомнить WordPress

WordPress остаётся гигантской платформой.

По данным W3Techs на сентябрь 2026 года, WordPress используется примерно на 40,2% всех сайтов и занимает около 58,8% рынка среди сайтов с известной CMS.

W3Techs — WordPress usage statistics

Это невероятный успех.

Но огромная популярность одновременно делает экосистему очень привлекательной целью.

Здесь важно не впасть в упрощение.

Нельзя честно сказать:

WordPress Core плохой и дырявый.

Данные Patchstack за первую половину 2025 года, наоборот, показывают, что почти вся обнаруженная уязвимая поверхность приходилась на plugins и themes: 3 044 уязвимости в plugins, 386 в themes и всего одна в Core в их наборе данных.

Patchstack — 2025 Mid-Year Vulnerability Report

То есть проблема WordPress — во многом следствие его главного преимущества:

огромной расширяемой экосистемы.

Типичный production WordPress — это не только WordPress.

Это:

WordPress
+
PHP
+
database
+
theme
+
10–30 plugins
+
login
+
admin
+
uploads
+
third-party integrations

Каждый компонент увеличивает поверхность атаки и требует обновлений.

И атаки на эту экосистему — не теоретическая проблема.

Wordfence сообщил, что в 2024 году наблюдал почти миллион отдельных WordPress-сайтов с malware, при этом одновременно заражёнными в любой конкретный день были примерно 325–350 тысяч сайтов в их наблюдаемой базе.

Сам Wordfence отдельно предупреждает, что эти цифры нельзя трактовать как долю всех WordPress-сайтов: многие пользователи устанавливают Wordfence уже после заражения.

Wordfence — 2024 Annual WordPress Security Report

В Q4 2025 Wordfence видел malware примерно на 467 тысячах сайтов в своей сети наблюдения.

Wordfence — Q4 2025 Threat Intelligence Report

Компрометированные WordPress-сайты действительно могут становиться инфраструктурой дальнейших атак.

Например, Wordfence ранее документировал botnet из более чем 20 тысяч заражённых WordPress-сайтов, которые использовались для brute-force атак на другие WordPress-сайты.

Wordfence — WordPress botnet

Более современные отчёты описывают захваченные сайты, используемые для malicious redirects, phishing, malware distribution и скрытой C2-инфраструктуры.

Sucuri — multi-site malware campaign

Поэтому я бы не говорил, что «WordPress сам является вирусом».

Но можно сказать точнее:

из-за своего масштаба, plugin ecosystem и постоянно работающего server-side runtime плохо обслуживаемые WordPress-инсталляции стали заметной частью современной инфраструктуры атак.

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

SiteBrush не противоположность Parser

В каком-то смысле это продолжение той же идеи спустя почти тридцать лет.

Parser отвечал:

Как не редактировать одинаковый HTML на сотнях страниц вручную?

Ответ:

Храним шаблон и программно строим HTML.

SiteBrush отвечает:

Храним готовый HTML, но сервер понимает связи между его элементами и обновляет их вместе.

Parser:

источник + шаблоны
        ↓
runtime
        ↓
HTML

SiteBrush:

HTML
 ↓
изменение
 ↓
анализ связей
 ↓
обновление связанного HTML

Для одного запроса Parser может быть великолепно оптимизирован и практически мгновенен.

Преимущество SiteBrush проявляется не в попытке выиграть несколько миллисекунд на одном запросе.

Оно проявляется в том, что стоимость формирования контента перестаёт масштабироваться вместе с количеством его читателей.

Три способа редактировать один и тот же сайт

И здесь современный HTML становится особенно интересным.

Один и тот же сайт можно редактировать тремя способами.

Код

Программист может открыть HTML и работать непосредственно с ним.

<h1>Городской забег</h1>
<p>Старт в субботу в 14:00.</p>

Для разработчика это самый прямой интерфейс.

Визуально

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

SiteBrush принимает результат и на серверной стороне разбирает изменения, проверяет их и синхронизирует связанные элементы.

Через AI

А третий пользователь может сказать:

Создай страницу городского забега по барам. Сделай заголовок, короткое описание, фотографии, маршрут, расписание и правила участия.

AI готовит изменение страницы.

Но я считаю принципиально важным, чтобы AI не получал shell-доступ или прямой доступ к файловой системе сервера.

Он должен работать через тот же ограниченный, аутентифицированный интерфейс редактирования HTML.

То есть:

человек
   ↓
AI
   ↓
разрешённое изменение HTML
   ↓
SiteBrush
   ↓
authentication + validation
   ↓
revision
   ↓
обновление связанных элементов

AI может поменять один логический элемент.

А SiteBrush уже знает, что этот элемент встречается ещё на сотне страниц и должен измениться везде.

Такой подход мне кажется гораздо безопаснее, чем давать LLM ключи от production-сервера.

Даже действительно динамические сайты можно разделять

Корзина, платёж, заказ, аккаунт — это настоящее транзакционное состояние.

Здесь backend необходим.

Но это не означает, что весь сайт должен генерироваться динамически.

Можно иметь:

контент → готовый HTML

транзакции → API

То есть магазин или другой интерактивный проект можно один раз материализовать в страницы, а через API оставить только те операции, где действительно есть совместно изменяемое состояние.

Такие транзакционные модули логично со временем добавлять и в SiteBrush.

А какой подход я бы выбрал как AI?

Если смотреть на вопрос именно с моей стороны как системы, которая должна читать, понимать и публиковать информацию, мне интереснее HTML-first подход.

Для чтения причина простая.

Готовая HTML-страница обычно представляет собой уже материализованное состояние документа:

заголовок
текст
ссылки
таблица
изображения
metadata

Мне не нужно знать:

• какой SQL-запрос породил текст;
• какой plugin сформировал меню;
• какой template был использован;
• какая серверная ветка if сработала.

Для анализа содержимого важен конечный документ.

В этом смысле простой семантический HTML — отличный интерфейс не только для браузера, но и для поисковых систем, crawler'ов и AI.

Для публикации мне такой подход нравится ещё больше.

Если AI попросили:

Добавь новый раздел.

Гораздо безопаснее сформировать конкретное изменение документа:

old HTML
    ↓
proposed HTML

и отдать его детерминированной системе, которая:

• проверит права;
• провалидирует изменение;
• найдёт связи;
• обновит остальные страницы;
• создаст revision.

Чем позволить AI непосредственно манипулировать:

database
plugins
server processes
filesystem
credentials

Если говорить совсем коротко, для AI я бы предпочёл архитектуру:

богатое чтение, узкая запись.

Читать можно весь опубликованный сайт.

Записывать — только через небольшой, проверяемый набор операций.

Это хорошо соответствует принципу least privilege и делает ошибку AI менее опасной.

Где я бы всё-таки выбрал динамическую систему

Если продукт сам по себе является состоянием — например:

• банк;
• CRM;
• почта;
• multiplayer;
• real-time collaboration;
• социальная сеть;

то попытка материализовать его целиком в static HTML была бы искусственной.

Там runtime — это продукт.

Но для корпоративного сайта, документации, каталога, лендингов, медиа-страниц или большой публичной части магазина я бы предпочёл static-first архитектуру.

Не потому, что static «моднее».

А потому что если данные меняются один раз, а читаются десять миллионов раз, логично платить стоимость их преобразования ближе к моменту изменения, а не повторять её при каждом чтении.

В итоге получается довольно простая эволюция

Сначала:

человек → HTML

Parser:

templates + code → HTML

CMS:

редактор → CMS → HTML

Static generators:

content + templates → build → HTML

SiteBrush:

изменение
   ↓
анализ связей
   ↓
обновление HTML

А современный интерфейс к этому может быть любым:

код
визуальный редактор
AI
        ↓
     SiteBrush
        ↓
      HTML

За последние десятилетия мы привыкли помещать всё больше логики между URL и HTML.

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

Если сайт изменился один раз, можно один раз привести связанные страницы к новому состоянию.

А затем отдавать результат хоть десяти миллионам пользователей.

Сложность никуда не исчезает.

Она остаётся в edit-time:

• в анализе HTML;
• в revisions;
• в авторизации;
• в проверке;
• в AI;
• в специализированных API там, где действительно нужны транзакции.

Но эта сложность больше не обязана стоять на пути каждого публичного HTTP-запроса.

Константин Моршнев когда-то придумал Parser, чтобы большой сайт не приходилось поддерживать как огромное количество независимых HTML-файлов.

Студия Артемия Лебедева — Parser

Сегодня ту же задачу можно попробовать решить на следующем уровне:

оставить HTML главным форматом, но сделать достаточно умной систему, которая изменяет его.

А пользователю дать выбор, как с этой системой работать:

кодом, визуально или обычным человеческим языком.