Сайт повільний і губить заявки: що перевірити до редизайну

Хтось уже чекає на вашому сайті. Форма висить недописана. Пошук крутиться. Менеджер запускає вивантаження і йде в інше вікно. Того ж місяця заявок меншає, а в пошті лежить пропозиція: нова верстка, нові сторінки, можливо нова платформа. Гроші в цій пропозиції йдуть на те, що видно оком. Гальмо майже завжди одне: запит до бази, занадто велика відповідь або колонка без індексу. Заявка губиться не через старий шрифт. Вона губиться, коли крок, який її створює, так і не добігає кінця.

Спершу назвіть екран і засічіть, скільки триває дія. Лише тоді вирішуйте, чи міняти сторінку. Повільна сторінка і тиха скринька заявок можуть збігтися в часі. З цього ще не випливає, що одне спричинило інше. Цифри нижче — про одну операцію на одному продукті. Для вашого сайту це не прогноз.

1. Назвіть те, на чому люди вже чекають

На нараді це вміщується в одне речення: сайт повільний, заявки губимо. З таким реченням нічого вдіяти. Не можна полагодити очікування, якого ніхто не назвав. І не можна списати заявки на сторінку, яку ніхто не засікав.

«Повільно» — спільне відчуття. Воно не вказує ні на екран, ні на вивантаження, ні на задачу. Головна може відкриватися нормально, а висітиме сторінка, з якої заявка якраз і з’являється: пошук, бронь, оплата, список, який менеджер оновлює цілий день. Редизайн тоді освіжає сторінку, яку люди й так терплять, і не чіпає крок, на якому вони йдуть.

До макетів запишіть ось це:

• Точний екран і хто чекає: відвідувач, менеджер чи партнер.
• Один замір до будь-яких правок. День, яка дія, скільки секунд.
• Два окремі рядки: «ця сторінка гальмує» і «хочемо новий вигляд». Обидва можуть бути правдою. Задачі різні.
• Крок, на якому заявка реально з’являється: відправка форми, дзвінок, бронь. Засікайте його, а не сторінку зверху.
• Коли заявок стало менше: до гальм, після, чи цього ніхто не знає. Відсоток не вигадуйте.

Нотатка має бути вузькою. На одній навчальній платформі фраза «платформа повільна» нічого не пояснювала. Цикл запитів до бази замінили одним агрегувальним запитом. Ця операція скоротилася з 12,41 до 2,451 секунди, пам’ять упала на 1,5 ГБ. Інша критична операція — з 23 937 мс до 48 мс. Одна відповідь API — з 912 КБ до 2,1 КБ. Середнє навантаження CPU за тиждень знизилося з 82,2% до 2,75%, коли розібрали вузькі місця, зокрема пошук без індексів. Кожна цифра про свою операцію. Жодна не означає, що весь продукт став швидшим у скількись разів. Ваша нотатка виглядає так само: цей екран, ця дія, стільки секунд. Розмова про новий вигляд — після.

2. Зазвичай гальмує одна операція

Нова тема оформлення не прибирає запит, який біжить по разу на кожен рядок. Новий логотип не додає індекс, якого бракує пошуку. Люди бачать, як сторінка з’являється на екрані, і записують проєкт як дизайн. Секунди часто минають раніше, на сервері, ще до того як браузер щось показав.

Час сидить у знайомих місцях. Запит усередині циклу. Колонка пошуку без індексу. Відповідь, яка віддає весь запис, хоча на екрані потрібні кілька полів. На тій самій навчальній платформі скорочення з 912 КБ до 2,1 КБ стосувалося однієї відповіді API. Решта екрану була не потрібна. Новий дизайн цього екрана віддав би той самий обсяг, якби ніхто не запитав, що лежить у відповіді.

Буває й інакше. Звіт, вивантаження або виклик чужого сервісу тримають вкладку, доки робота не скінчиться. Відвести це у фон — не те саме, що перемалювати сторінку. Окремий процес на Node тут не перше питання. Спершу назвіть операцію. Де проходить межа, розібрано в нотатці коли черга на Node стоїть поруч із Laravel.

Перш ніж погодитися з причиною, запитайте:

• Повільний крок — це запит, важка відповідь чи очікування зовнішнього сервісу? Повільний лог або людина, яка веде сервер, зазвичай може почати відповідь.
• Якщо ту саму таблицю читають по разу на рядок екрана, запишіть однією фразою: «запит у циклі».
• Якщо гальмує пошук, запитайте, чи є індекс на цій колонці. Без індексу пошук часто й здається зламаним.
• Якщо відповідь велика, порівняйте її розмір із тим, що реально видно на екрані.

