| ▲ | Matt138 5 hours 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] |
|
| ▲ | Banditoz 5 hours ago | parent | next [-] |
| How did the performance of GitHub become so slow in the first place? It didn't used to be this bad years ago. |
| |
| ▲ | ayewo 2 hours ago | parent | next [-] | | 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 | | |
| ▲ | jiggawatts 2 hours ago | parent [-] | | 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 | | |
| ▲ | dangus 18 minutes ago | parent [-] | | 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! |
|
| |
| ▲ | Strom 3 hours ago | parent | prev | next [-] | | AI. GitHub usage has exploded recently due to the ease at which code can be generated. | | |
| ▲ | adsteel_ 3 hours ago | parent [-] | | Not just due to code generation, but to AI code scraping and inspection. |
| |
| ▲ | userbinator 2 hours ago | parent | prev [-] | | 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. |
|
|
| ▲ | bsuvc 2 hours ago | parent | prev | next [-] |
| > 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). |
|
| ▲ | spike021 3 hours ago | parent | prev | next [-] |
| > 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? |
| |
|
| ▲ | Xunjin 5 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | freedomben 5 hours ago | parent [-] | | 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 |
|
|
| ▲ | Neywiny 5 hours ago | parent | prev [-] |
| 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? |
| |
| ▲ | ezfe 5 hours ago | parent | next [-] | | Navigation within a repository does not reload the page, only the section below the header. | | |
| ▲ | BlackFingolfin 3 hours ago | parent [-] | | 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. | | |
| ▲ | geerlingguy 2 hours ago | parent [-] | | 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. |
|
| |
| ▲ | mvdtnz 5 hours ago | parent | prev [-] | | 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. | | |
| ▲ | AlotOfReading 3 hours ago | parent | next [-] | | 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. | |
| ▲ | Matt138 5 hours ago | parent | prev [-] | | 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) | | |
| ▲ | nchmy 2 hours ago | parent | next [-] | | I'm curious, what causes the rails header to be so slow? They have a pretty good fragment caching story, don't they? | |
| ▲ | Banditoz an hour ago | parent | prev | next [-] | | Has the team considered going back all-in on Rails and SSR instead of this hybrid approach? | | |
| ▲ | altairprime an hour ago | parent [-] | | Have they completed the do-or-die Azure migration? I thought it had another year or something left.. |
| |
| ▲ | Neywiny 3 hours ago | parent | prev [-] | | That does seem very long so it's good you're working on it |
|
|
|
