Багфикс зависания меню

5 августа 2026: исправление подвисания UI при быстром переключении разделов CRM.

Симптом

При быстрых кликах по боковому меню страница иногда «залипала»: следующий раздел не открывался, вкладка выглядела зависшей. Особенно заметно после захода в Настройки или при серии кликов подряд.

Причина

1. Страница /settings отдавала огромный HTML (~8 МБ): все типы устройств, бренды, неисправности, теги внешнего вида и модели (тысячи строк) рендерились сразу в таблицах вкладки «Данные об устройстве», даже если вкладка не открыта.
2. Браузер долго качал и парсил документ — следующий переход по меню вставал в очередь и казался «сломанным».
3. Service Worker кэшировал документы cache-first: при быстрых навигациях мог отдавать устаревший HTML и усиливать ощущение зависания.

Меню и маршруты были в порядке — узкое место в объёме ответа и политике кэша.

Что сделали

Настройки

• Справочники устройств больше не SSR на GET /settings.
• Таблицы на вкладке «Данные об устройстве» заполняются AJAX (/api/device-types, brands, symptoms, appearance-tags, order-models) только когда вкладка открыта.
• После добавления/правки/удаления списка обновляются без полной перезагрузки страницы.

Service Worker

• Навигация по HTML — только из сети (без кэша документа).
• Кэшируется лёгкая статика (/static/…), версия кэша обновлена (nika-crm-v2-static).

Результат (локальный замер)

Метрика	Было	Стало
Размер HTML /settings	~7.9 МБ	~0.55 МБ
Кнопки моделей в HTML	тысячи	0 (до открытия вкладки)

Что проверить

1. Быстро кликнуть несколько пунктов меню подряд (Заявки → Клиенты → Зарплата → Настройки) — переходы должны успевать.
2. /settings открывается заметно быстрее; вкладка «Данные об устройстве» догружает списки после клика.
3. Один раз hard refresh (Ctrl+F5), чтобы подтянуть новый service worker.

Для админов

После выката достаточно перезапуска web-контейнера / сервиса. Отдельный сброс Redis для этого фикса не нужен.