💬 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. ⭐
14 replies
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 same issues in Chrome!! :(
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'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
I'm seeing the issue in several places, but most frequently when clicking on issues in a filtered issue list. Interestingly, if I open the issues in a new tab the slowness doesn't seem to occur.
0 replies
A new issue has recently developed, which is that now it happens that on occasion, when I attempt to view or reload a tab on GitHub, that all I get is a black page. I can clear the cache, do a full reload, but nothing ever loads.
The only way to get around this is to open the page in a new tab or session, where the page loads fine.
This is such a long running and complicated issue; it feels more like watching a human disease slowly cause new and wild symptoms. To those at GitHub who actually want this site to be usable on Safari, my heart goes out to you. This used to be such a great, performant, and usable system.
0 replies
- The width of turbo-progress-bar is adjusted constantly during navigation, triggering reflows. Meanwhile, loading content does so. This blocks tasks on the main thread, like fetching data and processing interaction logic, making the whole website insanely slow.
- The syntax highlighting results in enormous elements, which makes scrolling unresponsive, especially when a pull request or file contains codes with thousands of lines.
- On mobile devices, the document's width blows up on landing, and then becomes normal. The layout shift is annoying and makes users wait longer for loading.
0 replies
0 replies
0 replies
I really do not know how the experience in Safari is this bad. Yes, I know the different rendering engines have limitations but Safari having this level of an issue is unacceptable.
0 replies