Чытанне паказанняў пра выконвальную скорасць React у Chrome DevTools, каб знайсці сповольненую адрасаўку

Калі взаімадзеянне з React выглядае повольным, першым падзецем ёст тое, што дадаць useMemo, useCallback і React.memo і спадзявацца. Частае рашчыненне — сторанка застаецца повольной, таму што ніхто не вымерыў, што з’ядае час. У React 19.2 былі даданы Performance Tracks, якія запісваюць актыўнасць React у часовую шкалу прыстрою браузера; гэта тое, што паказвае кожны з эўрактов і як ператворыць запис у конкрэтны рашчыненне.

Чаму звычная часовая шкала была важкай для чытання

Запісаўшы повольнае взаімадзеянне ў панелі Performance прыстрою Chrome DevTools у аплікацыі без гэтых эўрактов, галоўны поток зазвычай выглядае так:

JavaScript
████████████████████
██████████
███
████████████

JavaScript явная споўнена роботай, але які самэ кампаненты былі відпаведальныя, які апдэйт запусціў рендарынг, чакала лі сторанка на сецьянары, чы не домінаваў якісь Effect, і чы React рэндарыла саме тады, калі корыстувач чакаў негайнай адпаведзі? Звычны падход заставляе чалавека самому складваць вясні з назв функцый. React-трэйкі запявляюць нехватную інфармацыю.

Што дадаюць React-трэйкі

React прыносіць спецыяльныя трэйкі для трох сфер:

Scheduler
Components
Server

Яны знаходзяцца празаўсюды ля звычных каналаў браузера, таму адно трэйс можна прачытаць приблізна так:

USER CLICK
    │
    ▼
┌─────────────────────────────┐
│ React Scheduler             │
│ Blocking → Render → Commit  │
├─────────────────────────────┤
│ React Components            │
│ Dashboard                   │
│ ├─ Header                   │
│ ├─ DataTable  ← expensive   │
│ └─ Chart                    │
├─────────────────────────────┤
│ Network / JavaScript        │
└─────────────────────────────┘

Ценнасць крыецца ў корэляцыі: актывасць React і актывасць браузера паказваюцца на адной спяльнай вектарной шкале часу.

Скеджалер: чаму гэты код запрацаваў зараз?

React не адмініструе кожную зміну адзінакова. Механізм Scheduler разлічва задачы па прыоритэтах, выделяючы такія канты як Blocking, Transition, Suspense і Idle, а таксама пазначае фазы кожной зміны: Update, Render, Commit і будзь-якія застаўшыяся Effects.

Гэта дазволяе даць адказ на такія запытанні, як "чаму ўвод дадзеных у гэта поле затрымляецца?" Ход задач можа паказаць, што нажатыя клавішы запусцілі тэжкую сінхронную обработку дадзеных у канце Blocking. Алі можа таксама паказаць, што дырогая задача вже была правільна абгорнута ў процес Transition, што паказвае направлення далейшага аналізу. У будзь-якам случае вы працюеце на адной падставе доказаў, а не інтуіцыі. Якщо панявы Transition і прыоритэты ёсць новымі для вас, модель, якая стоіць за гэтымі кантамі, прадстаўлена ў статыце Understanding React Lanes.

Компаненты: хто выконаў работу?

Для ўлучнай наладкі практычна ўсё часа яшчэ адной з найкорыстнейшых методаў. Яна паказвае, сколькі часу кожны элемент выдзейваў і запускаў эфекты у відэа-графіку, а пад час розработы таксама може выявіць змененыя параметры і последовыя апдэйты. Такі результат ёсць стандартным:

ProductPage        310ms
├── Header           12ms
├── Filters          18ms
├── DataTable       245ms  ←
└── Footer            8ms

У замяну нечыткай скарге на тое, што React работае медленна, тепер у вас є точны паводак: DataTable зайняў большую частку часу на выдзейванне. Потым пераканайцеся, чы не выдзейвае ён занадто много рядоў, чы не пераскладае данні з кожным разам або чы не прымае новыя параметры ад свайго родзіча ў кожны момент.

Сервер: чакае ўсё-такі сторанка на React?

