Bad Performance in Pull Request File Tree

[joshuambg]

Select Topic Area

Bug

Body

This is a topic that has been documented in the community postings. I can't find anyone from GitHub that answers.
#10830
#33663

Large PRs with lots of files crash GitHub PRs. This is a real problem that needs to get on GitHub's planning board. Use the latest version of any browser. The problem is with the GitHub feature.

• Create a PR in GitHub with lots of files
• Try using the PR UI and PR file tree

Expected

• Fast and responsive UI

Result

• Browser tab can crash
• Browser freezes
• Scrolling clunky
• Chrome warns about slow unresponsive page

[borbudak-jadbio]

Any updates on this?

Even with only a couple hundred changed files Github code review can be extremely slow, to the point of it being almost unusable. The file tree search feature is also unusable. It takes ~10 seconds just for the cursor to appear once clicked, and typing/searching is even worse.

[themanciraptor]

As a workaround, you can use Firefox. Using Firefox, my old intel mac (6c, 16GB ram) renders large pr's pretty much lag-free while a few of my coworkers' apple M2's running chrome are freezing and lagging like crazy.

[Wilma07]

Have you reported the issue to GitHub Support, and if so, have they provided any updates or suggestions?

[CoenWarmer]

If you have more than 3k changes the UI just informs you it won't show you the remainder. C'mon Github, can't we do better than that?

[EdmondsZinc]

Still nothing on this one? How is Chrome being left out here?
I can confirm FireFox does appear to be a valid workaround. I just tested my PR and 2000 files is unusable in chrome but works fine in Firefox... womp.
You can't even expand the file tree width to see longer file names... pretty sad.

[alexandru-pap-osf]

Firefox works. Currently i have 2k files in a single PR, and I could open it so fast in Firefox.
Thanks for sharing the info.

[andreieftimie]

I used to switch from Safari to Chrome for a small performance boost on huge PR's.

Today Chrome is also choking. I am literally unable to review large PR's :(

[udlose]

I am also having this problem. We had a refactor that could only be done in a single PR w/o breaking the code in the repo. We had ~2,200 files changed in the PR. Why isn't there some sort of paging that exists?

[mpiggott]

Even a couple hundred files renders the UI extremely slow - filtering a tree with 200 entries shouldn't require locking up the browser for 10-seconds.

[crobinson-expl]

I'm having the same issue over the last week. A PR with just 307 files has taken me days to go through. Just marking a file as viewed takes around 5 seconds. If I have to click to load the diff (on files down past some file count threshold, even though they are small), then that's another 8-10 seconds. I have reviewed much larger PRs in the past that have not had these performance issues.

[george-of-croton]

i agree. I have an 800 hundred liner im trying to review and im getting multi-second lag on text input when writing review comments.

[jeremy-hunter]

For whatever reason Firefox handles reviewing a 3000 file PR just fine while chrome and safari are unusable.
Chrome says the memory heap for the PR on first load is 66MB, Firefox has the memory heap at ~450MB on load - maybe it's just a browser trying to conserve memory

[crobinson-expl]

A team member who uses the Brave browser let me know that they aren't experiencing the same issues, so I tried it out. Marking files as "viewed" is much snappier, but the time to being able to type in anything on a code comment seems about the same.

I noticed in the browser developer tools network tab that Edge makes many posts to https://api.github.com/_private/browser/stats whereas Brave doesn't do this (Brave left, Edge right):

I opened a ticket with GitHub Support on Friday but haven't received any update yet.

[crobinson-expl]

@jeremy-hunter Thanks for the Firefox info! I tried it there and it works great, even better than it does in Brave. Everything is responsive and usable like it used to be in Edge.

[milivojsa]

I can confirm that Firefox works great. Here's my pull request:

Chrome was stuck when I switched to the Files changed section while Firefox works like a charm.

I compared memory usage. Chrome comes up to 2GB, while Firefox is most of the time 0.7 - 1GB on the same page.

[zgavin1]

I have a pretty mild PR compared to some of these examples (1200 files, 1700 changes) and Chrome outright crashes, and firefox seems barely any better if at all.

[Blafasel3]

Feels like this gets worse with every Github update. Please fix this, this has the potential to make people move to other tools.

[ValentinGurkov]

I've been using mostly Vivaldi except when I need to review PRs because it lags there. For viewing PRs I use Chrome but it's lagging now there too.

The PR is not that big, 3,700 additions, 1800 removals. I've worked with much larger PRs without lag in the past.

[Sinarab]

I'm having the same issue here using Chrome. I tried using Firefox as a temporary solution to this lag situation, and it works only partially. Marking items as 'viewed' is fine, but searching for comments through the 'jump to conversation' feature doesn't work on both crashing the app.

Hope someone can solve this issue asap. 🤞

[Jakoban2411]

Still a huge issue. I've been using Brave and for PRs with >1000 files, despite filtering out to have only ~100 files, there's a huge lag, the Ui is unresponsive, Brave keeps asking me to kill the tab.

[paul-vd]

I can also confirm tested today with a PR of 2600+ it was snappy on firebox, but really slow on chrome.

on FF the only thing a little slow is when adding a comment to a line of code, but still much better than chrome.

[vmendiola]

