💬 Your Product Feedback Has Been Submitted 🎉
Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.
Here's what you can expect moving forward ⏩
- Your input will be carefully reviewed and cataloged by members of our product teams.
- Due to the high volume of submissions, we may not always be able to provide individual responses.
- Rest assured, your feedback will help chart our course for product improvements.
- Other users may engage with your post, sharing their own perspectives or experiences.
- GitHub staff may reach out for further clarification or insight.
- We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.
Where to look to see what's shipping 👀
- Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
- Explore our Product Roadmap, which details upcoming major releases and initiatives.
What you can do in the meantime 💻
- Upvote and comment on other user feedback Discussions that resonate with you.
- Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.
As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.
Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐
13 replies
If it's possible, I think that Chrome or another seperately installed browser would perform better
I'd rather migrate my entire life to GitLab before I install Chrome again
A change was just deployed that should help. Try reloading the page and let us know.
@willsmythe Have noticed improvements in the label interface within the last hour. It's still pretty slow, but it's now usable again.
I was also running into this — trying to specify Reviewers on a new Pull Request was the worst. But this seems to have magically gotten fixed over the last week. So thanks!
This is a change in the CSS of GitHub, which unfortunately hits a specific performance issue of Safari.
Having the same issue, where GitHub got slower and slower in safari.
For bigger PRs I can't edit anything or press on any buttons. Seems like such a big page breaks something?
I just tried it from a current branch to a really old version of one of my projects, and there are 403 commits and 855 changed files. In such a case the GitHub UI becomes completely unusable.
I also disabled all content blockers and plugins for GitHub, didn't change anything :/
(using an M3 Pro Mac with 18GB Ram)
0 replies
Same here.
Even small PRs I can't do anything. Adding reviewers, adding labels, etc... every action on the page takes many seconds. The page often locks up as well.
This wasnt an issue a few weeks ago.
3 replies
What version of Safari are you using?
Version 18.6 (20621.3.11.11.3) for me
A change was just deployed in the last hour that should help. Try reloading the page and let us know if it helps.
Note: yesterday I was able to repro the exact problem with the labels selector on the same version of Safari, but I'm no longer experience the delay.
Same - I don't know what's driving the engineering behind this, but it is embarrassing. It's just getting slower and slower for no appreciable benefit.
14 replies
What version of Safari are you using?
@willsmythe, I've tried the following Safari versions, same issues present in all:
- Version 18.6 (20621.3.11.11.3) - MacOS 18.6.1 Safari
- Version 26.0 (21622.1.22.11.12) - MacOS 26 Beta 8 Safari
- Release 226 (WebKit 21623.1.3.19.1) - Safari Tech Preview
For me the issue is reproduced just by loading GH dashboard and hit / and starting to type in the search bar, the whole UI slows to a crawl.
@willsmythe This is not a regression in Safari. This is a change in the CSS of GitHub, which unfortunately hits a specific performance issue of Safari. You can contact me directly if you want.
I gave information on https://github.com/orgs/community/discussions/170922
The two main perf bugs from WebKit have been fixed this week, but they will not be available until the next release. It would be great if GitHub frontend teams could mitigate the issue in the meantime. Also, do not hesitate to contact me for the next release if you identify perf issues before releasing to the public. That would be great to be able to better plan in advance for this kind of issue.
@willsmythe This is not a regression in Safari. This is a change in the CSS of GitHub, which unfortunately hits a specific performance issue of Safari.
Thanks for looking into this, @karlcow (and for the fixes you made).
The team identified a change that shipped last week (to a component that exists on most GitHub.com pages but is not visible by default) involving :has() selector which appears to be the cause of the regression. The fix was to switch from CSS-based conditional styling to JavaScript (this rolled out about 1 PM ET today).
Let us know if you're still seeing this problem after doing a hard reload of the page(s).
I can confirm the issue is fixed for me
@willsmythe issue is fixed. Confirmed. Thanks a lot. Do not hesitate to contact the WebKit team (me through github or by email) in the future for new things you would love to deploy but have perf impact for Safari.
(I'm pretty sure mozilla webcompat team would love it too if a feature affects Firefox/Gecko in the future. @denschub for example )
Thanks a lot for the team at GitHub which implemented the quick solution.
And once the WebKit fixes have been deployed to Safari, we could together try to test and release your CSS changes. So you are not tied by this fix.
I'm pretty sure mozilla webcompat team would love it too if a feature affects Firefox/Gecko in the future. @denschub for example
Absolutely. My work email isn't hard to find, but I also always react to GitHub pings and will make sure the right Mozillian is looking at things.
Thanks again for your support on this, @karlcow. Thanks for the introduction (hi, @denschub).
Something that caused a delay in us detecting this is the lack of INP data for Safari (due to lack of PerformanceEventTiming support). Is there an existing discussion we can chime in on? In the meantime, any recommendations on alternatives we can use so we have some level of visibility to these kinds of regressions in the future?
Same problem over here. Renders GitHub completely useless. Nothing works. Totally frozen.
4 replies
Hope So Github will Resolve it soon
A fix has been deployed (see comment above.). Let us know if you're still experiencing freezes after reloading.
I don't think it's fixed @willsmythe
I cannot share an example PR because it's a private repo.
But a relatively simple PR with +1k -600 LOC and 100 files stutters like crazy.
Cannot scroll. Cannot see anything. The 6 images changed end up showing "Unable to render code block".
If I scroll just a little everything goes black. It's totally unusable. I cannot even approve a PR.
Chrome opens this PR no problem.
I am also still having problems with the UI locking after the fix - particularly when handling pull requests, even if the code is not rendering and I am just writing comments.
AFAICT this extends to all API actions triggered by the UI. Case in point, I just went to subscribe to this issue in Safari, and it took more than 20 seconds before the button state switched to "Unsubscribe". I'm now writing this comment in Chrome... 👎
0 replies
Our team has noticed this as well, very sluggish UI in general. Especially noticeable on pull requests and autocomplete boxes like / shortcut and command palette.
0 replies
It can take up to 10 seconds for this page to load on an M3 Ultra:
When I trace it, sometimes a long chunk of time is spent waiting for a network resource called "collect" that hangs the UI.
This is a trace with the Safari Tech Preview, which does not show that network hang, but it is just as slow:
The above on Safari preview, takes about 5 seconds for the first page display, it does something else, and it is still a bit hiccupy for a few more seconds.
At second 10, I started a "two page downs", and you can see it takes it about 2 seconds to render two page downs.
0 replies
It only took about a year to go from visibly slow but usable to now annoying and completely unusable. I had to install a 3rd-party app on my Mac to automatically open all GitHub URLs in Chrome. ¯_(ツ)_/¯
4 replies
a "protocol url router"? Sounds interesting, mind sharing?
0 replies
For folks looking for a temporary workaround to add labels in Safari: After creating the issue/PR go to the Issues/Pull requests tab, select the checkbox of the one you want to add a label to and use the Labels dropdown on the table header. This works a bit better.
0 replies
after stumbling upon yet another page struggling to render i decided to check the web inspector and it looks like at least some of the performance problems (in code browser) are caused by excessive compositing
github
vs codeberg / forgejo
maybe there's some deeper reason but github right now is literally the only website i have performance problems with in safari so in a way it's somewhat impressive
2 replies
Actually, the issue is simple. Safari runs transform requests on the GPU only.
And Github positions every text line using transform: translateY, forcing Safari to create thousands of layers.
Chrome only creates layers when transforms are animated or change though JavaScript. That is an optimisation that WebKit is currently missing.
Workaround is simple.
Pause JavaScript execution (the page does lazy loading, that resets the workaround) and then run
[...document.querySelectorAll('[style*="translateY("]')].forEach(e => {e.style.position = 'relative'; e.style.top = e.style.transform.match(/translateY\(([^)]+)\)/)[1]; e.style.transform = 'none'})
It's not perfectly positioned but the page is fast afterwards.
I'm currently using no Javascript, slow speed 4G, unknown tablet and Nord Double VPN.
Does this happen with the New Files Changed experience only, or does it happen no matter what you have that set to? It's a preview feature you can turn on and off by going to "Feature Preview" when you click your avatar icon.
3 replies
It happens for me in both experiences.
A fix landed a few hours ago that should improve performance on Safari across all pages, including the new and "classic" Files Changed pages. Give it a try and let us know.
As someone who writes bugs for a living I'm careful to complain. That said, this has become a real pain point for me, personally.
It's not uncommon for me to do the following things opening a PR:
- Changing the base branch
- Writing the description
- Toggling the create button between draft and ready to review
- Assigning reviewers
- Assigning myself
I do this several times a day and within the last few weeks the page will lock up every time. Sometimes I'll refresh the browser and even that takes a while to perform. Historically I've had no issues with this in Safari.
0 replies
1 reply
This is off-topic, please make another thread for non-safari issues.
I can confirm, that nothing has been fixed so far.
Opening a merely regular PR results into a header being rendered, while rest of it remains as a white page. Interesting, but some of the components are available, because I see a scrollbar, but page is not rendered. It takes a while to get to a content.
PR review with selection of a particular file is a madness and takes ages. PR size is, let's say, around 500 additions, 300 deletions, 20 files modified. Same happens on a really small PRs. Opened just a second ago a PR with only 8 additions and 8 removals, but around 12 comments. Header and part of content got rendered while rest of the page was blank and I had to wait.
Safari 18.6 (20621.3.11.11.3).
Labels performance, though, improved.
2 replies
Yeah, I thought I was tripping, but GitHub on Safari is extremely slow. Especially, if you open files with 50+ file changes.
Especially the diff view is absolutely unusable for larger diffs. Every comment keystroke takes seconds.
I was hoping that Safari Version 26.1 (20622.2.11.119.1) (which IIUC was released today) would be better, but it's still 30+ seconds for me to load github (for my primary work project, which has a ton of pull requests by a ton of authors), then click pull requests, then click my username, and then wait for the resulting page to actually load. In Firefox that's less than 10 seconds, and every step along the way feels much snappier.
0 replies
More fixes are coming to Safari through WebKit. Another recent fix (10 hours ago).
WebKit/WebKit#52781
Each time you identify something not working correctly for performances, please file a bug report with typing applefeedback://. This will create a feedback report with performance traces that will help determine what you are hitting as a perf bottleneck. You can share the FB with me, I will move it to the appropriate team. For other types of issues related to WebKit, you can always open a bug on https://bugs.webkit.org/
0 replies
This is still broken, running Linux with chromium. Slow to do just about anything and hangs on refresh.
0 replies
This is NOT a Safari issue. It's a GITHUB issue. I don't even use Macs, and this site is completely broken. I can't even star a repo anymore, let alone the sad performance situation. Just another rerun of everything M$ touches, they turn it to garbage. This all happened at once, after what must have been a 'site upgrade'. And of course there's nobody from Github on here even saying anything about it.
0 replies
Can confirm, had to move to Chrome specifically for github.
On Safari it is slow at best on small pull requests and unusable at worst when pr is at least 5 files and have active discussion/copilot working/checks etc;
M1 Pro / 32g RAM / macOS 15.5 / Safari 18.5
0 replies
I'm having the same issue. Github is unusable on Safari. Had to switch to Firefox, which is frustrating.
0 replies
Same here. Safari 26.1 on Sequoia. Noticed it on one other website that actually freezes in Safari but works in Chrome.
0 replies
The issue wasnt resolved. prs literally not loading on safari. Please fix
0 replies
Not resolved when I take a pr review comment.
0 replies
Review pages are unusably slow once you get even a few comments. We're not talking about big PRs with large diffs, these are things that worked fine back in 2010.
0 replies
I have a PR that is 35 comments long (aka. short) and it took 30 seconds to load on Safari 26.1 on MacOS 15.7.2
The same PR takes about 2 seconds to load in FireFox.
The "improvement" that I've seen is that one screen's height worth of the Github Conversation loads within about 5-7 seconds, but the rest of the page that is scrollable is completely blank for the next 20 seconds.
The PR (52 files, +2000, -1200) takes about 5 seconds to load the first screen's height, then another 10-15 to get the rest of the PR.
I call it an improvement, because last week it was 1-2 minutes with nothing showing.
I know this is a rendering/CSS issue, but worth mentioning that I'm on a 1GB up/1GB down, wired connection. My workaround is to load a bunch of the PRs I want to work on (conversations and diffs) in separate tabs, and hope they don't need to be reloaded.
0 replies
Github became the worst web app that I use day to day. This is feels extremely sad and frustrating because years ago GH was the best app, others felt slower (or on par)
It is so slow that I open a PR tab and just go do some other stuff, because I know it will take minutes for the page to render 🤯
Safari 18.6 (20621.3.11.11.3)
Macbook M1 Pro
0 replies
Medium+ sized PRs seem unbearably slow on Safari on M4 MBP.
0 replies
It was good for a while, but now PR reviews are unusable again
0 replies