React Compiler против ручной мемоизации

Долгие годы оптимизация производительности React сводилась к одному: расставлять useMemo, useCallback и React.memo по всей кодовой базе и надеяться, что массивы зависимостей указаны правильно. React Compiler меняет это уравнение. Но насколько? И есть ли ещё место ручной мемоизации в современных React-приложениях?

Вот что вам действительно нужно знать.

Что делает React Compiler

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

Сейчас он стабилен и готов к продакшену: используется в проде в Meta и поддерживается в Babel, Vite, Metro и Rsbuild. Next.js 15.3.1+ поддерживает путь вызова React Compiler через SWC для улучшения производительности сборки.

Ключевое слово здесь — время сборки. React Compiler — это не рантайм-кэш для произвольных значений. Он сосредоточен именно на оптимизации повторных рендеров компонентов на основе статического анализа структуры вашего кода.

Где React Compiler автоматически справляется с мемоизацией

Компилятор аккуратно обрабатывает типовые случаи:

• Простые изменения состояния — соседний компонент, который не зависит от изменившегося состояния, не будет перерендериваться.
• Пропсы с колбэками — встраиваемые стрелочные функции, передаваемые как пропсы, корректно мемоизируются, даже во вложенных случаях.
• Children как пропсы — печально известный сложный паттерн useMemo(() => <Child />, []) становится ненужным.
• Кастомные хуки — возвращаемые значения мемоизируются на основе их реальных зависимостей.

На третьем случае стоит остановиться. Большинство разработчиков делают это вручную неправильно. Компилятор делает это правильно автоматически.

Где ручная мемоизация в React по-прежнему важна

Реальное тестирование на нескольких кодовых базах рисует более приземлённую картину. Компилятор хорошо справляется с изолированными, самодостаточными компонентами. Он испытывает трудности, когда сторонние библиотеки возвращают немемоизированные объекты.

Самый показательный пример: useMutation из React Query возвращает новый объект при каждом рендере. Если ваш колбэк onDelete зависит от deleteCountryMutation, а не от деструктурированной функции mutate напрямую, компилятор не сможет его стабилизировать. Исправление простое, как только вы его знаете: деструктурируйте mutate напрямую. Но компилятор не может принять это решение за вас.

// Compiler-friendly: stable reference
const { mutate: deleteCountry } = useMutation(...)

// Compiler-unfriendly: new object every render
const deleteCountryMutation = useMutation(...)
const onDelete = () => deleteCountryMutation.mutate(name)

Другие случаи, где ручной контроль по-прежнему выигрывает:

• Зависимости эффектов — когда вам нужно мемоизированное значение именно для того, чтобы useEffect не срабатывал многократно.
• Динамические списки — строки, отрисованные внутри .map(), выигрывают от выделения в именованные компоненты со стабильными пропсами key. Компилятор оптимизирует внутри компонентов лучше, чем между инлайн-выводом рендера.
• Тонкая настройка производительности после профилирования — если вы измерили конкретное узкое место, явный useMemo даёт точный контроль, недостижимый для эвристик компилятора.

Как должны измениться ваши привычки кодирования на React

Сдвиг ментальной модели прост: перестаньте мемоизировать защитно, начните мемоизировать осознанно.

До появления компилятора по умолчанию было принято оборачивать всё на всякий случай. Это добавляло шум, нагрузку на сопровождение и иногда приводило к тонким багам (например, ловушка с useCallback и встраиваемой стрелочной функцией, на которую теперь обращает внимание официальная документация).

С включённым React Compiler новый дефолт — писать чистые, простые компоненты и позволять компилятору заниматься оптимизацией. Прибегайте к useMemo или useCallback, когда у вас есть конкретная, измеримая причина, а не рефлекторно.

Две практические привычки, которые стоит выработать уже сейчас:

1. Выделяйте элементы списков в именованные компоненты — <CountryRow /> вместо инлайн-JSX внутри .map().
2. Деструктурируйте стабильные значения из сторонних хуков — используйте mutate напрямую, а не весь объект мутации.

Практический вывод

React Compiler — это реальное улучшение оптимизации производительности React. Он устраняет большую часть защитной мемоизации, которая загромождала кодовые базы, и обрабатывает сложный паттерн children-as-props лучше, чем большинство разработчиков делают это вручную.

Но он не заменяет понимание того, как работают повторные рендеры в React. Больше всего от компилятора получат те разработчики, которые по-прежнему понимают компромиссы между useMemo и React Compiler и знают, к чему обращаться в каждом случае.

Заключение

React Compiler знаменует настоящий поворотный момент в том, как мы думаем о производительности в React. Рефлекторная привычка оборачивать каждое значение и функцию в хелпер мемоизации больше не является правильным дефолтом. Пишите более простой код, дайте компилятору делать своё дело и профилируйте перед ручной оптимизацией. Держите ручную мемоизацию в своём инструментарии для случаев, которые компилятор не видит, особенно вокруг сторонних хуков и измеренных узких мест. Это подход, который остаётся актуальным в 2026 году и далее.

FAQ

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.