Разработка Edge Functions для сайта (Vercel Edge)

Наша компания занимается разработкой, поддержкой и обслуживанием сайтов любой сложности. От простых одностраничных сайтов до масштабных кластерных систем построенных на микро сервисах. Опыт разработчиков подтвержден сертификатами от вендоров.

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

Это лишь некоторые из технических типов сайтов, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Разработка Edge Functions для сайта (Vercel Edge)
Средний
~2-3 дня
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1358
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    956
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    947

Разработка Edge Functions для сайта (Vercel Edge)

Хотите делать A/B-тесты без лагов? Или редиректить пользователей по геолокации за миллисекунды? Vercel Edge Functions запускаются на 100+ узлах по всему миру, холодный старт менее 1 мс. Мы разработали десятки таких функций — от middleware до API-роутов. Расскажем, как это работает и когда стоит применять.

Edge-вычисления становятся стандартом для высоконагруженных проектов: они снижают время ответа до 10–50 мс и улучшают Core Web Vitals. В этой статье — реальный опыт внедрения и готовые примеры кода.

Проблемы, которые решаем

Персонализация на SSG-сайте — проблема: каждый запрос требует нового рендера. Edge Functions решают это на границе сети без полной перегенерации. A/B-тесты без потери SEO — сложно без серверного редиректа. Edge Functions позволяют переписывать URL на лету, сохраняя статус-код 200. Геолокация для контента — без Edge пришлось бы поднимать сервер или платить за CDN с поддержкой VCL. Мы используем встроенную geolocation из @vercel/functions. По нашим оценкам, миграция логики на Edge сокращает затраты на облачную инфраструктуру на 30–50%.

Когда выбирать Edge Functions?

Edge Functions оптимальны для: персонализации (A/B тест, геолокация), редиректов и rewrite на основе условий, middleware-аутентификации, трансформации заголовков и ответов, кэш-валидации по cookie.

Обычные Node.js Functions нужны когда: требуется Node.js API (fs, crypto, нативные модули), соединение с PostgreSQL через TCP, время выполнения > 30 с, объём памяти > 128 MB.

Edge Runtime использует Web API (как в браузере), а не Node.js API.

Сценарий Edge Functions Node.js Functions
A/B тест ❌ (избыточно)
Геолокация ❌ (дорого)
JWT-защита
Работа с файлами
PostgreSQL TCP
Выполнение >30 с ❌ (Hobby)

Как Edge Functions ускоряют сайт?

Скорость достигается за счёт размещения кода на границе сети. Вместо запроса к серверу в одном регионе, Edge выполняется в ближайшем к пользователю узле. Это снижает задержку (latency) и улучшает LCP и INP. Кроме того, Edge может кэшировать ответы на уровне CDN, уменьшая нагрузку на origin. Для статически генерируемых сайтов Edge Functions позволяют персонализировать контент без полной перегенерации — ключевой фактор улучшения Core Web Vitals.Vercel Edge Functions documentation

Примеры реализации

Middleware для A/B тестирования

Файл middleware.ts в корне проекта Next.js:

import { NextRequest, NextResponse } from "next/server";

export function middleware(request: NextRequest) {
  const url = request.nextUrl.clone();

  // A/B тест для главной страницы
  if (url.pathname === "/") {
    const bucket = request.cookies.get("ab-bucket")?.value;

    if (!bucket) {
      const newBucket = Math.random() < 0.5 ? "a" : "b";
      const response = NextResponse.rewrite(
        new URL(newBucket === "b" ? "/home-variant" : "/", request.url)
      );
      response.cookies.set("ab-bucket", newBucket, { maxAge: 86400 * 30 });
      return response;
    }

    if (bucket === "b") {
      url.pathname = "/home-variant";
      return NextResponse.rewrite(url);
    }
  }

  return NextResponse.next();
}

export const config = {
  matcher: ["/", "/pricing", "/features"],
};

Наш опыт: на одном проекте с аудиторией 2 млн уникальных в месяц Edge-мидлвар сократил время до первого байта (TTFB) на 40% по сравнению с аналогичной логикой на сервере в AWS. Пользователи в Европе получали ответ за <20 мс.

Геолокация и персонализация

import { NextRequest, NextResponse } from "next/server";
import { geolocation } from "@vercel/functions";

