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

Прототип на вайб-коде летает: в базе 30 тестовых записей и один пользователь — вы. Через пару месяцев клиентов сотни, заказов десятки тысяч, и страница списка открывается 8 секунд, а иногда падает по таймауту. Это не значит, что проект плохой. Это значит, что его оптимизировали под демо.

Почему так происходит

• Нет индексов. ИИ создаёт таблицы, но редко индексы под фильтры, которые вы потом добавили. База перебирает всю таблицу на каждый запрос.
• N+1 запросов. Загружаем 100 заказов, затем для каждого отдельно клиента и товары — 201 запрос вместо одного-двух.
• Нет пагинации. Страница загружает все записи сразу и фильтрует их уже в браузере.
• select *. Тянем все поля, включая большие JSON и тексты, хотя на экране три колонки.
• Синхронные тяжёлые операции. Генерация PDF, отправка писем или вызов ИИ выполняются прямо в запросе пользователя.
• Ограничения тарифа. Бесплатные планы баз и хостингов дают мало памяти и засыпают при простое.

Что проверить самому

1. В DevTools → Network отсортируйте запросы по времени: какие API отвечают дольше секунды?
2. Посчитайте, сколько запросов делает одна страница. Десятки однотипных — признак N+1.
3. Если у вас Postgres или Supabase, найдите медленные запросы. В Supabase для этого есть раздел Query Performance, в обычном Postgres — расширение pg_stat_statements.
4. Проверьте план тяжёлого запроса:

explain analyze select * from orders where customer_id = 42 order by created_at desc;

Если в плане Seq Scan по большой таблице — нужен индекс:

create index on orders (customer_id, created_at desc);

5. Проверьте вес страницы: картинки по несколько мегабайт — частая причина медленного фронтенда.
6. Посмотрите нагрузку на сервер: память и CPU во время тормозов.

Когда звать разработчика. Если вы нашли одну медленную таблицу и индекс решил проблему, отлично. Помощь нужна, если медленно всё сразу, если сервер упирается в память или процессор, если индексы не помогают, если тормоза появляются в определённое время дня или после рассылок, или если вы не уверены, какие индексы безопасно создавать на живой базе. Создание индекса на большой таблице без нужных параметров может заблокировать запись на время построения и остановить работу сервиса.

Как чиним мы

Начинаем с измерений, а не с переписывания. Включаем статистику запросов, логи времени ответа и находим пять–десять мест, которые дают основную задержку. Добавляем индексы, переписываем N+1 в объединённые запросы, вводим пагинацию и кэш для редко меняющихся данных, выносим тяжёлые задачи в фоновую очередь. После каждого изменения замеряем результат и показываем вам цифры «было — стало» по вашему проекту. Подробнее — на странице «Аптечка вайб-кода».

Сколько стоит

Диагностика — 50 000 ₸, оптимизация скорости — 60 000 ₸, итого от 110 000 ₸ для небольшого проекта. Для проектов с кабинетами и большой базой действует коэффициент размера. Рассчитайте в калькуляторе. Чтобы новые функции не возвращали тормоза, полезны правила из статьи «Почему вайб-код ломается».