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