export function middleware(request: NextRequest) {
  const { country, city } = geolocation(request);

  // Редирект на локализованную версию
  if (country === "RU" && !request.nextUrl.pathname.startsWith("/ru")) {
    return NextResponse.redirect(
      new URL(`/ru${request.nextUrl.pathname}`, request.url)
    );
  }

  // Добавляем геоданные в заголовки для компонентов
  const response = NextResponse.next();
  response.headers.set("x-user-country", country || "unknown");
  response.headers.set("x-user-city", city || "unknown");
  return response;
}

Edge API Route

// app/api/edge-data/route.ts
import { NextRequest, NextResponse } from "next/server";

export const runtime = "edge";

export async function GET(request: NextRequest) {
  const { searchParams } = new URL(request.url);
  const id = searchParams.get("id");

  // Fetch работает нативно в Edge Runtime
  const data = await fetch(`https://api.external.com/data/${id}`, {
    headers: { Authorization: `Bearer ${process.env.API_KEY}` },
    // next.js cache: кэш на 60 секунд
    next: { revalidate: 60 },
  }).then(r => r.json());

  return NextResponse.json(data, {
    headers: { "Cache-Control": "s-maxage=60, stale-while-revalidate=120" }
  });
}

Защита маршрутов через JWT

import { NextRequest, NextResponse } from "next/server";
import { jwtVerify } from "jose";

const JWT_SECRET = new TextEncoder().encode(process.env.JWT_SECRET);

export async function middleware(request: NextRequest) {
  if (request.nextUrl.pathname.startsWith("/dashboard")) {
    const token = request.cookies.get("auth-token")?.value;

    if (!token) {
      return NextResponse.redirect(new URL("/login", request.url));
    }

    try {
      await jwtVerify(token, JWT_SECRET);
      return NextResponse.next();
    } catch {
      const response = NextResponse.redirect(new URL("/login", request.url));
      response.cookies.delete("auth-token");
      return response;
    }
  }
}

jose — единственная JWT-библиотека, совместимая с Edge Runtime (использует Web Crypto API вместо node:crypto).

Ограничения Edge Runtime

  • Нет node:fs, node:path, node:crypto (есть Web Crypto)
  • Нет нативных npm-пакетов
  • Память: 128 MB
  • CPU time: 30 мс (Hobby), без ограничений на Pro
  • Нет прямых соединений к PostgreSQL (Neon и PlanetScale поддерживают HTTP API)

Типичные ошибки при разработке

Ошибка Последствие Решение
Использование require вместо import Ошибка выполнения Всегда используйте ES-модули
Обращение к process.env вне верхнего уровня Переменные окружения не загружаются Читайте env только во время инициализации
Попытка прочитать файлы через fs Ошибка API Используйте fetch или внешние API
Длинные операции >30 мс на Hobby Тайм-аут Переход на Pro или оптимизация
Что делать, если функция превышает лимиты? Оптимизируйте код: выносите тяжёлые вычисления на клиент или используйте Vercel Pro. Для длительных задач применяйте обычные Serverless Functions.

Процесс работы и сроки

  1. Аналитика: разбираем текущую архитектуру, определяем места для Edge.
  2. Проектирование: выбираем сценарии (A/B, гео, auth), проектируем middleware.
  3. Реализация: пишем код с TypeScript, тестируем локально.
  4. Тестирование: проверяем TTFB, LCP, INP, корректность редиректов.
  5. Деплой: настраиваем Vercel, выкатываем постепенно (canary).

Сроки

Middleware с геолокацией и A/B тестом — 1–2 дня. Edge API Routes с кэшированием и JWT-защитой — 2–3 дня. Оценим ваш проект за 1 день.

Наш опыт: 5 лет с Vercel, более 50 проектов с Edge Functions. Получите консультацию — обсудим вашу задачу и предложим оптимальное решение. Закажите разработку Edge Functions — сроки от 1 дня. Гарантируем качество и производительность.

Serverless-разработка: AWS Lambda, Vercel Functions, Cloudflare Workers, Edge

Serverless не означает «без сервера». Серверы есть — вы просто не управляете ими. Правильнее читать это как «без менеджмента серверов»: нет патчинга ОС, нет настройки nginx, нет мониторинга дискового пространства. Функция получает событие, обрабатывает, возвращает ответ. Провайдер сам решает, на чём это запустить.

AWS Lambda: мощь и операционная сложность

Lambda — самая зрелая платформа с наибольшим набором триггеров: API Gateway, SQS, SNS, S3, DynamoDB Streams, EventBridge. Это важно для сложных event-driven архитектур.

