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