GitHubのWebサイトがSafariで遅く動作する

 (github.com/orgs)
2 ポイント 投稿者 GN⁺ 2025-08-29 | 1件のコメント | WhatsAppで共有
  • ここ数か月、SafariブラウザでGitHub Webサイトの速度が徐々に低下している
  • 大規模なPRや数千行に及ぶコードファイルでは、画面レンダリングが事実上不可能になっている
  • ブラウザのレンダリングプロセスが100%使用され、スクロール時に空白画面が表示されるほか、検索・コメント機能で深刻な遅延が発生
  • CSSの変更とtransformの使用がSafariの性能バグと衝突して問題を引き起こしており、Chromeなど他ブラウザは比較的良好
  • WebKitでは一部の性能パッチが適用されたものの、Safariの次回リリースまではGitHubフロントエンドチームによる暫定対応の必要性が言及されている

背景と主な問題

  • 最近、SafariブラウザでGitHub Webサイトにアクセスした際の全体的な性能低下が目立っている
  • 特にPull Request(PR)で数千行以上の変更を確認したり、大容量のコードファイルを閲覧したりする際、レンダリングそのものが不可能になるレベルに達している
  • Activity MonitorではレンダリングプロセスがCPUを100%占有し、ページの描画速度があまりに遅いため、スクロールすると画面が空白として表示される
  • 検索やコメントなどのインタラクティブ機能は深刻に遅延し、PRレビュー時にはチェックボックスをクリックするだけでも数秒以上かかる問題が発生
  • 高性能なApple Siliconを搭載した最新のMacBook Proでも同様の現象が発生しており、Chromeや他ブラウザでははるかに快適に利用できる

問題の原因と分析

  • Safari 18.6（およびベータ版/テクノロジープレビュー版）ユーザーから共通した不満が寄せられている
  • 一部ユーザーは、Safari全体ではなくGitHubでのみ特に深刻な性能低下が起きていると述べている
  • CSSセレクタとtransform: translateYの大量使用が、SafariのGPUレイヤー処理の限界と直接衝突していると説明されている
    • GitHubフロントエンドがすべてのテキスト行をtransform: translateYで配置することで、Safariは数千ものGPUレイヤーを作成することになる
    • Chromeはこのようなアニメーションがない場合、レイヤー生成を最適化するため、相対的にそこまで遅くならない
    • 暫定策としてtransformプロパティを削除するスクリプトを適用すると高速化するが、位置の精度は完全ではない

ユーザー体験と各種報告

  • 多くのユーザーが、PRでのレビュアー・ラベル追加やPR説明の編集など、あらゆる操作が数秒以上遅延すると不満を訴えている
  • Safariでアクセスすると、コードブラウザやオートコンプリート（検索バー、コマンドパレットなど）のUIも非常に遅くなる
  • iOS Safariでは、戻るのネイティブボタンなどブラウザ機能自体が正しく動作しない事例もある
  • アクセシビリティ（VoiceOver）の面でも性能低下が深刻で、視覚障害のあるユーザーにとってはほぼ利用不能な状況になっている

解決と対応の議論

  • WebKit（Safariエンジン）側では最近、このCSS/コンポジタ性能問題の一部パッチを進めたが、Safariの次回リリースまでは即時解決が難しい
  • GitHubのエンジニアには、次期Safariリリース前を見据えたバグ対応の提案と、性能問題に関する事前のコミュニケーションの必要性が指摘されている
  • さまざまなフロントエンドUIの変更（例: PRファイル変更UI、新機能など）が、性能低下と直接関係していると見られている
  • 一部ユーザーは、Graphite.dev、GitLab、カスタムプロトコルルーター（例: Finicky、Veljaなど）を使った回避や代替UIの利用を行っている

その他のコメントと実利用者向けのヒント

  • 一時的な回避策として、SafariでIssue/PRを作成した後、テーブル方式のラベル追加機能を使うよう勧める声がある
  • 過度に複雑なCSSやエンジニアリング構造の変化、Chrome一強化への懸念、そして多様なブラウザ対応の必要性を強調する声もある
  • 一部ユーザーは性能問題について批判的またはユーモラスなコメントを加えている（不要な感情的論争には議論上の注意が必要）
  • 性能最適化が必要なフロントエンド開発手法の見直しや、マルチブラウザテストの重要性について内外から意見が出ている

結論

  • GitHubの最近のUI構造の変化とCSSの活用方法がSafari固有のレンダリング特性と衝突し、業界標準のコラボレーション基盤で深刻なブラウザ上の不便を引き起こしている
  • WebKitとGitHubの双方に積極的な改善姿勢が求められており、Safariユーザーやアクセシビリティ利用者を重視した対応が短期的に必要とされる
  • 開発業務に支障をきたすほどのパフォーマンス問題であり、コミュニティ内で大きな共感と怒りが広がっている

関連記事

