GitHub's pull request Files Changed tab was melting down at scale: JavaScript heaps exceeding 1 GB, DOM node counts above 400,000, and Interaction to Next Paint scores high enough that input lag was physically noticeable. This is GitHub's own engineering team explaining how they rewrote the tab in React and what it cost them to make it fast.
The core problem was the v1 component architecture. A single diff line in unified view required 10 DOM elements, 8 React components, and 20+ event handlers. Split view was worse: 15 DOM elements, 13 components. Multiply that by thousands of lines and the heap fills up fast. Their fix was not one technique but three parallel strategies: optimize the diff-line component structure directly, add virtualization as a fallback for extreme cases, and improve foundational rendering that compounds across all pull request sizes. Even small cuts mattered: removing unnecessary code tags from line number cells eliminated 2 DOM nodes per line, which is 20,000 nodes across a 10,000-line diff.
The article is worth reading in full because it documents the reasoning behind each tradeoff, not just the outcomes. GitHub is explicit that techniques preserving every browser-native behavior, including find-in-page, hit a ceiling at the extreme end, and that virtualization solves the worst case but is the wrong call for everyday reviews. The architecture decisions behind where those thresholds sit are the actual story here.
[READ ORIGINAL →]