Сайт без CMS и базы данных: кому подходит статический подход

Можно ли обойтись без административной панели?

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

Рассмотрим корпоративный сайт с общими для всех посетителей страницами и формой обращения. У него нет личных кабинетов, индивидуальных цен и учёта заказов. В такой задаче выбор касается прежде всего работы сотрудников: нужен ли им редактор в браузере или публикацию можно поручить специалисту, который выпускает заранее подготовленные файлы.

Что получает посетитель

По определению MDN, статический сервер отдаёт для заданного адреса сохранённое содержимое. Браузер получает HTML, стили CSS и, когда он нужен, JavaScript. Чтобы изменить текст страницы, сначала меняют исходный материал, затем заменяют опубликованный файл. При динамической работе сервер может формировать ответ по запросу, используя данные и условия для конкретного посетителя. Это различие не видно по красоте макета: оба подхода позволяют оформить услуги и проекты одинаково. Новые материалы можно готовить в удобном формате и собирать в страницы программой, чтобы сотрудник не копировал меню и подвал вручную всякий раз, когда в блоге появляется статья о новой услуге.

Где находится управление

CMS — система управления содержанием — обычно даёт редактору панель для публикации. У сайта без CMS это действие выполняет другой набор инструментов: исходные тексты, сборка и загрузка файлов. Сборщик создаёт готовые страницы и списки материалов по шаблонам. Отсутствие привычной панели убирает один интерфейс, но оставляет работу с содержанием. Поэтому человека, который будет вести сайт, выбирают вместе со способом публикации.

Три способа публиковать одинаковые страницы

Для небольшой компании полезно сравнить ручное редактирование файлов, статическую сборку и CMS. Первое кажется простым только до появления повторяющихся блоков. Изменить телефон на одной странице легко, а обновить его во всех копиях шапки и старых материалах уже требует внимания.

Когда я выбираю сборщик

Если у сайта есть блог или каталог проектов с повторяющимся оформлением, сборщик предпочтительнее ручного копирования HTML: один шаблон задаёт вид всех материалов, а новая публикация получает меню, список связанных страниц и другие повторяемые части без отдельной ручной правки в каждом файле. При этом исполнитель обязан объяснить, какие операции автоматизированы, а какие останутся у человека. Для руководителя важнее возможность выпустить материал и восстановить предыдущую версию, когда на рабочем компьютере автора сломалась сборка или понадобилось передать задачу другому подрядчику.

Документация GitHub Pages показывает этот подход на конкретном сервисе: входным файлом могут служить index.html, index.md или README.md, а страницы можно готовить статическим генератором. Это пример устройства публикации, а не требование размещать корпоративный сайт на GitHub. Хостинг, способы загрузки и принадлежность аккаунтов выбирают отдельно, с учётом уже работающей инфраструктуры компании.

Когда панель окупает своё обслуживание

CMS удобнее, если сотрудники постоянно редактируют содержание независимо друг от друга, разграничивают роли и ожидают, что публикация не потребует разработчика. В такой работе ценность панели — не кнопка «Сохранить», а ежедневная самостоятельность редакторов. Если каждый небольшой текст всё равно передаётся исполнителю, обещанная экономия времени не возникнет, даже когда CMS уже установлена и оплачена.

Частота правок важнее числа страниц

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

Одна обычная правка

До выбора попросите исполнителя показать замену фотографии проекта, изменение описания услуги и выпуск статьи. Это три разных действия с точки зрения редактора: фотографию нужно подготовить, текст — сохранить без повреждения оформления, статью — добавить вместе с адресом и ссылкой в архиве. Если демонстрация заканчивается файлом на компьютере разработчика, путь публикации показан только наполовину.

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

Я выбираю CMS, когда компании нужна самостоятельная работа нескольких редакторов с правами и согласованием материалов, а подрядчик предлагает заменить это письмами ему по любому поводу. Статическая сборка выигрывает там, где выпуском уже занимается один ответственный и ему доступны понятные инструменты. Совместить подходы тоже возможно: содержание хранится в редакторе, а публичная часть остаётся статической. Но это уже отдельная система с панелью и обслуживанием, поэтому обещать одновременно все удобства CMS и полное отсутствие её затрат некорректно.

Срочные изменения

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

Для таких ситуаций назначают заменяющего сотрудника либо резервного исполнителя и хранят инструкцию рядом с исходными материалами. Руководителю нужен ответ на простой вопрос: кто уберёт неверную информацию сегодня, если основной специалист не отвечает. Сайт с редкими публикациями тоже нуждается в этом порядке, потому что редкая правка иногда важнее ежедневной новости.

Формы и сервисы остаются отдельной работой

Надпись «сайт без базы данных» относится к устройству страниц, а не ко всему бизнесу вокруг них. Форма обращения отправляет данные обработчику, который принимает запрос и передаёт обращение сотруднику.

Для обработки могут использоваться серверный код, внешний сервис или функция облачной платформы. Контакты клиента всё равно где-то обрабатываются.

Почему формы нельзя считать готовыми по виду

В примере Cloudflare HTML-форма посылает POST-запрос по адресу /api/submit, а Pages Function принимает его через обработчик onRequestPost. Эти названия разработчик может использовать для объяснения архитектуры, но заказчику важнее продолжение: где сохраняется обращение, кто его получает и какое подтверждение видит человек. Форма без обработчика выглядит как способ связи, но передать обращение сотруднику через неё невозможно. Если отправка зависит от чужой подписки, лимита или аккаунта исполнителя, эти условия включают в сопровождение сайта вместе с ответственным за оплату и восстановление доступа.

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

Скорость и доступность

Готовый HTML уменьшает объём работы сервера при выдаче страницы, но тяжёлые фотографии, сторонние виджеты и неудачный JavaScript остаются в браузере посетителя. Поэтому оценивать скорость нужно на опубликованных страницах с настоящими материалами. Пустой макет покажет другую нагрузку. Точно так же отсутствие административной панели не освобождает от защиты аккаунта хостинга, резервирования исходников и сопровождения обработчика формы.

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

Покажите публикацию силами компании

Решение о статическом сайте без CMS стоит принимать после небольшой демонстрации будущей работы. В ней участвует сотрудник компании, а разработчик объясняет порядок и помогает только там, где помощь останется частью оплачиваемого сопровождения. Это позволяет увидеть реальные обязанности сторон до запуска.

Что остаётся у владельца

Компании передают исходные материалы и шаблоны, инструкцию сборки, доступ к размещению, способ возврата предыдущего выпуска и сведения об обработке форм. Готовые HTML-файлы позволяют сохранить опубликованные страницы, а для дальнейших выпусков понадобятся исходные тексты и шаблоны. Потеряв исходники, следующий исполнитель начнёт восстанавливать структуру по результату чужой работы. В задании на создание сайта этот комплект лучше перечислить отдельным результатом, чтобы передача не ограничилась паролем от хостинга.

Затем сотрудник выпускает новую страницу. Она открывается по своему адресу, появляется в нужном списке, содержит работающие ссылки и выглядит правильно на телефоне.

Следом он исправляет намеренно оставленную в тестовом тексте опечатку и возвращает прежнюю редакцию. Так компания оценивает управление на собственных действиях.

Граница приемлемого обслуживания

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

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