How I Reduced Page Load Time by 30% — A Redux and Component Refactor Breakdown
The concrete, unglamorous changes to a legacy government React codebase that added up to a 30% load-time cut.
The Ease of Doing Business platform for MMRDA had years of legacy React and Redux behind it, supporting live departmental workflows that couldn't go down for a rewrite. The 30% load-time improvement came from refactoring in place, not from a clean-slate rebuild.
Where the time was actually going
- Redux selectors re-computing on every store update because they weren't memoized, cascading re-renders through components that hadn't actually changed.
- Components subscribed to more of the store than they used, so unrelated state changes triggered unnecessary renders.
- Form-heavy departmental workflows re-rendering entire multi-step forms on every keystroke instead of isolating the field that changed.
The refactor
Memoized selectors so a component only re-rendered when the slice of state it actually read had changed. Narrowed component subscriptions to the minimum state each one needed. Isolated form field updates so typing in one field didn't re-render the whole form tree.
None of this is exotic. It's the standard Redux performance playbook, applied consistently across a codebase that had grown without it — which is exactly why it added up to a measurable number instead of a marginal one.
Why in-place beat a rewrite
A government platform serving live departmental workflows doesn't get a maintenance window for a rewrite. Refactoring existing components against the existing architecture — while keeping every workflow compatible — was the only path that didn't put public services at risk mid-project.
A government Ease-of-Doing-Business platform for the Mumbai Metropolitan Region Development Authority had a legacy React codebase and multiple departmental workflows to keep running while improving it.