Чек-лист производительности React, которым я правда пользуюсь

Большая часть советов по производительности React либо слишком абстрактна, чтобы что-то с ней сделать, либо слишком заточена под чужой конкретный баг. Вот список, который я реально прогоняю перед тем, как считать экран готовым — именно в этом порядке, потому что порядок важен: первые два пункта ловят большинство проблем, а остальные — на случай, если не поймали.

1. Сначала профилировать, потом трогать код. Открыть профайлер React DevTools, записать то самое взаимодействие, которое кажется медленным, и посмотреть, какие компоненты перерендерились и почему. Угадывание, какой компонент тормозит, съедает больше времени, чем сам последующий фикс.
2. Проверить, сколько элементов списка перерендеривается. Если список из 200 строк перерисовывается целиком на каждое нажатие клавиши в никак не связанном поле фильтра, значит состояние, скорее всего, лежит слишком высоко по дереву. Опустить состояние поля вниз или поднять состояние списка выше поля — обычно чинит это одним движением.
3. Искать объекты и массивы, создаваемые прямо в рендере. style={{ margin: 8 }} или options={[...]}, написанные инлайном, создают новую ссылку на каждый рендер, что незаметно убивает memo у того, кто получает это пропсом. Вынести литерал наружу или обернуть в useMemo стоит одну строку кода.
4. Убедиться, что ключи стабильны, а не индексы. Ключ-индекс выглядит нормально ровно до первой вставки или удаления строки, после чего React переиспользует не тот DOM-узел, и локальное состояние — открытый дропдаун, сфокусированный инпут — прыгает не на ту строку. Перед каждым релизом я грепаю key={i}.
5. Проверить, что попало в стартовый JS-бандл. Модалка, библиотека графиков или редактор форматированного текста, импортированные в начале файла роута, уезжают всем, кто заходит на страницу, даже тем 5%, кто эту модалку никогда не откроет. next/dynamic с ssr: false для всего, что скрыто за кликом, чинится за пару минут и обычно оказывается самым весомым пунктом в списке.
6. Измерять на реальных данных, а не предполагать. Пятьдесят строк в деве ведут себя совсем не так, как пять тысяч у настоящего клиента. У меня специально для этой проверки есть один засеянный датасет реалистичного размера, потому что «во время разработки казалось быстрым» — это не бенчмарк.

Ничего экзотического в этом списке нет. Он работает именно потому, что скучный и повторяемый — я прогоняю его одинаково каждый раз, вместо того чтобы рефлекторно хвататься за memo и надеяться на лучшее.