На іншому продукті прибрали зависання екрана, і критичний процес скоротився приблизно з години до шести хвилин. Це результат того процесу. До кошторису на редизайн його не докладають. Кожне число тримайте біля операції, яка його дала.

3. Що перевірити, перш ніж замовляти редизайн

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

Сайт, який виглядає застарілим, іноді якраз і приймає замовлення. Спершу варто побачити, що реально працює, і стабілізувати це. «Старий, отже, міняємо продукт» можна обговорити потім.

Перед підписом пройдіться списком:

• Заміряйте крок заявки і один внутрішній крок, на який уже скаржаться. Вивантаження або звіт. Обидва числа збережіть.
• Запишіть фреймворк, мову і базу. Ви перевіряєте, чи поточну систему ще можна лагодити, а не обираєте новий стек.
• З’ясуйте, чи є окреме середовище. Якщо правку можна пробувати лише на живому сайті, редизайн і прискорення стають одним ризикованим релізом.
• Підтвердьте, що резервну копію хоча б раз відновлювали. Або відновіть її самі в цьому окремому середовищі.
• Якщо сайт передав інший розробник, до дизайн-роботи підтвердьте доступ до репозиторію, яка гілка викатана і чи є письмова інструкція. Цей прохід — чек-лист приймання Laravel.

Не оновлюйте всі пакети лише тому, що вийшла новіша версія. І не копіюйте чужий стек із портфоліо, бо він виглядає солідно. Запитайте, чи ця операція може стати швидшою без нового продукту.

4. Чого редизайн не лагодить

Новий фронтенд на тій самій повільній операції все одно чекатиме. Після запуску крок заявки триває стільки ж, і проєкт називають провалом дизайну. Дизайн зробив те, про що просили. Операцію змінювати його не просили.

В обсязі дизайну — сторінки, шрифт і компоненти. Повільний шлях — доступ до даних. Якщо пошук клієнта з’єднує великі таблиці без індексу, нове поле пошуку йде тим самим шляхом. Якщо вивантаження збирає файл усередині запиту, нова кнопка чекає так само. У тих, хто затвердив картинки, у брифі не було рядка: цей пошук повертається за час, який ми заміряли, або швидше.

Зафіксуйте обмеження письмово:

• Заміряні операції кладіть у бриф редизайну разом із секундами.
• Старі числа збережіть. Чесне порівняння — той самий екран, той самий тип даних, до і після.
• Якщо редизайн заодно змінює базу або хостинг, це другий проєкт зі своєю перевіркою.
• Якщо клієнти живуть в одному застосунку, запишіть, як дані одного акаунта відділені від іншого, до того як нові сторінки покажуть їх більше.

Швидка сторінка з чужими записами — не покращення. На одному продукті з кількома філіями в кожної філії була своя база, а міграції та індекси будували навколо цього розділення. У вас може бути інакше. Перш ніж редизайн покаже більше тих самих даних, запишіть, чи може один акаунт прочитати записи іншого.

5. Із нотаток виходить короткий план

Документ, який закінчується фразою «розглянути редизайн» і нікого не називає, планом не є. Розкладіть нотатки. Одразу: крок заявки, якщо він падає або впирається в таймаут, і відновлення з копії, якого ви ще не перевірили. Далі: операція, яку заміряли, і гіпотеза — цикл, індекс, розмір відповіді або робота, якій місце в черзі. Потім: візуальна правка, яку все ще варто робити, коли очікування вже зрозуміле.

У списку має бути відповідальний:

• У кожного рядка є людина і перевірка, за якою видно, що справу зроблено: повторний замір, відновлена копія, пошук за індексом.
• Домовтеся, яка візуальна робота може почекати, доки ці перевірки є.
• Редизайн не починається, доки в кроку заявки немає числа і гіпотези, чому так.

На успадкованих робочих системах робота йшла в іншому порядку: спершу архітектура і швидкість, потім нові функції. Вирішували, що привести до ладу. Редизайн може бути наступним проєктом. Першим він слабкий, коли доказ один: сайт здається повільним, а заявок ніби мало.

Коли звати спеціаліста

Замір зробіть самі. Щоб записати екран, дію і секунди, розробник не потрібен. Кличте людину, коли повільне місце в базі або в черзі і в команді його ніхто не читає, коли сайт дістався у спадок і репозиторій чи хостинг досі не ваші, або коли кошторис на редизайн уже в пошті, а в брифі немає операції, яку ви заміряли.

Таку діагностику я беру, і розробку після неї теж, на тій системі, яка у вас уже є. Послуги — швидкодія, SaaS і backend, та інтеграції з AI. Проєкти — ті самі ситуації: операція зі своїм заміром і результат біля неї. Якщо хочете другий погляд на екран, який ви засікли, напишіть мені в LinkedIn. Надішліть адресу, дію і секунди.