コードホスティングサイトのGitHubは2008年にサービスインして以来着実にリポジトリ数を増やし、ソフトウェア開発のプラットフォームとして不動の地位を確立しています。ただ多くの開発では不要な機能も多く実装されているため軽快さには程遠い状況となっています。また大規模なプルリクエストを実行すると極端に速度が低下することも知られています。GitClassicはGitHubから得られるエクスペリエンスをより軽量かつシンプルにすることに重点を置いたウェブサイトです。

GitClassic - Fast, lightweight GitHub browsing - GitClassic

https://gitclassic.com/



GitHubが何故遅くなってしまったかについて、GitClassicはブログにて以下のように語っています。

Why has GitHub gotten so slow? - GitClassic

https://gitclassic.com/blog/why-has-github-gotten-so-slow

・機能の肥大化：シンプルなコードホスティングプラットフォームから包括的なDevOpsエコシステムへと変貌した代償としてJavaScriptのオーバーヘッドが増加している

・JavaScriptパフォーマンスとモダンウェブの複雑性：JavaScriptバンドルの肥大化により、多数のファイルを含むリポジトリの読み込み・長いプルリクエストのスクロール・課題のフィルタリングなどで大幅な遅延が発生しがち

・サーバーサイドのスケーリングの課題：数百万人規模のの同時接続ユーザーに対応するためバックエンドインフラストラクチャへの負荷が非常に高い

・オールインワンであることの代償：アーキテクチャが複雑になりすぎて各機能がリソースを奪い合うため、専門ツールと比較してパフォーマンスが低くなる傾向がある

GitHubの遅さを分析した上で、コードホスティングの原点に立ち返った結果誕生したのがGitClassicです。既存のGitHubリポジトリと連携しながらも不要なUI要素やパフォーマンスを低下させる機能を排除した、超高速かつミニマルなインターフェースとなっています。GitClassicの特徴を要約すると以下の通りとなります。

・瞬時のページ読み込み：迅速なレンダリングとスムーズなインタラクションを提供する

・集中できるコードレビュー：サイドバーの煩雑さを排除し、差分と議論に集中できる

・応答性の高さ：低速な接続環境でも快適に動作する

・Gitワークフローの踏襲：GitHubのコア機能を維持しつつも余分な機能はは維持している



つまり、GitHubの築き上げてきた資産はそのままに、より軽快で高パフォーマンスなインターフェースを提供するのがGitClassicの狙いというわけです。さらにGitClassicは大規模オープンソースプロジェクトにおいて問題となる、GitHubで数百ものファイルを含む大きなプルリクエストの読み込みに時間がかかる問題について深掘りしています。

Why does GitHub take so long to load large Pull Requests? - GitClassic

https://gitclassic.com/blog/why-does-github-take-so-long-to-load-large-pull-requests

速度低下の原因が「GitHubの機能豊富なインターフェースが膨大な量のデータ・UI要素・インタラクティブなコンポーネントを一度にレンダリングしようとする結果」であることはわかっていますが、さらに舞台裏まで追求していくことで以下の要因が見えてきます。

・膨大なDOMノードのレンダリング：差分に含まれるすべてのファイル・コメント・UIコントロールに対してDOMツリーを構築する必要がある

・常時実行されるJavaScript：インラインコメント・サジェストプレビュー・構文ハイライトといったインタラクティブな機能を実現するには継続的なJavaScript処理が必要となる

・並行するネットワークリクエスト：コミット履歴の取得・ステータスの確認・レビューデータ・ユーザーアバターの取得などが並行して行われると ブラウザに過負荷をかける場合がある

・アセットの肥大化：ページの複雑さが増すにつれ、CSSスタイルシート・JavaScriptライブラリ・メディアアセットが肥大しオーバーヘッドを引き起こす要因になる

結果としてブラウザの処理能力が限界に達してCPU使用率が急増し、環境によっては読み込み時間が数分に及ぶこともあるという次第です。Linuxカーネル・Node.js・Reactといった大規模なオープンソースプロジェクトにおいては大規模なプルリクエストは決して珍しいことではなく、コントリビューターがコアシステムのリファクタリングや主要機能の追加を行う場合、1つのプルリクエストが複数のディレクトリにまたがり数百のファイルに影響を及ぼすことは珍しくありません。さらに多数のレビューアーが同時に同じ大規模プルリクエストを読み込みコメントや提案を追加していく状況を考えると、リアルタイムで発生する多数の変更を同期させるためサーバーはより多くの処理を求められ、各レビューアーの見ているブラウザも負荷に耐え切れなくなるといった状況が発生します。

別の要因としてGitHubが網羅性を重視した設計理念を持っていることも指摘されています。GitHubはビルドステータス・セキュリティスキャン結果・デプロイ情報・GitHub Copilotからの提案などありとあらゆる情報を提示しようとしますが、10〜30ファイル程度の一般的な規模のプルリクエストであればうまく機能するものの、規模が大きくなるにつれ処理速度は著しく低下します。GitHubチームも長年にわたり遅延読み込み・仮想化リスト・プログレッシブレンダリングなどといった様々な改善を続けてきましたが、そもそもの問題が設計理念に起因しているために最適化にも限界があるとGitClassicは主張しています。



GitClassicの考える快適なワークフローを実現する方法は以下の通りです。

・小さな単位でレビューする

・コマンドラインを使用する

・ファイルの種類でフィルタリングする

・ブラウザ拡張機能を無効にする

上記の考えに則り、GitClassicは以下の機能を提供していることのこと。

・大規模な差分でも超高速なプルリクエスト読み込み

・コードに対する集中を邪魔しないコードレビュー体験

・メモリ使用量とCPU負荷の大幅な削減

・GitHubとの完全統合により既存のワークフローに支障なし

興味深いのが、GitHubをより快適に閲覧する各種ツールに関して実際に使用した結果に基づく総評です。

Best Tools to Browse GitHub Code Faster - GitClassic

https://gitclassic.com/blog/best-tools-to-browse-github-code-faster

・Refined GitHub：インターフェースの整理と明らかに不足している機能の追加を行うブラウザ拡張機能、ページの読み込み速度は向上しないもののワンクリックでのプルリクエストのマージ競合解決やコード内課題参照のリンクなど本当に役立つ機能を追加

・Sourcegraph：最高のコード検索エンジンだがかなりの容量が必要、セルフホスト版を運用するには本格的なインフラが必要になる

・github1s：リポジトリのURLを書き換えるだけでVS Code風のインターフェースを表示、読み取り専用だが高速、ただし結局すべての操作でGitHubのAPIにアクセスするため根本解決にならない

・GitHubのコマンドラインツール：使いこなせば非常に便利だが、最大の欠点としてローカルにリポジトリをクローンする必要がある

・GitClassic：他のツールでは不満があったため最終的に自作した、インライン編集機能・Copilot・Actionsダッシュボードは利用できないので本家GitHubを使用する必要あり

上記のツールはそれぞれ異なる問題を解決するものであるため、GitHubのどこに不満を持っているのかに応じて使い分ければよく、また複数のツールを使ってみても構わない、とGitClassicはまとめています。