Вступление: 4 часа на деплой контентного сайта

На днях я стряхнул пыль с небольшого пет-проекта. Это простой блог, наверняка каждый из вас хотя бы думал о таком для себя.
В 2015 году я бы просто закинул файлы по FTP на хостинг за 100 рублей. Время деплоя: 30 секунд.
В 2026 году я потратил 4 часа. Я настраивал Edge Middleware, дебажил рассинхрон HTML между клиентом и сервером (hydration mismatch) и разбирался, почему облако не хочет дружить с моей базой данных из-за долгого пробуждения функций (холодного старта).

Где мы свернули не туда?
Это колесо Сансары, которое дало новый оборот.

Помните 2010-е годы? Все писали на PHP.
Как это работало?

1. Браузер просил страницу.

2. Сервер шел в базу, клеил HTML и отдавал его.

3. Пользователь видел контент сразу.

Потом мы сказали: «Фу, перезагрузка страницы – это прошлый век!». И изобрели SPA (Single Page Application). Мы перенесли рендеринг в браузер, убили SEO, заставили телефоны греться, но добились плавных переходов.

Прошло 16 лет. И теперь нам продают React Server Components (RSC).
Давайте посмотрим правде в глаза. Мы вернулись к PHP. Но с одним нюансом.

Найдите 10 отличий

Проведем слепой тест. Первый – код на PHP из 2010-х. Дальше – передовой Next.js код из 2026 года.

PHP (2010):

// index.php
// Без конфигов. Без сборки. Только код.
$db = new SQLite3('products.db');
$result = $db->query('SELECT * FROM items');
?>
<ul>
  <?php while ($row = $result->fetchArray()): ?>
    <li><?= $row['name'] ?></li>
  <?php endwhile; ?>
</ul>

Next.js RSC (2026):

// page.tsx (Server Component)
// Зависимости: Node.js, Webpack, Babel, PostCSS...
import { db } from './db';

export default async function Page() {
  const items = await db.query('SELECT * FROM items');
  return (
    <ul>
      {items.map(item => (
        <li key={item.id}>{item.name}</li>
      ))}
    </ul>
  );
}

Мы пишем то же самое. Логика та же. Рендеринг на сервере.
Но есть "нюанс" в инфраструктуре.
Чтобы запустить php файл, вам нужен любой шаред-хостинг за 150 рублей.
Чтобы запустить rsc файл, вам нужен:

• Node.js кластер.

• CI/CD пайплайн.

• Система сборки, которая разделяет код на "серверный" и "клиентский".

• Процесс сериализации данных.

Мы построили космодром, чтобы запустить бумажный самолетик.

Бенчмарк: цена "Hello World!"

Хватит лирики. Смотрим на цифры.
Возьмем пустое приложение, которое просто выводит <h1>Hello World</h1>.

PHP (v8.2):

• Размер бандла: 0 KB (шлет чистый HTML).

• Время до интерактивности (TTI): 50 ms.

• Потребление памяти: 5 MB на процесс.

Next.js (v14, App Router):

• Размер бандла (JS): 184 KB (React, React DOM, Next Runtime, Webpack runtime). (Даже если вы высушите его минификатором до 80 КБ, это всё ещё 80 КБ против 0 у PHP).

• Время до интерактивности (TTI): 350 ms (на мобильном 4G).

• Потребление памяти: 150 MB (Node.js процесс).

Зачем пользователю качать 184 килобайта JavaScript, чтобы увидеть статический текст?
«Но это для будущей интерактивности!» – скажете вы.
Это кредит, который вы берете у пользователя без его спроса. Вы тратите его трафик и батарею на потенциальную возможность, которая может никогда не понадобиться.

Каскад запросов: что происходит в сети

PHP:

[Клиент] -> GET /index.php -> [Сервер]
[Клиент] <- HTML (2kb)   <- [Сервер]
(Готово. Отрисовка в браузере.)

RSC:

