Когда объем данных в No-code приложении переваливает за 2 000–5 000 записей, стандартный метод загрузки всего массива в браузер приводит к «зависанию» интерфейса на 3–7 секунд и резкому росту потребления RAM до 500+ МБ. Для сохранения UX при работе с десятками тысяч строк необходимо переносить логику обработки с фронтенда на уровень базы данных.
Клиентская фильтрация: ловушка для новичков
Многие разработчики в Bubble или Glide используют стандартные фильтры, которые подгружают все данные в кеш браузера, а затем скрывают ненужные строки. Это работает до 500 записей. При достижении 2 000+ строк время отрисовки страницы (LCP) увеличивается в 4–5 раз, так как браузер вынужден пересчитывать DOM-дерево при каждом изменении фильтра.
Кейс: CRM-система с базой в 3 000 лидов. При использовании клиентской фильтрации поиск по имени занимал до 2.5 секунд на среднестатистическом ноутбуке. Переход на серверную фильтрацию сократил время отклика до 200–400 мс, независимо от объема БД.
Экспертный вывод: Клиентская фильтрация допустима только для статических справочников до 100 позиций. Всё, что растет динамически, должно фильтроваться на стороне сервера.
Пагинация: классическая против бесконечного скролла
Пагинация (разбиение на страницы по 20–50 записей) снижает нагрузку на сеть на 90-95% по сравнению с полной выгрузкой. Однако в No-code есть нюанс: классическая нумерованная пагинация требует от сервера знать общее количество записей (Count), что при массивах в 100 000+ строк может замедлить запрос на 1–2 секунды.
Бесконечный скролл (Infinite Scroll) работает быстрее, так как запрашивает только следующую порцию данных (Offset/Limit), но он убивает производительность при попытке достичь «низа» списка — через 10-15 подгрузок браузер начинает тормозить из-за раздувания DOM.
Экспертный вывод: Для административных панелей и таблиц используйте жесткую пагинацию по 50 записей. Для пользовательских лент — бесконечный скролл, но с обязательной очисткой старых элементов из памяти при достижении лимита в 200 строк.
Серверная сортировка и индексация полей
Сортировка на стороне клиента — это гарантированный «фриз» интерфейса при массиве от 1 000 записей. Проблема усугубляется в No-code, где мы часто не видим индексов БД. Без индексации поля, по которому идет сортировка, сервер делает Full Table Scan, что увеличивает время ответа с 100 мс до 3–5 секунд при росте базы с 10к до 50к записей.
Пример: В приложении для учета склада сортировка по «дате поступления» без индекса на внешней БД (например, Xano или Supabase) тормозила весь интерфейс. Внедрение индекса для этого поля сократило время выполнения запроса в 15 раз.
Экспертный вывод: Всегда настраивайте серверную сортировку. Если используете внешнюю БД, принудительно создавайте индексы для полей, по которым чаще всего происходит фильтрация и сортировка.
Архитектурные лимиты и точки отказа
Существует критический порог, когда даже серверная оптимизация не спасает. В No-code это часто связано с лимитами на количество запросов (WU в Bubble или строк в Glide). Когда приложение переходит порог в 50 000–100 000 активных записей, стоимость поддержки инфраструктуры растет экспоненциально, а скорость API падает из-за сложности джойнов (связей между таблицами).
В этот момент возникает необходимость пересмотреть разработку приложений на No-code: комплексное руководство по проектированию архитектуры масштабируемых систем подскажет, как вынести тяжелые расчеты в отдельные микросервисы или переехать на SQL-базы с оптимизированными процедурами.
Экспертный вывод: Не пытайтесь «дожать» встроенную БД платформы до миллиона записей. Как только время отклика API стабильно превышает 1.5 секунды при оптимизированных запросах — это сигнал к миграции данных на внешний бэкенд.
Вывод
Для работы с массивами данных в No-code забудьте про клиентскую обработку. Мой выбор: серверная фильтрация + жесткая пагинация по 50 записей + индексация всех ключевых полей на стороне БД. Избегайте бесконечного скролла в сложных интерфейсах и не используйте встроенные БД платформ для хранения более 20 000 активных записей — переходите на связку No-code фронтенд + Xano/Supabase. Это единственный способ сохранить скорость интерфейса на уровне 300-500 мс при любом росте базы.