![\"React](\"/static/d0f767f80866431ccdec18f200ca58f1/0a47e/devtools-prod.png\")
\n \n \n \n React за лаштунками використовує кілька розумних підходів для мінімізації кількості вартісних DOM-операцій, необхідних для оновлення користувацького інтерфейсу. Для більшості додатків, використання React дозволить мати швидкий інтерфейс без докладання особливих зусиль для оптимізації продуктивності. Не дивлячись на це, існує кілька шляхів для прискорення швидкодії вашого React-додатку.
\nЯкщо ви оцінюєте чи маєте проблеми зі швидкодією ваших React-додатків, впевніться в тому, що ви тестуєте мініфіковану продакшн-збірку.
\nReact включає багато корисних попереджень за замовчуванням. Вони є надзвичайно корисними при розробці, але в той самий час роблять React більшим та повільнішим. Саме тому ви маєте бути певними, що використовуєте продакшн-версію при розгортанні додатку.
\nЯкщо ви не впевнені у правильному налаштуванні процесу збірки, ви можете перевірити це, встановивши інструменти розробника React для Chrome. Якщо ви відвідаєте сайт на React у продакшн-режимі, іконка матиме темний фон:
\n\n \n \n \n \n\n \n \n \n \n \nЯкщо ви відвідаєте сайт, що використовує React у режимі розробки, то іконка матиме червоний фон:
\n\n \n \n \n \n![\"React](\"/static/e434ce2f7e64f63e597edf03f4465694/0a47e/devtools-dev.png\")
\n \n \n \n \n \nЯк правило ви маєте використовувати режим розробки під час роботи над додатком і продакшн-режим при його розгортанні.
\nНижче ви можете знайти інструкції по збірці вашого додатку для продакшну.
\nЯкщо ви використали Create React App для створення проекту, запустіть:
\nnpm run buildЦя команда створить продакшн-збірку у папці build/ вашого додатку.
Пам’ятайте, що це необхідно лише перед розгортанням на продакшн. Для звичайної розробки використовуйте npm start.
Ми пропонуємо готові для продакшу версії React та React DOM у вигляді окремих файлів:
\n<script src=\"https://unpkg.com/react@16/umd/react.production.min.js\"></script>\n<script src=\"https://unpkg.com/react-dom@16/umd/react-dom.production.min.js\"></script>Пам’ятайте, що для продакшну підходять тільки ті файли React, що закінчуються на .production.min.js.
Для найефективнішої продакшн-збірки з використанням Brunch, встановіть плагін terser-brunch:
# Якщо ви користуєтесь npm\nnpm install --save-dev uglify-js-brunch\n\n# Якщо ви користуєтесь Yarn\nyarn add --dev uglify-js-brunchПотім створіть продакшн-збірку, додавши прапорець -p до команди build:
brunch build -pПам’ятайте, що це потрібно робити лише для продакшн-збірок. Ви не повинні передавати прапорець -p чи застосовувати цей плагін під час розробки, тому що це приховає корисні попередження від React та сповільнить процес збірки.
Для найефективнішої продакшн-збірки з використанням Browserify, встановіть декілька плагінів:
\n# Якщо ви користуєтесь npm\nnpm install --save-dev envify terser uglifyify\n\n# Якщо ви користуєтесь Yarn\nyarn add --dev envify terser uglifyifyЩоб створити продакшн-збірку, впевніться, що ви додали наступні перетворення (у представленому порядку):
\nenvify гарантує правильність встановленого середовища для збірки. Зробіть його глобальним (-g).uglifyify видаляє необхідні для розробки імпорти. Зробіть його глобальним також (-g).terser для мініфікації (прочитайте навіщо).Наприклад:
\nbrowserify ./index.js \\\n -g [ envify --NODE_ENV production ] \\\n -g uglifyify \\\n | terser --compress --mangle > ./bundle.jsПам’ятайте, що це потрібно робити лише для продакшн-збірок. Ви не повинні використовувати ці плагіни під час розробки, тому що це приховає корисні попередження від React та сповільнить процес збірки.
\nДля найефективнішої продакшн-збірки з використанням Rollup, встановіть декілька плагінів:
\n# Якщо ви користуєтесь npm\nnpm install --save-dev rollup-plugin-commonjs rollup-plugin-replace rollup-plugin-terser\n\n# Якщо ви користуєтесь Yarn\nyarn add --dev rollup-plugin-commonjs rollup-plugin-replace rollup-plugin-terserЩоб створити продакшн-збірку, впевніться, що ви додали наступні плагіни (у представленому порядку):
\nreplace гарантує правильність встановленого середовища для збірки.commonjs надає підтримку CommonJS у Rollup.terser стискає та мініфікує фінальну збірку.plugins: [\n // ...\n require('rollup-plugin-replace')({\n 'process.env.NODE_ENV': JSON.stringify('production')\n }),\n require('rollup-plugin-commonjs')(),\n require('rollup-plugin-terser')(),\n // ...\n]Для більш повного зразку налаштування перегляньте цей gist.
\nПам’ятайте, що це потрібно робити лише для продакшн-збірок. Ви не повинні використовувати плагін terser чи replace із значенням 'production' під час розробки, тому що це приховає корисні попередження від React та сповільнить процес збірки.
\n\nПримітка:
\nЯкщо ви використовуєте Create React App, то використовуйте інструкції вище.
\n
\nЦей розділ потрібен, якщо ви самі налаштовуєте webpack.
Webpack версії 4, або вище, за замовчуванням мінімізує ваш код у продакшн-режимі.
\nconst TerserPlugin = require('terser-webpack-plugin');\n\nmodule.exports = {\n mode: 'production',\n optimization: {\n minimizer: [new TerserPlugin({ /* additional options here */ })],\n },\n};Ви можете дізнатися про це більше у документації webpack.
\nПам’ятайте, що це потрібно робити лише для продакшн-збірок. Ви не повинні використовувати UglifyJsPlugin чи TerserPlugin під час розробки, тому що це приховає корисні попередження від React та сповільнить процес збірки.
У режимі розробки, ви можете візуалізувати процес монтування, оновлення і демонтування компонентів, використавши інструменти продуктивності у браузерах, що їх підтримують. Наприклад:
\n![\"React-компоненти](\"/static/64d522b74fb585f1abada9801f85fa9d/1ac66/react-perf-chrome-timeline.png\")
\n \n \n \n \n Щоб зробити це в Chrome:
\nДля більш детальних інструкцій перегляньте цю статтю Бена Шварца (Ben Schwarz).
\nЗверніть увагу на те, що ці значення відносні і компоненти в продакшні будуть рендеритись швидше. Проте це допоможе вам зрозуміти, коли не пов’язані між собою частини інтерфейсу оновлюються через помилку та як глибоко і часто ці оновлення вібдуваються.
\nНаразі Chrome, Edge та IE є єдиними браузерами, котрі підтримують цю функціональність, але ми використовуємо стандарт User Timing API, а тому очікуємо, що більше браузерів додадуть її підтримку.
\nreact-dom 16.5+ та react-native 0.57+ надають додаткові можливості профілювання в режимі розробки з використанням профайлера React DevTools.\nОгляд профайлера можна знайти в пості блогу “Знайомство з React Profiler”.\nВідео-посібник також доступний на YouTube.
Якщо ви ще не встановили React DevTools, ви можете знайти їх тут:
\n\n\n\nПримітка
\nПродакшн-збірка профілювання для
\nreact-domтакож доступна якreact-dom/profiling.\nДокладніше про її використання ви можете дізнатись за посиланням fb.me/react-profiling
Якщо ваш додаток рендерить довгі списки даних (сотні чи тисячі рядків), ми радимо використовувати підхід під назвою “віконний доступ”. Цей підхід рендерить лише невелику підмножину ваших рядків у будь-який момент часу і може значно зменшити час, потрібний для повторного рендеру компонентів та кількість створених DOM-вузлів.
\nreact-window та react-virtualized — це популярні бібліотеки для віконного доступу. Вони надають кілька компонентів для відображення списків, сіток та табличних даних. Якщо ваш додаток потребує іншого підходу, то ви можете створити власний компонент для віконного доступу, як це зроблено в Twitter.
\nReact створює і підтримує внутрішній стан відображуваного користувацького інтерфейсу. Він також включає React-елементи, які ви повертаєте з ваших компонентів. Це дозволяє React уникати створення нових DOM-вузлів та доступу до вже існуючих без необхідності, тому що ці операції можуть бути повільнішими за операції зі звичайними JavaScript-об’єктами. Іноді цей стан називають “віртуальний DOM”, але в React Native він працює так само.
\nКоли пропси чи стан компонента змінюються, React вирішує чи необхідне оновлення DOM, порівнюючи новий повернутий елемент з вже відрендереним. Якщо вони не рівні, то React оновить DOM.
\nНезважаючи на те, що React оновлює тільки змінені вузли DOM, повторний рендер все ж займає певний час. У більшості випадків це не проблема, але якщо ви помітите, що швидкодія зменшиться, то ви можете прискорити все, перевизначивши метод життєвого циклу shouldComponentUpdate, котрий викликається перед початком процесу повторного рендерингу. За замовчуванням, реалізація цієї функції повертає true, змушуючи React здійснити оновлення:
shouldComponentUpdate(nextProps, nextState) {\n return true;\n}Якщо ви знаєте, що в певних ситуаціях ваш компонент не повинен оновлюватись, то ви можете повернути false з shouldComponentUpdate, щоб пропустити весь процес рендерингу, включно з викликом render() поточного компонента та компонентів нижче.
У більшості випадків, замість написання shouldComponentUpdate() вручну, ви можете наслідуватись від React.PureComponent. Це еквівалентно реалізації shouldComponentUpdate() з поверховим порівнянням поточних та попередніч пропсів та стану.
На рисунку зображено піддерево компонентів. Для кожного з них SCU позначає значення, повернуте shouldComponentUpdate, і vDOMEq позначає чи були відрендерені React-елементи рівними. Нарешті, колір кола позначає те, чи має компонент бути узгодженим, чи ні.
![\"should](\"/static/5ee1bdf4779af06072a17b7a0654f6db/cd039/should-component-update.png\")
\n \n \n \n \n Оскільки shouldComponentUpdate повернув false для піддерева з коренем в C2, React не буде намагатися відрендерити C2 і навіть викликати shouldComponentUpdate для C4 і C5.
Для C1 і C3 shouldComponentUpdate повернув true, тому React має перейти вниз до листів дерева і перевірити їх. Для C6 shouldComponentUpdate повернув true і, оскільки значення відрендерених елементів не було еквівалентним, React має оновити DOM.
Останнім цікавим випадком є C8. React має відрендерити цей компонент, але оскільки повернуті React-елементи були рівні попереднім, то DOM не буде оновлений.
\nЗверніть увагу на те, що React повинен був здійснити зміну DOM лише для C6, що було неминучим. Для C8 він уникнув змін завдяки порівнянню відрендерених React-елементів, а для піддерева C2 та C7 не потрібно було навіть виконувати це порівняння, оскільки процес рендерингу зупинився у методі shouldComponentUpdate і метод render не був викликаний.
Якщо ваш компонент має змінюватись лише тоді, коли змінюються змінні props.color чи state.count, ви можете виконати цю перевірку в shouldComponentUpdate:
class CounterButton extends React.Component {\n constructor(props) {\n super(props);\n this.state = {count: 1};\n }\n\n shouldComponentUpdate(nextProps, nextState) {\n if (this.props.color !== nextProps.color) {\n return true;\n }\n if (this.state.count !== nextState.count) {\n return true;\n }\n return false;\n }\n\n render() {\n return (\n <button\n color={this.props.color}\n onClick={() => this.setState(state => ({count: state.count + 1}))}>\n Рахунок: {this.state.count}\n </button>\n );\n }\n}У цьому коді shouldComponentUpdate лише перевіряє наявні зміни в props.color чи state.count. Якщо ці значення не змінились, то компонент не оновиться. Якщо ваш компонент буде більш складним, ви можете використати схожий шаблон і зробити “поверхове порівняння” всіх полей props і state, щоб визначити, чи має компонент оновитись. Цей шаблон трапляється часто, а тому React надає допоміжну функцію для цієї логіки — просто унаслідуйтесь від React.PureComponent. Наступний код показує простіший шлях для досягнення цього ефекту:
class CounterButton extends React.PureComponent {\n constructor(props) {\n super(props);\n this.state = {count: 1};\n }\n\n render() {\n return (\n <button\n color={this.props.color}\n onClick={() => this.setState(state => ({count: state.count + 1}))}>\n Рахунок: {this.state.count}\n </button>\n );\n }\n}У більшості випадків ви можете використовувати React.PureComponent замість написання власного методу shouldComponentUpdate. Він робить лише поверхове порівняння, а тому ви не можете використати його, якщо пропси чи стан можуть змінитись таким чином, що поверхове порівняння пропустить цю зміну.
Це може бути проблемою для більш складних структур даних. Наприклад, ви хочете, щоб компонент ListOfWords рендерив список слів розділених комами з батьківським компонентом WordAdder, що дає можливість натиснути на кнопку і додати слово в список. Цей код працює неправильно:
class ListOfWords extends React.PureComponent {\n render() {\n return <div>{this.props.words.join(',')}</div>;\n }\n}\n\nclass WordAdder extends React.Component {\n constructor(props) {\n super(props);\n this.state = {\n words: ['марклар']\n };\n this.handleClick = this.handleClick.bind(this);\n }\n\n handleClick() {\n // Даний метод є поганим стилем і спричиняє помилку\n const words = this.state.words;\n words.push('марклар');\n this.setState({words: words});\n }\n\n render() {\n return (\n <div>\n <button onClick={this.handleClick} />\n <ListOfWords words={this.state.words} />\n </div>\n );\n }\n}Проблема в тому, що PureComponent зробить просте порівняння старого значення this.props.words з новим. Оскільки цей код змінює масив words у методі handleClick класу WordAdder, то нове та старе значення this.props.words будуть вважатися однаковими як посилання, хоча вміст масиву і змінився. ListOfWords не оновиться, хоч він і містить нові слова, що мають бути відрендерені.
Найпростішим шляхом уникнення цієї проблеми є уникнення зміни значень, які ви використовуєте як пропси чи стан. Наприклад, метод handleClick вище, міг би бути переписаний з використанням concat:
handleClick() {\n this.setState(state => ({\n words: state.words.concat(['марклар'])\n }));\n}ES6 підтримує синтаксис розпакування для масивів, щоб спростити цю задачу. Якщо ви використовуєте Create React App, цей синтаксис доступний за замовчуванням.
\nhandleClick() {\n this.setState(state => ({\n words: [...state.words, 'марклар'],\n }));\n};Ви також можете подібним чином переписати код, що змінює об’єкти. Наприклад, у нас є об’єкт colormap і ми хочемо написати функцію, що змінить colormap.right на 'blue'. Ми могли б написати:
function updateColorMap(colormap) {\n colormap.right = 'blue';\n}Щоб переписати це без зміни оригінального об’єкта, ми можемо використати метод Object.assign:
\nfunction updateColorMap(colormap) {\n return Object.assign({}, colormap, {right: 'blue'});\n}updateColorMap тепер повертає новий об’єкт, а не змінює старий. Object.assign — це ES6 і для його роботи потрібен поліфіл.
Оператор розкладу дозволяє оновлювати об’єкти, не мутуючи їх:
\nfunction updateColorMap(colormap) {\n return {...colormap, right: 'blue'};\n}Ця функція була додана до JavaScript у ES2018.
\nЯкщо ви використовуєте Create React App, то Object.assign та розпакування об’єктів доступні за замовчуванням.
Коли ви працюєте з глибоко вкладеними об’єктами, то постійне іх оновлення може заплутати вас. Якщо ви зіткнулися з такою проблемою, зверніть увагу на Immer або immutability-helper. Ці бібліотеки допомогають писати читабельний код, не втрачаючи переваг незмінності.
","frontmatter":{"title":"Оптимізація продуктивності","next":null,"prev":null},"fields":{"path":"content/docs/optimizing-performance.md","slug":"docs/optimizing-performance.html"}}},"pageContext":{"slug":"docs/optimizing-performance.html"}},"staticQueryHashes":[]}