Каждые 50 мс задержки: как выбор локации сервера отражается на заказах в магазине

MAATRIX

Владелец интернет-магазина выбирает сервер, сравнивая цену и характеристики железа — CPU, память, диск. Локация в этом сравнении часто идёт последним пунктом, а то и вовсе не обсуждается: «ну, возьмём где дешевле, разница же в миллисекундах». Проблема в том, что эта разница не разовая — она добавляется к каждому запросу на пути пользователя от каталога до оплаты, и суммарно способна ощутимо изменить то, сколько посетителей доходит до кнопки «Оформить заказ». Разбираемся, как именно задержка складывается в потерянные заказы и почему локация сервера — это не техническая деталь, а решение, влияющее на выручку.

Как задержка складывается в ощущение «быстро» или «медленно»

Решение о покупке в интернет-магазине принимается под влиянием десятков факторов: цена, доверие к продавцу, наличие товара, отзывы, удобство навигации, ясность условий доставки. Скорость отклика сайта — один из этих факторов, и не самый заметный на первый взгляд: пользователь редко формулирует для себя «я не куплю здесь, потому что сайт на 200 мс медленнее конкурента». Но он вполне может сформулировать «здесь как-то неудобно» или «что-то тормозит, пойду посмотрю в другом месте» — и это субъективное раздражение часто и есть накопленный эффект множества мелких задержек.

Механика простая: каждое действие пользователя на сайте — открыть карточку товара, добавить в корзину, перейти к оформлению, ввести адрес — сопровождается запросом к серверу. Если каждый такой запрос выполняется на 50-100 мс дольше, чем мог бы, по отдельности это незаметно. Но за одну сессию покупки пользователь совершает не один запрос, а десяток-другой, и сайт с систематически более медленным откликом ощущается не как «конкретный клик подвис», а как общее фоновое раздражение — то самое чувство «сайт какой-то неотзывчивый», которое сложно выразить словами, но легко почувствовать.

Важно не путать это с единичным зависанием — если страница один раз не загрузилась за секунду, это не критично. Речь именно о систематической добавке ко времени отклика на каждом шаге, которая копится в общее впечатление о сайте за всю сессию.

Точки воронки, где задержка стоит дороже всего

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

Ключевые точки воронки по возрастанию цены задержки:

• Просмотр каталога и карточек товара. Пользователь ещё сравнивает варианты, задержка раздражает, но редко становится причиной ухода — если только не критична (страница реально долго не открывается).
• Добавление товара в корзину. Это первое действие, за которым стоит намерение купить. Если клик «В корзину» подвисает или не даёт мгновенной визуальной реакции, пользователь начинает сомневаться — сработало ли вообще, стоит ли кликать ещё раз, не задвоился ли товар.
• Переход к оформлению заказа и заполнение формы. Здесь пользователь уже инвестировал время и внимание, но именно здесь решается — довести дело до конца или закрыть вкладку. Любая заминка на этом шаге воспринимается острее, чем такая же заминка при просмотре каталога, потому что ставки для пользователя в моменте выше: он не хочет вводить данные повторно, не хочет разбираться, применилась ли скидка, не хочет гадать, ушёл запрос или нет.
• Переход к оплате. Самая чувствительная точка. Пользователь вводит платёжные данные или переходит на страницу платёжного шлюза — любая задержка здесь читается не просто как «медленно», а как «может, что-то не так, лучше не рисковать». Это тот момент воронки, где раздражение конвертируется в закрытую вкладку быстрее всего.

Практический вывод: при ограниченном бюджете в первую очередь стоит оптимизировать именно последние шаги воронки, а не главную страницу. Но выбор локации сервера действует не выборочно на один шаг, а на всю воронку сразу, потому что сетевая задержка закладывается в каждый запрос независимо от того, какая часть сайта его обрабатывает.

Почему выбор локации сервера — это задержка на каждом запросе воронки

Здесь важно разделить два источника задержки. Один — это то, сколько сервер обрабатывает запрос (работа приложения, запросы к базе данных, генерация страницы). Второй — это чистое время в пути, RTT (round-trip time), которое пакету нужно, чтобы физически преодолеть расстояние от браузера пользователя до сервера и обратно, независимо от того, насколько быстро сервер обработал сам запрос.

