Pull requests are central to GitHub, but performance can suffer when reviewing massive diffs. The Files changed tab, recently rebuilt in React, aimed to stay fast even for PRs with thousands of files and millions of lines. This Q&A explores the challenges, metrics, and solutions behind GitHub's performance improvements.
- What performance issues did GitHub face with large pull requests?
- What was the main goal of the new React-based experience?
- What metrics did they measure and improve?
- Why wasn't there a single solution to these performance problems?
- What are the three strategies GitHub used?
- How does focused optimization help medium and large PRs?
- What does graceful degradation mean for the largest PRs?
- How do foundational improvements benefit all PRs?
What performance issues did GitHub face with large pull requests?
When pull requests grew large—involving thousands of files and millions of lines—the Files changed tab became sluggish. Users experienced high memory usage, with the JavaScript heap exceeding 1 GB and DOM nodes surpassing 400,000 in extreme cases. Interactions like scrolling, clicking diffs, or using find-in-page felt laggy, and metrics like Interaction to Next Paint (INP) showed unacceptable latency. The overall experience quantified input lag that hindered code review. GitHub needed to address these bottlenecks for its largest PRs while maintaining speed for everyday use.
What was the main goal of the new React-based experience?
The primary goal was to ensure a consistently performant experience across all pull request sizes, with special attention to large PRs. GitHub invested in optimized rendering, reduced interaction latency, and lower memory consumption. The React redesign aimed to make the Files changed tab fast and responsive for the majority of reviews while preventing extreme cases from degrading usability. This meant prioritizing hard engineering problems like efficient diff-line components and intelligent rendering strategies.
What metrics did they measure and improve?
GitHub focused on several key performance metrics: JavaScript heap size (targeting reductions from >1 GB), DOM node count (cutting from over 400,000), and Interaction to Next Paint (INP) scores. INP measures responsiveness—how quickly a page reacts to user input like clicks or keypresses. High INP values indicated noticeable lag. After improvements, these metrics meaningfully improved, especially in large pull requests. The team also tracked rendering times and memory pressure across different PR sizes to validate their strategies.
Why wasn't there a single solution to these performance problems?
Because the problem varied by pull request complexity. No single technique could handle both tiny fixes and massive diffs without tradeoffs. Optimizations that preserve all features and native browser behaviors (like find-in-page) hit a ceiling for extreme cases. Conversely, aggressive mitigations (like full virtualization) could hinder everyday reviews where users expect instant interactivity. So GitHub adopted a layered approach with multiple targeted strategies, each designed for a specific range of PR size and complexity.
What are the three strategies GitHub used?
GitHub implemented three main strategies:
- Focused optimizations for diff-line components—making the primary diff experience efficient for most PRs.
- Graceful degradation with virtualization—for the largest PRs, limiting what is rendered to keep the interface usable.
- Foundational components and rendering improvements—investments that benefit every PR size, regardless of which mode a user encounters.
These tactics work together to balance performance and user expectations.
How does focused optimization help medium and large PRs?
By optimizing the core diff-line components, GitHub ensured that medium and large reviews stay fast without sacrificing expected behaviors. For example, native find-in-page (Ctrl+F) remains fully functional even while rendering many diff lines. This strategy uses efficient data structures and minimal re-renders. It handles the majority of pull requests (up to tens of thousands of lines) without triggering the heavier fallbacks. This approach keeps everyday reviews snappy and respects developer workflows.
What does graceful degradation mean for the largest PRs?
For the most extreme pull requests—those with hundreds of thousands of lines or more—GitHub employs virtualization. This technique renders only the visible portion of the diff plus a small buffer. As the user scrolls, new content replaces what scrolls off-screen. This dramatically reduces DOM node count and memory usage, preventing the browser from freezing. Features like find-in-page are adapted to work within a virtualized list. The experience prioritizes responsiveness and stability over showing every line at once, making huge PRs usable again.
How do foundational improvements benefit all PRs?
Investments in foundational components—like optimized React memoization, efficient diff algorithms, and better CSS—compound across every pull request size. These improvements reduce overhead in rendering, event handling, and state management. Even for small PRs, users see faster load times and smoother interactions. For large PRs, these foundations make the other strategies more effective. No matter which mode (optimized or virtualized) applies, every user gains from lower memory pressure and better performance.