Pull request page become so slow when pr is big #33663
Replies: 40 comments 34 replies
-
|
Same problem here. Is horrible. this should be high priority |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
I've been using the |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Same here |
Beta Was this translation helpful? Give feedback.
-
|
This has gotten incredibly bad. |
Beta Was this translation helpful? Give feedback.
-
|
Above 50 files changed the UI becomes unusable. How about paging the results instead of loading more than the browser can handle? |
Beta Was this translation helpful? Give feedback.
-
|
Indeed, it is horribly slow |
Beta Was this translation helpful? Give feedback.
-
|
What browser? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
It is so bad, can't believe a company at GitHub's level is doing this |
Beta Was this translation helpful? Give feedback.
-
|
What browser? |
Beta Was this translation helpful? Give feedback.
-
Safari (Version 18.3 (20620.2.4.11.5)) on MacOS (Apple M4 Pro) for me. I also have no extensions installed. |
Beta Was this translation helpful? Give feedback.
-
|
Using Chrome on both Apple M4 Pro and Apple Intel 2019 on my end - same issue |
Beta Was this translation helpful? Give feedback.
-
|
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 ? |
Beta Was this translation helpful? Give feedback.
-
|
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: |
Beta Was this translation helpful? Give feedback.
-
|
It would be useful to know if you also see the issue in Firefox. |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
I think the GitHub devs only work in Firefox :p |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
@namse Please could you rename your discussion to: I think the issue is Chrome specific, and the GitHub devs should know that. |
Beta Was this translation helpful? Give feedback.
-
|
I'm experiencing the same issue on Safari, so it's not Chrome-specific issue |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
Good to know. Did you try running Safari without extensions?
How about when you run Firefox without add-ons? |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
Amazing! Great testing. I didn't try with Firefox add-ons but good to know that add-ons contribute to the problem.
Yep, same here. |
Beta Was this translation helpful? Give feedback.
-
WorkaroundTemporary 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). |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Great testing. I tested by opening that PR in Zen Browser (Firefox) also, and no noticeable lag; plugins: Browser Extensions List
(please feel free to tell me if any of these are garbage and/or malicious) |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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"... |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I look forward to this issue getting solved soon. |
Beta Was this translation helpful? Give feedback.
-
|
This is also an issue on Firefox. |
Beta Was this translation helpful? Give feedback.
-
|
Ditto on all the comments. Large PRs freeze most of our teams browsers. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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? 🤣 |
Beta Was this translation helpful? Give feedback.
-
|
This occurs on Firefox too, its unusable quite often for me. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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/ |
Beta Was this translation helpful? Give feedback.
-
|
Excellent write up. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
Using Helium Browser - Its chromium... and the pr page completely sucks |
Beta Was this translation helpful? Give feedback.
-
|
This is absolutely atrocious, I'm barely able to comment on a 12-file PR at this point (chromium browser). Is this really being ignored for that long? |
Beta Was this translation helpful? Give feedback.
-
|
Goes to show that most likely vast majority of GitHub's paying user base never does code reviews 🥲 |
Beta Was this translation helpful? Give feedback.
-
|
I experience loading spinners in the conversation tab. It's weird that elements that have already been rendered is struggling to display when i don't even interact with anything other than scrolling. |
Beta Was this translation helpful? Give feedback.
-
|
same, chrome macos m2 |
Beta Was this translation helpful? Give feedback.
-
|
We are experiencing incredibly slow load times on even medium sized PRs (30 some files). Often it's not even reviewable in Github and we end up looking at the git commits and reviewing the code in our IDEs. Review in Github has really gone down hill lately where its painful to use now. Using Safari on MacOS M2 machine. |
Beta Was this translation helpful? Give feedback.
-
|
This is horrible Github, this is all we use your platform for is code reviews. Can anyone recommend alternatives? |
Beta Was this translation helpful? Give feedback.
-
|
GitLab. |
Beta Was this translation helpful? Give feedback.
-
|
Cmon Github, the UI has become horrifically slow. This should be a top priority |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions