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

[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

[wtfloris]

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

[willsmythe]

A change was just deployed that should help. Try reloading the page and let us know.

[p-linnane]

@willsmythe Have noticed improvements in the label interface within the last hour. It's still pretty slow, but it's now usable again.

[fungible-leedom]

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!

[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

[willsmythe]

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.

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

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

[willsmythe]

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

[lorenzo]

I can confirm the issue is fixed for me

[karlcow]

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

[denschub]

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.

[willsmythe]

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?

[sospedra]

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

[msheikhmsh-blip]

Hope So Github will Resolve it soon

[willsmythe]

A fix has been deployed (see comment above.). Let us know if you're still experiencing freezes after reloading.

[sospedra]

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.

[emrwlkr]

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.

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

[lastforkbender]

I'm currently using no Javascript, slow speed 4G, unknown tablet and Nord Double VPN.

[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

[willsmythe]

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.

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

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

[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!

[willsmythe]

The engineering team identified a change that shipped last week involving :has() CSS selector which appears to be the cause of this recent regression. The quick fix was to switch from CSS-based conditional styling to JavaScript.

After doing a hard reload of the page, let us know if you're still seeing this problem!

(hey, @lukehefson ... yes, lots of internal Safari users raising awareness to this problem 😄)

[lukehefson]

After doing a hard reload of the page, let us know if you're still seeing this problem!

Yup. Instantly loads better. Still finding that file view not as snappy as I'd like it, but I'll take it.

hey, @lukehefson ... yes, lots of internal Safari users raising awareness to this problem 😄)

Hey Will! Glad to hear it and thanks for the fix/update!

[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

[willsmythe]

A fix was rolled out about 2 hours ago to address this recent performance regression. Reload the page and let us know if performance is not back to where it was last week 😄.

[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

[sethrj]

GitHub is not an appropriate venue for trolling. If your feedback isn't constructive, please post it on X instead.

[ebndev]

Hi all, thanks for being valued members of the GItHub Community!

While we appreciate your participation, we ask users to be mindful of their language in order to contribute in a positive and constructive way.

Comments have been marked as abuse due to violating the code of conduct:

Contributors and maintainers pledge to making participation in GitHub Community a harassment-free experience for everyone

What is Not Allowed: Other conduct which could reasonably be considered inappropriate in a professional setting. GitHub Community is a professional space and should be treated as such.

Any repeat and future violations may result in a temporary or indefinite block from the Community.

Thanks!

[cdlewis]

I’m on an M1 Mac and search within files is almost unusable with safari

[buikhoa40]

The problems seem solved for me, I'm using linux with chrome 140 beta

[mcichecki]

I also think the issue has been resolved. For more than a week I wasn't able to submit a PR because the PR creation was lagging that much (latest beta of macOS 26.0) and I was forced to use github CLI but today I was able to get back to the old workflow using web.

[dawebmastaa]

This has NOT been resolved. 6 different browsers on linux and they all run like crap on here. It's barely usable.

[karlcow]

@dawebmastaa
Which webkit browsers are you using? (os and browser versions)
And do you have detailed steps to reproduce?

[dawebmastaa]

Sorry for the late reply - it's working much better today.

[joeldrapper]

I still experience many significant performance issues across the application in Safari. I don’t think it’s even limited to Safari though. The new PR review page for example takes just over 10 minutes to load if you have 300 files in the PR.

[sihayas]

I am sorry but there is no reason it should take 10 seconds for quite literally every single link on this website with even a marginal amount of code to load. Not only that, half of the time it does not even render. My first thought was a might as well use the desktop app because maybe that is written in native Swift and maybe it performs better. You cannot even browse through repositories in the native app. What is the point of it then?!

[joeldrapper]

Anyone saying this is fixed is obviously not working with PRs larger than a handful of files. Try scrolling down on this page. https://github.com/joeldrapper/large-pr-demo/pull/1/files?new_files_changed=true

Your React is obviously doing some kinds of O(n²) re-rendering. That page takes 10 minutes to load. Every time a new file loads, it re-renders all the files. It’s so badly done.

React is a hot pile of garbage when it comes to state management but some muppet at GitHub picked it so you’re going to have to suck it up and make it work, or insist on building this component in something good like Svelte or Solid.

You need to use an intersection observer to only render the files that are scrolled into view. And you should use the custom highlight API to highlight ranges of text on the GPU rather than adding hundreds of thousands of <span> nodes to the document.

[fungible-leedom]

That is a Very Big Pull Request and rendering it is pretty slow on my machine (M2 PRO, 32GB).

It sounds like @karlcow might be the person to investigate this. His insight was very valuable on the Cascading Style Sheet versus the new GitHub use of :has() ...

[joeldrapper]

It's not uncommon to open PRs this size. Especially when changing formatting rules or doing project wide rename of some common API.

Using the techniques I mentioned, it should be possible to have PRs millions of lines long and still have incredibly smooth performance.

I know it works because I've done it before. I was highlighting transcripts with AI confidence. But it's the same principle. I tested my implementation with millions of lines.

[naikrovek]

Your React is obviously doing some kinds of O(n²) re-rendering.

That's how JavaScript developers think. EVERYTHING is slower than snot so the different complexity classifications like O(n) and O(n²) mean nothing to most of them.

JavaScript can very easily blind you to those kinds of problems if you aren't extra careful to keep them in mind, and the ease of React damn near prevents you from keeping those things in mind. In that way, JavaScript is kind of like a mind cancer for developers because of how much it removes the developer from the CPU and how the CPU works. And the fact that O(n) and O(n²) look so similar when you're not paying attention to what you're doing, you wind up with a lot of inexperienced developers doing the easiest thing that works for their teeny tiny test cases and calling it done without ever actually thinking about what they're doing.

I know I am decades late with this, but I really wish JavaScript had been replaced with something better. The amount of time that humans have collectively spent addressing the JavaScript problems over and over and over has got to be over 1 million person-years by now. That time could have been spent much better coming up with a language that wasn't the ad-libbed invention of one guy and 10 days of his time.