Cold start — главная боль Lambda на Node.js: от 200ms до 1.5s в зависимости от размера бандла и VPC. В VPC холодный старт был до 10 секунд до 2019 года, сейчас улучшили, но он всё ещё дольше. Для production-функций с latency-требованиями: Provisioned Concurrency (держит инстансы прогретыми), SnapStart для Java, минимизация бандла через tree-shaking.

Практический кейс: функция обработки загружаемых изображений (ресайз, WebP-конвертация, загрузка в S3). Бандл с sharp весил 40MB из-за нативных бинарников. Решение — Lambda Layer с sharp, основная функция 800KB. Cold start упал с 3.2s до 400ms.

Lambda Layers — общие зависимости между функциями. До 5 слоёв на функцию, каждый до 250MB. Стандартная практика: layer с heavy dependencies (sharp, puppeteer, ffmpeg), layer с общей бизнес-логикой.

Инфраструктура Lambda через AWS CDK или Terraform. SAM — для тех, кто только начинает, CDK — для серьёзных проектов с типобезопасностью.

Vercel Functions и Edge Runtime

Vercel Functions — это Lambda под капотом (us-east-1 по умолчанию), но с минимальным порогом входа для Next.js-проектов. API Routes и Route Handlers деплоятся автоматически. Serverless функции на Node.js runtime с лимитом в 300 секунд на Vercel Pro.

Edge Runtime принципиально другой: функция запускается на V8 isolate в ближайшей к пользователю точке CDN-сети Vercel (120+ регионов). Нет cold start как такового — isolate стартует за ~0ms. Но жёсткие ограничения: нет Node.js API (fs, crypto через Web API), нет доступа к базам данных через TCP (только через HTTP API), размер бандла до 4MB.

Edge Runtime идеален для: middleware (auth check, redirect, A/B test), трансформации ответов, геолокационной логики, Edge Config. Не подходит для: обращения к PostgreSQL, тяжёлых вычислений, работы с файловой системой.

Cloudflare Workers: настоящий Edge

Workers запускаются на V8 isolates в 300+ точках присутствия Cloudflare. Latency для пользователя — буквально ближайший дата-центр. Cold start < 1ms.

Workers Durable Objects решают проблему состояния в Edge: каждый Durable Object — это одна точка координации, выполняется в одном регионе. Идеально для: игровых комнат, документов с реальным временем, rate limiting без гонок.

Workers KV — eventually consistent хранилище. Запись распространяется по всем регионам за ~60 секунд. Не подходит для финансовых транзакций, подходит для конфигов, feature flags, кэша.

D1 — SQLite на Edge. На одной реплике для чтения работает отлично, write latency зависит от расстояния до primary региона. Для глобальных write-heavy приложений — не лучший выбор.

Ecosystem: Hono.js — минималистичный роутер, работающий на Workers, Deno, Bun, Node.js. Если нужен единый код для Edge и сервера — хороший выбор.

Когда serverless не подходит

Длительные вычисления (>15 минут на Lambda, >30 секунд на Vercel) — нужен Fargate или обычный сервер. WebSocket-сервер с состоянием — нет постоянного процесса. Задачи с частым обращением к диску — эфемерный storage, /tmp на Lambda 512MB–10GB. Если функция вызывается тысячи раз в секунду постоянно — EC2 или Fargate дешевле.

Vendor lock-in — реальная проблема. Lambda-специфичный код (handler-сигнатура, Lambda context) сложно портировать. Hono.js, Remix, или адаптеры типа @hono/node-server помогают держать логику portable.

Observability

Без нормального observability serverless — чёрный ящик. Стандарт: AWS X-Ray или Powertools for AWS Lambda (structured logging, tracing, metrics из коробки). Для мультиоблачного стека — OpenTelemetry с экспортом в Grafana Cloud или Honeycomb.

Distributed tracing критичен когда функция А вызывает функцию Б через SQS — без trace ID невозможно связать логи.

Процесс работы

Начинаем с анализа паттерна нагрузки: если трафик непредсказуемый или редкий — serverless даст экономию. Если стабильно высокий — может оказаться дороже. Проектируем границы функций по принципу single responsibility. Разрабатываем локально через SST, Wrangler или LocalStack. CI/CD с preview deployments обязательно.

Сроки

Serverless API для стартапа (10–20 функций): 2–5 недель. Миграция монолитного Laravel/Node API на Lambda: 4–10 недель в зависимости от объёма. Edge Middleware + Workers для глобального продукта: 2–4 недели.