Achieving Fast Diff Line Rendering: GitHub's Performance Overhaul for Pull Requests

Pull requests are central to GitHub's workflow, serving as the primary space where engineers review and discuss changes. With the platform handling everything from single-line fixes to massive changes spanning thousands of files and millions of lines, ensuring a consistently fast and responsive review experience is a critical challenge. GitHub recently shipped a new React-based experience for the Files changed tab, now the default for all users, with a primary goal of improving performance across the board—especially for large pull requests. This meant tackling hard problems such as optimized rendering, interaction latency, and memory consumption.

The Challenge of Large Pull Requests

For most users, the previous experience was already fast and responsive. However, when viewing extremely large pull requests, performance would noticeably decline. In the worst cases, the JavaScript heap could exceed 1 GB, DOM node counts surpassed 400,000, and page interactions became sluggish or even unusable. A key metric, Interaction to Next Paint (INP), scored above acceptable levels, meaning users could feel the input lag quantitatively. These issues made reviewing large PRs a frustrating experience, undermining productivity.

Achieving Fast Diff Line Rendering: GitHub's Performance Overhaul for Pull Requests — Source: github.blog

A Multi-Strategy Approach

As the team investigated performance issues, they quickly realized there would be no single silver bullet. Techniques that preserve every feature and browser-native behavior can hit a ceiling at the extreme end, while mitigations designed to handle the worst-case scenario often trade off the everyday experience. Instead, GitHub adopted a set of strategies tailored to different pull request sizes and complexities. These strategies focused on three themes:

Focused optimizations for diff-line components—making the primary diff experience efficient for most pull requests, keeping medium and large reviews fast without sacrificing expected behavior like native find-in-page.
Graceful degradation with virtualization—keeping the experience usable for the largest pull requests by limiting what is rendered at any moment, prioritizing responsiveness and stability.
Investment in foundational components and rendering improvements—these compound across every pull request size, regardless of which mode a user ends up in.

Let's explore each strategy in detail. Jump to optimized diff components, jump to virtualization, or jump to foundational improvements.

Focused Optimizations for Diff-Line Components

The core diff view—the lines showing additions, deletions, and unchanged context—forms the heart of the review experience. To keep it performant for the majority of pull requests, GitHub made several targeted improvements to diff-line components. They leveraged React memoization to avoid unnecessary re-renders, ensuring that only components with changed props update. They also optimized the DOM structure by reducing nested elements and using more efficient CSS selectors. These changes allowed the diff view to handle medium and large PRs smoothly while preserving native browser features like find-in-page, which relies on the DOM being fully rendered.

Graceful Degradation with Virtualization

For the largest pull requests—those with thousands of files or millions of lines—simply rendering everything at once is not viable. GitHub implemented a virtualization strategy that limits the number of diff lines rendered at any given time. Instead of building the full diff in the DOM, the viewport shows only the visible area plus a small buffer around it. As the user scrolls, components are dynamically added or removed. This approach dramatically reduces memory pressure and avoids the extreme heap sizes and DOM node counts seen previously. While virtualization may slightly alter the scrolling experience for extremely large PRs, it ensures that the page remains responsive and that interactions like clicking, selecting, or commenting are not delayed.

Investing in Foundational Components and Rendering

Beyond the diff view itself, GitHub invested in foundational improvements that benefit all pull request sizes. They updated core UI components to use more efficient state management and reduced the overhead of event listeners. Performance profiling guided them to optimize common code paths, such as syntax highlighting and line numbering. They also adopted modern React features like concurrent rendering to prioritize user input over background updates. These cross-cutting changes compound, making every interaction faster—from loading a small PR to navigating within a large one.

Impact and Results

After deploying these improvements, GitHub saw meaningful gains in key performance metrics. For large pull requests, the JavaScript heap dropped from over 1 GB to manageable levels, and DOM node counts fell well below 400,000. INP scores improved significantly, moving into the acceptable range—users no longer felt input lag. The changes also reduced memory pressure, leading to fewer browser crashes and smoother scrolling. While the experience for small and medium PRs remained fast, the most dramatic improvements came for the extreme cases that previously struggled.

Conclusion

GitHub's approach to diff line performance shows that solving performance at scale requires a combination of targeted optimizations and graceful fallbacks. By understanding the different needs based on pull request size and complexity, they delivered a solution that balances feature completeness with responsiveness. The result is a Files changed tab that works well for the 99% of reviews while still handling the 1% that are unusually large. This multi-pronged strategy serves as a model for any team dealing with rendering large amounts of data in the browser.