Хостинг для сайта не нужен: GitHub вместо WordPress

Большинство контентных сайтов сегодня все также делают на WordPress. На сервер устанавливают PHP, базу данных MySQL, сам движок, тему и набор плагинов. После этого приходится следить за обновлениями, делать резервные копии, закрывать уязвимости и разбираться, почему очередной плагин сломал сайт.

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

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

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

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

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

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

Есть только готовые HTML, CSS и JavaScript файлы. Сайт работает быстро, предсказуемо и практически не требует обслуживания.

Astro — это современный фреймворк для создания сайтов. Он особенно хорошо подходит для:

Разработчик создаёт шаблоны страниц и компонентов, а статьи можно хранить в обычных Markdown-файлах.

Например, публикация может выглядеть так:

Во время сборки Astro превращает эти файлы в готовые страницы сайта.

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

Код сайта и Markdown-файлы со статьями можно хранить в репозитории GitHub или GitLab.

Для добавления статьи необязательно устанавливать редактор кода и работать с Git через командную строку. У GitHub и GitLab есть веб-интерфейс, через который можно:

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

Если стандартный интерфейс GitHub покажется слишком техническим, позднее можно подключить отдельную Git-based CMS. Она предоставит более привычные поля для заголовка, описания, изображения и текста, но продолжит сохранять материалы в тот же репозиторий.

Процесс публикации выглядит следующим образом:

Ничего вручную загружать по FTP не нужно.

Для размещения можно использовать бесплатные тарифы статических платформ, например Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify или Vercel. Для небольшого информационного сайта их бесплатных лимитов, как правило, более чем достаточно.

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

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

У статического сайта очень мало движущихся частей. WordPress-сайту для работы обычно необходимы:

Статическому Astro-сайту после сборки нужны только готовые файлы.

Даже если GitHub, GitLab или система автоматической сборки временно окажутся недоступны (что на моей памяти было буквально один раз), уже опубликованная версия сайта продолжит открываться. Проблема затронет добавление новых материалов, но не обязательно сам работающий сайт.

Отсутствие базы данных и серверной панели также значительно уменьшает поверхность атаки. Это не означает, что безопасность можно полностью игнорировать, но типовых проблем WordPress здесь гораздо меньше.

Astro по умолчанию старается отправлять в браузер минимум JavaScript. Если интерактивность на странице не нужна, пользователь получает практически чистый HTML.

Это даёт несколько преимуществ:

Для информационного сайта это почти идеальная модель: страница уже создана и остаётся только передать её посетителю.

Главный недостаток — отсутствие привычного бэкенда.

Статический сайт сам по себе не умеет:

Если проекту нужен полноценный веб-сервис, одной статической генерации может быть недостаточно. В таком случае Astro всё равно можно использовать для публичной части, но к нему придётся подключить отдельный API или серверное приложение.

Второй недостаток — интерфейс публикации. После WordPress редактирование Markdown через GitHub или GitLab может показаться менее дружелюбным. Особенно если материалы будет добавлять человек, далёкий от разработки.

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

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

Для обработки формы можно использовать облачную функцию. Например, создать небольшую функцию в Yandex Cloud, которая будет:

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

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

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

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

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

После WordPress и серверного рендеринга именно статические сайты кажутся мне самым чистым решением: один раз правильно настроил сборку — и дальше остается только писать статьи и продлевать домен.