Для пользователя техническая сторона продукта остается за кадром. Но именно от нее зависит, насколько быстро открывается страница и насколько предсказуемо работает интерфейс. Это напрямую сказывается на поведении пользователей. Согласно исследованию Google и SOASTA, если время загрузки мобильной страницы увеличивается с одной до трех секунд, вероятность того, что пользователь покинет страницу, возрастает на 32%.
Но скорость загрузки - лишь один из показателей, по которым стоит оценивать технические решения. Как решения фронтенд-разработки отражаются на бизнес-результатах? Какие привычные подходы приходится пересматривать и как понять, что изменения действительно пошли продукту на пользу?
Об этом рассказал Владислав Теличко, Lead Frontend Developer с более чем 10-летним опытом в веб-разработке. Почему бизнес видит последствия проблем с производительностью, но не всегда участвует в работе над ними? Производительность часто воспринимают как техническую задачу.
Разработчики смотрят на время загрузки и другие показатели, бизнес - на конверсию, удержание и результаты экспериментов. Когда эти показатели обсуждаются отдельно, работа над производительностью остается в рамках разработки. В то же время технические решения влияют на продукт гораздо шире.
Если архитектура мешает быстро запускать A/B-тесты или новые сценарии, команде требуется больше времени, чтобы проверять гипотезы о продукте. Если интерфейс долго реагирует на действия пользователя, тот может уйти еще до целевого действия. Поэтому производительность следует связывать с конкретными задачами продукта.
Тогда становится понятнее, как работа разработчиков сказывается на результате. Пользователь видит интерфейс и результат своего действия. Разработчик видит, сколько технических ограничений стоит за этим результатом. Например, две функции могут казаться одинаково простыми.
Но одну команда собирает из готовых механизмов, а другую каждый раз создает заново. Со временем на доработку уходит больше времени, а новые задачи запускаются медленнее. Во время работы с Breeze я столкнулся с ситуацией, когда задачи на фронтенде реализовывались отдельно друг от друга.
Мы пересмотрели архитектуру и начали создавать внутреннюю платформу с общими механизмами для повторного использования. Для пользователя интерфейс практически не изменился. У команды стало меньше повторяющейся работы, а новые задачи перестали каждый раз требовать отдельной реализации.
ЧИТАЙТЕ ТАКЖЕ: Microsoft прекращает поддержку распространенных версий Windows Как понять, подходит ли архитектурное решение конкретному продукту? У продуктов разные сценарии, аудитория и технические ограничения. Поэтому архитектурное решение нельзя оценивать отдельно от контекста, в котором оно работает.
Представим себе два продукта. В одном интерфейс меняется редко, в другом команда постоянно тестирует новые варианты. То, что удобно для одного, не обязательно подойдет другому: при редких изменениях сложные общие механизмы могут оказаться лишними, а при частых - помогают не делать одну и ту же работу заново.
То же самое касается устройств. Решение, которое незаметно на мощном компьютере, на слабом смартфоне может вызвать заметную задержку. В Welltech я работал с фронтендом в продуктах, где проводилось много A/B-тестов. В такой среде особенно важно учитывать, насколько легко изменять интерфейс и поддерживать различные варианты сценариев.
Поэтому готовое решение не всегда подходит конкретному продукту. Сначала нужно понять, как устроен продукт и как им пользуются, а уже потом выбирать архитектуру. Почему опыт иногда мешает инженеру взглянуть на проблему по-новому? Опыт помогает быстро распознавать типичные ситуации.
Но иногда новая проблема слишком быстро попадает в знакомую категорию, и инженер начинает исправлять предполагаемую причину вместо реальной. Если страница работает медленно, легко сразу искать причину в коде или отдельных элементах. Но проблема может быть совсем в другом месте.
Я стараюсь сначала восстановить путь пользователя: что он пытается сделать, где возникает задержка и какое действие должно произойти дальше. После этого выбираю технический подход. В вопросах производительности это особенно важно. Отдельный показатель может улучшиться, а нужный элемент все равно будет появляться с задержкой.
Что стоит проверить, прежде чем искать новый инструмент для оптимизации? Сначала нужно понять, где возникает проблема и что ее вызывает. Новый инструмент может ускорить отдельную операцию, но не исправит архитектурное ограничение или лишнюю работу внутри системы.
Перед оптимизацией я смотрю на сам процесс: какие действия повторяются, где команда тратит время и что мешает выполнить задачу быстрее. Если причина в архитектуре, я ее меняю. Если проблема связана с ручными операциями, я ищу, что имеет смысл автоматизировать.
Такой подход помогает решать проблему на том уровне, где она действительно возникает, а не ускорять отдельный этап ради самого ускорения. Как понять, что повышение производительности действительно помогло пользователю? Отдельная метрика не всегда показывает, что произошло с пользовательским сценарием.
Страница может загружаться быстрее, а нужный элемент все равно появляться с задержкой. Или интерфейс может быстрее открываться, но медленно реагировать на действие. Поэтому после изменений я проверяю сам сценарий: где пользователь ждет, что происходит в этот момент и насколько быстро он может перейти к следующему действию.
Так становится видно, повлияло ли обновление на реальный опыт, а не только на показатель. Какие показатели стоит учитывать при оценке производительности? Одной цифры здесь недостаточно. Важны скорость прохождения ключевых этапов, влияние технических изменений на запуск экспериментов и то, насколько легко после них продолжать развивать продукт.
Бывает и другая ситуация: интерфейс работает быстрее, но новые функции после изменения приходится внедрять дольше. Для пользователя это улучшение, а для команды - новый источник ограничений. Поэтому для меня продуктивность связана не только со скоростью. Нужно учитывать, как решение работает в реальном продукте и что оно меняет для пользователя и команды в дальнейшем.