[Клиент] -> GET /page -> [Сервер]
[Клиент] <- HTML shell (Skeleton) <- [Сервер] (Первая отрисовка)
[Клиент] -> GET /_next/static/chunks/main.js (React) -> [Сервер]
[Клиент] -> GET /_next/static/chunks/app/page.js (Клиентский код) -> [Сервер]
[Клиент] -> GET /_next/data/.../page.rsc (RSC Payload) -> [Сервер]
[Клиент] (Гидратация...)
(Готово. Интерактив.)

Вы видите разницу? Мы добавили 3 сетевых запроса и 200ms латенсии просто так.
И это на "Hello World". На реальном проекте Waterfall превращается в Ниагарский водопад.

Проблема гидратации и сериализации

Главный аргумент защитников RSC: "Мы убрали гидратацию!".
Это правда, но лишь отчасти.

Да, RSC не гидратируются. Они прилетают как готовый HTML.
Но как только вам нужна интерактивность хоть для одной кнопки "Купить", вы добавляете директиву 'use client'.
И тут начинается магия сетевого барьера (Network Boundary).

Вместо того чтобы просто отдать HTML, сервер теперь должен:

1. Отрендерить Server Components.

2. Сериализовать props для Client Components (и не дай бог вы передадите туда функцию или класс — ошибка сериализации!).

3. Отправить HTML + JSON с данными гидратации.

4. Браузер должен скачать React, скачать код клиентских компонентов и снова выполнить код, чтобы "оживить" HTML.

Как мы сломали целый шкаф ради одной петли
Это как если бы вы купили шкаф. Сервер (Server Component) собирает его на складе и привозит вам готовым. Вы видите красивый шкаф. Ура!

Но тут заходит бригада грузчиков (Client Component/Hydration). Они говорят: «Нам нужно убедиться, что дверцы открываются».
Они разбирают ваш собранный шкаф обратно на доски прямо у вас в коридоре.
А потом, сверяясь с инструкцией (JSON-данными), собирают его заново у вас на глазах, тратя ваше время и ресурсы процессора.

Мы буквально заставляем компьютер делать работу дважды. Сначала на сервере, потом на клиенте.
Эффективно? Нет.
Модно? Да.

Цена сложности

Вся эта сложность имеет конкретную цену.

Сценарий: простой E-commerce магазин.

Стек PHP/Go/Python (Классика):

• VPS: 500 руб/мес.

• База данных: на том же VPS (бесплатно).

• Деплой: git pull или Docker Compose.

• Итого: 500 рублей. Предсказуемо. Независимо от санкций.

Стек Next.js (облако):

• Vercel Pro (чтобы не упереться в лимиты): $20/мес (2000 руб).

• Оплата зарубежной картой: геморрой с посредниками (+20%).

• Задержка пробуждения (cold start): ваши бессерверные функции "спят". Первый пользователь ждет несколько секунд.

• Итого: от 2500 руб + нервы оплатой + риск блокировки аккаунта.

Стек Next.js (Docker):

• VPS: 500 руб/мес (как у PHP).

• Сложность: вам нужно написать Dockerfile (многоэтапная сборка), настроить Nginx для статики, Redis для кеша и разобраться, почему sharp не собирается на Alpine Linux.

• Итого: 500 руб + ваши бесплатные выходные, потраченные на DevOps.

Мы платим не за нагрузку. Мы платим за сложность архитектуры и жесткую привязку к платформе (vendor lock-in).

Ловушка "Edge Runtime"

Есть еще один нюанс, о котором молчат в маркетинговых брошюрах.
Vercel активно продвигает Edge Middleware и Edge Functions.
«Это быстрее! Это работает на CDN!» – говорят они.

Но что такое эта "граничная" среда (Edge Runtime)?
Это кастрированный JS. Забудьте про fs, забудьте про привычный Node API. Вас заперли в песочнице и сказали, что это инновации.
Код, написанный под Edge, не запустится в стандартном Node.js контейнере на вашем дешевом VPS.

Вы пишете код, который может работать только в инфраструктуре Vercel (или Cloudflare Workers).
Вы своими руками надеваете наручники vendor lock-in.
Хотите переехать на свое железо, когда счет за Vercel превысит $1000? Переписывайте половину бэкенда.
Только нужно объяснить это бизнесу.

