Почему ваше приложение на ИИ кажется медленным (и что с этим делать)

Понятное объяснение четырёх причин, по которым приложения, созданные с ИИ, ощущаются вялыми — изображения, списки, экраны ожидания и база данных — и решение для каждой, о котором можно попросить ваш ИИ-конструктор.

Ваше приложение, созданное с ИИ, работает. Кнопки ведут куда надо, экраны выровнены, данные сохраняются. Но что-то ощущается не так. Страницы грузятся на мгновение дольше, чем хотелось бы. Список из пятидесяти элементов на секунду подвисает. Нажатие «сохранить» заставляет вас ждать, потом ждать ещё немного, потом гадать, не нажать ли ещё раз. Ничего не сломано — просто кажется медленным.

Если вы нетехнический основатель и выпускаете продукт с помощью ИИ-конструктора приложений, это один из самых частых моментов «я не знаю, что не так». Хорошая новость в том, что 80% медленных приложений на ИИ медленные по одной и той же горстке причин. Ни одна из них не требует от вас разбираться, как работают базы данных. У каждой из них есть решение, о котором можно попросить ваш ИИ-конструктор обычными словами.

Этот пост — шпаргалка.

Почему «медленно» — это обычно четыре вещи

Когда пользователи говорят, что приложение кажется медленным, они почти никогда не имеют в виду «сервер слабоват». Они имеют в виду одно из четырёх:

  1. Медленная первая отрисовка — они кликают по ссылке и пару секунд смотрят на белый экран, прежде чем что-либо появится.
  2. Длинный список тормозит — прокрутка, фильтрация или загрузка «всех моих проектов» занимают дольше, чем прокрутка Instagram.
  3. Действие длится слишком долго, не сообщая, что происходит — они нажимают «сохранить» или «отправить», и ничего видимо не реагирует.
  4. Базе данных задают слишком много вопросов — страницы, показывающие данные из нескольких мест, тянут каждый кусок по отдельности и складывают время ожидания.

Вот и всё. Почти каждое медленное приложение на ИИ, что я видел, медленное по одной из этих четырёх причин. Вот как распознать каждую и о чём попросить ваш конструктор.

Причина медлительности №1: первая отрисовка

Как это выглядит: вы кликаете по ссылке на ваше приложение, адресная строка дозагружается, но страница белая секунду-другую, прежде чем что-либо появится.

Что обычно вызывает: приложение загружает каждый кусок JavaScript, который ему может понадобиться, прежде чем хоть что-то вам показать. ИИ-конструкторы приложений склонны собирать с запасом — лучше что-то включить, чем упустить, — и этот бандл становится тем больше, чем больше функций вы добавляете.

О чём попросить ваш ИИ-конструктор: «Первая загрузка страницы кажется медленной. Можешь разбить JavaScript-бандлы по маршрутам, чтобы главной странице не приходилось скачивать весь админский раздел?» Или, проще: «Добавь ленивую загрузку для маршрутов, которые не главная страница». Большинство современных фреймворков поддерживают это в одну-две строки конфига. ИИ знает как — вам просто надо попросить.

Заодно: «Есть ли на лендинге большие изображения, которые мы могли бы оптимизировать?» Фото на главном экране весом в 4 МБ просадит ощущаемую скорость сильнее любой проблемы в коде.

Причина медлительности №2: длинный список

Как это выглядит: у вас есть список — проекты, контакты, посты, что угодно — и как только в нём становится больше сорока-пятидесяти элементов, прокрутка дёргается или фильтрация занимает заметную паузу.

Что обычно вызывает: приложение отрисовывает на странице каждый элемент сразу, даже те, что вы не видите. С десятью элементами это нормально. С пятьюстами браузер захлёбывается.

О чём попросить ваш ИИ-конструктор: «Список проектов тормозит, когда элементов много. Можем добавить пагинацию или виртуализировать список, чтобы отрисовывались только видимые строки?» Пагинация («показывать по 20 на страницу, с кнопками вперёд/назад») — самое лёгкое решение. Виртуализация («отрисовывать только то, что на экране, по мере прокрутки пользователем») ощущается плавнее, но чуть больше работы. Подойдёт любой вариант.

Если у списка ещё есть поиск или фильтрация: «Может ли фильтр поиска работать на сервере, а не в браузере?» Фильтрация на стороне сервера означает, что браузер в любой момент держит только совпавшие строки, а не весь набор данных.

