8月6日、Matyáš Racek氏のブログで「Why is GitHub UI getting so much slower?」と題した記事が公開され、話題を呼んでいる。
この記事では、近年 GitHub のユーザーインターフェイス（UI）が著しく遅くなっている現状を実測プロファイルとともに検証し、原因と課題を考察している。
PR 画面切替えに5秒超――“高速化”のはずの Turbo が逆効果
筆者はまず、プルリクエスト画面で Conversation タブから Files changed タブへ切り替える際に 5 秒以上かかる という例を示す。Chrome DevTools で取得したプロファイルを解析すると、GitHub が採用するクライアントサイドルーティングライブラリ Turbo が事前読み込みした HTML を DOM に挿入した後の「後処理」がボトルネックになっており、新しいタブで直接ページを開く場合より約 2 倍遅い という逆転現象が確認できたという。
さらに、遅延を隠蔽する目的で導入された新しいプログレスバーが、かえって待ち時間を可視化し利用者のストレスを増幅させていると指摘する。
巨大 DOM と無駄な SVG が引き起こす描画ラグ
Files changed ビューでは、行ごとに配置された「見えない」プラスボタンを含め、10 万件を超える DOM ノードが生成されるケースがある。加えて同一の SVG アイコンがインラインで重複描画されるため、スクロールやウィンドウリサイズのたびに数秒間 UI がフリーズする現象も観測された。
主な性能問題（記事中の指摘）
- タブ切替えの遅延：クライアントサイドルーティングの後処理がサーバ応答時間を上回る。
- SPA 化の形骸化：完全リロード並みの待ち時間を再現しており、シングルページアプリの利点が失われている。
- 大量 DOM 要素：差分ビューで不要な要素を大量に描画し、ブラウザのレイアウト計算を圧迫。
- ロードインジケータの乱用：パフォーマンス問題を根本解決せず、待機演出でごまかす実装。
GitHub ロードマップに“救い”はあるか
GitHub は公式ロードマップの中で「Platform for Collaboration at Scale」を掲げるが、公開リポジトリを検索しても Web パフォーマンスに直接言及した課題やマイルストーンはほとんど見当たらない。Stack Overflow やコミュニティフォーラムでは「差分表示のフリーズ」「ロード時間の増大」といった報告が相次いでおり、改善を求める声は強まる一方だ。
まとめ
かつては軽快さで評価された GitHub UI だが、近年はモダンフレームワークの乱用やフロントエンド実装の肥大化により、基本操作でも数秒単位の遅延が発生している。筆者は「せめてクライアントサイドルーティングを採用するのであれば、ページ遷移をリロードより速くすべきだ」とし、パフォーマンス改善に向けた抜本的な設計見直しを GitHub に求めている。
詳細はWhy is GitHub UI getting so much slower?を参照していただきたい。
