За последний год Vercel и Cloudflare с разной интенсивностью продают edge-функции как ответ на любой вопрос. На пяти наших проектах мы попробовали edge в разных сценариях. Делимся, где он реально даёт выигрыш.
Где edge выигрывает
A/B тесты и редиректы
Решение принимается за миллисекунды на edge-узле, до того, как пользователь увидит TTFB. Альтернатива - на клиенте через JavaScript, что даёт мерцание контента. Edge тут чистый плюс.
Геолокация и персонализация
Меняем язык / валюту / витрину по IP без RTT до origin-сервера. Особенно чувствуется на пользователях в Азии и Латинской Америке, где origin часто в US/EU.
Auth-проверка (JWT validation)
Проверить токен и принять/отклонить запрос можно на edge без обращения к origin. Снижает нагрузку на основной сервер процентов на 30 при потоке невалидных запросов.
Где edge - пустая трата времени
- Любой запрос, который всё равно идёт в БД в одном регионе. Latency определяется самым медленным звеном.
- Тяжёлые вычисления - лимит CPU на edge скромный, а cold start есть и тут.
- Работа с большими библиотеками - edge runtime сильно ограниченный (нет fs, нет нативных модулей).
- ML-inference - почти всегда edge не подходит, нужны нормальные GPU/CPU инстансы.
Cold start: миф и реальность
Cold start у edge-runtime реально низкий (10–50мс против 200–800мс у Node lambda). Но если ваш bundle весит 5+ МБ - добро пожаловать обратно в мир задержек. На edge нужно жёстко следить за размером кода.
Что мы рекомендуем
- Middleware - да, на edge.
- API-routes под классические CRUD - нет, оставляйте на Node-runtime.
- Streaming-роуты для SSE/AI - на edge, если поддерживается провайдером.
- Любая работа с ORM (Prisma) - лучше Node, edge пока сырой для большинства DB-стеков.