The Github website is extremely slow on Safari

[ghugues]

Select Topic Area

Bug

Body

Over the past few months, Github has been getting slower and slower on Safari. It has now reached a point where it is unusable.

Displaying any pull request with more than a thousand lines changed or even browsing any file with a thousand or more lines of code is fully broken.

What happens:

• In Activity Monitor, the rendering process is running at 100%.
• Rendering the page is so slow, Safari displays blank space when scrolling up and down.
• Any interactive features like search is so slow it doesn't work.
• Pull request review is extremely painful (scrolling back and forth is impossible to do quickly, posting comments is extremely slow, even checking the "Viewed" checkbox sometimes takes several seconds, etc.).

I have a 16-inch MacBook Pro with a 16-cores Apple M4 Max and 48GB of RAM, using it plugged-in with performance mode enabled. It's one of the most powerful laptops on the market today. Github is the only website I know that doesn't run on it.

This is Safari specific, Google Chrome on the same machine performs way better (although it still struggles with very large pull requests). I'm using Safari 18.6 (20621.3.11.11.3) on macOS Sequoia 15.6 with no extensions installed.

[github-actions[bot]]

💬 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. ⭐

[rhysm94]

If it's possible, I think that Chrome or another seperately installed browser would perform better

That's not a solution, at all. Not least because iOS browsers are all WebKit.

[neon-sunset]

If it's possible, I think that Chrome or another seperately installed browser would perform better

chrome monoculture must stop, please do not suggest this

[AlekSi]

[Evilscaught]

I used to believe in a diversity of software, now I my beliefs are void. Google is life, Google is love.

[davidmatter]

@willsmythe this issue seems to be only relevant if you're signed-in to GitHub. No issues for me in incognito mode. Also 18.6

[LeLunZ]

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)

[BrentMifsud]

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.

[willsmythe]

What version of Safari are you using?

[jasonkarns]

Version 18.6 (20621.3.11.11.3) for me

[plusplus]

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.

[plusplus]

Maybe copilot is rewriting it with no human reviews.

[mscuthbert]

The number of bugs going unfixed suggests that AI is not being the order-of-magnitude improvement that Github and other companies imply that it is.