У дапытках, якія викорыстоўваюць React Server Components, версіі для розработы таксама паказваюць запиты сервера і работу серверных компанентаў на графіку часу. Це дазволяе выявіць распашчастую дыагнозацыю:

Slow page
   │
   ▼
Assume React render
   │
   X
   │
   ▼
Actually waiting on:
getProducts()
      │
      ▼
Database / API

Якщо логі з’являецца, што сторынка працуе без дзейнаў, пакалі getProducts() чакае на базе дадзенаў аб API, то спасабліванне трэба шукать у процесе запрашэння дадзенаў — напрыклад, у кэшаванні, паралельных запрашэннях аб болей эфектывах запытках. Абгорткаванне компонентаў за дапамогою React.memo не будзе дапамагаць. Самэ гэтая прычына, чаму трэба бачыць весь час выканання ў аднам відзоре.

Процес дэбагавання, які можна паўтарыць

Калі взаімадзея здаецца медленной, ўсё час следавайце той самы парадок:

1. Reproduce the problem
          ↓
2. Open Performance
          ↓
3. Record the interaction
          ↓
4. Find the slow React work
          ↓
5. Inspect the component / phase
          ↓
6. Check network and browser work
          ↓
7. Fix the actual bottleneck
          ↓
8. Record again

Не прыхоўдзайце да заканчальнага крока. Запісваўце зноў за тымі ж умовамі і парабяйце. Оптымаўзацыя, якая ніколі не перамеравалася, ёсць толькі гіпотэзай. Іноды другі лог паказвае, што змяны перанеслі вартасць куды-небудзь іншае, а не пазбавілі яе.

Знаёмце меры локальнага логу

Тракінг выконання ўжоўсяць як адказ на патрэбы розработкі та аналізу. React паведамляе, што наявнасць такіх засобаў адбіваеся на выконанні, і ў стандартных версіях для практычнага викорыстання яны выключаны, а тракінг на серверах дзейсні толькі у версіях для розработкі. Кроме таго, версіі для розработкі працуюць медленней, таму трэба больш верыць у прапорціі, чым у абсалютныя цифры.

Это значыць, што чысты трак-файл на вашам комп’ютеры не паводзіць да вынікнення заключэння, што рэальныя корыстувачы маюць шырокі спектар можлівасцей. Для аналізу выконання ў рэальных умовах патрэбны даны з практычнаг викорыстання та стежэнне за рэальнымі корыстувачамі. Тракінг адпавядае на болей вузкі, але дужа практычны запит: што самэўсь робіць прыстановка, крок за крокам, калі вы воспрамоўляеце гэтую конкретную проблему?

Ключовыя выводы

Найбольш шкодзячая прычына падвышанага выконання — не выбіранне неправильнага способу фіксацыі дадзеных; гэта оптымізацыя раней, чым будзе зрозумела сама проблема. Болей правільны падход выглядае так:

Slow interaction
       │
       ▼
    Measure
       │
       ▼
 Find the bottleneck
       │
 ┌─────┼──────┐
 ▼     ▼      ▼
React Network Browser
 │      │      │
 ▼      ▼      ▼
Fix    Fix    Fix

• Спачатку звярзайцеся з мерамі: трэкі робяць запіс і выявленне «узкае галавы» простымі задачамі.
• Ўжывайце трэк Планавальніка, каб разумець прыоритэты та фазы, а таксама трэк Компанентав, каб знайсці дорогі падрэсны дрэво.
• Пераканаецеся ў стані сервера та канальных лініях сеті, перш чым прыпускати, што проблема ў процесе атрыбутавання.
• Перазапісвайце матэрыял пасля кожных змян, каб парадактнаць выправленне.
• Расследаванні локальных следаў трэба спрыяць дыагназе, а для розумення таго, што перажываюць корыстувальнікі, неабходна спалагацца на данных з практыки.

Такі падход пераключае акцэнт з пытання, чы гэта трэба дадаць useMemo, на тое, што на самай працэ выкорыставало тыя 200 мілісекунд, і самэ гэта пытанне дапамагае знайсці рэальнае выправленне.