差分表示のパフォーマンス向上への挑戦

プルリクエストは GitHub の中核をなす存在です。エンジニアにとって、ここが私たちの時間の多くを費やす場所です。そして GitHub のスケール——プルリクエストは小さな 1 行の修正から、数千ファイル、数百万行にわたる変更まで多岐にわたります——において、プルリクエストのレビュー体験は常に高速で応答性が高いものでなければなりません。 私たちは最近、[Files changed] タブ（現在すべてのユーザーのデフォルト体験）のための新しい React ベースの体験をリリースしました。私たちの主な目標の一つは、特に大規模なプルリクエストにおいて、全体的により高性能な体験を確保することでした。つまり、最適化されたレンダリング、インタラクションレイテンシ、メモリ消費といった難しい問題に投資し、一貫して優先順位をつけることを意味しました。 最適化以前、ほとんどのユーザーにとって体験は高速で応答性がありました。しかし、大規模なプルリクエストを表示する際、パフォーマンスは顕著に低下しました。例えば、極端なケースでは JavaScript ヒープが 1 GB を超え、DOM ノード数が 400,000 を超え、ページのインタラクションが極端に遅くなったり、使用不能になったりすることが観察されました。Interaction to Next Paint (INP) スコア（応答性を判断する主要な指標）が許容範囲を超え、ユーザーが入力遅延を定量的に感じられる体験となっていました。 最近の「変更済みファイル」タブに対する改善により、いくつかのコアなパフォーマンス指標が有意義に向上しました。これらの変更のいくつかは最近の変更履歴で簡潔に触れましたが、ここではより詳細に解説します。なぜこれらが重要だったのか、何を測定したのか、そしてそれらの更新が全体的な応答性とメモリ負荷、特に大規模なプルリクエストにおいてどのように改善されたのかについて、続きをお読みください。 プルリクエストのサイズと複雑さによるパフォーマンスの改善 これらのパフォーマンス問題の改善に向けた次のステップを調査・計画し始めた際、初期段階から明白だったのは、万能薬となる単一の解決策が存在しないということです。すべての機能やブラウザネイティブの動作を保持する手法でも、極端なケースでは頭打ちになる可能性があります。一方、最悪のケースが破綻しないように設計された緩和策は、日常的なレビューには不適切なトレードオフになる場合があります。 単一の解決策を探すのではなく、一連の戦略を開発し始めました。私たちは複数のターゲットを絞ったアプローチを選択し、それぞれが特定のプルリクエストのサイズと複雑さに対応するように設計されました。 これらの戦略は以下のテーマに焦点を当てました： Diff行コンポーネントの集中的な最適化。主要なdiff体験を、ほとんどのプルリクエストに対して効率的にします。中規模および大規模なレビューでは、ネイティブのページ内検索などの期待される動作を犠牲にすることなく高速な状態を維持します。 バーチャライゼーションを用いて段階的に機能低下させる。最大のプルリクエストでも操作性を維持する。同時に描画される内容を制限し、応答性と安定性を優先する。 基盤となるコンポーネントとレンダリングの改善に投資する。これらは、ユーザーが最終的にどのモードを使用するかに関わらず、すべてのプルリクエストのサイズに対して複合的な効果をもたらす。 これらの戦略を念頭に置き、これらの課題に対処するために私たちが取った具体的なステップと、その初期の試行がその後の改善への道を開いた方法を探っていこう。 最初のステップ：diff 行の最適化 プルリクエストのパフォーマンス向上というチームの目標に向け、私たちは3つの主要な目的を定めた。 メモリとJavaScriptヒープサイズの削減。 DOMノード数の削減。 平均INPの削減、およびp95およびp99測定値の大幅な改善。 これらの目標を達成するため、私たちは簡素化に注力した。状態の削減、要素数の削減、JavaScriptコード量の削減、そしてReactコンポーネント数の削減である。結果と新しいアーキテクチャを見る前に、起点となった当初の状況を確認しよう。 v1での成功と失敗 v1では、各diff行のレンダリングコストが高かった。統一ビューでは1行あたり約10個のDOM要素が必要であり、分割ビューではさらに15個近くに達した。これらは構文強調表示を行う前の話であり、構文強調表示はさらに多くのタグを追加し、DOM数をさらに押し上げる。 以下は、v1のdiffにおけるReactコンポーネント構造とDOMツリー要素を混合した簡略化された視覚図である。 ![image](https://github.blog/wp-content/uploads/2026/04/3.png?resize=960%2C1340) React レイヤにおいて、統一差分（unified diffs）は通常、1 行あたり少なくとも 8 つのコンポーネントを含み、分割ビュー（split view）では最小で 13 個となります。これらの数字は基本となるカウントを示すものであり、コメント、ホバー、フォーカスなどの追加 UI 状態が存在すれば、さらに多くのコンポーネントが加わります。 このアプローチは、当時の v1 において、古典的な Rails ビューから差分行を React に初めて移植した際に、私たちに理にかなっているように思えました。当初の計画は、多くの小さく再利用可能な React コンポーネントを作成し、DOM ツリーの構造を維持することに焦点を当てていました。 しかし、結果として、小さなコンポーネントに多くの React イベントハンドラをアタッチすることになりました。コンポーネントあたり 5〜6 個程度が一般的でした。小規模なスケールでは問題ありませんでしたが、大規模になるとその影響は急速に蓄積しました。1 行の差分が 20 以上のイベントハンドラを持ち、それが数千行にわたって掛け合わされることになります。 パフォーマンスへの影響だけでなく、開発者にとっても複雑さが増しました。これはよくあるシナリオです。初期デザインを実装した後、無制限のデータという要求に直面した時点で、その限界を発見することになります。 要約すると、v1 の差分行 1 行あたりには以下の要素が含まれていました： - DOM ツリー要素が最小で 10〜15 個 - React コンポーネントが最小で 8〜13 個 - React イベントハンドラが最小で 20 個 - 多くの小さく再利用可能な React コンポーネント この v1 の戦略は、最も大きなプルリクエスト（pull requests）には持続可能ではありませんでした。私たちが一貫して観察したところ、大きなプルリクエストのサイズは直接的に INP（Interaction to Next Paint）の低下と JavaScript ヒープ使用量の増加につながっていました。この構成を改善するための最善の方法を特定する必要がありました。 小さな変更が大きな影響をもたらす：v2 パフォーマンスの観点からは、小さな変更でも無視できません。特に大規模なスケールではなおさらです。例えば、行番号セルから不要なタグを削除しました。差分行ごとに2つのDOMノードを削減するのは一見些細に思えるかもしれませんが、10,000行にわたれば、DOM内のノード数が20,000個減少することになります。こうした狙いを定めた段階的な最適化は、どれほど小さくても積み重なり、より高速で効率的な体験を生み出します。これらの詳細を見落とさないことで、改善の機会をすべて捉え、最大のプルリクエスト全体への影響を増幅させることができました。 v1とv2の比較は以下の画像をご覧ください。 ![image](https://github.blog/wp-content/uploads/2026/04/Screenshot-2026-04-02-at-4.12.35-PM.png?resize=720%2C899) ![image](https://github.blog/wp-content/uploads/2026/04/Screenshot-2026-04-02-at-4.12.47-PM.png?resize=704%2C874) このHTMLの背後にあるコンポーネント構造を見ると、より明確になります。 ![image](https://github.blog/wp-content/uploads/2026/04/Screenshot-2026-04-02-at-4.13.00-PM.png?resize=681%2C1024) ![image](https://github.blog/wp-content/uploads/2026/04/Screenshot-2026-04-02-at-4.13.11-PM.png?resize=667%2C1024) Diff 行あたりのコンポーネント数を8つから2つに削減しました。v1 のほとんどのコンポーネントは、Split 表示と Unified 表示の間でコードを共有できるようにする薄いラッパーでした。しかし、この抽象化にはコストがかかりました：各ラッパーは両方の表示のロジックを保持していましたが、一度にレンダリングされるのは片方だけでした。v2 では、各表示に専用のコンポーネントを割り当てました。一部のコードは重複していますが、結果としてシンプルかつ高速になりました。 コンポーネントツリーの簡素化 v2 では、深くネストされたコンポーネントツリーを削除し、各 Split 行および Unified 行に専用のコンポーネントを採用しました。これによりコードの重複が生じましたが、データアクセスが簡素化され、複雑さが軽減されました。 イベント処理は、data-attribute 値を使用する単一のトップレベルハンドラによって管理されるようになりました。例えば、複数の Diff 行を選択するためにクリックしてドラッグする場合、ハンドラは各イベントの data-attribute をチェックしてハイライトする行を決定し、各行が独自のマウスエンター関数を持つ必要はありません。このアプローチはコードの簡素化とパフォーマンス向上の両方を実現します。 複雑な状態を条件付きでレンダリングされる子コンポーネントへ移動 v1 から v2 への最もインパクトの大きい変更は、コメントやコンテキストメニューのためのアプリケーション状態をそれぞれのコンポーネントへ移動させたことです。GitHub の規模では、一部のプルリクエストが数千行のコードを超えることもあり、コメントやメニューが開かれるのはごく一部の一部の行に過ぎないため、すべての行が複雑なコメント状態を保持することは現実的ではありません。各 diff 行のネストされたコンポーネントへコメント状態を移動させることで、diff-line コンポーネントの主な責任はコードのレンダリングのみであることを保証し、これは単一責任の原則（Single Responsibility Principle）により近いものとなりました。 O(1) データアクセスと「useEffect」フックの削減 v1 では、共有データストアやコンポーネント状態全体にわたって O(n) のルックアップが徐々に蓄積されました。また、diff-line コンポーネントツリー全体に散在する useEffect フックを通じて、余分な再レンダリングも導入されました。 v2 ではこれに対処するため、2 つの部分からなる戦略を採用しました。まず、useEffect の使用を diff ファイルの最上位レベルに厳格に制限しました。さらに、行ラッピング React コンポーネントにおいて useEffect フックが導入されないよう防止するリンティングルール（linting rules）を確立しました。このアプローチにより、diff 行コンポーネントの正確なメモ化（memoization）が可能になり、信頼性が高く予測可能な動作が保証されます。 次に、JavaScript の Map を活用し、O(1) の定数時間でのルックアップを実現するよう、グローバルおよび差分状態機械を再設計しました。これにより、行の選択やコメント管理など、コードベース全体で共通する操作に対して高速かつ一貫性のあるセレクターを構築できました。これらの変更により、平坦化されたマップデータ構造を維持することで、コード品質の向上、パフォーマンスの改善、そして複雑さの削減を実現しました。 現在、任意の差分行は、ファイルパスと行番号をマップに渡すことで、その行にコメントが存在するかどうかを判定します。アクセス例は以下のようになります：commentsMap['path/to/file.tsx']['L8'] 効果はあったでしょうか？ 間違いなくあります。ページは以前よりも高速に動作し、JavaScript ヒープと INP（Interaction to Next Paint）の数値は大幅に削減されました。数値的な結果を確認するには、以下のデータをご覧ください。これらの指標は、差分比較で 10,000 行の変更を含む分割表示設定のプルリクエストを使用して評価されました。 Metricv2 改善率 総コード行数 2,000 行 27% 減少 総ユニークコンポーネントタイプ数 10 47% 減少 総レンダリング済みコンポーネント数 ~50,004 74% 減少 総 DOM ノード数 ~180,000 10% 減少 総メモリ使用量 ~80-120 MB ~50% 減少 大型プルリクエストでの INP（m1 MacBook Pro、4倍の遅延シミュレーション）: ~100 ms 78% 高速化 ご覧の通り、この取り組みは大きな影響をもたらしましたが、改善はそこで終わりではありません。 最大規模のプルリクエストに対する仮想化 巨大なプルリクエスト、特にp95+（diff行が10,000行以上で、その周辺のコンテキスト行も含むもの）を扱う場合、通常の性能最適化手法は通用しません。最も効率的なコンポーネントであっても、数万個を一度にレンダリングしようとすれば、処理は重くなります。ここで登場するのがウィンドウ・バーチャライゼーション（window virtualization）です。 フロントエンド開発において、ウィンドウ・バーチャライゼーションとは、ある時点で見えている領域のデータのみをDOMに保持する技術です。すべてのデータをロードするとメモリが圧迫され処理速度が劇的に低下するため、この手法では画面上に表示されている部分のみを動的にレンダリングし、スクロールに応じて新しい要素を入れ替えます。これはデータの上に動く「窓」があるようなもので、ブラウザが画面外のコンテンツで重くなるのを防ぎます。 これを実現するために、私たちはdiffビューにTanStack Virtualを導入し、常にDOM内にはdiffリストの表示部分のみが存在するようにしました。その効果は大きく、p95+のプルリクエストにおいてJavaScriptヒープの使用量とDOMノード数が10分の1に減少しました。また、インタラクティブ・ネス・パーセンタイル（INP: Interaction to Next Paint）は、これらの大きなプルリクエストにおいて275〜700ミリ秒（ms）から40〜80msまで低下しました。必要なものだけを表示することで、体験は大幅に高速化されました。 さらなるパフォーマンス最適化 パフォーマンスをさらに向上させるため、スタック全体にわたる複数の主要な領域に取り組み、速度とレスポンス性において意味のある成果を上げました。不要なReactの再レンダリングを削減し、状態管理(state management)を最適化することに注力することで、無駄な計算を減らし、UIの更新を大幅に高速化し、インタラクションを滑らかにしました。 スタイリング面では、重いCSSセレクター（例：:has(...)）を置き換え、GPUトランスフォーム(GPU transforms)を用いてドラッグおよびリサイズ処理を再設計しました。これにより、強制レイアウト(forced layouts)と遅延が排除され、複雑な操作に対してユーザーはシャープで効率的なインターフェースを利用できるようになりました。 また、インタラクションレベルのINP(Interaction to Next Paint)追跡、差分サイズ(segmentation)によるセグメンテーション、メモリタグ付け(memory tagging)を導入し、Datadogダッシュボードで可視化しました。これにより、開発者はボトルネックが問題になる前に特定し、解消するためのリアルタイムで実行可能なメトリクスを継続的に得ています。 サーバーサイドでは、表示される差分行(diff lines)のみをハイドレート(hydrate)するようにレンダリングを最適化しました。これによりインタラクティブになるまでの時間(time-to-interactive)が短縮され、メモリ使用量が抑制されました。その結果、巨大なプルリクエスト(pull request)であっても、読み込み時に高速かつレスポンシブに感じられるようになりました。 最後に、プログレッシブな差分読み込み(progressive diff loading)とスマートなバックグラウンドフェッチ(smart background fetches)により、ユーザーはコンテンツをより早く表示し、操作できるようになりました。もはや、大量の差分が読み込み完了するまで待つ必要はありません。 これら一連の targeted な最適化により、私たちのUIはより軽量で高速になり、ユーザーがどのような要求を投げかけても対応できる準備が整いました。 間違いなく改善：ストリーラインドなパフォーマンスの力 この、diff line アーキテクチャの簡素化に向けたエキサイティングな旅は、パフォーマンス、効率性、保守性の大幅な向上をもたらしました。不要な DOM ノードを削減し、React コンポーネント ツリーを単純化し、複雑な状態管理を条件付きでレンダリングされる子コンポーネントへ移動させることで、より高速なレンダリング時間と低いメモリ消費量を実現しました。O(1) のデータアクセスパターンを採用し、状態管理に関する厳格なルールを導入したことで、パフォーマンスがさらに最適化されました。これにより、UI の応答性（INP の高速化！）が向上し、推論も容易になりました。 これらの測定可能な成果は、大規模で成熟したコードベース内でのターゲットを絞ったリファクタリングでも、すべてのユーザーに意味のある恩恵をもたらすことができること、そして時には小さくシンプルな改善に焦点を当てることが最大のインパクトを生む可能性があることを示しています。パフォーマンスの向上を実際にご覧いただくには、オープンなプルリクエストをご確認ください。 「The uphill climb of making diff lines performant」という記事は、最初に GitHub ブログ に掲載されました。

差分表示のパフォーマンス向上への挑戦

背景や根拠まで確認しますか？

このニュースを、実務の判断につなげる

関連記事

調べる

選ぶ

サイト