Исправления задержек до второго региона: что настроить первым

Почему второй регион может не помочь

Когда пользователи говорят, что приложение работает медленно, мысль о втором регионе кажется очевидным решением. Иногда это действительно помогает. Но часто — нет.

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

Поэтому первая волна работы над задержками обычно остаётся рядом с самим запросом. Уменьшите объём данных, которые отправляются в браузер. Уберите лишнюю работу с запросами. Перестаньте делать побочные задачи, пока пользователь ждёт ответ.

Возьмём простой пример. Дашборд загружается за 2,8 секунды для пользователей в Европе, а приложение работает в США. Очень хочется добавить EU-регион. Но если 1,4 секунды уходят на фронтенд-ассеты, 800 мс — на два медленных запроса, а 300 мс — на отправку письма внутри запроса, география не является первой проблемой. Даже с близким сервером страница всё равно будет казаться медленной.

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

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

Измерьте, где именно теряется время

Страница может казаться медленной, даже если сервер отвечает быстро. Пользователь ждёт весь путь целиком: первый HTML, скрипты, стили, изображения, API-запросы и работу базы данных за этими запросами.

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

Разбейте задержку на несколько частей: первичный HTML-ответ, статические ассеты вроде JS и CSS, API-запросы после начала рендера и время базы данных внутри этих запросов. Такое разделение подсказывает, куда направить усилия. Медленный HTML-ответ указывает на сервер или запросы. Медленные ассеты — на кэширование, размер файлов или сжатие. Медленные API-запросы часто показывают слишком болтливый фронтенд или повторные чтения из базы.

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

Не доверяйте только средним значениям. Страница со средним временем 1,2 секунды всё равно может раздражать пользователей, если один из десяти визитов занимает 5 секунд. Смотрите и на более медленный хвост распределения. Мобильные сети, старые устройства и периоды высокой нагрузки обычно быстрее показывают настоящую проблему, чем спокойное офисное подключение.

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

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

Сократите доставку ассетов

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

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

Со шрифтами, скриптами и стилями та же история. Сжимайте их. Убирайте код, который больше не нужен. Делите большие бандлы на части, чтобы браузер получал только то, что нужно для первого экрана. Такая уборка обычно даёт результат быстрее, чем запуск нового региона.

Сторонние скрипты — отдельная частая проблема. Аналитика, виджеты чата, heatmap, рекламные теги и вставки из соцсетей часто замедляют первый полезный экран. Если страница может работать без них несколько секунд, загружайте их позже. Пользователям важнее увидеть страницу и нажать основную кнопку, чем мгновенно получить всплывающий чат.

Быстрый аудит часто находит простые победы. Агрессивно кэшируйте статические файлы, чтобы повторные посетители не скачивали их снова. Откладывайте неважные скрипты до момента, когда страница уже стала полезной. Загружайте дополнительный код только тогда, когда пользователь открывает нужную функцию. Держите первый экран лёгким: один семейство шрифтов, небольшой CSS и как можно меньше JavaScript. Потом проверьте сетевую панель и в первую очередь уберите самые тяжёлые элементы.

Представьте страницу регистрации с hero-изображением, двумя шрифтами, виджетом чата и полным бандлом дашборда, загружаемым сразу. Уберите изображение, оставьте один шрифт, отложите виджет и загружайте код дашборда только после входа. Страница часто начинает ощущаться гораздо быстрее — вообще без изменений в географии.

Укоротите цепочки запросов

Многие медленные страницы тормозят не из-за географии. Они тормозят из-за того, что путь к ответу слишком длинный.

Один экран загружается, запускает десяток мелких запросов, обращается к двум внутренним сервисам, ждёт оба и только потом отрисовывается. Такой сценарий быстро становится дорогим. Десять запросов по 15–25 мс каждый могут ощущаться хуже, чем один хорошо составленный запрос из более далёкого региона.

Начните с экранов, которые пользователи открывают чаще всего. Посмотрите, сколько запросов к базе запускает один запрос, сколько времени занимает каждый из них и ждёт ли страница ещё какие-то сервисы. Админские панели, страницы аккаунта и результаты поиска часто скрывают самые плохие цепочки запросов.

Паттерн N+1 по-прежнему встречается повсюду. Страница загружает список из 50 элементов, а затем ещё 50 раз запрашивает связанные данные. Пользователь видит одну страницу. Ваше приложение делает 51 поход, чтобы собрать её.

