Периферийные вычисления для отдельного сайта: сценарии применения и производительность Cloudflare Workers/Vercel Edge
Что такое периферийные вычисления и как они связаны с CDN
Обычный CDN только кэширует статические файлы и отдаёт их из кэша по запросу. Edge computing выполняет небольшой фрагмент JavaScript прямо на узле CDN и до отправки ответа может принять логическое решение: перенаправить на разные страницы в зависимости от геолокации пользователя, выбрать версию для показа по cookie, проверить валидность JWT. Эта логика выполняется на узле в десятках миллисекунд от пользователя, без обращения к origin-серверу.
Отличие от серверного рендеринга (SSR): SSR работает на вашем собственном сервере, и всем пользователям по всему миру приходится пересекать океан, чтобы подключиться к этому серверу; периферийные функции работают одновременно на более чем 300 узлах по всему миру, и пользователю достаточно подключиться к ближайшему. Для трансграничного B2B-сайта эта разница в расстоянии напрямую определяет, будет TTFB 100 миллисекунд или 800. О связи CDN и периферии читайте Глобальное ускорение CDN.
Контринтуитивный вывод: edge computing — это не «более быстрый сервер», а «более маленький сервер». У каждой edge-функции есть жёсткий лимит CPU, тяжёлые вычисления ей недоступны. Если перенести на периферию логику с запросом к базе на 200 мс, результат будет более чем в 3 раза медленнее, чем на origin-сервере — из-за большого сетевого расстояния от периферийного узла до базы данных.
| Среда выполнения | Место запуска | Лимит времени CPU | Холодный старт | Доступ к базе данных | Модель оплаты |
|---|---|---|---|---|---|
| Традиционный сервер (VPS) | Один дата-центр | Без жёсткого лимита | Нет (постоянно в памяти) | Локально/внутренняя сеть, быстро | Фиксированная оплата за месяц |
| Cloudflare Workers | Более 300 узлов по всему миру | 10 мс бесплатно/30 мс платно | Почти ноль (изоляция V8) | Нужно подключать внешнюю базу данных, медленно | Оплата за количество запросов |
| Vercel Edge Functions | Более 25 узлов по всему миру | До 30 секунд | 10–50 миллисекунд | Поддерживает Edge DB | Оплата за время вызова |
| AWS Lambda@Edge | Узлы CloudFront по всему миру | До 5 секунд | 10–100 миллисекунд | Нужно подключаться к RDS через публичную сеть | За запросы + время |
Три сценария, где периферийные вычисления действительно стоит использовать
Сценарий первый: редирект по геолокации и языку. Немецкий пользователь заходит на сайт и автоматически попадает на /de/ — немецкую версию, пользователь из Ближнего Востока — на /ar/ — арабскую. Обычно для этого сервер читает IP-базу и принимает решение, а каждый запрос идёт к источнику. С Cloudflare Workers достаточно 10 строк кода: на периферийном узле сразу возвращаем 301 по стране из IP, и TTFB падает с 400 до 50 миллисекунд. Как настроить hreflang для мультиязычного сайта, читайте в статье Hreflang для мультиязычных сайтов.
Сценарий второй: разделение трафика для A/B-тестов. Вы хотите сделать две версии главной страницы: 50% пользователей видят версию A, 50% — версию B. Обычно сервер читает cookie и решает, какую версию отрендерить. На периферии проще: Workers по хешу cookie переписывает пути к ресурсам в HTML или подставляет другие переменные, а источник об этом даже не знает. Само разделение занимает меньше 10 миллисекунд и не влияет на TTFB.
Сценарий третий: лёгкая аутентификация и защита от парсинга. Запросы после входа пользователя сначала проверяются на периферии: если JWT недействителен, сразу возвращаем 401 и не идём к источнику. Так источник обрабатывает только легитимные запросы, экономя трафик и CPU. Защиту от парсинга тоже можно делать на периферии: при подозрительном User-Agent или слишком высокой частоте запросов сразу отдаём страницу с проверкой и не пропускаем запрос к источнику.
| Ситуация | Реализация на периферии | Выигрыш в производительности | Объём работ | Рекомендуемый приоритет |
|---|---|---|---|---|
| Георедирект | Workers читает request.cf.country | TTFB снижается на 50–150 мс | Полдня | Высокий |
| Разделение трафика для A/B-тестов | Workers делит трафик по хешу cookie | TTFB не растёт | 1–2 дня | Средний |
| Аутентификация JWT на периферии | Проверка токена на периферии, недействительный сразу отклоняется | Нагрузка на источник снижается на 20–40% | 2 дня | Высокий |
| Защита от парсинга и ограничение частоты | Проверка User-Agent и частоты на периферии | Вредные запросы не доходят до источника | 1 день | Высокий |
| Персонализированный рендеринг страниц | Сборка HTML-фрагментов на периферии | Работает только для повторяющихся фрагментов | 3–5 дней | Низкая |
Три: две ловушки, где периферийные вычисления не нужны
Ловушка первая: перенос запросов к базе данных на периферию. Многие считают, что «периферийные вычисления — это круто», и переносят туда даже логику запросов из личного кабинета. В итоге периферийный узел подключается к удалённой базе, и один сетевой запрос занимает 200 миллисекунд — в 5 раз медленнее, чем локальный запрос на источнике. Периферийные функции подходят для логики «без состояния, с малыми вычислениями, на кеше», но не для логики, которой нужна база данных.
Ловушка вторая: перенос всего SSR на периферию. Режим Edge Runtime в Next.js действительно позволяет запускать рендеринг React на периферийных узлах Vercel, но рендеринг сложной страницы может занять больше 100 миллисекунд CPU, упереться в лимиты бесплатного тарифа или из-за холодного старта заставить первого посетителя ждать лишние 50 миллисекунд. Сложный серверный рендеринг по-прежнему должен работать на источнике, а периферия — только лёгкий промежуточный слой. Как управлять сторонними скриптами, читайте в статье Управление сторонними скриптами.
Пример из практики: SaaS-продукт выходит на зарубежные рынки, странице дашборда нужно обратиться к базе данных и отрендериться. Команда с энтузиазмом переписала эту страницу на Vercel Edge Runtime и обнаружила, что задержка от edge-узла до их базы AWS RDS составляет 80 мс, а вместе со временем рендеринга TTFB вырос с 250 мс до 450 мс. После того как дашборд вернули на origin, а на edge оставили только проверку авторизации и маршрутизацию, TTFB снова стал 250 мс.
| Ловушка | Кажется, что даёт | Что получают | Правильный подход |
|---|---|---|---|
| Перенос запросов к базе на edge | “Ближе к пользователю” | Сеть от edge до БД далеко, задержка вырастает в 3–5 раз | Запросы к БД остаются на origin, edge только читает из кэша |
| SSR всего сайта на edge | “Глобальное ускорение” | Превышение CPU и медленный холодный старт, TTFB только растёт | Edge — только промежуточный слой, рендеринг остаётся на origin |
| Интенсивная работа с файлами | “Локальная обработка” | На edge нет постоянного диска, память ограничена | Файловые операции идут через API объектного хранилища |
| Долгие вычисления | “Параллельно быстрее” | Превышение CPU даёт ошибку 1102 | Разбить на мелкие задачи или вынести в очередь сообщений |
4. Стоимость и выбор платформы: Cloudflare Workers vs Vercel Edge
Cloudflare Workers和Vercel Edge Functions是目前独立站最常用的两个边缘平台。选型主要看你的技术栈和流量规模。Cloudflare Workers用V8 isolate，冷启动接近零，免费版每天10万次请求，非常适合做轻量路由和鉴权。Vercel Edge Functions和Next.js深度集成，如果你已经用Next.js，迁移成本最低，但冷启动比Workers慢。
По стоимости: платный тариф Cloudflare — от 5 долларов в месяц, включает 10 млн запросов; Vercel Pro — от 20 долларов в месяц, edge-функции тарифицируются по времени выполнения, и при большом трафике счёт растёт быстро. Для небольшого и среднего B2B-сайта с месячным PV до 100 000 бесплатного тарифа Cloudflare в основном хватает. Как следить за производительностью, читайте в Мониторинг сайта и оповещения.
| Измерение | Cloudflare Workers | Vercel Edge Functions | AWS Lambda@Edge |
|---|---|---|---|
| Холодный старт | Почти нулевой (V8) | 10–50 миллисекунд | 10–100 миллисекунд |
| Бесплатный лимит | 100 000 запросов в день | 100 GB-hours в месяц | 1 млн запросов в месяц |
| Платный тариф от | 5 долларов в месяц | 20 долларов в месяц | По факту использования, без месячной подписки |
| Язык разработки | JavaScript/TypeScript | JavaScript/TypeScript | Node.js/Python |
| Подходящие фреймворки | Чистые функции/промежуточное ПО | Глубокая интеграция с Next.js | Сайты в экосистеме AWS |
| Покрытие узлов | 300+ городов | 25+ стран | CloudFront по всему миру |
FAQ: частые вопросы
Бесплатного тарифа Cloudflare Workers действительно хватает?
Как edge-функции связаны с кэшем CDN?
Что быстрее — Vercel Edge Functions или Cloudflare Workers?
Можно ли с помощью edge-функций улучшить SEO?
Как откатить edge-функцию при ошибке?
В каких случаях edge-вычисления не ускорят сайт?
В заключение
Edge-вычисления — это точечная оптимизация, а не революция в архитектуре всего сайта. Они решают конкретное узкое место — «каждый запрос должен идти на origin» — и подходят для лёгкой маршрутизации, аутентификации и распределения трафика. Если идти в edge с ожиданием «весь сайт станет вдвое быстрее», скорее всего вас ждёт разочарование: большая часть медленных мест — это запросы к базе данных и сторонние скрипты, а не сетевое расстояние.
Совет по внедрению: начните с минимального сценария — сделайте геоперенаправление на Cloudflare Workers, чтобы немецких пользователей автоматически перекидывало на немецкую версию сайта. Такой правкой можно заняться уже через полдня, прирост производительности заметен сразу, а рисков минимум. Когда две недели всё проработает стабильно, можно думать о A/B-тестировании или аутентификации на периферии. Не пытайтесь с самого начала перенести весь сайт на периферию.
Запомните одну фразу: периферийные вычисления — это пункт выдачи заказов рядом с пользователем, а не склад рядом с базой данных. Сортировку отдайте туда, а складские задачи пусть остаются на месте.