Как можно оптимизировать рендер

На интервью лучше не отвечать только списком инструментов. Сильнее звучит такой порядок. Сначала измерить, потом найти причину, потом выбрать минимальное исправление и проверить результат.

В React рендер компонента может запускаться из-за изменения state, props или context. Но сам факт рендера еще не означает плохую производительность. Иногда render phase дешевый, а проблема в тяжелом вычислении, большом списке, layout и paint в браузере, сетевых данных или сторонней библиотеке.

Практический вывод простой. Не обещайте, что один хук решит все. Скажите, что оптимизация рендера должна быть точечной и измеримой.

Удобная формулировка для интервью:

Я сначала проверяю, что именно дорого. Это может быть вычисление, рендер большого дерева, commit в DOM или частые обновления. Если проблема в лишнем обновлении дерева, уменьшаю область state или стабилизирую props. Если проблема в большом списке, выбираю виртуализацию. Если проблема в начальной загрузке, применяю code splitting. Если события слишком частые, ограничиваю их частоту.

Такой ответ показывает, что вы не путаете разные виды производительности. Например, React.lazy может ускорить первый экран, но не ускорит тяжелый компонент, когда он уже открыт.

Частая причина медленного UI в том, что state лежит выше, чем нужно. Тогда изменение одного поля перерисовывает большое дерево. Иногда лучший шаг не memo, а перенос state ниже или разделение компонента на независимые части.

Плохой пример. Каждый ввод в поле обновляет родителя, а вместе с ним большой список.

function Page({ items }) {
  const [query, setQuery] = useState("");

  return (
    <>
      <Search value={query} onChange={setQuery} />
      <HeavyList items={items} />
    </>
  );
}

Последствие такого кода заметно при вводе. Каждое нажатие клавиши может снова запускать дорогой рендер списка. Безопаснее отделить state поиска от списка или мемоизировать список только при стабильных props. Еще лучше проверить профайлером, действительно ли список дорогой.

const HeavyList = React.memo(function HeavyList({ items }) {
  return items.map((item) => <Row key={item.id} item={item} />);
});

Если items создается заново на каждый рендер, React.memo не поможет. Тогда сначала стабилизируйте данные или перенесите состояние поиска ниже по дереву.

React.memo помогает пропустить рендер дочернего компонента, если его props не изменились по поверхностному сравнению. useMemo сохраняет результат вычисления. useCallback сохраняет ссылку на функцию.

Типичная ловушка такая. Родитель каждый раз создает новый объект или функцию, поэтому мемоизированный ребенок все равно получает новые props.

const ProductCard = React.memo(function ProductCard({ product, onBuy }) {
  return <button onClick={() => onBuy(product.id)}>{product.title}</button>;
});

function ProductList({ products, onBuy }) {
  return products.map((product) => (
    <ProductCard
      key={product.id}
      product={product}
      onBuy={(id) => onBuy(id)}
    />
  ));
}

В этом примере onBuy создается заново для каждой карточки на каждом рендере. Поэтому React.memo не сможет пропустить рендер дорогой карточки, даже если данные товара не изменились. Безопаснее передавать стабильный обработчик и не закрывать старые значения.

function ProductList({ products, onBuy }) {
  const handleBuy = useCallback((id) => {
    onBuy(id);
  }, [onBuy]);

  return products.map((product) => (
    <ProductCard
      key={product.id}
      product={product}
      onBuy={handleBuy}
    />
  ));
}

Если обработчик уже приходит сверху стабильным, можно передать его напрямую без обертки. Этот вариант помогает только если onBuy, products и отдельные product тоже сохраняют ссылки между рендерами. Если карточка дешевая, добавлять несколько хуков ради формальной стабильности ссылок не нужно.

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

Key нужен React, чтобы правильно сопоставить элементы между рендерами. В изменяемых списках индекс массива как key опасен. После сортировки или вставки React может переиспользовать состояние не той строки. Пользователь редактировал один инпут, а значение визуально оказалось в другом месте.

Безопасная формулировка такая. Для статичного списка индекс иногда допустим, но для данных с сортировкой, фильтрацией, вставкой и удалением нужен стабильный id.

Scroll, resize, mousemove и быстрый input могут запускать обновления слишком часто. Если на каждое событие делать тяжелый расчет и setState, главный поток будет занят, а интерфейс начнет дергаться.

В таких случаях помогает ограничение частоты. Для поиска часто подходит debounce, когда запрос или фильтрация запускаются после паузы. Для scroll и resize часто подходит throttle или requestAnimationFrame, чтобы не обновлять UI чаще, чем это нужно для кадра.

При подписках не забывайте cleanup:

const frameRef = useRef(null);

useEffect(() => {
  const handleResize = () => {
    if (frameRef.current !== null) return;

    frameRef.current = requestAnimationFrame(() => {
      frameRef.current = null;
      setWidth(window.innerWidth);
    });
  };

  window.addEventListener("resize", handleResize);

  return () => {
    window.removeEventListener("resize", handleResize);

    if (frameRef.current !== null) {
      cancelAnimationFrame(frameRef.current);
      frameRef.current = null;
    }
  };
}, []);

Если не отменять запланированный кадр, компонент может попытаться обновить state после размонтирования. Еще одна проблема в очереди из лишних кадров при частых событиях. Поэтому обработчик ограничивает частоту обновлений, а cleanup снимает подписку и отменяет незавершенную работу.

В конце ответа полезно назвать критерий успеха. Оптимизация хорошая, если конкретный сценарий стал быстрее, а поведение интерфейса осталось корректным. Проверьте не только число рендеров, но и ввод в формы, фокус, состояние списков, скелетоны, ошибки загрузки и доступность.

Если вы говорите про производительность в React, разделяйте три задачи. Меньше лишних обновлений, меньше тяжелой работы в одном обновлении и меньше кода на первом экране. Для каждой задачи подходят разные инструменты.