Меня зовут Максим, я веб-разработчик. Знаете, что общего между интернет-магазином в Москве и его посетителем из Хабаровска? Расстояние в 6 000 километров — и 150–200 миллисекунд задержки на каждый запрос. Умножьте на 30–50 запросов при загрузке страницы — и получите секунды потерянного времени. Edge computing решает эту проблему: ваш код выполняется не на одном сервере в Москве, а на десятках серверов по всему миру, максимально близко к каждому посетителю. В 2025 году я перевёл два проекта на edge-архитектуру — и расскажу, что из этого получилось.

Что такое edge computing простыми словами

Классическая схема: ваш сайт живёт на сервере в дата-центре (допустим, в Москве). Когда посетитель из Владивостока открывает страницу — запрос летит через всю страну до Москвы, сервер обрабатывает его, формирует ответ, отправляет обратно. Время: 200–400 мс на каждый запрос, просто из-за расстояния. А таких запросов при загрузке страницы — десятки.

CDN (Content Delivery Network) частично решает проблему: статические файлы (изображения, CSS, JS) раздаются с ближайшего к пользователю сервера. Но HTML-страницу, которая генерируется динамически (с персонализацией, ценами, остатками), CDN не кэширует — она всё равно летит из Москвы.

Edge computing — это следующий шаг: ваш серверный код выполняется прямо на edge-серверах, рядом с пользователем. Не только статика, но и логика: рендеринг HTML, персонализация, A/B-тесты, редиректы, авторизация.

Представьте: посетитель из Новосибирска открывает ваш сайт — и его запрос обрабатывается на сервере в Новосибирске. Не в Москве. Задержка: 10–20 мс вместо 150–200 мс. Страница загружается мгновенно.

Как edge computing работает технически

Edge-платформы

Cloudflare Workers. Самая зрелая платформа. Код на JavaScript/TypeScript выполняется на 300+ серверах по всему миру (включая несколько точек в России). Время холодного старта: ~0 мс (технология V8 Isolates — без контейнеров и виртуальных машин).

Vercel Edge Functions. Если ваш сайт на Next.js и хостится на Vercel — edge-функции доступны «из коробки». Серверные компоненты и middleware могут работать на edge.

Яндекс Cloud CDN + Serverless. Российская альтернатива: serverless-функции в Яндекс Облаке + CDN с точками в России. Не полный edge computing, но близко по концепции.

Что можно выполнять на edge

SSR (Server-Side Rendering). Рендеринг HTML-страниц на edge-сервере, рядом с пользователем. Next.js поддерживает edge runtime для серверных компонентов — страница рендерится за 10–50 мс вместо 200–500 мс.

Middleware. Промежуточная логика до основного обработчика: редиректы, авторизация, A/B-тесты, геолокация. В Next.js middleware с `runtime: 'edge'` выполняется на ближайшем edge-сервере.

Персонализация. Определение региона посетителя по IP (geo-detection на edge), подстановка локального контента (цены, телефоны, адреса филиалов) без обращения к основному серверу.

Кэширование с инвалидацией. Edge-сервер кэширует HTML-страницу и отдаёт её мгновенно. При обновлении данных (изменение цены, остатка) — кэш инвалидируется, и следующий запрос получает свежие данные.

A/B-тестирование. Распределение пользователей по вариантам эксперимента на edge — без задержки на обращение к серверу эксперимента.

Ограничения edge

Нет доступа к базе данных. Edge-функции не могут напрямую подключиться к PostgreSQL в вашем дата-центре — задержка до базы съест весь выигрыш. Решение: edge-совместимые базы данных (Turso, PlanetScale, Neon с edge-прокси) или предварительное кэширование данных в edge KV-хранилище.

Ограниченное время выполнения. Cloudflare Workers: до 30 секунд (обычно задачи выполняются за 5–50 мс). Vercel Edge: до 25 секунд. Тяжёлые вычисления — не для edge.

Ограниченный набор API. На edge нет полноценного Node.js: нет доступа к файловой системе, ограничены встроенные модули. Код должен быть «легким».

Два моих проекта на edge

Проект 1: мультирегиональный интернет-магазин

