Чому ваш застосунок на ШІ відчувається повільним (і що з цим робити)

Ваш застосунок на ШІ працює. Кнопки ведуть, куди мають, екрани вишикувані, дані зберігаються. Але щось відчувається не так. Сторінки завантажуються на мить довше. Список із п’ятдесяти елементів зависає на секунду. Клік «зберегти» змушує вас чекати, потім чекати ще трохи, потім гадати, чи варто клікнути знову. Нічого не зламано — воно просто відчувається повільним.

Якщо ви нетехнічний засновник, що випускає за допомогою конструктора застосунків на ШІ, це один із найпоширеніших моментів «я не знаю, що не так». Хороша новина в тому, що 80% повільних застосунків на ШІ повільні з тієї самої жменьки причин. Жодна з них не вимагає, щоб ви вивчали, як працюють бази даних. У всіх них є виправлення, які можна попросити свій конструктор на ШІ зробити простою мовою.

Цей допис — шпаргалка.

Чому «повільно» зазвичай чотири речі

Коли користувачі кажуть, що застосунок відчувається повільним, вони майже ніколи не мають на увазі «сервер слабкий». Вони мають на увазі одне з чотирьох:

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

Ось і все. Майже кожен повільний застосунок на ШІ, на який я дивився, повільний з однієї з цих чотирьох причин. Ось як помітити кожну й що попросити свій конструктор з нею зробити.

Повільна причина №1: перше відмалювання

Як це виглядає: ви клікаєте посилання на свій застосунок, рядок URL завершує завантаження, але сторінка біла секунду-дві, перш ніж щось з’явиться.

Що зазвичай це спричиняє: застосунок завантажує кожен шматок JavaScript, який йому може знадобитися, перш ніж щось показати. Конструктори застосунків на ШІ схильні пакувати щедро — краще щось включити, ніж пропустити — і цей пакет більшає, що більше функцій ви додаєте.

Що попросити свій конструктор на ШІ: «Перше завантаження сторінки відчувається повільним. Можеш розділити пакети JavaScript за маршрутами, щоб головній сторінці не треба було завантажувати весь адмінський розділ?» Чи простіше: «Додай ліниве завантаження для маршрутів, що не є головною сторінкою». Більшість сучасних фреймворків підтримує це в одному-двох рядках конфігурації. ШІ знає як — вам просто треба попросити.

Поки ви цим займаєтеся: «Чи є на лендінгу великі зображення, які ми могли б оптимізувати?» Героїчне фото на 4 МБ просадить сприйману швидкість більше за будь-яку проблему коду.

Повільна причина №2: довгий список

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

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

Що попросити свій конструктор на ШІ: «Список проєктів повільний, коли елементів багато. Чи можемо ми додати пагінацію чи віртуалізувати список, щоб відмальовувалися лише видимі рядки?» Пагінація («показуй 20 на сторінку, з кнопками вперед/назад») — найлегше виправлення. Віртуалізація («відмальовуй лише те, що на екрані, поки користувач прокручує») відчувається плавніше, але трохи більше роботи. Будь-яке підходить.

Якщо в списку також є пошук чи фільтрування: «Чи може фільтр пошуку відбуватися на сервері замість браузера?» Фільтрування на боці сервера означає, що браузер завжди тримає лише відповідні рядки, а не весь набір даних.

Повільна причина №3: тихе очікування

Як це виглядає: ви клікаєте «зберегти», чи «надіслати», чи «згенерувати». Нічого видимо не стається. За дві секунди екран оновлюється, і ви розумієте, що воно працювало весь час.

Що зазвичай це спричиняє: застосунок робить справжню роботу — зберігає в базу даних, викликає API — але конструктор на ШІ не додав стану завантаження. Тож з вашого погляду клік нічого не зробив.

Це насправді не проблема продуктивності. Це проблема сприйманої продуктивності, а вони часто болісніші за справжні. Дія на 200 мілісекунд без зворотного зв’язку відчувається повільнішою за дію на 2 секунди зі спінером, бо мозок користувача в темряві.

Що попросити свій конструктор на ШІ: «Додай стан завантаження до кожної кнопки, що запускає дію. Показуй спінер чи текст “Збереження…”, поки воно працює, і вимикай кнопку, щоб користувачі не могли клікнути двічі». Це єдине виправлення продуктивності з найвищою віддачею в будь-якому застосунку, і воно коштує майже нічого.

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

Повільна причина №4: балакуча база даних

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

Що зазвичай це спричиняє: сторінка завантажує проєкти одним запитом, потім завантажує кількість завдань для кожного проєкту окремим запитом. Десять проєктів? Одинадцять запитів. Сотня проєктів? Сто один. Це називається «запит N+1», і це найпоширеніший баг продуктивності бази даних у застосунках на ШІ, бо ШІ оптимізує під код, що читається чітко, а не код, що працює ефективно.

Що попросити свій конструктор на ШІ: «Ця сторінка робить один запит на елемент. Чи можемо ми підтягнути всі пов’язані дані одним запитом — джойном чи агрегацією?» Вам не треба знати, що означає будь-яке з цих слів. ШІ знає. Показати йому повільну сторінку й сказати «думаю, тут проблема N+1» зазвичай достатньо.

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

Слово про передчасну оптимізацію

Пастка, у яку падають нові будівники: намагатися зробити кожну сторінку швидкою, перш ніж хтось користується застосунком. Не треба.

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

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

Як говорити зі своїм конструктором на ШІ про швидкість

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

Хороші промпти для копіювання:

«Коли я відкриваю сторінку налаштувань, є секундна затримка, перш ніж щось з’явиться. Чи можемо ми з’ясувати, що блокує перше відмалювання?»
«Дашборд завантажується довше за головну сторінку, хоча показує менше даних. Чи можемо ми подивитися, як він підтягує свої дані?»
«Коли я клікаю “зберегти зміни” на сторінці профілю, нічого не стається дві секунди. Додай стан завантаження й переконайся, що кнопку не можна клікнути двічі».
«Протестуй цей список із 500 фейковими елементами й скажи мені, де уповільнення».

Останній недооцінений. Попросити ШІ згенерувати тестові дані й самому спробувати сторінку — одна з найкорисніших речей, які ви можете зробити. Він часто знайде повільні місця раніше за ваших користувачів — і запропонує виправлення в тій самій відповіді.

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