Причина медлительности №3: тихое ожидание

Как это выглядит: вы нажимаете «сохранить», «отправить» или «сгенерировать». Видимо ничего не происходит. Через две секунды экран обновляется, и вы понимаете, что всё это время оно работало.

Что обычно вызывает: приложение делает реальную работу — сохраняет в базу данных, вызывает API, — но ИИ-конструктор не добавил состояние загрузки. Так что с вашей точки зрения клик ничего не сделал.

На самом деле это не проблема производительности. Это проблема ощущаемой производительности, а такие часто болезненнее настоящих. Действие в 200 миллисекунд без обратной связи кажется медленнее, чем действие в 2 секунды со спиннером, потому что мозг пользователя остаётся в неведении.

О чём попросить ваш ИИ-конструктор: «Добавь состояние загрузки к каждой кнопке, которая запускает действие. Показывай спиннер или текст „Сохранение…“, пока оно работает, и блокируй кнопку, чтобы пользователи не могли кликнуть дважды». Это исправление производительности с самой высокой отдачей в любом приложении, и стоит оно почти ничего.

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

Причина медлительности №4: болтливая база данных

Как это выглядит: страница, которая показывает список элементов, у каждого с дополнительной информацией — например, список проектов с числом задач в каждом, — грузится куда дольше, чем грузился бы простой список.

Что обычно вызывает: страница загружает проекты одним запросом, а потом загружает число задач для каждого проекта отдельным запросом. Десять проектов? Одиннадцать запросов. Сто проектов? Сто один. Это называется «запросом N+1», и это самая частая ошибка производительности базы данных в приложениях на ИИ, потому что ИИ оптимизирует код так, чтобы он понятно читался, а не чтобы он эффективно работал.

О чём попросить ваш ИИ-конструктор: «Эта страница делает по одному запросу на элемент. Можем получить все связанные данные одним запросом — через join или агрегат?» Вам не нужно знать, что значит любое из этих слов. ИИ знает. Показать ему медленную страницу и сказать «по-моему, тут проблема N+1» обычно достаточно.

Вы можете распознать проблему N+1 без всяких инструментов: откройте страницу, засеките, сколько она грузится, а потом добавьте в исходный список в десять раз больше элементов. Если страница теперь в десять раз медленнее, у вас N+1. Если она стала медленнее лишь чуть-чуть — у вас её нет.

Пара слов о преждевременной оптимизации

Ловушка, в которую попадают новички: пытаться сделать каждую страницу быстрой ещё до того, как кто-либо пользуется приложением. Не надо.

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

Так что сначала собирайте как обычно. Выпускайте. Смотрите, как этим пользуются. Когда что-то покажется медленным реальному человеку — в том числе вам, — сопоставьте симптом с одной из четырёх категорий выше и попросите именно это исправление. Вы получите более быстрое приложение, не потратив неделю на инфраструктуру, которую ваши пользователи никогда не заметят.

Как разговаривать с вашим ИИ-конструктором о скорости

Подход, который работает: описывайте симптом, а не решение. ИИ гораздо лучше подбирает правильное исправление, чем вы могли бы ожидать, — при условии, что он знает, что на самом деле не так.

Хорошие промпты, которые можно скопировать:

  • «Когда я открываю страницу настроек, есть задержка в секунду, прежде чем что-либо появится. Можем разобраться, что блокирует первую отрисовку?»
  • «Дашборд грузится дольше главной страницы, хотя показывает меньше данных. Можем посмотреть, как он тянет свои данные?»
  • «Когда я нажимаю „сохранить изменения“ на странице профиля, две секунды ничего не происходит. Добавь состояние загрузки и убедись, что кнопку нельзя нажать дважды».
  • «Протестируй этот список с 500 выдуманными элементами и скажи, где замедления».

Последний недооценён. Попросить ИИ сгенерировать тестовые данные и самому попробовать страницу — одна из самых полезных вещей, что вы можете сделать. Он часто найдёт медленные места раньше ваших пользователей — и предложит исправление в том же ответе.

Скорость в приложениях на ИИ — это не про магию. Это про то, чтобы знать, в какое из четырёх вёдер попадает ваша проблема, и попросить правильное исправление понятными словами. Сделайте это — и «кажется медленным» превратится в «кажется нормальным» с помощью горстки небольших точечных изменений, а не переписывания с нуля.