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.

[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.

[pazoozooCH]

+1

This is in a desolate state for even medium sized PRs. Interestingly, it doesn't help much if I filter out the already Viewed files. Somehow it remains slow, even if 90% of the files are not shown. Can't believe this has been an issue for over 2 years now... 🤯

[kevinfiol]

In the last few years, Github has really shat the bed on multiple features, either actively making them less useful or less performant. This one is unbelievably embarrassing; I can't believe this is unfixed almost 3 years later.

[ashton-seek]

Please look into this.

[bitaccesscomau]

This is absolutely pathetic.

[jonholdsworth]

Hello. I'm afraid this is still happening in April 2025.

[LucasMontoya4]

Why is there no quick workaround to this? And why isn't this problem more common? Surely every single person with a GitHub repo that has large PRs is having the same problem!?

[yuan-kuan]

Firefox is the workaround. I just refreshed my Firefox just for this and confirmed this workaround is still valid after a year. Safari is simply unusable.

[pyrtsa]

We're also getting bitten by this issue. The PR doesn't even need to be very big: you only need some 100 removed files in one PR for the checkbox to take 3+ seconds to click in macOS Safari; see screen recording further below.

I added some breakpoints around in Safari Web Inspector and found two lines modifying the DOM tree to be exceptionally slow, taking about a second for the debugger to step over to the next line:

• setting checkbox.disabled = true on https://github.githubassets.com/assets/app/assets/modules/github/pulls/toggle-user-reviewed-file.ts line 33, and
• replacing the form target.replaceWith(response.html) on line 54.

Maybe the DOM tree would need some pruning or optimisation?

---

toggle-user-reviewed-file.mov

[marianhlavac]

While I hate to suggest this, I recommend contacting GitHub customer support directly about this issue, since it's clear they don't read the community discussions. Everyone experiencing this problem should reach out. Support will likely respond with a template message saying they don’t have an ETA and that they understand the reply isn’t ideal. Still, it’s worth expressing your dissatisfaction—especially if you're a paying customer. Be sure to emphasize that. Unfortunately, there aren’t many other options. Well you can always leave GitHub, but we all know that it's easy to say this, but hard to execute.

[msw-kialo]

I would suspect/hope they will link to github/roadmap#1102; if the roadmap is up-to-date this issue should be at least soften within the next 2 months.

[embostan]

Every change they made in the past years made performance worse.

[GoodPie]

Once or twice a year, I have to deal with a large PR where lot's of files are removed or our icon package changes. Once or twice a year, I always end up in this same thread. It's disappointing that this hasn't been resolved yet.

[joshuambg]

Hiii. OP here. Pretty clear GitHub dev either does not read these threads or the message is not getting through.

If you happen to end up here, frustrated but motivated, one thing to try is contacting the dev team directly. Search for GitHub engineering titles on LinkedIn, then try to find their emails. If you or your company has a paid plan, then why are you even here? Complain through official channels.

Otherwise, the answer could very well be that GitHub management is fully aware of this problem. It would mean investing a lot of resources into refactoring the code for PRs. The answer is no and they know you're not switching platforms.

[saudsami]

Unbeleivable that this has still not been resolved.

[embostan]

I'm getting pretty convinced the GitHub teams do not use their own product

[udlose]

Maybe this will finally be fixed!

https://github.blog/changelog/2025-06-26-improved-pull-request-files-changed-experience-now-in-public-preview/

[importRyan]

Can't comment on perfection (used it only on macOS beta), but it remarkably improved performance reviewing a 8k line branch. Great! Sadly, "large diff" files are still defaulted to hidden and buried in between other more-than-screen-height diffs.

[vedmant]

Having the same problem, but I manage to do PR review in Firefox, it's slow but doesn't hang indefinitely like chrome.

[hasansino]

UI on chrome is very unstable at the moment.
Event now, when I am typing this message, I have crazy latency.