Аудит времени запуска приложения: найдите задержки, которые ощущают пользователи

Как ощущается медленный запуск приложения

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

Этот разрыв важнее, чем думают многие команды. Пользователи не считают миллисекунды. Они замечают неопределённость. Если первое, что они видят, — пустота, многие решают, что приложение зависло, интернет не работает или в последнем обновлении есть баги.

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

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

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

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

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

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

Что измерять до изменений в коде

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

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

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

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

Ведите короткую запись для каждого тестового запуска:

• модель или тип устройства
• версия ОС
• качество сети, например Wi‑Fi, хороший 5G или слабый 4G
• время до первого видимого экрана
• время до того, как первый экран начинает принимать ввод

Этот контекст важнее, чем кажется. Запуск, который отлично выглядит на новом телефоне в офисном Wi‑Fi, может казаться очень медленным на старом Android-устройстве на вокзале. Если не записать условия, числа будут выглядеть случайными.

Ещё один момент: отделяйте факты от догадок. Не пишите «примерно 2 или 3 запроса» или «аналитика должна быть дешёвой». Откройте логи, посчитайте запросы и запишите их. Чёткие цифры делают разговоры о производительности запуска намного короче и спокойнее.

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

Разделите задержку на понятные группы

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

На первом проходе используйте три простые группы:

• Ожидание сети: запросы конфигурации, данных профиля, флагов функций, удалённых изображений или всего остального, что приложение запрашивает до того, как почувствует себя готовым.
• Тяжёлая настройка экрана: создание представлений, расчёт расположения, большие списки, чтение локальной базы, загрузка шрифтов и код, который слишком рано строит слишком много интерфейса.
• Аналитика и трекеры: вызовы старта сессии, SDK атрибуции, очереди событий, проверки согласия и дополнительные хуки запуска от маркетинговых инструментов.

Такое разделение работает, потому что каждая группа указывает на свой тип исправления. Медленный API-запрос требует одной работы, а экран, который строит пять вкладок до первого нажатия, — совсем другой. Код трекеров тоже отдельная проблема. В ревью он часто выглядит маленьким, но несколько небольших вызовов на старте могут дать заметную пользователю задержку.

Простой пример делает это понятнее. Допустим, приложение показывает пустой splash на 2,8 секунды. Первые 1,1 секунды уходят на запрос профиля и получение удалённой конфигурации. Ещё 1,2 секунды — на построение дашборда с графиками, аватарами и длинной лентой активности. Последние 0,5 секунды съедают запуск SDK аналитики и настройка событий. Теперь команда может обсуждать факты, а не догадки.

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

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

Как провести простой аудит запуска

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

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

Каждый раз записывайте одни и те же отметки:

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

Экран, который появляется за 700 мс, но потом ещё две секунды остаётся замороженным, всё равно медленный. Пользователям не важно, что пиксели появились раньше, если нажать всё равно нельзя.

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

После этого убирайте по одному стартовому вызову и тестируйте снова. Не выдёргивайте сразу пять вещей. Отключите получение удалённой конфигурации, потом обновление авторизации, потом флаги функций, потом запрос главной ленты. Сравнивайте временную линию после каждого изменения. Одна команда может обнаружить, что первый экран в порядке, а блокирующий запрос профиля добавляет 1,4 секунды. Другая — что сеть почти ни при чём, а тяжёлая сборка интерфейса съедает то же время при каждом запуске.

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

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

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

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

Аудит разложил задержку на части и нашёл два ожидания до того, как главный экран мог показать полезные данные:

• Приложение делало паузу из-за запроса обновления авторизации.
• После этого запускался запрос главной ленты.
• Параллельно во время запуска срабатывали десять событий аналитики.

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

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

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

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

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

Ошибки, которые тратят время впустую

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

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

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

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

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

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

• холодный старт на старых телефонах
• первый запуск после установки
• случаи со слабой сетью
• p95 и p99 времени запуска

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

Быстрые проверки перед оптимизацией

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

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

Потом проверьте, какие запросы действительно нужны до появления первого экрана.

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

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

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

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

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

Когда проблема больше, чем код запуска

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

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

Сторонние инструменты делают ситуацию хуже, потому что добавляют работу на запуск, которую вы не писали сами. Аналитика, атрибуция, баннеры согласия, чат, A/B‑тесты и инструменты сбоя могут инициализироваться во время старта. Если один SDK блокирует главный поток на 300 мс, это может перечеркнуть дни аккуратной настройки интерфейса. Рассматривайте каждый из них как отдельную стоимость, а не как фоновый шум.

Короткий аудит времени запуска приложения должен ответить на несколько простых вопросов:

• Что должно загрузиться до того, как пользователь сможет действовать?
• Что можно отложить до появления первого экрана?
• Какие SDK запускаются во время старта?
• Какие запросы нужны для отчётности, а не для пользы пользователю?
• Не пытается ли первый экран делать слишком много?

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

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

Что делать дальше вашей команде

Хороший аудит полезен только тогда, когда команда превращает его в короткий план. Начинайте с боли пользователя, а не с инженерного любопытства. Если одно исправление экономит 1,5 секунды до появления первого экрана, оно важнее аккуратной уборки, которая убирает 50 миллисекунд из кода, которого никто не чувствует.

Записывайте каждую находку простым языком. «Приложение ждёт три API-запроса, прежде чем что-то показать» лучше, чем «оптимизировать поток запуска». Затем ранжируйте список сначала по влиянию на пользователя. Инженерные усилия используйте только как второй критерий. Задержки, которые бьют по холодным запускам на старых телефонах, обычно должны идти наверх. Работа по аналитике, которая засоряет трассировку, но не блокирует интерфейс, может подождать.

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

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

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

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

Иногда аудит показывает более серьёзную проблему: работа на старте переплетена с решениями по продукту, архитектурой приложения или запутанным процессом поставки. Если команде нужна внешняя помощь, Oleg Sotnikov предлагает поддержку в формате Fractional CTO для архитектуры приложения, обзоров производительности и практичных планов реализации. Такая помощь особенно полезна, когда все видят задержку, но никто не отвечает за порядок исправлений.