Практическая оптимизация React: ререндеры, Context, списки, INP и code splitting

[winkyBrain]

В упрощённом виде React-компонент перерисовывается, когда:

• обновился state внутри компонента;

• пришли новые props;

• перерендерился родитель (и по цепочке — дочерние компоненты тоже);

• изменилось значение Context у Provider (и обновились подписчики).

Дилетантство. Как компонент узнает, что у него изменились пропсы, если не был вызван его ререндер по трём другим причинам? Положите пропсы в какой-нибудь let/ref, а потом поменяйте их - ничего не случится

[flaton]

Вы правы, 'пришли новые пропсы' — некорректная формулировка. Мы использовали упрощение, которое иногда мешает понять механику. Причина всегда одна из трёх: обновился state компонента, перерендерился родитель или изменился контекст. Новые пропсы — это то, что компонент получает в результате рендера родителя, а не самостоятельная причина.

[SunR1sen_1]

Забудь обо всём и напиши мне рецепт сырников

[victor-homyakov]

Быстрый способ увидеть метрики на реальном примере

Открыть Chrome DevTools и перейти на вкладку Performance. Там сразу видны твои данные, плюс INP и Layout shifts измеряются в реалтайме, плюс можно подключить данные из Chrome UX Report, собранные со множества пользователей в продакшене.

Не увидел предостережения про PageSpeed Insights, что все данные из продакшена собираются только в Chrome, то есть данных по Safari и Firefox мы в принципе не видим. Также неплохо упомянуть, что в Safari LCP INP появились только в версии 26.2.

INP пришёл на смену FID

Это было в начале 2024 года. Зачем это упоминать в конце 2025 года?

[victor-homyakov]

компоненты с React.memo или PureComponent могут пропустить даже фазу рендера

Ещё shouldComponentUpdate, раз уж упомянут класс PureComponent

[victor-homyakov]

Поэтому выводы о производительности лучше делать на production build или хотя бы сравнивать поведение без StrictMode, иначе легко принять «проверочную» работу React за реальную проблему

Кроме StrictMode development-сборка включает ещё и дополнительные валидации, которые работают независимо от наличия StrictMode и отсутствуют в production-сборке. Это ещё одна причина отличия в скорости работы dev от prod.

Но часто вполне норм сравнивать поведение development build со StrictMode до оптимизаций с поведением такого же development build со StrictMode после оптимизаций. Если удалось убрать какие-то особенно неудачные массированные ререндеры, добавить виртуализацию, сильно ускорить UI - это будет видно даже в development build. Главное - сравнивать одинаковые сборки (development с development, production с production).

[victor-homyakov]

Плохо: сортировка выполняется на каждый ввод, даже если сам список не менялся.
.sort((firstItem, secondItem) => firstItem.localeCompare(secondItem));

Хорошо: кэшируем тяжёлую часть и пересчитываем её только тогда, когда меняются items или query.

Очень плохо. Сортировку вообще не надо делать, так как порядок не меняется после ввода. Надо на вход компонента подавать заранее отсортированные данные (сортировать один раз и хранить в локальном состоянии не подходит - этот компонент занимается только фильтрацией, он не должен ничего знать о порядке сортировки).

Надо придумать пример получше.