Культ сложности и Resume Driven Development

Почему мы это делаем?
Потому что никто не хочет писать в резюме: «Поддерживаю легаси на jQuery, бизнес доволен».
Все хотят: «Архитектор микрофронтендов на Next.js App Router, мигрировал проект на Edge Runtime».

Индустрия поощряет сложность. Если ты делаешь просто – ты джун. Если ты делаешь сложно – ты сеньор.
Это работает индустриальный комплекс JavaScript. Мы создаем проблемы, чтобы героически их решать и требовать повышения зарплаты.
А бизнес? Бизнес просто платит за "современные технологии", не понимая, что покупает воздух.

Фреймворк как корсет

Но давайте будем объективны. У RSC и тяжеловесных фреймворков вроде Next.js есть одна бесспорная "киллер-фича" – масштабируемость команды.

Когда у вас 50, 100 или 500 фронтендеров, главная проблема бизнеса – это не скорость загрузки страницы и не стоимость серверов. Главная проблема – это броуновское движение разработчиков. Каждый пишет код в своем стиле, каждый придумывает свой велосипед для управления состоянием и свой архитектурный паттерн для запроса данных.

В этот момент Next.js с его жесткой файловой маршрутизацией и RSC становятся архитектурным корсетом. Они навязывают единые рельсы. Шаг влево, шаг вправо – ошибка компиляции. В кровавом энтерпрайзе вам нужно, чтобы код всех 500 человек выглядел одинаково уродливо, но одинаково. Вы меняете производительность приложения на конвейерную сборку, где любого разработчика можно заменить за неделю.

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

Что делать?

Я не призываю всех вернуться в 2010 год (хотя index.html все еще прекрасен).
Я призываю к инженерной честности.

1. Считайте TCO (Total Cost of Ownership). В России сейчас проще и дешевле поднять VPS, чем мучиться с оплатой облаков. Не тащите Next.js туда, где хватит простого Go/Python или PHP.

2. Используйте нативные возможности браузеров. View Transitions API уже делает переходы плавными, а новые возможности HTML/CSS позволяют собирать сложные интерфейсы без гигабайтов JS.

3. Не ведитесь на маркетинг. Vercel продает хостинг. Им выгодно, чтобы ваш код был сложным и привязанным к их серверам.

Иногда лучший фреймворк – это его отсутствие.

Чек-лист: нужен ли вам Next.js?

Я не противник прогресса. Next.js и RSC – мощные инструменты. Но использовать их для блога – это забивать гвозди микроскопом.
Вот простой алгоритм выбора:

Вам НУЖЕН Next.js / RSC, если:

1. У вас Facebook*/ AirBnB (сотни маршрутов, сложная стейт-машина).

2. Вам критичен Optimistic UI (интерфейс реагирует быстрее, чем отвечает сервер).

3. У вас команда из 50+ фронтендеров, и вам нужны жесткие рельсы фреймворка, чтобы они не написали лапшу.

* Meta Platforms Inc. (владелец Facebook и Instagram) – организация признана экстремистской, её деятельность запрещена на территории РФ

Вам НЕ НУЖЕН Next.js (берите Python, Go, PHP), если:

1. Вы делаете Блог / Контентный сайт. (HTML кэшируется лучше, чем JSON).

2. Вы делаете B2B панель управления. (Там не нужен SEO, там нужно надежное управление состоянием приложения, а старый добрый SPA на Vite + React будет проще в отладке).

3. Вы стартап с бюджетом 0 рублей. (VPS за 300 руб выдержит 10к пользователей на PHP/Go. Vercel выставит счет при первой же DDoS-атаке).

P.S. Эта статья – адаптированный отрывок из моей книги «Поколение JSON». Там я перевожу наши ежедневные инженерные боли на язык денег и показываю, почему "бесплатные" абстракции часто обходятся бизнесу дороже всего.
У себя в Telegram-канале в закрепе я выложил удобный бесплатный PDF-чек-лист для руководителей: «10 признаков того, что ваш проект умирает от техдолга». Забирайте, пока ваши микросервисы не съели весь монолитный бюджет.