RTT определяется в первую очередь географией и качеством маршрута между сетью пользователя и дата-центром — расстоянием, числом промежуточных сетей, наличием прямого пиринга. Если сервер стоит физически далеко от основной массы аудитории, эта сетевая составляющая присутствует в каждом запросе как неустранимый минимум, поверх которого уже добавляется время обработки на сервере. Разница между тем, что показывает ping, и тем, что реально ощущает пользователь в браузере, подробно разобрана в статье про пинг 20 мс, а страницу, которая всё равно грузится 4 секунды — сетевой RTT там только часть картины, но именно та часть, которую нельзя ускорить оптимизацией кода.

Ключевая особенность именно сетевой задержки — в отличие от медленного запроса к базе данных, который можно ускорить индексом, RTT до удалённой локации не устраняется настройками сервера. Можно оптимизировать код магазина до идеала, поставить NVMe-диски, добавить кеширование — а базовая сетевая задержка до пользователя останется той же, потому что она определяется физическим расстоянием и маршрутом, а не мощностью сервера. Это архитектурное ограничение закладывается один раз, в момент выбора дата-центра, и присутствует в каждом запросе на протяжении всей жизни проекта.

Отдельно стоит учитывать, что «медленно» может ощущаться даже при невысоком пинге, если серверная часть TTFB сама по себе тяжёлая — разбор, из каких слоёв складывается время до первого байта ответа помимо чистой сети, есть в статье про TTFB 800 мс при пинге 20 мс. Для магазина это значит: даже устранив сетевую составляющую правильным выбором локации, стоит отдельно проверить логику приложения — это дополняющие, а не взаимозаменяемые источники задержки.

Сколько запросов реально стоит за одним оформлением заказа

Чтобы почувствовать масштаб эффекта, полезно посчитать, сколько отдельных запросов к серверу реально происходит за одну сессию покупки в типичном интернет-магазине — не одна загрузка страницы, а цепочка действий:

1. Загрузка главной страницы или страницы категории (HTML, CSS, JS, изображения товаров).
2. Переход в карточку товара — новый запрос страницы, часто с дополнительными AJAX-запросами (наличие на складе, похожие товары, отзывы).
3. Клик «В корзину» — AJAX-запрос на добавление, обновление счётчика корзины в шапке сайта.
4. Открытие страницы корзины — загрузка актуальных цен, проверка наличия, возможно запрос к сервису расчёта доставки.
5. Переход к оформлению заказа — загрузка формы, автоподстановка адреса (нередко с обращением к внешнему API геокодирования).
6. Применение промокода, если есть, — отдельный запрос на проверку и пересчёт суммы.
7. Выбор способа доставки — часто динамический запрос к API транспортной компании или курьерской службы за расчётом стоимости и сроков.
8. Переход к оплате — редирект на платёжный шлюз или встроенная форма, которая тоже обменивается данными с сервером.
9. Подтверждение заказа — финальный запрос, создающий заказ в системе, и переход на страницу «Спасибо за заказ».

Даже без AJAX-обвязки набирается 6-9 полноценных обращений к серверу за сессию, а с современными интерактивными элементами (динамический пересчёт корзины, проверка адреса, живой расчёт доставки) их может быть в разы больше. Если каждое из них несёт дополнительные 50 мс сетевого RTT из-за удалённой локации сервера, за сессию покупки набегает уже не 50 мс, а несколько сотен миллисекунд суммарной добавленной задержки — распределённой по самым чувствительным точкам воронки, разобранным в предыдущем разделе.

Здесь важна честность: это не значит, что каждые лишние 50 мс RTT напрямую вычитаются из процента конверсии по какой-то универсальной формуле — такой формулы не существует, и любые «каждые X мс = минус Y% продаж» из презентаций почти всегда взяты из чужого кейса в чужой нише. Но общий принцип — задержка на каждом шаге воронки суммируется в итоговое ощущение «быстро» или «медленно», и это ощущение статистически связано с готовностью пользователя довести покупку до конца — подтверждён достаточно широко, чтобы относиться к выбору локации сервера серьёзно, а не как к второстепенному параметру после цены тарифа.

