This was a performance driven change. We added this as loading a cross repo issue is a much slower experience than loading an issue in the same repo due to the way the header is loaded (which is being worked on).
But we hear you on the feedback - we will roll this back while we keep pushing on the root performance causes.
[update - this change has been reverted and the previous behaviour is back]
How did the performance of GitHub become so slow in the first place? It didn't used to be this bad years ago.
AI. GitHub usage has exploded recently due to the ease at which code can be generated.
Not just due to code generation, but to AI code scraping and inspection.
From what I remember, it got much worse the moment they started requiring JS for displaying what would otherwise be mostly static (and thus easily cached) content.
Used to be full page loads when you clicked on links too, performance got a lot worse (for me), both network-wise and client-side-wise when that changed.
Some hard numbers [1] as to why GitHub is struggling with stability issues, directly from GitHub's COO:
Yup, platform activity is surging. There were 1 billion commits in 2025. Now, it's 275 million per week, on pace for 14 billion this year if growth remains linear (spoiler: it won't.)
GitHub Actions has grown from 500M minutes/week in 2023 to 1B minutes/week in 2025, and now 2.1B minutes so far this week.
So we're pushing incredibly hard on more CPUs, scaling services, and strengthening GitHub’s core features.
1: https://x.com/kdaigle/status/2040164759836778878
All of which can be handled with horizontal scaling of identical components.
None of which explains poor latency when opening UI elements, which is more likely be explained by overuse of SPA or spaghetti code in microservices.
Update: yup, that’s exactly it, just as I guessed: https://news.ycombinator.com/item?id=47912867
This whole thread is so embarrassing for GitHub.
The idea that you would change your product design in this way as a quick fix to solve a performance problem is insane.
This would be like if the battery life on a MacBook Pro was too short so Apple fixed it by removing the screen.
Job’s done, boss!
In a large enterprise if you task a front end team with solving a performance issue that is caused by the back end, invariably they’ll hack together some workaround… in the front end.
People only ever solve problems in the areas they have control over, whether that’s where the root cause is or not.
> loading a cross repo issue is a much slower experience
Why not solve the real problem instead of putting in a janky workaround?
At risk of being cliche, it seems like you guys could benefit from the 5 Whys approach here: "Why is loading a cross repo issue slow?" and iterate until you discover the root cause, and fix that.
I suspect fixing the root cause is going to be a lot less glorious career-wise than implementing a UX change that is easier to tout at review time (well maybe not so much after this debacle).
Maybe fixing the root cause is slower, and this janky workaround was quicker as its something largely already built (a few views/links in Github already open issues in a drawer).
You've never done a temporary fix to stop the bleeding?
Can you elaborate? The header meaning the top part of the page? I just checked on a recent repo I visited and it has the usual banner (which would stay the same), the repo path, some links, and some stats. Considering every page navigation would likely pull which links and stats are shown, why is this a delta to go to another repo and why are presumably 3 database entries (possible links, stars, forks) so slow?
Navigation within a repository does not reload the page, only the section below the header.
which is also driving me nuts because it frequently fails to update the issue and PR counts when I close issues or PRs. Only a hard reload, or closing the tab and opening a new new one, fixes it.
Yeah over the past six months I've trained myself to just hit Command-R every time I switch back to a GitHub issue tab, otherwise things get stale or broken far too often.
I can't speak for GitHub but I've worked on multiple nav headers for large SaaS products and they can be ridiculously heavy weight to render given they appear on every page. They tend to be a dumping ground for features, many of which require their own permissions checks, feature flag checks, etc. it's not unusual to have to perform hierarchical permissions checks. They also tend to contain contextual info about the current nav state and dynamic information about navigable states.
A lot of this can be cached but it's easy to see why moving from one repo to another will invalidate most or all permission checks and feature flag checks.
Yes, pretty much this as well as some additional complexities due to the issue content being in React and the header in Rails - to the cost of approx 500-800ms p50 for a page load vs sub 100ms for a nav to an issue in the same repo (or without the header which is what we tried with this change here)
That does seem very long so it's good you're working on it
I'm curious, what causes the rails header to be so slow? They have a pretty good fragment caching story, don't they?
Has the team considered going back all-in on Rails and SSR instead of this hybrid approach?
Have they completed the do-or-die Azure migration? I thought it had another year or something left..
is `current_user` really costing that much?
How many checks are we talking? A well-implemented monotonic system should be able to do tens of thousands of these checks (or more) in the time budget I associate with a heavy page, and start before the entirety of the permissions/feature data is available.
To be honest GitHub should have like a switch for "preview stuff adopter" where you guys could give any benefits for it (maybe more copilot usage?). This way you can test with a specific public, using metrics and feedback, while testing and people could comment more about it.
I would like this personally as I hate change in general, but from their perspective it's not a great test because the sample is far from random. They should still do it though
> GitHub should have like a switch for "preview stuff adopter"
They do. And they tend to avoid using it, and/or ignore feedback if it's not in line with the direction that they actually want to go. :( :( :(
> update - this change has been reverted and the previous behaviour is back
was an on-call engineer paged for this on the weekend just to roll a revert instead of waiting until Monday?
we both know the answer to that