Сеть магазинов стройматериалов, 18 регионов. Проблема: страницы каталога генерировались на сервере в Москве, для Сибири и Дальнего Востока загрузка занимала 3–4 секунды.

Что сделали:

  1. Перенесли рендеринг каталога на edge (Vercel Edge Functions)
  2. Middleware определяет регион посетителя по IP и подставляет локальные цены, наличие, контакты филиала
  3. Популярные страницы каталога кэшируются на edge с TTL 5 минут (обновление цен — раз в 15 минут через фоновую инвалидацию)
  4. Персонализация: авторизованный пользователь видит свои цены (скидочная категория), данные берутся из edge KV-хранилища

Результат:

  • TTFB (Time to First Byte) для Новосибирска: с 380 мс до 45 мс
  • TTFB для Владивостока: с 520 мс до 60 мс
  • LCP (Largest Contentful Paint): улучшение на 40% по всем регионам
  • Конверсия в регионах (кроме Москвы): +18%

Проект 2: SaaS-платформа с глобальной аудиторией

Российский SaaS для управления проектами, пользователи в России, СНГ и Юго-Восточной Азии. Проблема: дашборд загружался из Москвы, для пользователей из Ташкента и Бангкока — 2–3 секунды на каждое действие.

Что сделали:

  1. Middleware на edge: авторизация (проверка JWT-токена) выполняется на ближайшем сервере
  2. Статический shell приложения (App Shell) кэшируется на edge — пользователь мгновенно видит интерфейс
  3. Данные загружаются асинхронно с основного сервера, но skeleton-loading создаёт ощущение быстрой работы
  4. Частые API-запросы (список проектов, уведомления) кэшируются на edge с TTL 30 секунд

Результат:

  • Воспринимаемая скорость загрузки: субъективно «мгновенно» для пользователей из всех регионов
  • Среднее время до интерактивности: с 3,2 сек до 1,1 сек
  • Retention (удержание) в первый месяц: +12%

Когда edge computing оправдан

Да, стоит внедрять:

  • Аудитория разбросана по регионам (Россия — огромная страна)
  • Критична скорость загрузки (интернет-магазины, SaaS)
  • Нужна персонализация в реальном времени (геолокация, A/B-тесты)
  • Высокий трафик (edge снижает нагрузку на основной сервер)

Нет, пока не нужно:

  • Аудитория в одном городе (достаточно хорошего сервера в том же ЦОД)
  • Малый трафик (до 10 000 визитов в месяц — выигрыш незаметен)
  • Сложная бизнес-логика, требующая доступа к базе данных на каждый запрос (edge пока не заменяет полноценный бэкенд)

Edge computing в российских реалиях

Основная проблема: большинство edge-платформ (Cloudflare, Vercel, Deno Deploy) — зарубежные. У Cloudflare есть точки присутствия в России (Москва, Санкт-Петербург), но политическая ситуация создаёт неопределённость.

Российские альтернативы:

  • Яндекс Cloud CDN + Cloud Functions — серверлесс-функции + CDN с точками по России. Не полноценный edge runtime, но для SSR и кэширования — работает
  • Selectel CDN — точки в крупных российских городах
  • VK Cloud — развивающаяся платформа с серверлесс-возможностями

Мой подход: для проектов, ориентированных только на российский рынок, использую Яндекс Cloud + CDN. Для проектов с международной аудиторией — Vercel (с edge-функциями) или Cloudflare Workers, с осознанием рисков.

Стоимость

Настройка edge-кэширования и middleware на существующем Next.js-проекте. Срок: 1–2 недели. Бюджет: 50–150 тысяч рублей.

Миграция SSR на edge runtime. Срок: 2–4 недели. Бюджет: 100–300 тысяч рублей.

Полная edge-архитектура для нового проекта. Надбавка к стоимости разработки: 15–25%.

Инфраструктура: Cloudflare Workers — бесплатный план покрывает 100 000 запросов в день. Платный — от $5/мес. Vercel — бесплатный план для небольших проектов, Pro — от $20/мес.

Если хотите ускорить ваш сайт для региональной аудитории — обращайтесь.