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