Just experienced this today with a PR having ~800 files changed. Sadly, it is unbearable to work with.

[ChristianOellers]

Having the same issue in MacOS Chrome 131. For about 500 changed files, it's impossible to open even a Pull Request. Plus, just opening one, I would not expect or need an immediate diff to be visible.

Some ideas for an optimized UI:

1. Can't we just remove the auto-preview of the diff and make it opt-in or available on toggle?
2. If the displaying logic is inverted, I can also imagine the 'filter by filetype' tool, that really optimizes the performance, to work in the opposite way -> Toggle on what to see, not off what to remove

This really would need a change – The web UI is completely useless for large changes. Given the logical structuring of the project, making smaller Pull Requests is not an option, and large changes are a common requirement.

🙏

[JulianKingman]

376-file PR, mutiple second delay in Safari. Firefox is reasonably snappy, but I still get blank spots when scrolling where it takes it a minute to catch up. Also I don't think it's unreasonable to expect all the file names to load immediately and be searchable, regardless of the size. We're not talking about that much data here, are we? Even a big PR is probably in the 10's of megabytes...

[zcoffin86]

Same issue here. 54 Files changed, +640 -621. Chrome is unbearably slow, but Firefox has no issue. Looking forward to Chrome being usable again.

[henrahmagix]

I'm seeing a 2-3 second delay in Safari 18.1.1 on macOS 15.1.1, when clicking a line to add a comment:

• with the network panel open, I click the blue plus button and it's 1-2 seconds until a request to /review_comment/suggestion_button is made, which returns quite quickly with the html for the suggestion button: Add a suggestion, <Ctrl+g>
• then it's another 1-2 seconds to render the comment box

And it's the same total delay when clicking cancel on the comment box.

This is on a PR with 19 files changed, 465 lines added, 272 lines removed, so not very big at all.

I've tried quitting and reopening Safari, I've tried restarting, and I've tried refreshing without the cache: it's still super slow 😭

[henrahmagix]

I'm also seeing a 2 second delay when clicking "Start a review" until it becomes disabled, and then another 2-3 seconds until it submits the comment. It literally feels like it's running on a setTimeout(..., 1000) call or something 🤔

[dlohvinov]

Same here, in Safari, Chrome, and Firefox too. 🥲

[dungkhoai]

same, all repo

[ppamorim]

I am unable to create PRs due to this issue, we have automated actions to modify source code and those apply massive changes (think of a linter). I tried on both Safari and Firefox and both are unable to let me open the PR. The page freezes. I will need to force merge the PR instead.

[bmanturner]

Unable to open a pull request at all anymore. Before it took a few tries, but now the entire page just freezes, doesn't matter what browser.

[TKTang1]

When reviewing a large PR, GitHub is massively slow and unusable. Azure DevOps surprisingly has a UI/UX that's actually performantly flawless when reviewing a PR of identicial size.

[nbolton]

Above 50 files changed the UI becomes unusable. How about paging the results instead of loading more than the browser can handle?

Files changed: 681
Browser: Chrome (with extensions)

[nbolton]

I think I have "solved" this. Using a fresh Firefox with no extensions, it is fairly responsive.

[zcoffin86]

The issue persists for me when running chrome with --disable-extensions.

[nbolton]

Oh, what about if you use Firefox? Would be good to narrow this down if browser specific.

[ValentinGurkov]

I've noticed that my NordPass browser extension can also affect the performance of the PR page.

[nbolton]

Ah, browser extensions. I should have realised.

[zcoffin86]

The issue persists for me when running chrome with --disable-extensions.

[nbolton]

Oh, what about if you use Firefox? Would be good to narrow this down if browser specific.

[DanielGumpHTT]

Safari 18.2 on a Macbook Pro M1 hangs up for me when creating new PRs that contain only a couple hundred files changed. This started about a week ago.

[nbolton]

What happens if you use Firefox?

[nbolton]

@joshuambg Based on all discussiuons so far, I suspect this is a Chrome-specific issue. Everyone I asked so far finds that Firefox fixes the problem. If you agree, please rename this issue to:

"Bad performance in Pull Request file tab on Chrome"

I believe this will help GitHub devs understand why the issue occurs and may help them fix it. It's likely most of the dev team uses Firefox, and so they don't see the issue very often.

[OddMathisenNOV]

This is not only affecting the Chrome browser, but seemingly any Chromium (Browser Codebase) related browsers.

[nbolton]

Yes, I should have said Chrome/Chromium. I also hear Safari is quite bad too. Someone else also mentioned Firefox is better but not perfect (though I don't think they disabled their add-ons).

[AntonMikhailovAH]

On Chrome issue isn't as bad as on Safari

[nbolton]

Workaround

Temporary solution until GitHub fixes this: Use Firefox with add-ons disabled.

Many people have reported that Firefox (with add-ons disabled) has far better performance on the PR file tab compared to Chrome, Chromium and Safari. Many say that disabling extensions in Chrome doesn't seem to help (I can confirm this).

Re-post from: #33663

[ppamorim]

@joshuambg This gets bad when the Github compare screen defaults to the default repository branch, if you are working in the development branch and you try to open a PR, and if your development is massively different from main, your pre-PR screen will never finish loading.