Добавляйте индексы для фильтров и сортировок, которые люди используют постоянно. Если страница всегда загружает заказы по ID аккаунта и сортирует их по дате создания, индексируйте именно этот путь. Но не добавляйте индексы вслепую. Лишние индексы замедляют запись и добавляют работу по обслуживанию.

Возвращайте меньше данных. Если странице нужны имя, статус и сумма, запрашивайте только эти поля. Не вытаскивайте полные строки, большие текстовые колонки или JSON-объекты только потому, что ORM это позволяет.

Кэшируйте чтения, которые почти не меняются. Таблица цен, набор feature flags, список стран или лимиты тарифов можно ненадолго хранить в памяти или Redis и экономить повторные обращения к базе. Кэш на 30 секунд или 5 минут часто сильно сокращает лишнюю работу, не добавляя большого риска.

Внутренние сервисные вызовы тоже могут накапливаться внутри одного запроса. Если страница оформления заказа обращается к user service, billing service, inventory service и analytics service по очереди, самый медленный шаг определяет скорость всей страницы. Во многих случаях один агрегированный запрос или небольшая read model быстрее и проще.

Небольшой пример хорошо показывает эффект. Клиентский дашборд загружается за 900 мс. Трассировка показывает 320 мс в браузере, 180 мс в базе данных и 260 мс на внутренних API-вызовах. После одного составного индекса, более короткого SELECT и одного кэшированного summary вместо трёх вызовов сервисов та же страница падает примерно до 380 мс. Второй регион не нужен.

Перенесите медленную работу из запроса

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

Самый быстрый подход прост: сохраните минимально необходимое, верните ответ, а остальное завершайте в фоне.

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

Отчёты заслуживают особого подхода. Если люди открывают один и тот же дашборд каждое утро, собирайте отчёт по расписанию, а не заставляйте каждого ждать по 8–10 секунд. Предсобранные сводки часто ощущаются мгновенными, даже когда вычисления на самом деле тяжёлые.

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

Разница легко заметна. Клиент отправляет заказ и ждёт, пока приложение создаст заказ, отправит чек, обновит CRM и сформирует счёт. Это может занять несколько секунд. Если приложение сохраняет заказ и сразу отвечает, клиент почти мгновенно видит подтверждение, а остальное завершается в фоне.

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

Тестируйте в простом порядке

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

Опишите сценарий простыми словами и зафиксируйте его. Например: пользователь нажимает «Войти», вводит данные и попадает на рабочий дашборд.

Затем снимите базовую линию там, где пользователи действительно находятся. Сеть вашего офиса не считается, если только ваши клиенты тоже не сидят там же. Если основная часть трафика приходит из Лондона, Нью-Йорка и Сингапура, тестируйте именно оттуда и записывайте и медиану, и более медленный хвост.

Хорошо работает простой порядок:

1. Выберите один медленный сценарий с чётким началом и концом.
2. Измерьте его из самых важных пользовательских локаций.
3. Меняйте только одну вещь.
4. Запустите тот же тест ещё раз.
5. Запишите выигрыш по времени и стоимость изменения.

Делайте каждое изменение небольшим. Сожмите изображения, уменьшите JavaScript, добавьте недостающий индекс или перенесите отправку письма в фоновую задачу. Не объединяйте три исправления в один релиз, если цель — понять, что сработало. Когда изменения складываются, вы теряете ответ на простой вопрос: какая именно правка дала эффект?

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

Ошибки, которые сжигают деньги

Самый быстрый способ потратить бюджет впустую — открыть второй регион до того, как вы поняли, откуда берётся задержка. Если пользователи ждут из-за JavaScript-бандла на 2 МБ, медленной доставки изображений или одного плохого запроса к базе, дополнительная география почти ничего не меняет. Вы просто платите дважды за одно и то же узкое место.

Команды также часто переусердствуют и копируют вообще всё. Один медленный экран аккаунта не означает, что вам нужен второй кластер базы, ещё одна очередь, дублирование поиска и полноценная схема failover. Такой шаг добавляет облачные расходы, операционную работу и ещё больше вещей, которые могут сломаться. Сначала чините узкий путь.

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

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