(See also #167400)

[willsmythe]

What version of Safari are you using?

[wavded]

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

[karlcow]

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

[sospedra]

Same problem over here. Renders GitHub completely useless. Nothing works. Totally frozen.

[msheikhmsh-blip]

Hope So Github will Resolve it soon

[rjernst]

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

[wavded]

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.

[migueldeicaza]

It can take up to 10 seconds for this page to load on an M3 Ultra:

https://github.com/kg/runtime/blob/73fb0e3f00cff127e996b36c493949fa7b2c38e8/src/coreclr/vm/interpexec.cpp

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.

[shiltian]

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. ¯_(ツ)_/¯

[salzig]

a "protocol url router"? Sounds interesting, mind sharing?

[salzig]

I was curious and found https://github.com/johnste/finicky.

[shiltian]

Yes, something similar to that. I'm using https://sindresorhus.com/velja.

[jasonkarns]

I currently use Choosy, but now I’m curious to look at these others. https://choosy.app/

[karlcow]

This is probably related to some type or combinations of CSS selectors.
https://github.com/orgs/community/discussions/170922

[felixbarny]

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.

[vlad-ivanov-name]

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

[Nemo64]

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.

[naikrovek]

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.

[rhysm94]

It happens for me in both experiences.

[shiltian]

Both for me as well

[jasoncharnes]

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.

[pannous]

Better slow than not loading at all. E.g. https://github.com/pannous/hieros/wiki/1

"The wiki page took too long to render."

2600 characters in 10 seconds should be doable despite unicode?

[nightpool]

This is off-topic, please make another thread for non-safari issues.

[winston-riley-zocdoc]

Similar problem here, starting a few weeks ago, its effectively impossible to label PRs in safari.

[vinnymac]

I now use https://graphite.dev instead of GitHub because their UI works fine in Safari, they support stacked PRs, and many features GitHub does not, such as actually scrolling me to the comment I was linked to 😮

Might be a helpful workaround for anyone who uses Safari as their daily driver.

[superkuh]

And don't even think of trying to read the github website with a screen reader for accessibility for the visually impaired. If you don't run all javascript with a bleeding edge browser then there's no text to read at all. In this sense the github website has become extremely slow during the Microsoft ownership period: the text never shows up.

[adincebic]

I can confirm that accessing github with voiceover on Safari has gotten extremely slow.

[xoxorwr]

It's not just Safari, Github is slow, world class developpers can't be bothered to care about performance

Perhaps it's time to start shrinking your salaries, since money doesn't seem to translate to better software it seems

[drborges]

This may be related to this webkit bug I opened a few days ago. A fix has been released but I have not heard anything about a new Safari release yet.

[karlcow]

see https://github.com/orgs/community/discussions/170922

[bpavuk]

vibe-coded.
I'm on GitLab now.

[lukehefson]

I’m also seeing this slowdown quite a bit. For me it’s been noticeable on Safari for a long time, especially in PRs, but over the past few days the entire site feels sluggish as hell. Chrome is much better.

(For context: I was previously a PM at GitHub and often advocated for and discovered Safari bugs during my time there, so hopefully anyone on staff here who knows me will understand I’m not posting lightly!)

[rhysm94]

To be more explicit. It feels like a change was implemented in the last week that really tanked performance on Safari.

This lines up with my experience. Initially the new files experience seemed to improve things, but in the last week, I've noticed the changed files feature is unbelievably sluggish. I can barely scroll through more than a few hundred lines of change, and the page locks up.

[karlcow]

To be more explicit. It feels like a change was implemented in the last week that really tanked performance on Safari.

yes recent changes in GitHub UI have hit a bug in Safari with CSS selectors.
https://github.com/orgs/community/discussions/170922

[lukehefson]

Thanks @karlcow - good to know @WebKit are doing what you can too!

[lukehefson]

This lines up with my experience. Initially the new files experience seemed to improve things, but in the last week, I've noticed the changed files feature is unbelievably sluggish. I can barely scroll through more than a few hundred lines of change, and the page locks up.

Yeah it's definitely the files experience. But I've also noticed sluggishness all around the past week or so. For example: In any comment box, when you start to type something that autocompleted (like an @mention), the character rendering slows riiiiight doooooown.

[lukehefson]

When I worked at GitHub I know that there was scant testing of non-Chrome browsers. At the time we relied largely on GitHub employees who use Safari (like myself) to report oddities. I would hope that in 2025 GitHub is taking multi-browser testing a bit more seriously. But if it's not — at the very least I would like to think that there are more Safari users working at GitHub in 2025 who are internally pushing to get this resolved!

[rv-ragul]

I am also experiencing the similar rendering issue in safari

[canpoyrazoglu]

As a Safari-only user, I didn't know it was a problem only occurring on Safari. I'm not having problems on any other sites so it's probably GH.

What's more interesting is that one of the top sites used by programmers is not testing one of the most common tasks on the website with one of the most common browsers.

Hope it gets fixed soon. Any large PRs is unworkable with Safari.

[uson1x]

Wow I did not know this problem was only in safari. I assumed GitHub UI is just super slow and nobody cared.
And it has been like that for a... year? Or more?
It did get faster with latest PR review UI update, but still rather slow right now

[zerobias]

Browser native back button is broken on iOS safari too. When the one navigate source code usually it doesn’t do anything but change url. Hitting back several times with no effect and reloading page in disgust leading to jump to arbitrary url in history.

Reconsider your approach to frontend development, please

[dlvhdr]

Until this is fixed you can try some faster frontends like a TUI https://github.com/dlvhdr/gh-dash

[el1s7]

Because Safari sucks, like most of Apple's software. And any dev using it and not accepting this, is in denial.

Go ahead, bring me the dislikes (hopefully the emoji interaction is still working in your Safari).

[erhosen]

It's weird that you call yourself a dev, considering your poor GitHub activity 🤔