1件のコメント

 
GN⁺ 2025-08-29
Hacker Newsの意見

  • GitHubのWebサイトは全体的に遅い。性能面でもUX/UI面でも、あらゆる意味で良いソフトウェアとは言えず、多くの人のKPIや企画の都合が入り込んだ結果物のように感じる。開発者向けソーシャルネットワークという点こそが最も「革新的」な部分で、日常的な開発作業ではあまりに平凡で、GitLabのほうがずっと良いと感じるほど。この問題はRailsのせいではなく、技術論で本質から目をそらすのは正しくないと思う

    • GitHubの問題はRailsではなくReactへ移ったことにある。以前のSSRベースのGitHubは本当に速く、大規模なPRでも問題なくレビューできた
    • 数年間GitHubを使っておらず、今年また使ってみたら、どれほど遅くなったのか本当に驚いた。操作のたびに遅さのせいで使い方そのものを変えなければならなかった。何かがおかしい感覚がずっとあり、数秒間まったく反応がないと、サーバーが止まったのではないかという不安さえ覚える
    • 10年間Phabricatorを使ったあとでGitHubに来ると、品質差が大きくて戸惑うし、これが標準だというのが信じられない。Phabricatorが今ではメンテナンスのみになっているのが残念だ Phabricator Wiki
    • GitHubは昔は本当に快適だったが、SPAに変わってから息苦しくなった
    • 昔、CTOがレガシーアプリの性能低下の原因を何でもRailsのせいにして、Javaに全面移行しようと言っていた経験がある。実際には無能な企画担当、経営陣、経験不足の開発者たちが積み重なったことこそが根本原因だった。10年以上誤って管理されたプロジェクトなら、どんなスタックでも結果は同じだ

  • WebKitチームがこの2日間でGitHubの性能問題の改善を適用した 関連リンク。チーム内で大規模PR（1000ファイル以上）を作ることもあったが、同僚たちはPRの読み込みを待ちながら「開いたら承認するよ」と言っていた

    • みんなJSやReactが問題だと言うが、実際に今回のパッチはCSS性能に関するものだ
    • Chromeとその派生ブラウザが事実上レンダリングエンジンを支配している状況なので、Firefoxの伸びが鈍い今、macOS/iOSでSafariを競争力のある存在に保とうとするAppleの変化は歓迎したい
    • 1000ファイル以上を含むPRが、具体的にどんな作業なのか気になる
    • 実際には、Safari WebKitにGitHubが過度な負荷をかけたことで露呈したバグだった。開発者やユーザーである私たちは、原因をGitHubのせいだけにしがちだ
    • WebKitのパッチが実際のユーザーに届くまでどのくらいかかるのか気になる。SafariはOSアップデートを待たなければならないのか、それともChrome/Firefoxのように更新が速いのか知りたい

  • MicrosoftがGitHubを買収すると、GitHubはほとんどすぐにJavaScriptレンダリング方式（SPA）へ移行した。以前は2011年型Mac MiniでJavaScriptを無効にしていてもGitHubを閲覧できたが、今ではJSを有効にしていても旧式ブラウザ互換性の問題でGitHubを使えない。どちらがより問題かは言いにくいが、両方に責任があると思う。新しい機器に替えることもできるが、意図的に旧型機器のサポートを放棄し、将来の機能性よりも計画的陳腐化を強いる雰囲気の中で、Web標準への信頼さえ揺らぐ感じがする

    • もし今日初めて知ったのなら、OpenCore Legacy Patcherを使えば2007年型MacでさえmacOSを最新バージョンまで上げられる OpenCore Legacy Patcherリンク
    • ChromeやFirefoxをインストールして使うのはどうだろうか
    • なぜTuring completenessが嘘のように感じられるのか疑問だ。計画的陳腐化もあるが、現代のソフトウェア環境は抽象化が過剰になっている。もしすべてのソフトウェアをC言語で書かなければならなかったなら、今の世界は大きく違っていただろう。あまりに高い抽象化に陥っている気がするが、ここまで来た以上、もう戻るのは難しい。Turing completeness自体はこれとほとんど無関係で、むしろその結果としてより大きな資源消費を要求するようになっている
    • Turing completenessは性能とは無関係だという点を強調したい。理論上は、現在の機器上で最新機器をエミュレートすることさえ可能だ
    • 2011年のMac MiniのOSサポートが打ち切られたことに不満を持つ人もいるが、8年以上前のブラウザでインターネットを使うのは、セキュリティ的には家のドアを全部開け放しているのと似たようなものだと思う

  • Reactへの批判は多いが、今回の問題はCSS transformの問題だ。関連リンクの内容を実際に読んでみることを勧める

  • Forgejo、Codeberg、SourceHutへの移行を勧める。GitHubやGitLabと比べると稲妻のように速い Forgejo / Codeberg / SourceHut

    • Forgejoサーバーを壊れかけた回線（秒あたりキロビット級）で数週間動かしたことがあるが、それでもかなりよく耐えた。push/pullは何とか動いたが、Actionsは100MB以上の転送が必要なので厳しかった

  • 大規模組織でどうしてこうした問題が繰り返されるのか気になる。主要ブラウザのテストで性能問題は確実に見つかっていたはずなのに、誰かが強行承認したのかと思うと理解できない

    • 現在のIT業界には3つのグループがある。1) PMが無理にリリースを急がせ、速度だけを重視する。2) 開発者はこうした要求に反発しながら継続的に政治的資本を消耗し、燃え尽きる。3) 何もかもに無関心で、与えられた仕事だけを機械的にこなす開発者集団。結局、文化そのものに問題があり、Cレベルで全面的に改革しない限り変わらない。ほとんどの役員にはそれを変える意思がない
    • 大きな組織で技術スタックを決める際の最重要基準は「採用と解雇がどれだけ容易か」だ。React開発者は多いがRailsは見つけにくい。開発者の意見は無視され、組織の都合が優先されることで、遅いサービスと低品質につながる。開発者たちも問題は分かっているが、生き残ることが先だ
    • 昔は「IBMを買えばクビにならない」という言葉があったなら、今は「Reactを使わなければクビになる」という空気だ。みんながReactを使うので、GitHubですら遅くなる現象が続いている。悪い開発者は他人が使っているものを追いかけ、良い開発者はKISS原則に従って最も単純な道具を選ぶ
    • 大企業では「オーナーシップ」が曖昧になり、人材の入れ替わりや短期目標重視によって、こうした問題が常に繰り返される。機能追加の圧力と技術的負債が積み上がり、責任感は失われる。問題提起をすると、かえって対立が生じ、改善計画の対象にされてしまう

  • React開発者としてこのスレッドを見ると、世の中の憎悪を実感する。非現実的なスケジュールや、バックエンドロジックまでフロントに載せるSPAの落とし穴が多い。React自体が間違った選択なのか、本当にうまく作られたReactアプリが存在するのか気になる

    • 長いあいだReact/SPAの熱烈なファンだったが、次第にC++ MFCのデスクトップアプリを作っていた時代より、むしろ開発が難しくなっていると気づいた。宣言的マークアップが認知負荷を減らすと言われていたのに、実際には宣言的UIとイベント/状態管理の複雑さが増し、手続き的に開発していた頃より複雑になっている。昔のC++コードのほうが、むしろReact hookより理解しやすかった
    • SPAへの批判は多いが、本当に良くできたReact/Angularアプリもある。例: Clockify。問題のあるアプリがSSRでレンダリングされたからといって、UXが急によくなるようには思えない。実際の原因は、品質よりも機能の迅速なリリースだけを重視する組織風土だ
    • こうした技術は、性能が悪いときにだけ目立つ。みんなが毎日Web技術を使っているので、批判しやすい。特に初心者開発者が多く使う技術なので、なおさら叩かれる。境界の崩壊が激しい例だ
    • React自体の問題ではなく、使う開発者が誤用するのが問題だ。数多くの最適化があっても、組み合わせ方を誤ればクリック反応が1.3秒もかかるような現象が起きる
    • React自体は悪くなく、SPAという構成が構造的に問題になることが多い。Reactは単にSPAを使いやすくした道具にすぎない

  • コンピューティング全般で、あらゆるものが遅くなった感じがする。最新のMac Studio M4 Max、64GB RAMを使っていても、2011年のMacBook Pro時代よりすべてのWebサイトが遅い

    • 15年前にインターネットを使っていた頃も確かに遅かったが、その頃はWeb上で複雑なスプレッドシートやデザインツールは使っていなかった。MシリーズMacは、これまで使った中で最も速いコンピューターだ（Linuxデスクトップを除けば）
    • Web開発者は、少なくともユーザー下位10%程度のスペックの機器を使って開発すべきだと思う。あるいは、性能そのものをWCAG（Webアクセシビリティ）の基準にするのも方法だ

  • HNでGitHubがReactにUIを移行してから遅くなったという話をよく見るが、実際にそうなのか気になる。小規模プロジェクトでは影響がないので、確かな根拠を探したい

    • 最近読んだブログ記事が原因をうまく説明していた。要するに、PRビューで10万個以上のDOMノードがレンダリングされ、そのかなりの部分が見えないSVGノードだという。SPAルーティングのせいでナビゲーションもはるかに遅くなっているという分析だ 関連ブログ / HN議論
    • 最近PR diffページが新しくリデザインされ、DOMがさらに肥大化したように見える

  • SafariだけでなくFirefoxでもGitHubは非常に遅く、あちこちでローディングスピナーが表示され、ページ遷移も以前より時間がかかる。以前は完全にうまく動いていたSSRを、いったいどんな指標でSPAに変えたのか理解できない

    • 最近はChromeでも同様の問題がある。3つのブラウザすべてで、PRが大きくなくてもまともに動かない状況だ