high-perf-browser
ネットワークプロトコル・リソース読み込み・ブラウザレンダリングの内部動作を通じてWebパフォーマンスを最適化するスキル。「ページ読み込み速度」「Core Web Vitals」「HTTP/2」「リソースヒント」「レンダーブロッキング」「Service Worker」「クリティカルレンダリングパス」などが話題に上がった場合や、低速ページの診断・TTFB最適化・WebSocketとSSEの選定・バンドルサイズ削減が必要な場面でトリガーされる。TCP/TLSチューニング・キャッシュ戦略・プロトコル選択を幅広くカバーし、UIの視覚的パフォーマンスはrefactoring-ui、フォント読み込みはweb-typographyを参照。
description の原文を見る
Optimize web performance through network protocols, resource loading, and browser rendering internals. Use when the user mentions "page load speed", "Core Web Vitals", "HTTP/2", "resource hints", "network latency", "render blocking", "TCP optimization", "service worker", or "critical rendering path". Also trigger when diagnosing slow page loads, optimizing time to first byte, choosing between WebSocket and SSE, or reducing bundle sizes. Covers TCP/TLS optimization, caching strategies, WebSocket/SSE, and protocol selection. For UI visual performance, see refactoring-ui. For font loading, see web-typography.
SKILL.md 本文
高性能ブラウザネットワーキングフレームワーク
ブラウザ、プロトコル、ネットワークの実際の動作に基づいた、体系的なウェブパフォーマンス最適化アプローチです。フロントエンドアプリケーションの構築、パフォーマンスバジェットのレビュー、サーバの設定、あるいは遅いページロードの診断時に、これらの原理を適用してください。
コア原理
ボトルネックは帯域幅ではなく遅延です。 ほとんどのウェブパフォーマンスの問題は、スループットの不足ではなく、ラウンドトリップが多すぎることから生じています。帯域幅を5倍にしても効果は限定的ですが、遅延を5分の1に削減すればユーザー体験が劇的に改善します。
基礎： すべてのネットワークリクエストはコンテンツの1バイトが届く前に、DNS解決、TCP三者間ハンドシェイク、TLS交渉、HTTP交換を通過します。各ステップはラウンドトリップ遅延を追加します。高性能アプリケーションはラウンドトリップを最小化し、リクエストを並列化し、不要なネットワークホップを排除します。プロトコルスタックを理解することはオプションではなく、意味のある最適化の前提条件です。
スコアリング
目標：10/10。 ウェブアプリケーションをレビューまたは構築する際、以下の原理への準拠に基づいてパフォーマンスを0～10で評価してください。10/10は全てのガイドラインへの完全準拠を意味し、低いスコアは対処が必要なギャップを示しています。常に現在のスコアと、10/10に到達するために必要な具体的な改善を提供してください。
高性能ブラウザネットワーキングフレームワーク
高速で耐障害性のあるウェブアプリケーション構築のための6つのドメイン：
1. ネットワークの基礎
コアコンセプト： すべてのHTTPリクエストは遅延税を支払います。DNS参照、TCPの3段階ハンドシェイク、TLSネゴシエーション――これらはすべてアプリケーションデータが流れる前に発生します。これらのラウンドトリップを削減または排除することが、単一の最大レバレッジ最適化です。
なぜ機能するか： 光は有限の速度で移動します。ニューヨークからロンドンへのパケットは、帯域幅に関係なく片道約28msかかります。TCPスロースタートは新しい接続が低速で送信を開始することを意味します。TLSはさらに1～2つのラウンドトリップを追加します。これらの物理的制約はより大きなパイプでは解決できず、トリップ数を減らすことでのみ解決できます。
主要なインサイト：
- TCPの3段階ハンドシェイクはデータ転送開始前に1つのフルRTTを追加
- TCPスロースタートは初期スループットを最初のラウンドトリップで～14KB（10セグメント）に制限――クリティカルリソースはこのしきい値より下に保つ
- TLS 1.2は2RTTを追加；TLS 1.3はこれを1RTTに削減（セッションレジューメーションで0-RTT）
- TCPのヘッドオブラインブロッキングは、1つのロストパケットがその接続上のすべてのストリームを停止させることを意味
- 帯域幅遅延積は飛行中データ容量を決定；高遅延リンクは帯域幅を十分に利用しない
- DNS解決は20～120msを追加；
dns-prefetchで事前解決
コード応用：
| コンテキスト | パターン | 例 |
|---|---|---|
| 接続ウォームアップ | クリティカルオリジンへの事前接続確立 | <link rel="preconnect" href="https://cdn.example.com"> |
| DNS先読み | サードパーティドメインを早期に解決 | <link rel="dns-prefetch" href="https://analytics.example.com"> |
| TLS最適化 | TLS 1.3とセッションレジューメーション有効化 | サーバ設定：ssl_protocols TLSv1.3;とセッションチケット |
| 初期ペイロード | クリティカルHTMLを圧縮後14KB以下に維持 | クリティカルCSSをインライン化、非必須スクリプトは延期 |
| 接続再利用 | 繰り返されるハンドシェイクを避けるためキープアライブ接続 | Connection: keep-alive（HTTP/1.1以降でデフォルト） |
参考：references/network-fundamentals.mdでTCP輻輳制御、帯域幅遅延積、TLSハンドシェイク詳細を確認
2. HTTPプロトコル進化
コアコンセプト： HTTPはシンプルなリクエスト/レスポンスプロトコルから多重化、バイナリ、サーバプッシュ対応システムへ進化しました。正しいプロトコルバージョンを選択し、適切に設定することで、パフォーマンス問題のカテゴリ全体を排除します。
なぜ機能するか： HTTP/1.1は複数のリクエストを多重化できないため、ドメインシャーディングやスプライトシートのような回避策をブラウザに強制します。HTTP/2は多重化を解決しますがTCPのヘッドオブラインブロッキングを継承します。HTTP/3（QUIC）はUDPに移行し、ヘッドオブラインブロッキングを排除し接続マイグレーション可能にします。各世代がボトルネックを1つ削除します。
主要なインサイト：
- HTTP/1.1はTCP接続あたり1つのアウトスタンディングリクエストのみ許可；ブラウザはホストあたり6接続を回避策として開く
- HTTP/2は1つのTCP接続上で無制限ストリームを多重化し、ドメインシャーディングを非生産的にする
- HTTP/2のHPACKヘッダ圧縮は繰り返されるヘッダオーバーヘッドを85～95%削減
- HTTP/3はQUIC（UDP）上で実行され、TCPヘッドオブラインブロッキングを排除し0-RTT接続レジューメーション可能に
- サーバプッシュ（HTTP/2）はブラウザがリクエストする前にリソースを送信――使用は控えめに、代わりに
103 Early Hintsを推奨 - HTTP/2の接続統合は1つの接続で証明書を共有する複数ホストを処理可能
コード応用：
| コンテキスト | パターン | 例 |
|---|---|---|
| HTTP/2移行 | HTTP/1.1回避策を削除 | ドメインシャーディング廃止、スプライトシート削除、ファイル連結停止 |
| ストリーム優先順位付け | リソース重要性をサーバに通知 | CSSとフォント最高優先度；画像は低優先度 |
| 103 Early Hints | フル応答前にプリロードヒント送信 | サーバがLink: </style.css>; rel=preloadを伴う103を送信 |
| QUIC/HTTP/3 | CDNまたはオリジンでHTTP/3有効化 | Alt-Svc: h3=":443"ヘッダ追加でHTTP/3サポートをアドバタイズ |
| ヘッダ最適化 | オーバーヘッド削減のため定義ヘッダ最小化 | クッキーと定義ヘッドを監査；不要なもの削除 |
参考：references/http-protocols.mdでプロトコル比較、移行戦略、サーバプッシュ vs. Early Hints
3. リソース読み込みとクリティカルレンダリングパス
コアコンセプト： ブラウザはピクセルを描画する前にDOM、CSSOM、レンダリングツリーを構築する必要があります。このパイプラインをブロックするリソースはすべてファーストペイントを遅延させます。クリティカルレンダリングパスを最適化することはこれらのボトルネックを特定し排除することを意味します。
なぜ機能するか： CSSはレンダリングをブロック：すべてのCSSが解析されるまでブラウザは描画しません。JavaScriptはデフォルトでパーサブロッキング：<script>はスクリプトがダウンロードと実行まで完了するまでDOM構築を停止させます。フォントはテキスト描画を最大3秒ブロック可能。各ブロッキングリソースはファーストペイント時間に直接遅延を追加します。
主要なインサイト：
- クリティカルレンダリングパス：HTMLバイト → DOM → CSSOM → レンダリングツリー → レイアウト → ペイント → 合成
- CSSはレンダリングをブロック；JavaScriptはパーサをブロック――これらは異なる最適化戦略を持つ
asyncはスクリプトを並列ダウンロードして即座に実行；deferは並列ダウンロードしてDOM解析後に実行<link rel="preload">はクリティカルリソースをレンダリングをブロックせずに高優先度で取得<link rel="prefetch">は可能性の高い次ナビゲーションのリソースを低優先度で取得- インラインクリティカルCSS（ビューポート上部スタイル）とレンダリングブロッキングCSS要求を排除するため残り分を延期
- フォント：
font-display: swapでフォント読み込み中の不可視テキストを避ける
コード応用：
| コンテキスト | パターン | 例 |
|---|---|---|
| クリティカルCSS | <head>内にビューポート上部スタイルをインライン化 | <style>/* critical styles */</style> + フルCSS非同期読み込み |
| スクリプト読み込み | ほとんどのスクリプトでdefer；独立スクリプトでasync | <script src="app.js" defer></script> |
| リソースヒント | クリティカルフォント、ヒーロー画像、ビューポート上部アセットをプリロード | <link rel="preload" href="font.woff2" as="font" crossorigin> |
| 画像最適化 | ビューポート下部画像遅延読み込み；モダンフォーマット使用 | <img loading="lazy" src="photo.avif" srcset="..."> |
| フォント読み込み | font-displayで不可視テキストを防止 | @font-face { font-display: swap; } |
参考：references/resource-loading.mdでasync/defer動作、リソースヒント戦略、画像最適化
4. キャッシング戦略
コアコンセプト： 最速のネットワークリクエストは発生しないものです。ブラウザメモリ、ディスクキャッシュ、サービスワーカー、CDN、オリジンの層状キャッシング戦略は、リピートビジターと後続のナビゲーション時の読み込み時間を劇的に削減します。
なぜ機能するか： Cache-Controlヘッダはブラウザと中間機にレスポンスが有効なままである期間を正確に指定します。コンテンツハッシュURLはアグレッシブな不変キャッシングを可能に。サービスワーカーはオフライン対応の可視化可能キャッシュレイヤーを提供。各キャッシュヒットはフルネットワークラウンドトリップを排除します。
主要なインサイト：
Cache-Control: max-age=31536000, immutableをコンテンツハッシュ静的アセット（JS、CSS、画像）用にCache-Control: no-cacheはキャッシュし続けるが毎回レバリデート――HTMLドキュメント用ETagとLast-Modifiedは条件付きリクエスト（304 Not Modified）を可能にして帯域幅節約stale-while-revalidateはバックグラウンドで新鮮なコピーを取得しながら即座にキャッシュコンテンツを提供- サービスワーカーはフェッチリクエストをインターセプトしてキャッシュから提供、ネットワークにフォールバック、またはカスタム戦略を実装可能
- CDNキャッシングはコンテンツをユーザーに近づけ、RTTを削減；
Varyヘッダを正確に設定してキャッシュポリューションを避ける
コード応用：
| コンテキスト | パターン | 例 |
|---|---|---|
| 静的アセット | ハッシュバスティング付き長期間不変キャッシュ | style.a1b2c3.cssでCache-Control: max-age=31536000, immutable |
| HTMLドキュメント | 毎回レバリデート | ETagを伴う条件付きリクエスト用Cache-Control: no-cache |
| APIレスポンス | 短いTTLで古い間に再検証 | Cache-Control: max-age=60, stale-while-revalidate=3600 |
| オフラインサポート | サービスワーカーキャッシュファーストパターン | 静的シェルをキャッシュ；ダイナミックコンテンツはネットワークファースト |
| CDN設定 | 適切なVaryヘッダで縁でキャッシュ | Vary: Accept-Encoding, Acceptで間違ったフォーマット提供を防止 |
参考：references/caching-strategies.mdでキャッシュ階層、サービスワーカーパターン、CDN設定
5. Core Web Vitals最適化
コアコンセプト： Core Web Vitals――LCP、INP、CLS――はGoogleのユーザー中心パフォーマンスメトリクスで、検索ランキングとユーザー体験に直接影響。各メトリクスは異なるフェーズをターゲット：読み込み（LCP）、相互作用性（INP）、ビジュアル安定性（CLS）。
なぜ機能するか： これらのメトリクスはユーザーが実際に体験することを測定します。ページは高速TTFBを持つ可能性がありますが、ヒーロー画像の読み込みが遅い場合は悪いLCP。ページは高速で読み込まれる可能性がありますが、メインスレッドJavaScriptが入力処理をブロックする場合は遅くなります（悪いINP）。これらのメトリクスのために最適化することは実ユーザー知覚のために最適化することを意味します。
主要なインサイト：
- LCP（最大コンテンツフル塗装）：目標 < 2.5s――最大可視要素（ヒーロー画像、見出しブロック、またはビデオポスター）を最適化
- INP（相互作用から次ペイント）：目標 < 200ms――メインスレッドを自由に保つ；長いタスクを分割；
requestIdleCallbackを非緊急作業用に - CLS（累積レイアウトシフト）：目標 < 0.1――ダイナミックコンテンツのスペース予約；画像とエンベッドに明示的な寸法設定
- TTFB（最初のバイトまでの時間）：目標 < 800ms――サーバレスポンス時間最適化、CDN使用、圧縮有効化
- FCP（最初の描画）：目標 < 1.8s――レンダリングブロッキングリソース排除、クリティカルCSSをインライン化
- ラボ条件の合成テストではなく、本番環境で実ユーザーモニタリング（RUM）で測定
コード応用：
| コンテキスト | パターン | 例 |
|---|---|---|
| LCP最適化 | LCP要素をプリロード；fetchpriority="high"を設定 | <img src="hero.webp" fetchpriority="high"> |
| INP最適化 | 長いタスク分割；メインスレッドに譲歩 | scheduler.yield()または作業をチャンク化するsetTimeout |
| CLS防止 | 非同期コンテンツ用スペース予約 | <img width="800" height="600">またはCSSaspect-ratio |
| TTFB削減 | CDN、サーバ側キャッシング、ストリーミングSSR | Transfer-Encoding: chunkedを伴うエッジレンダリング |
| パフォーマンスバジェット | しきい値設定とデプロイをブロック超過時 | CI パイプラインでLCP < 2.5s、INP < 200ms、CLS < 0.1 |
参考：references/core-web-vitals.mdで測定ツール、デバッグワークフロー、最適化チェックリスト
6. リアルタイム通信
コアコンセプト： データがクライアントとサーバ間で継続的に流れる必要がある場合、正しいトランスポート――WebSocket、SSE、またはロングポーリング――を選択することは遅延、リソース使用、スケーラビリティを決定します。
なぜ機能するか： HTTPのリクエスト/レスポンスモデルはリアルタイムデータのオーバーヘッドを作成。WebSocketは最小限のフレーミングオーバーヘッド（フレームあたり～2バイト）を伴う永続全二重接続を確立。サーバ送信イベント（SSE）は標準HTTPを介したサーバ/クライアント向けプッシュより単純。正しい選択は通信が一方向か双方向、データがどのくらいの頻度で流れるか、インフラストラクチャ制約に依存します。
主要なインサイト：
- WebSocket：全二重、最小フレーミングオーバーヘッド、チャット、ゲーム、協調編集に理想的
- SSE：サーバ/クライアント方向のみ、自動再接続、HTTPプロキシ経由で動作、WebSocketより実装が単純
- ロングポーリング：WebSocket/SSE不可時のフォールバック；繰り返されたHTTPリクエストからの高オーバーヘッド
- WebSocket接続はHTTP/2多重化をバイパス――各WebSocketは個別TCPコネクション
- ハートビート/pingフレームを実装して死接続を検出；モバイルネットワークは無音でアイドル接続をドロップ
- 接続管理：再接続時指数バックオフ；切断中メッセージをキュー
コード応用：
| コンテキスト | パターン | 例 |
|---|---|---|
| チャット/協調編集 | ハートビートと再接続を伴うWebSocket | new WebSocket('wss://...')で30秒ごとにping |
| ライブフィード/通知 | サーバ/クライアントストリーミング用SSE | new EventSource('/api/updates')と自動再接続 |
| レガシーフォールバック | WebSocketブロック時ロングポーリング | ループでfetch('/poll')とタイムアウト |
| 接続復原力 | 再接続で指数バックオフ | 遅延：1s、2s、4s、8s...最大30sでキャップ |
| スケーリング | WebSocketサーバの背後でpub/subブローカー使用 | Redis Pub/SubまたはNATS水平スケーリング用 |
参考：references/real-time-communication.mdでWebSocketライフサイクル、SSEパターン、スケーリング戦略
よくある間違い
| 間違い | なぜ失敗するか | 修正 |
|---|---|---|
| 遅いページを修正するために帯域幅を追加 | ほとんどのウェブトラフィックではボトルネックは遅延で帯域幅ではない | ラウンドトリップ削減：preconnect、キャッシュ、CDN |
| すべてのJSを初期に読み込む | パーサブロッキングスクリプトはファーストペイントと相互作用性を遅延 | コード分割；defer使用；非クリティカルモジュール遅延読み込み |
| リソースヒント無し | ブラウザは解析中遅くにクリティカルリソースを発見 | ビューポート上部クリティカルリソース用にpreconnect、preload追加 |
Cache-Controlなし、またはどこにもno-store | 訪問するたびにオリジンからすべてのリソースを再ダウンロード | 静的アセット用適切なmax-age設定；コンテンツハッシング使用 |
| CLSを無視 | レイアウトシフトはユーザー信頼を破壊し検索ランキングを傷つける | すべての画像、エンベッド、広告に明示的な寸法設定 |
| すべてにWebSocketを使用 | SSEまたはHTTPポーリングで十分な場合の不要な複雑性 | トランスポートをデータフロー形式に一致；サーバプッシュ用SSE |
| HTTP/2でドメインシャーディング | 多重化を無視；余分なTCP接続を作成 | 1つのオリジンに統合；HTTP/2多重化を許可 |
| 圧縮なし | HTML、CSS、JSをフルサイズで転送、帯域幅浪費 | サーバとCDNでBrotli（推奨）またはGzip有効化 |
クイック診断
| 質問 | いいえの場合 | アクション |
|---|---|---|
| TTFBは800ms以下？ | サーバまたはネットワークが遅い | CDN追加、サーバキャッシング有効化、バックエンド確認 |
| LCPは2.5s以下？ | 最大要素が遅延読み込み | LCPリソースプリロード；fetchpriority="high"設定 |
| INPは200ms以下？ | 相互作用中メインスレッドがブロック | 長いタスク分割；非クリティカルJS延期 |
| CLSは0.1以下？ | レンダリング後に要素がシフト | 明示的な寸法設定；ダイナミックコンテンツ用スペース予約 |
| 静的アセットはコンテンツハッシュでキャッシュ？ | リピートビジターがすべて再ダウンロード | ファイル名にハッシュ追加；Cache-Control: immutable設定 |
| HTTP/2またはHTTP/3有効？ | 多重化とヘッダ圧縮欠落 | サーバでHTTP/2有効化；CDN経由HTTP/3追加 |
| レンダリングブロッキングリソースが最小化？ | CSSと同期JSがファーストペイント遅延 | クリティカルCSS をインライン化；スクリプトdefer；未使用CSS削除 |
| 圧縮有効（Brotli/Gzip）？ | 非圧縮テキストリソースを転送 | サーバ/CDNでBrotli有効化；Gzipにフォールバック |
リファレンスファイル
network-fundamentals.md：TCPハンドシェイク、輻輳制御、TLS最適化、DNS解決、ヘッドオブラインブロッキングhttp-protocols.md：HTTP/1.1回避策、HTTP/2多重化、HTTP/3とQUIC、移行戦略resource-loading.md：クリティカルレンダリングパス、async/defer、リソースヒント、画像とフォント最適化caching-strategies.md：Cache-Controlヘッダ、サービスワーカー、CDN設定、キャッシュ無効化core-web-vitals.md：LCP、INP、CLS最適化、測定ツール、パフォーマンスバジェットreal-time-communication.md：WebSocket、SSE、ロングポーリング、接続管理、スケーリング
さらに詳しく
このスキルはIlya Grigorikのブラウザネットワーキングとウェブパフォーマンスの包括的ガイドに基づいています：
- 「High Performance Browser Networking」（著者：Ilya Grigorik）――ネットワークプロトコル、ブラウザインターナル、パフォーマンス最適化のための完全な参考書
- hpbn.co――著者が保守している無料オンライン版
著者について
Ilya Grigorik はウェブパフォーマンスエンジニア、著作家、開発者アドボケート。Googleで10年以上、Chrome、ウェブプラットフォームパフォーマンス、HTTP標準に従事。W3C Web Performance Working Groupの共同議長で、HTTP/2および関連ウェブ標準の開発に貢献。著作『High Performance Browser Networking』（O'Reilly、2013）はブラウザがネットワークと相互作用する方法を理解するための決定的な参考書として広く認識――TCPおよびTLS基礎からHTTPプロトコル進化、リアルタイム通信パターンまで。Grigorikのアプローチは表面的なトリックを適用するだけではなく、基盤となるプロトコルを理解する必要があることを強調し、遅延はウェブパフォーマンスを形作る基本的制約です。
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- wondelai
- リポジトリ
- wondelai/skills
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/wondelai/skills / ライセンス: MIT
関連スキル
doubt-driven-development
重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。
apprun-skills
TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理（非同期ジェネレータを含む）、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。
desloppify
コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。
debugging-and-error-recovery
テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。
test-driven-development
テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。
incremental-implementation
変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。