Ускорять один API бессмысленно, если пользователь ждёт другой участок цепочки. End-to-end latency начинается в момент появления нового состояния у источника и заканчивается только тогда, когда клиент его обработал и отрисовал. Поэтому измерение нужно раскладывать по границам, а не сводить к серверному response time.

Timestamp на каждой смене ответственности

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

Статические данные и live state нельзя кэшировать одинаково

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

Хвост распределения важнее красивого среднего

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

Клиент способен быть главным bottleneck

Большой список live-рынков может тратить больше времени на перерасчёт и перерисовку, чем сеть на доставку обновления. Виртуализация, дифф-обновления и сокращение лишних layout-проходов нужно проверять теми же timestamp, что и backend, иначе команда оптимизирует «удобный» участок вместо медленного.

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

Разложение задержки даёт больше, чем среднее число

End-to-end latency складывается из нескольких независимых участков: источник, backend, сеть, сериализация, устройство и рендер. Среднее значение скрывает хвосты распределения и не показывает, где задержка появляется именно в live-пике. Полезнее измерять p50/p95/p99 отдельно для ключевых шагов.

Контрольные вопросы

  • ставить timestamp на границах каждого сервиса
  • отделять сетевую задержку от времени рендера на устройстве
  • проверять холодный запуск и возврат приложения из фона
  • сравнивать поведение на медленной сети и слабом устройстве

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

Client timestamps требуют осторожности

В end-to-end измерении легко вычесть два времени с разных часов и получить красивую, но неверную latency. На клиенте полезно сочетать monotonic duration для локальных этапов с серверными timestamps и явно понимать, где есть clock skew. Для RUM также важна сегментация по версии приложения, типу сети и классу устройства: деградация main-thread на старых телефонах не должна растворяться в среднем по быстрым устройствам. Без этих разрезов backend-команда будет искать bottleneck не там.

Путь нужно измерять по меткам времени, а не по ощущениям интерфейса

Мобильный пользователь воспринимает задержку целиком: нажатие, сетевой путь, backend, доставку ответа, обработку JavaScript/native слоя и финальную отрисовку. Серверный p95 покрывает только одну часть. Поэтому для критичных сценариев полезно иметь несколько согласованных timestamps и понимать, где они снимаются. Это позволяет отличить медленный API от задержанного push, тяжёлого render или повторной синхронизации после возврата приложения из background.

Серверные метрики стоит сверять с synthetic-проверкой live-центра, которая проходит внешний путь. Если внутренний trace заканчивается быстро, а synthetic видит старую версию ещё несколько секунд, поиск смещается к CDN, cache invalidation, клиентскому polling/reconnect или фронтенд-обработке. Такая связка особенно полезна при географически распределённом трафике, где среднее значение скрывает локальную проблему.

Оптимизация должна начинаться с самого дорогого участка, а не с привычного слоя. Иногда уменьшение backend latency на десятки миллисекунд почти незаметно, пока клиент выполняет тяжёлую переработку большого payload. Реальный выигрыш появляется после измерения всей цепочки и проверки результата на устройстве, а не только в лабораторной сети.

Измерения на реальных устройствах стоит сегментировать хотя бы по версии клиента и типу сети. Один неудачный release может ухудшить render path только на части устройств, и общий p95 сгладит эффект. При этом слишком детальная телеметрия быстро создаёт высокую cardinality, поэтому набор измерений выбирают под конкретные гипотезы. Цель — объяснить задержку и подтвердить улучшение после изменения, а не собрать максимально возможное число меток.

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