Article

GitHub、Issues画面のナビゲーションを「瞬時表示」に刷新——P10で約600ms→70msの大幅短縮

GitHubは2026年5月14日、Issues画面のナビゲーション性能を全面的に刷新した詳細を公式エンジニアリングブログで公開しました。Service WorkerによるHTMLシェル化、IndexedDBへの永続キャッシュ、プリヒート戦略の組み合わせで、ReactソフトナビゲーションのインスタントヒットはCache rollout時点で4％から22％へ、プリヒート導入後は約70％まで上昇したと案内しています。

This article is not published in this language yet, so the Japanese version is shown instead.

GitHubは2026年5月14日、Issues画面のナビゲーション性能を全面的に刷新した取り組みを公式エンジニアリングブログで公開しました。記事は、Issuesチームのシニアエンジニアであるアレクサンダー・レリディス氏（Alexander Lelidis）が執筆しています。「Latency isn’t just a metric. It’s a context switch」を冒頭に置き、レイテンシ短縮が単なる数字の改善ではなく開発者の集中を守る課題であると位置づけている点が特徴です。

GitHub Issuesの瞬時ナビゲーション化を象徴するMonaのイラスト

画像引用元: GitHub Blog

3層のキャッシュ戦略で「ネットワーク往復ゼロ」を狙う

GitHubの発表によると、刷新の中核は「ネットワーク往復をできるだけ消す」ことに置かれています。具体的には、Reactの状態ストアに加えて、ブラウザのIndexedDBに永続キャッシュ層を持たせ、さらに同期アクセスできる「in-memory hot cache」を挟むことで、ページ遷移時のIO待ちを段階的に排除しています。

加えてService Workerが新しい役割を担っています。ナビゲーションリクエストを傍受してローカルキャッシュ命中時はサーバー側に「軽量HTMLシェルだけ返してよい」とシグナルを送り、フルSSRレスポンスを避ける構造です。サーバー側はキャッシュ前提でレスポンスを切り替える形になります。

プリヒートで「画面を開く前に取りに行く」

GitHubは「Preheating」と呼ぶ戦略を導入したと案内しています。これは、Issue一覧やダッシュボードのような滞在時間が長い画面から、次に開かれそうなIssueをバックグラウンドで先読みする手法です。先読みは低優先度のワーカーで動かし、レートリミットとサーキットブレーカーを組み合わせることで、サーバーへの負荷を制御していると説明されています。

GitHubの数字によると、初回のキャッシュ展開時点ではReactソフトナビゲーションのインスタントヒット率は4％から22％へ上昇し、プリヒート導入後はReactトラフィックの約70％がインスタント遷移になりました。キャッシュヒット率は約33％から96％へ伸びたとしています。

ナビゲーション体感の指標：HPCパーセンタイルの動き

ユーザー体感の指標として、GitHubは「Highest Priority Content（HPC）」パーセンタイルを採用し、刷新前後の値を公開しています。

パーセンタイル	刷新前	刷新後
P10	約600ms	70ms
P25	約800ms	120ms
P50	約1,200ms	700ms
P75	1,800ms	1,400ms
P90	2,400ms	2,100ms

「Instant: 200ms未満／Fast: 1,000ms未満／Slow: 1,000ms以上」の3段階の体感基準が示されており、P10とP25は「Instant」、P50は「Fast」の領域に入りました。重い遷移（P75・P90）の改善幅は相対的に小さく、これは「Hard navigations（フル遷移）」の割合が依然57.6％ある現状を反映していると整理されています。

GitHubは現状のトラフィックを、Hard navigations（57.6％）、Rails Turboによるソフトナビゲーション、React.lazyによるソフトナビゲーション（37.5％）の3系統に分けて計測しています。種別ごとの平均HPCは、刷新前ベースラインで「Hard 2.05秒／Turbo 1.76秒／React 1.04秒」と整理されています。

つまり、Reactソフトナビゲーション層の刷新が今回の主戦場であり、Hard navigationsとTurbo経由の遷移は別軸で改善が必要という現実が示されている形です。GitHubは「Stale-While-Revalidate（SWR）」パターンと、React.lazyによるルート単位・コンポーネント単位のコード分割を組み合わせ、まずReact層の体感を「Instant」に近づけたことを成果として強調しています。

「許容できる古さ」を測る運用指標

性能改善と表裏一体で、GitHubは「Controlled staleness（許容できる古さ）」を運用指標として導入したと案内しています。サーバーと永続キャッシュの差分が4.7％の範囲に収まっており、これを許容範囲とみなしてユーザーに古い情報を見せないバランスを取っているとしています。

開発者目線で示唆深いのは、Issue画面のような「リアルタイム性が要求される画面」でも、適切なキャッシュ無効化とプリヒートを組み合わせれば「ほぼInstant」の体感が出せるという点です。GitHubは今後さらにHard navigations比率の削減と、P75・P90領域の改善に取り組むとしています。今回の刷新は、Rails TurboとReactを併用する大規模Webアプリにおけるパフォーマンス改善の実例として、フロントエンドエンジニアにとって参考価値の高い事例といえます。