Комментарии 3
Ну вы сами напросились...
Прежде всего у вас куча ошибок в консоли:
![](https://habrastorage.org/getpro/habr/upload_files/0f0/c34/12e/0f0c3412e547ce1f2d351a149217655c.png)
Далее, приборы показывают крайне низкий перфоманс:
![](https://habrastorage.org/getpro/habr/upload_files/d8c/bde/e2a/d8cbdee2a80c344073a64fb98f04331c.png)
Рекомендую вам:
![](https://habrastorage.org/getpro/habr/upload_files/ebc/a10/fce/ebca10fcef32733c23f2d97302f08f79.png)
С вас 100к за аудит.
Хочу поделиться опытом, на работе проходили похожие этапы.
Рассматриваем тут большой веб проект.
Мы изначально разделили основной монолит (проект) на микрофронтенд. Получилось около 50 модулей (страниц).
У нас были библиотеки, которые лежали в отдельных репозиториях и имели Sem Ver в npm.
Т.к. это веб, то приложение по сути едино.
Накладные расходы на поддержание версий во всех связанных страницах были около 4 часов кропотливой работы - нужно было пройтись по каждой библиотеки вручную, поднять версию, проследить, что действительно ничего не упало.
Потом мы перенесли все эти библиотеки в монорепозиторий от nx.
Эти библиотеки остались изолированными библиотеками внутри монорепозитория.
Весь код под рукой, все зависимости тайпчекаются, настроено разделение по слоям библиотек, библиотеки экспортирую только нужные компоненты (сервисы). Зачастую - это 1 страница + несколько типов.
Возможно вам стоит посмотреть в эту сторону.
Чистый микрофронтенд не тоже самое, что и микробэкенд. Чаще всего это одно или несколько приложений, которые должны работать всегда
Банки.ру: от монолита до микрофронтендов