Pull request page become so slow when pr is big

[namse]

My company used to make a big PR for major update. It's very difficult to review or check comment with code in Pull request page because it become too laggy to review in page.

I hope it become optimized.

[robotocryptogame]

Same problem here. Is horrible. this should be high priority

[GoodPie]

I've been using the Github Pull Requests extension to get around this at the moment. With a relatively large feature pull request (~50 files touched), starting a comment causes the whole page to become unresponsive. With the extension, it seems to be a lot smoother.

[james-arawhanui]

Same here on Chrome. Switching to Firefox, and it's no longer an issue.

Here's my tampermonkey script to remind me to use firefox instead.

[hamzaseif13]

Same here

[royathan]

This has gotten incredibly bad.

[nbolton]

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

[timofeymukha]

Indeed, it is horribly slow

[nbolton]

What browser?

[royathan]

It's rough in Chrome (massive slowdowns) it's unusable in Safari (can't modify PR description text).

It's reproducible by opening a PR in a go project that vendors the dependencies, you'll get a massive million line pr.

[ujain6]

It is so bad, can't believe a company at GitHub's level is doing this

[nbolton]

What browser?

[MarkMurphy]

What browser?

Safari (Version 18.3 (20620.2.4.11.5)) on MacOS (Apple M4 Pro) for me. I also have no extensions installed.

[thomas-bc]

Using Chrome on both Apple M4 Pro and Apple Intel 2019 on my end - same issue

[thomas-bc]

Commenting to get more traction on this. Using Chrome - PRs aren't even that big (~50-80 files, not too many lines per file) and slowness becomes unbearable. It really does sound like paging could help ?

[jameswilliamknight]

Here's a few projects that may shed some light, in case it's react rerenders.

https://github.com/aidenybai/bippy

https://github.com/aidenybai/react-scan

I saw some magic using this:

https://www.npmjs.com/package/babel-plugin-react-compiler

[nbolton]

It would be useful to know if you also see the issue in Firefox.

[thomas-bc]

@nbolton ah that's interesting. The issue is almost gone when using Firefox. Still a little slow to load, but nothing unexpected for a large page like this. Chrome is incredibly painfully slow.

[nbolton]

I think the GitHub devs only work in Firefox :p

[danielschenk]

@jameswilliamknight Actually, this video shows that enabling the compiler can indeed fix this easily. GitHub is shown as a specific example of the rerender issue.

https://youtu.be/INLq9RPAYUw?si=ExVnt2mrQBvTMG4e

[nbolton]

@namse Please could you rename your discussion to:
"Pull request page become so slow on Chrome when PR is big"

I think the issue is Chrome specific, and the GitHub devs should know that.

[hamzasharuf]

I'm experiencing the same issue on Safari, so it's not Chrome-specific issue

[namse]

I fundamentally suspect that this issue arises because the GitHub PR viewer loads HTML tags for all files at once, overloading the browser. This can be seen as a problem similar to implementing infinite scroll. Not only GitHub but also other websites have experienced significant lag when displaying a large amount of content within a scrollable view.

There may be differing opinions on whether this optimization issue should be resolved by the browser or by the website (GitHub). However, one thing is clear—if GitHub wants to provide a better experience for its users, they should take the initiative. Therefore, I don't want to attribute this issue to a specific browser unless sufficient data can support that conclusion.

[nbolton]

I'm experiencing the same issue on Safari, so it's not Chrome-specific issue

Good to know. Did you try running Safari without extensions?
https://apple.stackexchange.com/questions/173647/is-it-possible-to-disable-safari-extensions-when-using-private-browsing

For me Chrome is worse than Firefox but Firefox also starts lagging when PRs get bigger

How about when you run Firefox without add-ons?
https://smallbusiness.chron.com/start-firefox-addons-59185.html

[Myloc-MEK]

It seems to be the plugin for my password manager that is causing the poor performance on Firefox, if i disable it and refresh the page it feels like it is working without lag on a PR with 300+ changed files, I will check later if it's the same when I have added multiple comments, the same can not be said for Chrome, I tried running Chrome in incognito mode and also in regular mode with all extensions disabled and it still had bad performance

[nbolton]

if i disable it and refresh the page it feels like it is working without lag on a PR with 300+ changed files

Amazing! Great testing. I didn't try with Firefox add-ons but good to know that add-ons contribute to the problem.

the same can not be said for Chrome, I tried running Chrome in incognito mode and also in regular mode with all extensions disabled and it still had bad performance

Yep, same here.

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

[eduardoldc]

Using Edge is also another possible solution, since I couldn't use Firefox I decided to try it and so far it is working much better than Safari/Chrome for me.

[peppy]

Here's an example of a PR that isn't even too large causing stalls of 2-10 seconds on Safari (Mac Studio, highest specs) when performing operations such as as scrolling (causing the header content to anchor to the top of the page), changing tabs, typing in a textbox, etc.

For tab changes, there is a large overhead of 5 second spent in JS (turbolinks). For scrolling, style invalidation is 2-4 seconds. Typing the first character in a textbox has a noticeable delay. Posting review feedback can sometimes get in a stuck state where the content is posted but the page never reports that it is, likely due to low performance.

Please github give this some attention.

[jameswilliamknight]

Great testing. I tested by opening that PR in Zen Browser (Firefox) also, and no noticeable lag; plugins:

Browser Extensions List

• Awesome Screenshot
• Bitwarden Password Manager
• Dark Reader
• Ghostery Tracker & Ad Blocker
• Momentum
• Obsidian Web Clipper
• React Developer Tools
• Reddit Enhancement Suite
• Redux DevTools
• SponsorBlock for YouTube
• Tampermonkey
• uBlock Origin

(please feel free to tell me if any of these are garbage and/or malicious)

[peppy]

Switching from "files changes" to "conversation" takes around 11 seconds, with the majority being CPU bound:

This is just one example, but currently the most egregious I can find.

[laurencee]

Looks like this has been fixed as it loads fine on firefox and chrome for me as of today at least (tested on Win10 & 11). It could of course be faster, but it doesn't freeze the whole browser.

I've tried some larger PRs too with 100 odd files, 5k lines changes, and it also loaded fine with a loading bar/progress for around 5 seconds rather than completely locking the browser.

Might have been a very recent fix.

[thomas-bc]

Safari and Chrome are the two largest browsers by market share, and by far. It does not sound right that such a large issue would be ignored by GitHub, and the only workaround is "use something else"...

[pabloarista]

it has def gotten worse this past year and in the last few days too. I thought something was wrong with my machine when another team member told me they have the same issue and only with GitHub. FF is a nice workaround because I need to be productive, but pretty sad that all of MS's products are just garbage lately. I haven't used windows as my main machine in years, I wonder how it is there too. I just remember they had some solid products when I was a windows dev. what is going on with this company? Too busy working on AI and neglecting everything else?

[peppy]

I believe things got to a new breaking point with the recent UI component changes that github rolled out, based on the sudden influx in complaints in this (and other threads), and also based on my personal perception – crossing the threshold of wanting to continue working on a pull request review.

[HanMoeHtet]

I look forward to this issue getting solved soon.
Please forgive my bad language in the previous comment as I was stressed and losing my temper while writing it.

[bhagdave]

This is also an issue on Firefox.

[bene-tyler]

Ditto on all the comments. Large PRs freeze most of our teams browsers.

[Prasundas99]

20 File changes is also not showing on any Chromium browsers

[njfamirm]

still have issue, if pr is very large, 100 files and more

[Jgordon-pencilwrench]

Adding fuel to the fire. The UI is approaching unusable. I'm on the latest Safari/MacOS.

[thomas-bc]

It makes no sense to me that GitHub would not even acknowledge this and at least pretend to look into it.

[Prasundas99]

They are too busy working with AI, doing vibe coding

[damonearl]

I am constantly crashing in Safari while doing reviews, GitHub needs to fix this it's clearly getting worse overtime.

[udlose]

I'm hoping this release finally resolves this issue! https://github.blog/changelog/2025-06-26-improved-pull-request-files-changed-experience-now-in-public-preview/

[minoesteban]

Tried it just now by enable it via Feature Preview (Safari, latest version) - improves the experience by a lot

[peppy]

Can also confirm that things are slightly better with the new version. There's still issues but largely alleviated to the point it's no longer frustrating.

[mariczne]

No wonder things seem better:

Warning
Only the first 300 files are currently being shown. To see more, switch back to the classic page.

[peppy]

We were seeing issues with far less than 300 files, and those cases are looking much better.

[themightyoarfish]

For me this happens even with <40 files, none of which are particularly big. I don't know if this is a firefox browser issue yet, but it's pretty much unusable for anything but really small PRs.

[malekelkssas]

The issue is even worse when using the Edge browser.

[Celtian]

This is so bad. Show us that React is better than Angular. IMHO github should be the proof that React is useful for large scale apps, but it is not.

[znorris]

Very slow, freezes my Windows machine when using the PR review site. Resizing the window is a sure-fire way to freeze my system now.

[SAGV]

Ohhh, we've switched to Github from Gitlab for our corporate repos and… wow, so hard to review PRs. The page is literally dying on us when using Arc browser (a fresh fork of chrome).

Come on, Github, you are a huge company! How do you even manage to review your own PRs? 🤣

[themightyoarfish]

This occurs on Firefox too, its unusable quite often for me.

[crash83k]

I highly doubt this would be an issue if Microsoft hadn't bought GitHub. It's been down hill since.

What's even crazier to me is that this issue is going on 3 years now, and being the LARGEST open source software repository source in the world, you'd imagine that there'd be more effort to try and fix this.

3 years next month since this discussion started!!!

It's obvious that, because browsers limit their resource usage, that the specs of your computer will not really matter here because GitHub is already hitting the resource maximums with just loading the page. face palm

I'm sure there's a lot of engineers trying to come up with work-arounds and bandaids, but this needs to be fixed at the root of the issue.

[sanamhub]

GitHub now really needs a fierce competitor (and something will come soon), because they're not fixing fundamental issues of software engineering and modern software.

https://yoyo-code.com/why-is-github-ui-getting-so-much-slower/

[crash83k]

Excellent write up.

[njfamirm]

I think a change happen in new pr mode, now Github use lazy render and don't render all files at same time, in pr with 90 files, with +4000 lines, the issue not exists

[eduardoldc]

Last couple weeks I did not have problems on Safari but now I would say it is even worse, to the point that I am not even able to approve a 30 files PR