Profiling and Measuring

// React DevTools -> Profiler -> record -> interact -> stop

// The flame chart shows, per commit:
//   - which components rendered
//   - actual duration (this component and its children)
//   - self duration (this component alone)
//   - WHY it rendered, with "Record why each component rendered" on

// Read it in this order:
//   1. How many commits did one interaction cause? Several is a
//      cascade — usually chained effects or state set during render.
//   2. Which component has the largest self duration?
//   3. Why did it render — props, state, hooks, or parent?

// The Profiler API for production measurements
<Profiler id="ProblemList" onRender={(id, phase, actual, base) => {
  if (actual > 16) analytics.track('slow_render', { id, phase, actual })
}}>

// 16ms is one frame at 60fps. Anything longer drops a frame.

// Always confirm in a production build: development React is far
// slower, and StrictMode doubles the render count.

// Lighthouse, or better, real user data from the field:
//   LCP  largest contentful paint  < 2.5s   "when did I see it"
//   INP  interaction to next paint < 200ms  "did it respond"
//   CLS  cumulative layout shift   < 0.1    "did it move"

// Cause -> fix, by metric:
//   LCP  bundle size, render-blocking CSS/JS, unoptimised hero image
//        -> code splitting, preload the hero, server rendering
//   INP  long tasks blocking the main thread
//        -> break up work, defer non-urgent updates, virtualise
//   CLS  images and ads without reserved space, late-loading fonts
//        -> width/height on images, font-display: swap, skeletons

// Measure in the field, not only on your machine
new PerformanceObserver(list => {
  for (const e of list.getEntries()) send('lcp', e.startTime)
}).observe({ type: 'largest-contentful-paint', buffered: true })

// A React app's LCP is usually decided by bundle size and by whether
// the shell renders before data arrives — not by component code.

npx vite-bundle-visualizer
ANALYZE=true npm run build        # Next, with @next/bundle-analyzer
npx source-map-explorer 'dist/**/*.js'

// The usual findings, in order of frequency:
//   - a chart or editor library on the critical path -> lazy import
//   - an icon set imported as a barrel               -> import per icon
//   - moment or a full lodash                        -> Intl, date-fns, native
//   - two copies of React from a linked package      -> npm ls react
//   - a locale bundle including 200 languages        -> configure the plugin

// Set a budget and fail CI when the initial chunk grows past it.
// Bundles regress one merge at a time, and nobody notices until the
// number is embarrassing.

// Then the React-specific wins: route splitting, deferring below
// the fold, and not shipping admin code to logged-out visitors.