Comment by Matt138
3 days ago
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.
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
2 replies →
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.
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.
> 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?
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)
5 replies →
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.
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.
1 reply →
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.
> 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. :( :( :(
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
> 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