Средние значения скрывают такие ошибки. Приложение может показывать приличные 400 мс в среднем, хотя самые медленные 5% запросов всё ещё длятся 4 секунды. Именно такие запросы люди запоминают. Они же создают обращения в поддержку и брошенные корзины.

Быстрый обзор находит большую часть таких проблем. Смотрите не только на среднее, но и на p95 и p99. Разделяйте время между ассетами, кодом приложения, базой данных и сторонними вызовами. Сравнивайте поведение с прогретым кэшем и с холодным. Проверяйте, не выполняют ли пути запросов по-прежнему пакетную работу. Тестируйте самый медленный экран, а не только главную страницу.

Большая часть этой работы скучная. И это нормально. Уменьшайте размер ассетов, укорачивайте цепочки запросов и переносите не срочную работу в асинхронные задачи. Если после этого второй регион всё ещё имеет смысл, вы будете точно понимать, зачем он нужен.

Простой пример

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

Первой проблемой был бандл дашборда. Каждый визит загружал большую библиотеку графиков, хотя пользователю часто нужна была только простая сводная карточка, а до вкладки с графиком он вообще не доходил. В быстром офисном интернете это раздражало. На Wi‑Fi в отеле или на мобильном интернете это ощущалось как поломка.

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

Потом был checkout. После оплаты приложение формировало и отправляло письмо со счётом ещё до показа экрана успеха. Пользователи сидели и ждали ещё секунду-другую, думая, не провалилась ли оплата.

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

Ничего из этого не меняло географию. Это просто убрало лишнее время из пути запроса.

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

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

Именно к такой уборке Oleg Sotnikov часто подталкивает команды до того, как они начнут тратить больше на инфраструктуру. Это дешевле, быстрее проверяется и часто само по себе уже достаточно.

Короткая проверка перед расширением

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

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

Перед тем как добавлять новую инфраструктуру, проверьте несколько простых вещей:

• Пересмотрите самые тяжёлые изображения, шрифты, видео и скрипты. Телефон не должен скачивать desktop hero image.
• Пересмотрите медленные запросы к базе. Нагруженные запросы должны использовать индексы, затрагивать меньше строк и возвращать меньшие наборы данных.
• Посмотрите на путь запроса: нет ли там работы, которая пользователю не нужна сразу. Отправка писем, генерация отчётов, рассылка вебхуков и большие audit writes обычно должны жить в фоновых задачах.
• Сравните время первого и повторного визита. Если повторные визиты почти не ускоряются, с кэшированием браузера ещё нужно поработать.
• После этих исправлений посмотрите, где именно находятся медленные пользователи по регионам. Если жалобы теперь сосредоточены в одной далёкой географии, второй регион начинает иметь смысл.

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

Асинхронная работа — ещё одна частая утечка. Если запрос ждёт обработки изображений, генерации документа или вызова стороннего API, пользователь ощущает эту паузу напрямую. Перенесите такую работу в очередь, верните страницу и обновите статус позже.

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

Что делать дальше

Выберите два или три пользовательских сценария, которые приносят деньги. Поставьте цель для каждого ещё до любых изменений. Формулируйте конкретно: вход в аккаунт — меньше 500 мс на p95, загрузка дашборда — меньше 1,2 с, отправка checkout — меньше 700 мс. Размытые цели рождают размытые действия.

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

Хороший следующий проход выглядит просто. Измеряйте реальные пользовательские сценарии, а не только тесты главной страницы. Сравнивайте время на ассеты, код приложения, базу данных и сторонние сервисы. Убирайте медленную работу с пути запроса там, где это возможно. После каждого изменения повторяйте те же тесты из тех же городов. Добавляйте второй регион только если расстояние по-прежнему остаётся главным источником задержки.

Запишите одно правило для расширения: «Мы открываем второй регион только если пользователи в целевых городах всё ещё не укладываются в цель по задержке после исправления приложения и базы данных». Эта одна фраза может сэкономить много денег.

Если вам нужен внешний взгляд, Oleg Sotnikov на oleg.is работает со стартапами и небольшими командами как Fractional CTO по архитектуре, инфраструктуре и практической AI-assisted разработке. Такой разбор особенно полезен после того, как вы измерили задержки и хотите понять, что исправлять первым.

Следующий шаг должен быть легко обоснован: поставьте цель, протестируйте из реальных локаций пользователей, исправьте медленный путь и расширяйтесь только тогда, когда расстояние всё ещё видно в цифрах.