世界を動かす技術を、日本語で。

GitHubのウェブサイトはSafariで遅い

2025年8月27日原文(github.com)

概要

Safari上でのGitHubのパフォーマンスが数ヶ月にわたり著しく低下。 大規模なPull Requestやファイル閲覧時にページがほぼ利用不可能。 高性能Mac環境でもSafariのみで顕著な遅延・フリーズ発生。 Chrome等他ブラウザでは問題が軽減されるが完全解決には至らず。 一時的な回避策や他サービスへの移行事例も報告。

Safari上でのGitHubパフォーマンス問題

  • Safariブラウザ でのGitHub動作がここ数ヶ月で 極端に遅く なった現象

  • Pull Request の差分が 1,000行以上 やファイルサイズが大きい場合、表示や操作がほぼ不可能

  • Activity Monitor でSafariのレンダリングプロセスが CPU 100% を継続

  • スクロール時の 画面白抜け や、 検索・コメント・チェックボックス 等の UI操作が数秒単位で遅延

  • Apple M4 Max 16コア/48GB RAM などのハイエンドMacでもSafariのみで問題発生

  • Chrome では大規模PRで多少遅くなるが、Safariほど致命的ではない

  • Safari 18.6M3 Pro Mac など、複数環境で同様の報告

    • 小規模PRですらラベル追加・レビュワー追加等の操作が数秒遅延
    • ページ自体が フリーズ するケースも多数
  • コンテンツブロッカーやプラグイン を無効化しても改善せず

  • 新しいFiles Changed体験 の有無に関わらず発生

  • API操作(UI経由) も大幅に遅延

  • ネットワークリソース"collect" の待機でUIがハングする場合あり

  • Safari Tech Preview でも同様の遅延

  • Webインスペクタ での調査では 過剰なコンポジット処理 が原因の一端と推測

コミュニティ・ユーザーの対応と意見

  • GitHub公式 はフィードバックを受領し、製品改善の参考にしていると案内
    • ただし個別対応は難しい場合が多く、コミュニティ内で情報共有推奨
  • 一時的な回避策 として
    • PR/Issue作成後にリスト表示からラベル付与する方法
    • graphite.dev 等の代替サービス利用
    • プロトコルURLルーター 等でGitHubリンクを自動的にChromeで開く方法
  • アクセシビリティ (VoiceOver等)やスクリーンリーダー利用時にも深刻な遅延・表示問題
  • AI(Copilot等)によるバグ増加 やパフォーマンス低下を指摘する声
  • GitLab 等他サービスへの移行例が増加
  • WebKitバグ として報告済み、修正はリリース待ち
  • 過去は問題なかった が、ここ数週間で急激に悪化したとの指摘

まとめ・今後の対応

  • Safari上のGitHubパフォーマンス問題 は多くのユーザーが深刻に認識
  • 大規模PRやファイルの閲覧・編集 がSafariでは現状ほぼ不可能
  • 一時的な回避策他ブラウザ・サービスの併用 が現実的な対応
  • GitHub公式・WebKit側の修正リリース を待つ必要性
  • コミュニティ内での情報共有・フィードバック が引き続き重要

関連リンク・参考情報


推奨アクション

  • Chrome等他ブラウザの利用 による一時回避
  • 大規模PR時の分割・小分け による負荷軽減
  • コミュニティでのフィードバック共有・議論参加
  • 公式ChangelogやRoadmapの定期確認

Hackerたちの意見

オンラインで(HNでも)見たコメントによると、GitHubがUIをReactで書き直してから遅くなったらしいんだけど、これが本当かどうかは分からない。自分のプロジェクトは小さいから、パフォーマンスに影響は感じてないし。具体的な情報持ってる人いる?

新しいデザインのプルリクエストの差分ページが公開されたみたいだけど、DOMが膨れ上がったに違いない。

最近、問題に光を当てるブログ記事[1](HNスレッド[2])を見つけた。要するに、PRビューは10万以上のDOMノードをレンダリングすることができ、その多くは目に見えないインラインSVGノードで、SPAルーティングがナビゲーションをかなり遅くしているってこと。[1]: https://yoyo-code.com/why-is-github-ui-getting-so-much-slowe... [2]: https://news.ycombinator.com/item?id=44799861

WebKitチームが最近2日間でマージした改善点: https://github.com/orgs/community/discussions/170922#discuss... 俺はたまにGitHubで大きなPR(> 1,000ファイル)を作るんだけど、チームメイト(ほとんどがChrome使ってる)が「読み込むまで承認しないよ…」って言うことがある。

それはほぼレビュー不可能だね。もしNDAを破らずに共有できるなら、そんなにファイルが関わるPRってどんなの?

その改善がユーザーに届くまでどれくらいかかるの?OSのアップデートが必要なのかな、それともSafariはFirefoxやChromeみたいに早いアップデートの仕組みを使ってるの?

ありがとう、それは確かに良い兆候だね。Chromeとその派生のレンダリングエンジンの独占状態や、Firefoxの普及があまり進んでないことを考えると、AppleにはSafariをmacOS/iOSでただ生き残らせるだけじゃなく、素晴らしいものにしてほしいな。

ここにいるみんながJSとReactを責めてるのが面白いよね。でも、君がリンクした修正はCSSのパフォーマンスについてだし。

GitHubのウェブサイトはどこでも遅い。パフォーマンスもUX/UIも含めて、本当にクソなソフトウェアだよ。多くの人が関わって、彼らの素晴らしいアイデアやKPIの産物で、開発者向けのソーシャルネットワークであるコードがその中で一番「素晴らしい」ものだ。日常の開発作業に関しては、GitLabですらGitHubと比べると金の標準に見えるほどの平凡さだし。で、問題は「Rails」でもなくて、[他の技術的な言い訳を挿入して本当の問題を逸らす]でもない。

で、問題は「Rails」じゃない。 彼らはRailsを捨ててReactに移行したのが問題だ。古いSSRのGitHub体験はすごく良かった。移行する前は、どんなマシンでも大きなPRをレビューできたのに。

そうそう、まさにその通りだと思ってた!それに、GitHubの検索機能は最悪だし、diffの表示もひどいよね。今のクライアントがBitbucketからGitHubに移ったばかりで、開発者たちが大騒ぎしてるよ。

Gistを埋め込むのに、ダークモードやライトモードを完全に実装してないのがイライラする。テーマは常にライトに設定されてて、値をオーバーライドする方法がないんだ。せめて、自動に設定してほしいな。

Hacker Newsで議論の続きを見る