Команда собирает статический сайт, и на этапе публикации начинаются споры. Один разработчик предлагает одну платформу, второй настаивает на другой, третий вообще предлагает развернуть сервер и настроить всё вручную. Обсуждение идёт на уровне вкусов, потому что критерии не сформулированы. Между тем обе площадки появились недавно, но выросли из разных задач, и разница между ними проистекает из этого.
Обе площадки выросли из идеи сборки на стороне платформы
Первая компания была основана в конце января 2014 года и публично представила продукт в апреле следующего года. Её создатель заметил, что разработчики всё чаще хранят исходники в системе контроля версий, собирают их инструментами и получают набор статических файлов. Не хватало только места, куда этот набор удобно положить.
Вторая компания появилась в 2015 году под другим названием, а в апреле 2020 года сменила его. Её основатель известен созданием популярного фреймворка для серверного рендеринга. Неудивительно, что платформа оказалась тесно связана с этим фреймворком и оптимизирована под него.
Общая идея у обеих одинакова. Разработчик подключает хранилище с кодом, платформа собирает проект и раздаёт готовые файлы через сеть доставки. Каждое изменение в основной ветке автоматически превращается в новую версию сайта.
Разница начинается в деталях: что именно платформа умеет делать помимо сборки, как обрабатывает серверную логику и сколько стоит при росте.
Понятие конвейера объясняет, что вообще автоматизируется
Прежде чем сравнивать, стоит уточнить термины, потому что их часто путают.
Непрерывная интеграция это частое слияние небольших изменений в основную ветку. Каждое слияние запускает сборку и проверки.
Непрерывная доставка это производство программного обеспечения короткими циклами, при котором версия готова к выпуску в любой момент, а процесс публикации прост и повторяем.
Непрерывное развёртывание это автоматический выпуск новых изменений без ручного подтверждения.
Вместе эти практики называют конвейером. Смысл его в том, чтобы убрать ручные шаги между правкой в коде и обновлением на работающем сайте. Именно это и предлагают обе площадки, только разными средствами.
// универсальный конвейер, применимый на любой платформе
build:
stage: build
script:
- npm ci
- npm run build
artifacts:
paths:
- dist/
test:
stage: test
script:
- npm run lint
- npm run test -- --run
deploy:
stage: deploy
script:
- ./scripts/deploy.sh
only:
- mainТакой файл описывает три этапа: сборку, проверку и публикацию. Платформы, о которых идёт речь, умеют выполнять этот сценарий без отдельной настройки сервера.
Первая площадка делает ставку на простоту и статические сайты
Платформа, появившаяся раньше, выросла из хостинга статических сайтов. Её сильная сторона в том, что она берёт на себя рутинные задачи, о которых разработчик обычно забывает.
Первое это сборка. Платформа сама определяет инструмент по файлу настроек проекта и запускает команду. Отдельный сервер сборки не нужен.
Второе это предварительные версии. Каждое изменение в отдельной ветке получает собственный адрес, и по нему можно посмотреть результат до слияния. Для командной работы это экономит круг общения: дизайнер открывает ссылку, а не собирает проект локально.
Третье это серверные функции. Небольшие обработчики на языке сценариев разворачиваются рядом с сайтом и обслуживают запросы к внешним службам, скрывая ключи доступа.
Четвёртое это формы и проверка подлинности. Встроенные сервисы позволяют принимать заявки и разграничивать доступ без написания собственного бэкенда.
Пятое это откат. История публикаций хранится, и вернуться к предыдущей можно одним действием. При неудачном выпуске это спасает.
Практический итог: площадка хорошо подходит проектам, где серверная часть минимальна или отсутствует, а важна скорость запуска.
Вторая площадка делает ставку на серверный рендеринг и пограничные вычисления
Вторая платформа выросла из фреймворка и потому решает другую задачу. Её основа это выполнение кода на узлах, распределённых по миру.
Первое отличие это серверный рендеринг. Страница собирается на стороне сервера при каждом запросе или через заданные интервалы. Для сайтов, где содержимое зависит от пользователя, это даёт лучшую скорость первой отрисовки.
Второе отличие это функции на границе. Обработчик выполняется в ближайшем к пользователю узле, что сокращает задержку. Для проверки прав или выбора региона это заметно.
Третье отличие это промежуточный слой. Запрос можно перехватить до отдачи страницы и изменить ответ: добавить заголовок, перенаправить, проверить условия.
Четвёртое отличие это тесная связь с фреймворком. Обновления фреймворка и платформы согласованы, а новые возможности появляются сначала здесь.
Пятое отличие это инструменты для совместной работы. Комментарии к предварительным версиям и автоматические проверки встроены в интерфейс.
Итог: площадка лучше подходит проектам на соответствующем фреймворке, где серверная логика играет заметную роль.
В 2025 году компания привлекла триста миллионов долларов, а оценка достигла девяти с лишним миллиардов. Число сотрудников превышает пятьсот человек. Для сравнения, у первой компании выручка в 2023 году составила около тридцати трёх миллионов долларов при двухстах сорока четырёх сотрудниках. Разница в масштабах объясняется разными рынками: одна обслуживает в основном статические сайты и небольшие команды, вторая целится в крупные приложения.
Стоимость и ограничения проявляются на росте
На старте обе площадки предлагают бесплатные тарифы, и разница незаметна. Проблемы начинаются при росте.
Первое ограничение это лимиты бесплатного уровня. Число минут сборки, объём трафика, количество вызовов функций. Превышение приводит к счёту или к отказу в обслуживании.
Второе ограничение это время выполнения функций. Обработчик, работающий дольше установленного предела, будет прерван. Долгие операции приходится выносить на отдельный сервер.
Третье ограничение это размер развёртывания. Очень большие проекты с множеством файлов упираются в ограничения и требуют оптимизации.
Четвёртое ограничение это привязка к платформе. Специфичные возможности, такие как промежуточный слой или специальные форматы настроек, усложняют переезд. Чем больше платформенных функций используется, тем дороже смена хостинга.
Пятое ограничение это предсказуемость счёта. При резком росте трафика расходы могут вырасти неожиданно. Лимиты и оповещения стоит настроить заранее.
// проверка бюджета перед выпуском
const budget = {
buildMinutes: 300,
bandwidthGb: 100,
functionCalls: 100000,
};
function checkUsage(usage) {
const warnings = [];
for (const [key, limit] of Object.entries(budget)) {
const used = usage[key] || 0;
const share = used / limit;
if (share >= 0.8) {
warnings.push(key + ": " + Math.round(share * 100) + "% от лимита");
}
}
return warnings;
}Такой счётчик стоит встроить в служебную панель. Тогда о приближении к лимиту узнаёт команда, а не бухгалтерия через месяц.
Что выбрать в конкретной ситуации
Полезно разобрать несколько типовых случаев.
Первый случай это лендинг или сайт документации. Содержимое статическое, серверная логика не нужна. Подойдёт любая площадка, и решать стоит по удобству интерфейса и цене.
Второй случай это интернет-магазин с серверным рендерингом. Здесь важна скорость первой отрисовки и работа с персонализированными данными. Лучше подойдёт платформа, заточенная под соответствующий фреймворк.
Третий случай это внутренний инструмент с проверкой прав. Нужны перехват запросов и близость к пользователю. Опять же выигрывает вторая площадка.
Четвёртый случай это сайт с большим объёмом медиа. Важна раздача статики и стоимость трафика. Здесь стоит считать деньги и сравнивать тарифы.
Пятый случай это проект с жёсткими требованиями к размещению данных. Ни одна из публичных площадок не подойдёт, если данные должны лежать на своей территории. Тогда остаётся собственный сервер или частное облако.
Переезд возможен, но требует подготовки
Смена площадки редко бывает приятной, зато вполне выполнимой, если заранее ограничить привязку.
Первое правило это минимум платформенных возможностей. Чем меньше специфичных функций используется, тем проще перенос. Серверную логику стоит держать в отдельном сервисе, а не в функциях площадки.
Второе правило это сборка в конвейере, а не на площадке. Если сборка выполняется собственными средствами, а на хостинг попадают готовые файлы, смена хостинга сводится к копированию.
Третье правило это конфигурация через переменные окружения. Адреса служб, ключи и настройки не должны быть зашиты в код.
Четвёртое правило это проверка после переноса. Стоит пройти основные сценарии: загрузку страницы, отправку формы, работу с изображениями, обновление после публикации.
Пятое правило это сохранение старой версии. Пока новая площадка не проверена, старая остаётся доступной. Переключение адресов выполняется в самом конце.
// проверка основных страниц после переезда
for path in / /catalog /cart /about; do
code=$(curl -s -o /dev/null -w "%{http_code}" "https://new.example.net$path")
printf "%s -> %s\n" "$path" "$code"
doneТакой короткий сценарий ловит половину проблем переезда: неверные перенаправления, отсутствующие страницы, ошибки настройки.
Сравнение по конкретным критериям убирает спор
Когда мнения расходятся, помогает таблица критериев с весами. Ниже перечень, по которому стоит пройтись перед решением.
Первый критерий это тип приложения. Статический сайт, серверный рендеринг, гибрид. От него зависит половина выбора.
Второй критерий это требования к скорости. Если важна быстрая первая отрисовка, серверный рендеринг обязателен.
Третий критерий это объём трафика. При миллионах просмотров стоимость раздачи становится главной статьёй расходов.
Четвёртый критерий это география аудитории. Если пользователи распределены по миру, важна сеть доставки и расположение узлов.
Пятый критерий это требования к размещению данных. Часть отраслей обязывает хранить сведения на своей территории.
Шестой критерий это размер команды. Небольшой команде нужна простота, крупной важнее управляемость и разграничение прав.
Седьмой критерий это долгосрочные планы. Если через год планируется переезд, стоит избегать платформенных особенностей.
Пройтись по этим семи пунктам занимает полчаса, а предотвращает месяцы переделок. Спор о вкусах превращается в обсуждение требований, а оно заканчивается решением.
Проверка перед выпуском экономит нервы после
Независимо от выбранной площадки, полезно пройти одинаковый набор проверок перед первым выпуском.
Убедиться, что сборка проходит на чистой машине, а не только на компьютере разработчика. Проверить, что переменные окружения заданы для всех режимов. Посмотреть, что происходит при падении сборки: приходит ли уведомление, виден ли журнал. Проверить откат на предыдущую версию. Убедиться, что предварительная версия ветки создаётся и доступна по ссылке. Проверить, что перенаправления работают и старые адреса не отдают ошибку. Убедиться, что счётчик расхода настроен и оповещения включены.
Семь проверок занимают час. Пропуск любой из них рано или поздно обернётся ночным разбирательством, потому что проблемы публикации всегда всплывают в самый неудачный момент.
Выбор платформы для публикации фронтенда получился вопросом не вкуса, а соответствия задаче. Обе площадки делают примерно одно и то же на базовом уровне и расходятся там, где начинается серверная логика. Начинать стоит не со сравнения тарифов, а с ответа на вопрос, что именно приложение делает помимо отдачи статики. Ответ на него убирает большинство споров.