Edge Runtime в Next.js обещает низкие задержки и глобальное распределение. На практике у него есть существенные ограничения, которые стоит знать до того, как переписать половину кода.
Что такое Edge Runtime
Edge — это облегчённая среда выполнения на основе V8, разворачиваемая в географически распределённых дата-центрах ближе к пользователю. Холодный старт у Edge ~5-50 мс против ~200-500 мс у обычного Node serverless.
В Next.js Edge доступен для middleware, API-роутов и страниц через export const runtime = "edge". Vercel, Cloudflare Workers и другие провайдеры поддерживают его нативно. На своём сервере (Yandex Cloud, Selectel) Edge сводится к Node — это просто маркетинг без реального преимущества.
Что работает в Edge
Базовый JS, fetch, Web Crypto, Streams API, URL, FormData. Часть npm-пакетов, написанных для веб-стандартов: Zod, jose (для JWT), nanoid, drizzle-orm с HTTP-драйвером, neverthrow.
Многие современные библиотеки (Stripe SDK, OpenAI SDK) явно поддерживают Edge — у них есть отдельные сборки. Если в README пакета упоминается edge — почти всегда работает.
Что не работает в Edge
Нет fs, crypto (только Web Crypto), child_process, net, dns, tls напрямую. Это значит — нет нативного Postgres-клиента (pg), нет Redis-клиента (ioredis), нет любых пакетов с native bindings (например, sharp для обработки изображений, bcrypt).
Решение: использовать HTTP-варианты этих сервисов. Postgres через @neondatabase/serverless или Supabase — поверх HTTP. Redis через Upstash. Это работает, но добавляет латентность HTTP по сравнению с TCP-соединением.
Когда Edge оправдан
Middleware, который отрабатывает на каждом запросе: A/B-тесты, геолокация, редиректы, проверка авторизации по cookie. Edge даёт прирост в 100-300 мс на пользователях, географически удалённых от вашего основного дата-центра.
OG-image generation через @vercel/og — отлично работает на Edge, генерирует картинки за 50-200 мс. Простые API-эндпоинты для прокси, обогащения данных, агрегации. Стриминг ответов от LLM (OpenAI, Claude) — Edge с правильной поддержкой streaming работает значительно быстрее.
Когда Edge не нужен
Тяжёлые SQL-запросы с JOIN'ами 5-10 таблиц — Edge только добавит задержку HTTP-драйвера. Работа с файлами, обработка изображений, генерация PDF — всё это либо невозможно, либо медленнее Node.
Российская специфика: если все ваши пользователи в РФ, а серверы — в Yandex Cloud в Москве, географическое распределение Edge не даёт ничего. Нет смысла переходить ради «модно».
Edge на своём сервере
Vercel и Cloudflare продают Edge как географически распределённую сеть. На VPS в Yandex Cloud это не работает — у вас один регион, один сервер, никакого Edge. Декларация runtime: "edge" просто использует более лёгкую среду выполнения, но без географического профита.
Если нужна низкая задержка для глобальной аудитории — рассмотрите Cloudflare Workers как реальный Edge-провайдер. Для аудитории СНГ — Yandex Cloud Functions ближе по сути, хотя это не Next.js Edge.
Миграция на Edge
Если решили перевести часть приложения на Edge: начните с middleware. Это самый безопасный вариант, и часто там не нужна тяжёлая логика. Дальше — простые API-роуты, типа GET /api/feature-flags, GET /api/og.
Тестируйте на staging обязательно. Часть багов (типа неподдерживаемых API) проявится только при определённых ветках кода.
Итого
Edge Runtime — полезный инструмент для middleware, OG-картинок, простых прокси и стриминга LLM. Для полноценного приложения с тяжёлыми запросами он не подходит. На VPS в РФ без географической распределённости профит сводится к меньшему холодному старту serverless. Перед миграцией оцените, что вам реально даст Edge в конкретном сценарии.
Частые вопросы
Что такое Edge Runtime в Next.js и чем он отличается от Node?
Edge — это облегчённая среда выполнения на основе V8, разворачиваемая в географически распределённых дата-центрах ближе к пользователю. Холодный старт у Edge ~5-50 мс против ~200-500 мс у обычного Node serverless. В Next.js Edge доступен для middleware, API-роутов и страниц через export const runtime = "edge". Vercel, Cloudflare Workers и другие провайдеры поддерживают его нативно. На своём сервере (Yandex Cloud, Selectel) Edge сводится к Node — это просто маркетинг без реального преимущества.
Какие API работают и не работают в Edge Runtime?
Работают: базовый JS, fetch, Web Crypto, Streams API, URL, FormData. Часть npm-пакетов, написанных для веб-стандартов: Zod, jose (для JWT), nanoid, drizzle-orm с HTTP-драйвером, neverthrow. Не работают: fs, crypto (только Web Crypto), child_process, net, dns, tls напрямую. Это значит — нет нативного Postgres-клиента (pg), нет Redis-клиента (ioredis), нет любых пакетов с native bindings (sharp для обработки изображений, bcrypt). Многие современные библиотеки имеют отдельные edge-сборки.
Когда Edge Runtime реально оправдан?
Middleware, который отрабатывает на каждом запросе: A/B-тесты, геолокация, редиректы, проверка авторизации по cookie. Edge даёт прирост в 100-300 мс на пользователях, географически удалённых от вашего основного дата-центра. OG-image generation через @vercel/og — отлично работает на Edge, генерирует картинки за 50-200 мс. Простые API-эндпоинты для прокси, обогащения данных, агрегации. Стриминг ответов от LLM (OpenAI, Claude) — Edge с правильной поддержкой streaming работает значительно быстрее.
Когда не стоит использовать Edge Runtime?
Тяжёлые SQL-запросы с JOIN'ами 5-10 таблиц — Edge только добавит задержку HTTP-драйвера. Работа с файлами, обработка изображений, генерация PDF — всё это либо невозможно, либо медленнее Node. Российская специфика: если все ваши пользователи в РФ, а серверы в Yandex Cloud в Москве, географическое распределение Edge не даёт ничего. Нет смысла переходить ради «модно». Для типового CRM или e-commerce внутри РФ Edge не нужен.
Как Edge работает на собственных серверах в РФ?
Vercel и Cloudflare продают Edge как географически распределённую сеть. На VPS в Yandex Cloud это не работает — у вас один регион, один сервер, никакого Edge. Декларация runtime: "edge" просто использует более лёгкую среду выполнения, но без географического профита. Если нужна низкая задержка для глобальной аудитории — рассмотрите Cloudflare Workers как реальный Edge-провайдер. Для аудитории СНГ — Yandex Cloud Functions ближе по сути, хотя это не Next.js Edge.
Как мигрировать часть приложения на Edge Runtime?
Если решили перевести часть приложения на Edge: начните с middleware. Это самый безопасный вариант, и часто там не нужна тяжёлая логика. Дальше — простые API-роуты, типа GET /api/feature-flags, GET /api/og. Тестируйте на staging обязательно. Часть багов (типа неподдерживаемых API) проявится только при определённых ветках кода. Postgres через @neondatabase/serverless или Supabase — поверх HTTP. Redis через Upstash. Это работает, но добавляет латентность HTTP по сравнению с TCP.