Edge computing для лендинга: где персонализацию делать на краю, а где не надо

Edge computing для лендинга: где персонализацию делать на краю, а где не надо

Персонализация на edge полезна, когда решение нужно принять до загрузки тяжёлого фронта: страна, язык, тип трафика, простая сегментация по cookie. Тогда на edge можно отдать другой заголовок, CTA, валюту, UTM-блок или даже собрать разный первый экран без похода на origin.

Схема рабочая только для лёгких правил:
— гео и язык по IP/Accept-Language;
— A/B-развилка по cookie или query string;
— отдельные офферы для mobile/desktop;
— скрытие лишних блоков до первого paint.
Если логика тянет БД, CRM или сложный профиль — выносите это на сервер. Edge не должен превращаться в медленный мини-бэкенд.

Главный риск — кеш. Если не разделить ответ по ключам, один посетитель увидит чужой вариант лендинга. Нужны разные cache key, аккуратный Vary и явный bypass для персонализированных страниц. Для тестов держите отдельный путь без кеша, иначе будете ловить фантомные баги и «почему у меня не так».

Ещё две ошибки: делать на edge тяжёлые скрипты и менять 10 элементов сразу. Чем больше условий, тем выше задержка и сложнее отладка. Персонализация должна усиливать первый экран, а не ломать LCP и стабильность.

Если правило нельзя объяснить за 2 строки и проверить без доступа к базе, ему не место на edge.