Какие могут быть проблемы с оптимизацией React?

Проблемы с оптимизацией в React бывают двух родов: недооптимизация (тормоза) и — что часто недооценивают — вред от самой оптимизации.

Проблемы производительности (недооптимизация)

• Каскадные перерендеры от состояния в корне дерева.
• Тяжёлые вычисления в рендере без useMemo.
• Списки на тысячи элементов без виртуализации.
• «Толстый» контекст, будящий всех потребителей.
• Огромный бандл без code splitting.

Проблемы от самой оптимизации

Преждевременная мемоизация. React.memo/useMemo/useCallback на всём подряд: код сложнее, памяти больше, а выигрыша нет — сравнение props тоже стоит ресурсов. Мемоизация без профилирования — карго-культ.

Сломанная мемоизация (молчаливая). Один нестабильный проп (инлайн-объект, children) — и React.memo не работает, но об этом никто не узнает: код выглядит оптимизированным, а рендеры идут.

Баги от useMemo/useCallback. Неполные зависимости ради «стабильности» → устаревшие замыкания: обработчик видит старый state, данные не обновляются. Это хуже медленного кода — он неправильный.

Хрупкость. Цепочка «useCallback → memo-ребёнок → его эффекты» ломается от одного рефакторинга; новые разработчики не понимают, почему нельзя «просто передать объект».

Оптимизация не того. Профилирование в dev-сборке (медленнее прода), микрооптимизации при реальной проблеме в сети/бандле, борьба с рендерами, которые ничего не стоят.

Как подходить правильно

Измерять production-сборку (Profiler, Web Vitals) → чинить архитектурные причины (структура состояния, спуск вниз, разделение контекстов) → мемоизация точечно → перепроверять. React Compiler (React 19) снимает ручную мемоизацию.

Коротко для собеседования

Кроме классических тормозов, назвать обратную сторону: преждевременная мемоизация усложняет код без пользы, молча ломается от одного нестабильного пропа, неполные deps дают stale-баги, профилирование dev-сборки обманывает. Порядок: измерить прод → архитектура → точечная мемоизация.