The GitHub website is slow on Safari

Original Article ↗ Hacker News Discussion ↗

Safari-specific slowdown on GitHub

  • Many report GitHub PR diffs and large files being extremely slow or crashing Safari (including on modern M-series Macs and iOS), while the same pages are fast in Firefox/Chrome.
  • A linked WebKit bug and GitHub discussion indicate Safari had serious performance issues with large DOMs and certain CSS selectors/transforms; fixes were recently merged in WebKit and should reach users via Safari updates / Technology Preview.
  • Some argue this is primarily a Safari/WebKit bug exposed by GitHub’s heavy pages, not JavaScript per se; others still blame GitHub for “abusing” the platform.

DOM bloat, SPA navigation, and React blame

  • A referenced blog post found GitHub PR views rendering 100k+ DOM nodes (including many inline SVGs); SPA-style navigation was slower than full page reloads, inspiring a browser extension that forces hard reloads to speed things up.
  • Many commenters attribute slowness to GitHub’s move from Rails SSR + PJAX to React/SPA-style UIs, saying old GitHub could handle massive diffs on modest hardware.
  • Others push back: React’s core isn’t that slow; the main culprits are DOM size, CSS complexity, and misuse of frameworks. They note this particular Safari issue is about CSS performance, not React itself.
  • There’s broad skepticism that SSR→SPA rewrites ever improve UX; people report consistent regressions across sites.

Large PRs and human review

  • Some see 1,000+ file PRs as inherently unreviewable; others give real-world cases (mass renames, framework/API migrations, vendored deps, config changes) where huge diffs are unavoidable and still need some human oversight.
  • Discussion touches on using automation, tooling, and PR-splitting to make such changes tractable, but consensus is that large diffs are painful regardless of platform.

GitHub UX, Actions, and comparisons

  • GitHub Actions UI is described as sluggish, with issues like delayed job appearance and broken auto-scrolling; several users resort to userscripts.
  • Other UX complaints: broken history/back button, slow branch/label selectors, search failures, heavy issue/PR UIs, and degraded performance vs past GitHub.
  • Opinions split on competitors: some say GitLab, Forgejo, SourceHut, Phabricator/Phorge, or Gerrit feel faster or better-designed; others find GitLab itself heavy unless well-provisioned.

Broader critique of modern web and org incentives

  • Frequent comparisons to Jira, GCP console, Stripe, Slack, etc. as examples of JavaScript-heavy, sluggish “modern” web apps.
  • Strong sentiment that feature creep, KPIs, and PM-driven timelines trump performance and simplicity; developers feel pressure to ship features, not optimize.
  • Several argue SPA frameworks and over-abstraction make it easy to produce slow software, especially when tested only on high-end hardware.