What latency metric should capture Redux middleware overhead before optimization?

Answer

Use action-to-reducer latency. It is the elapsed time from when an action is dispatched to the moment it enters the root reducer. This isolates the synchronous middleware chain cost from reducer execution and downstream UI rendering.

How to measure it with low overhead

Capture high-resolution timestamps at the start of the chain and immediately before the reducer call.

const timingMiddleware = store => next => action => {
  const start = performance.now();
  const result = next(action);
  const end = performance.now();
  if (Math.random() < 0.02) {
    // sample 2% to limit observer effect
  }
  return result;
};

Place this middleware first. The delta end - start is action-to-reducer latency.

Separate reducer cost with a wrapper:

const reducerTiming = reducer => (state, action) => {
  const start = performance.now();
  const nextState = reducer(state, action);
  const end = performance.now();
  return nextState;
};

Middleware overhead = action-to-reducer latency - reducer latency.

Asynchronous middleware

For thunks, sagas or observables, synchronous chain timing only captures dispatch overhead. Async side-effect duration is a separate dispatch-to-completion metric and should not be mixed with synchronous middleware cost.

Continuous monitoring

• Sample 1-5% of actions in production with a random guard.
• Disable timing in production builds unless behind a feature flag.
• Aggregate p50/p95/p99 per minute, not per action.

When to investigate

Metric	Investigate if
Action-to-reducer p95	> 2 ms desktop, > 5 ms low-end mobile
Middleware overhead trend	Sustained 20% increase over 3+ releases
Single middleware delta	> 1 ms vs baseline with middleware toggled off

Measure without Redux DevTools and redux-logger enabled, as they add 0.5-3 ms per action in development.