Несовпадение аудитории и локации: как это выглядит на практике

Возьмём типичную ситуацию: магазин ориентирован на покупателей из России, а сервер по историческим причинам (первый деплой у знакомого хостера, случайный выбор при регистрации, «там было дешевле») стоит в дата-центре, физически далёком от основной аудитории и без хороших прямых стыков с российскими операторами. Формально сайт работает, страницы открываются, ничего не падает — просто на каждом запросе присутствует лишняя сетевая задержка, которая для одиночного клика незаметна, а за всю сессию покупки складывается в заметный фон.

Показательно, что интуитивная оценка «сервер в соседней стране — значит, там быстрее» часто не подтверждается замерами: маршрут в интернете определяется не расстоянием по карте, а реальной топологией сетей и пирингом между конкретными операторами. Иногда формально более далёкий дата-центр с хорошими прямыми стыками с сетями вашей аудитории оказывается быстрее географически близкого — и наоборот. Это ещё один аргумент в пользу того, чтобы не полагаться на предположения, а измерять.

Отдельно стоит учитывать, что для интернет-магазина к базовой сетевой задержке часто добавляются внешние интеграции — платёжный шлюз, служба доставки, SMS-провайдер для подтверждения заказа. Если эти сервисы тоже физически удалены от сервера магазина или от пользователя, каждый такой вызов на критичном шаге оформления заказа добавляет свою долю к общей задержке. Выбор локации сервера в этом смысле стоит делать не только с оглядкой на аудиторию, но и с оглядкой на то, где физически находятся основные интеграции, через которые проходит воронка заказа.

Как проверить реальную задержку для своего магазина, а не гадать

Прежде чем принимать решение о переезде или о выборе локации для нового проекта, стоит измерить, а не предполагать. Общий принцип «задержка от локации влияет на восприятие сайта» верен почти всегда, но конкретная величина эффекта для конкретного магазина зависит от того, где реально находится его аудитория, какой стек используется и сколько внешних вызовов встроено в воронку заказа.

Практический порядок проверки:

1. Определите, где реально находится аудитория — не по предположению, а по данным аналитики и логам сервера: разбивка по городам и, что важнее, по операторам связи (ASN), потому что маршрут до дата-центра у разных операторов одного города может ощутимо отличаться.
2. Измерьте текущую сетевую задержку и TTFB отдельно. Быстрая проверка через curl -w показывает, сколько времени уходит на DNS, TCP- и TLS-хендшейк отдельно от времени, которое сервер тратит на формирование ответа:

curl -o /dev/null -s -w "\
DNS: %{time_namelookup}s\n\
Connect: %{time_connect}s\n\
TLS: %{time_appconnect}s\n\
TTFB: %{time_starttransfer}s\n\
Total: %{time_total}s\n" https://ваш-магазин.ru/

Запускать эту проверку стоит не с ноутбука разработчика, а с точки, физически близкой к реальной аудитории — иначе легко получить обманчиво хороший результат, не отражающий опыт настоящих покупателей.

1. Прогоните замеры для ключевых шагов воронки отдельно, а не только для главной страницы: добавление в корзину, переход к оформлению, обращение к платёжному шлюзу. Именно эти точки, как разобрано выше, наиболее чувствительны к задержке.
2. Сравните кандидатов на локацию по фактическим замерам, а не по названию города на карте. Подробная методика — от того, как узнать реальную географию аудитории по логам и ASN, до того, как читать результаты через перцентили, а не только среднее значение — разобрана в статье про выбор локации по замерам аудитории. Тот же план на неделю применим и к выбору сервера именно для интернет-магазина: тестовые точки в 2-4 локациях, замеры в течение нескольких дней, сравнение по p50/p95, а не по единичному пингу.

Если после замеров выяснится, что задержка не является узким местом — это тоже полезный результат: значит, ресурсы стоит направить на оптимизацию кода, базы данных или интерфейса, а не тратить бюджет на переезд сервера. Но принимать это решение стоит на основе цифр, а не предположения «наверное, и так нормально».

Частые вопросы