Why is GitHub UI getting slower?

Original Article ↗ Hacker News Discussion ↗

Perceived slowdown and flakiness

  • Many report a clear slowdown starting around the UI revamp: pages half-loading, navigation bar without content, or long delays even for small actions (notifications, logs, diffs).
  • Code view and diff view are frequent pain points: long files or ~5k-line diffs cause hangs or unusable lag, sometimes failing to fully render.
  • Users increasingly resort to “View raw”, cloning locally, or alternative tools just to read or review code.

React/SPA rewrite as main suspect

  • Multiple comments tie the degradation to GitHub’s ongoing migration to React and heavier SPA-style client-side rendering.
  • Previously, GitHub relied on Rails with mostly server-rendered HTML, jQuery/PJAX, and later web components; now many key areas load via JSON/GraphQL APIs and React.
  • Some say basic functionality was broken for long periods (e.g., Safari back/forward, older browser support) during this transition.

Technical explanations and debates

  • Critics highlight:
    • Excessive numbers of API requests per page.
    • Huge DOM trees (e.g., character-by-character nodes for search compatibility) leading to CSS recalculation cost.
    • React’s “inverted” reactivity model making performance tuning hard at scale, with constant need for memoization.
  • Others argue React alone isn’t to blame; implementation choices and DOM size matter more.
  • There’s frustration that simple server-rendered HTML would handle many use cases faster and more reliably.

UX regressions and navigation issues

  • SPA routing frequently breaks or confuses browser history: back button unpredictability, stuck pages, lost scroll position, stale issue lists.
  • Design changes (e.g., “New Issue” in a small modal, symbol explorer hijacking back behavior) are seen as worse UX.
  • Some basic keyboard and multi-tab workflows (Ctrl+Enter to open in new tab, opening organizations, navigating to author profiles) reportedly broke or became awkward.

Diff size and tooling expectations

  • One camp argues 5k-line diffs are “too big” and should be split.
  • Others counter with valid large-diff scenarios (bulk renames, translations, big new files, cross-version comparisons) and say tools should handle them, as they previously did.

Alternatives and new projects

  • Users mention moving to or self-hosting Forgejo/Gitea, Codeberg, and new performance-focused frontends (HTMX-based Git hosting, alternate PR UIs, GitHub wrapper apps).
  • Many express nostalgia for a stripped-down, fast 2012-era GitHub and call for parallel “old” UIs as a performance benchmark.