frontend-performance

フロントエンドのパフォーマンス

Lighthouse のスコアと実ユーザーのパフォーマンスを最大化できるよう、フロントエンドアプリケーションを最適化します。このスキルでは技術的なパフォーマンスの側面を扱います。見た目については sheleg-design、インターフェースが何をするべきかについては super-ux を参照してください。

監査ワークフロー

1. 測定 — PageSpeed Insights または Lighthouse（Chromium）を実行し、まず WebKit で同じシナリオを読み込みます（下記の テストブラウザー を参照）。スコア、失敗した監査項目、各数値を計測したエンジンを記録します。
2. 原因の特定 — 失敗した各監査項目を、コードレベルの具体的な原因に結び付けます（下記のチェックリストを参照）。
3. 優先順位付け — 影響度に応じて修正します。P0 はレンダリングをブロックし、P1 は指標を悪化させ、P2 は情報提供のみです。
4. 実装 — リファレンスガイドに従って修正を適用します。
5. 検証 — next build（またはフレームワークに相当するコマンド）を実行し、Lighthouse と WebKit で再度実行します。どちらのエンジンでもリグレッションがないことを確認します。

テストブラウザー — まず WebKit（Safari）

まず WebKit でページを読み込み、プロファイリングします。実ブラウザーには safaridriver を通じて Safari を使用します （WebDriver。初回のみ sudo safaridriver --enable を実行します）。スクリプト実行とトレースには Playwright の webkit（webkit プロジェクト、--browser webkit、npx playwright install webkit でインストール）を使用し、デバッグには Safari Web Inspector の Timelines を使用します。macOS ではシステムのデフォルトブラウザー（別のエンジンの場合があります）ではなく、 open -a Safari <url> でページを開きます。自動化ライブラリ（browser-use など）は、利用可能であれば WebKit/Safari バックエンドで実行します。主要な 3 つのエンジンのうち、WebKit のサポート範囲は最も狭いため、iOS Safari のユーザーだけが感じるリグレッションは、以下の Chrome 用ツールではすべて見逃されます。

Lighthouse、PageSpeed Insights、CrUX、CDP トレース、chrome-devtools MCP は、定義上 Chromium です。これらは、このワークフロー内で明示された Chromium の例外として扱います。タスクで Chrome 自体が必要な場合に使用し、どれを使用したか、その理由も明記してください。自分で Chrome を起動して実行する場合は、Chrome Dev ビルドを優先してください。一時プロファイル（ユーザーのものは使用しないでください）を割り当て、起動したものを記録し、作業終了前に起動したすべてのプロセスを終了します。Chromium だけで確認したページは「Chromium だけで確認済み」と報告し、「ブラウザーでテスト済み」とは報告しません。Lighthouse のスコアは Chrome のラボ測定値であり、クロスブラウザーでの評価ではありません。

Core Web Vitalsと、それに関連する診断指標

独立した2つの軸があり、これらを混同するのがよくある間違いです。 1つ目の軸は、 Core Web Vitalかどうか — Googleが報告し、ランキングに使用する指標（LCP、INP、CLS） かどうかです。2つ目の軸は、どこで測定できるか — フィールド（実際のユーザー、 CrUX）か、ラボ（合成テスト）のみかです。この2つは一致しません。Core Web Vitalでは ない指標でも、フィールドで測定できる場合があります。FCPは、1つの軸だけでは説明 できない例です。Core Web Vitalではありませんが、フィールドで測定できます （CrUXはFCPを報告し、web.devはラボとフィールドの両方の測定ツールを掲載しています）。 「フィールドで測定できるのは3つのCWVだけ」という先の主張は誤りでした。

指標	Core Web Vitalか？	フィールドで測定可能か？	良好	要改善	不良
LCP	はい	はい（CrUX）	< 2.5s	2.5-4.0s	> 4.0s
INP	はい	はい（CrUX）	< 200ms	200-500ms	> 500ms
CLS	はい	はい（CrUX）	< 0.1	0.1-0.25	> 0.25
FCP	いいえ	はい（CrUX）	< 1.8s	1.8-3.0s	> 3.0s
TBT	いいえ	いいえ（ラボのみ）	< 200ms	200-600ms	> 600ms
SI	いいえ	いいえ（ラボのみ）	< 3.4s	3.4-5.8s	> 5.8s

フィールドの測定値を示す場合は、必ずその出所も示します。p75（Googleが分類に使用 する75パーセンタイル値であり、平均値ではありません）、デバイス／コホート（スマート フォンかデスクトップか、および対象の母集団）、期間（CrUXは直近28日間の移動期間 です）、そしてサンプルサイズ（オリジンのデータが少ない場合はフィールドデータが なく、それは「良好」ではなくunknownです）。この4つを伴わない数値は、フィールド ラベルを付けたラボの測定値にすぎません。

TBTはINPと相関する診断指標であり、INPのエビデンスの代わりにはなりません。 ラボでTBTが良好ならINPも問題ない可能性を示しますが、INPはラボで実行していない実際の 操作を測定するため、TBTが良好でもINPを証明することはできません。そのため、CrUXの FCPデータとLighthouseのTBTがあってもフィールドのINPがないページは、FCP = フィールドデータで裏付けあり、INP = unknownと報告します。「TBTによってINPに合格 した」と報告することはありません。Speed IndexがCore Web Vitalとして不合格だと クライアントに伝えるのは、Googleがランキングに使用していないものについて伝えること です。TBTの結果によってINPに合格したと伝えるのは、誰も行っていない測定について伝える ことです。

しきい値と分類はweb.dev/articles/vitalsを参照し、2026-08-16に検証しました。

パフォーマンスチェックリスト

フォント（LCP、FCP）

• フォントをセルフホストする -- <link>タグを使って外部CDNから読み込まないでください。フレームワークのフォント最適化機能（next/font/google、@fontsourceなど）を使い、CSSをインライン化してファイルをセルフホストしてください。
• 重要なフォントをプリロードする -- LCP要素で使用するフォントは、早い段階で読み込む必要があります。
• フォントファミリーを制限する -- 最大3ファミリーです。ファミリーごとに約20～50KB増加します。
• フォントをサブセット化する -- 必要な文字セット（latin、latin-ext）のみを読み込みます。
• font-display: swapを使う -- 読み込み中にテキストが見えなくなるのを防ぎます（FOIT）。
• 未使用のpreconnectを削除する -- フォントをセルフホストしている場合、フォントCDNへのpreconnectは無駄です。

これらの変更を行う前に、必ず測定し、決めつけないでください。 以下の項目は 最適化のヒューリスティックであり、すべてに適用するルールではありません。それぞれ エビデンスに基づいて適用する必要があり、根拠なく適用すると、スコアのために機能を 損なう可能性があります。何かを変更する前に、次の3点を確認してください。 パフォーマンストレースとシナリオ（低速なネットワークを使うローエンドデバイスが 実際に何を待つのか）、ブラウザーサポートの契約（誰に対してページの動作を維持 する必要があるか）、そしてアクセシビリティの担当者（構造はスコアではなく担当者 の領域です）。変更をリリースするのは、次の条件を網羅した受け入れ確認を行う場合に 限ります。ローエンドデバイス／低速ネットワークのシナリオに対応していること、 キーボード操作と見出し構造を維持していること、サポート対象のブラウザーマトリクスに 引き続き対応していること、承認されていないCSPオリジンを新たに追加していないこと、 そして機能を損なわずに改善できたことを示す、複数の比較可能な変更前／変更後の測定 結果があること。

JavaScript（TBT、FCP、LCP）

• 実測したウォーターフォールに基づいてコードを分割します -- トレースで初回描画に不要と確認できたものを遅延読み込みします。「ヒーローとナビだけを初期バンドルに含める」は出発点となる仮説であり、ルールではありません。シナリオでファーストビューに必要なセクションは、スコアにかかわらず残します。
• サードパーティのスクリプトを遅延させます -- GA、アナリティクス、チャットウィジェットは、インタラクティブになった後（afterInteractive または defer）に読み込みます。
• ユーザーが利用しているブラウザーを対象にします -- browserslist はデフォルトの「直近2バージョン」ではなく、明示されたユーザーサポート方針（アナリティクスや契約）に従います。以下の last 2 は例です。対象から外すユーザーを確認せずにこれを適用すると、ポリフィルの削減と引き換えに、実際に使えていたブラウザーがサポートされなくなる可能性があります。

  # example only — replace with your measured support matrix
  last 2 Chrome versions, last 2 Firefox versions, last 2 Safari versions, last 2 Edge versions
  

• インポートをツリーシェイクします -- バンドルアナライザーで import * as が不要なコードを取り込んでいるとわかった場合は、名前付きインポートを優先します。これはツリーシェイクを助ける手段であり、禁止事項ではありません。実測してコストがない名前空間インポートは問題ではありません。
• バンドルを分析します -- @next/bundle-analyzer、source-map-explorer、または vite-plugin-visualizer を使用します。

CSS とアニメーション（CLS）

• 合成処理のみでアニメーションします -- アニメーションさせるのは transform と opacity（GPU 合成）のみにします。background-position、width、height、top/left、margin、padding はアニメーションさせません。
• will-change は控えめに使います -- 実際にアニメーションする要素にのみ、will-change: transform または will-change: filter を追加します。
• クリティカル CSS をインライン化します -- フレームワークに任せます（Next.js では自動的に行われます）。
• レイアウトシフトを避けます -- 画像と埋め込みコンテンツには明示的な width と height を設定します。動的コンテンツ用のスペースを確保します。

画像（LCP、CLS）

• <Image> コンポーネントを使います -- フレームワーク最適化コンポーネント（next/image、Astro の <Image>）は、自動的にサイズを調整し、WebP/AVIF に変換し、width/height を追加します。
• LCP 画像を優先読み込みします -- ヒーロー/LCP 画像に priority（Next.js）または fetchpriority="high" を追加します。
• ファーストビューより下の画像を遅延読み込みします -- 初期ビューポートより下にあるすべての画像に loading="lazy" を設定します。
• サイズの目安：ヒーローは 200KB 未満、サムネイルは 50KB 未満、アイコンは SVG にします。
• レスポンシブな sizes -- レスポンシブ画像には必ず sizes 属性を指定します。

キャッシュ（再訪時）

• 静的アセット：ハッシュ付きファイル（JS、CSS、フォント、画像）には Cache-Control: public, max-age=31536000, immutable を設定します。
• HTML：Cache-Control: public, max-age=0, must-revalidate（またはフレームワークのデフォルト）を設定します。
• パターンを検証します -- キャッシュヘッダーの source パターンを実際の URL に対してテストします。よくある間違いとして、glob 形式のパターン（{.svg,.png}）は、すべてのフレームワークのパスマッチングで機能するわけではありません（例：Next.js は path-to-regexp を使用します）。代わりに正規表現のパラメーター構文を使います。

  /:path*.:ext(svg|png|jpg|jpeg|gif|webp|ico|woff|woff2)
  

コンテンツセキュリティポリシー（ベストプラクティス）

• スコアではなく、機能上の必要性に基づいてオリジンを承認します -- オリジンを CSP に追加するのは、ページで本当に必要であり、個別にレビューした場合に限ります。コンソールエラーを抑えるためにページが読み込むものをすべて許可リストに追加すると、CSP の本来の目的をベストプラクティスのスコアと引き換えにすることになります。新しいオリジンは、承認なしに公開しません。
• サードパーティを変更するたびに監査します -- アナリティクス、フォント、CDN スクリプトの追加には CSP の更新が必要です。
• 移行後に制限を強化します -- 外部フォントからセルフホストに切り替えた場合は、古い CSP エントリーを削除します。
• 一般的な CSP オリジン：
  • Google Analytics：https://www.googletagmanager.com、https://www.google-analytics.com
  • Cloudflare：https://static.cloudflareinsights.com
  • Stripe：https://js.stripe.com

アクセシビリティ（Lighthouse A11y スコア）

これらは Lighthouse のアクセシビリティスコアに直接影響します。

• コントラスト比 -- WCAG AA では通常のテキストに 4.5:1、大きなテキストに 3:1 が求められます。テキストカラーに不透明度修飾子を使わないでください（例：Tailwind の text-primary/80 はコントラストを低下させます）。不透明度 100％のカラー トークンを使用してください。
• 見出し階層は構造に従い、アクセシビリティ担当者と決定します -- h1->h2->h3 のように順番に並べ、レベルを飛ばさないでください。見出しを <p> に格下げするのは、本当にセクションタイトルではない場合に限ります。Lighthouse の監査を回避するために、実際のフッターセクションの見出しを <p> に格下げすると、スクリーンリーダーのユーザーが移動に使う構造が失われます。ここで優先されるのはスコアではなく、アクセシビリティです。
• 代替テキスト -- 同じテキストの横にある装飾画像には alt="" を指定します。情報を伝える画像には、内容を説明する代替テキストを指定します。隣接するテキストと重複させないでください。
• タップ対象 -- モバイルでは最低 48x48px が必要です。ボタン、リンク、フォーム入力欄に適用されます。

フレームワーク別ガイド

• Next.js：next/font、next/image、next/dynamic、next/script、next.config のキャッシュヘッダー、CSP の設定、バンドル分析については、references/nextjs.md を参照してください。
• CSS／アニメーション：合成ルール、グラデーションアニメーションの代替手段、will-change の使用方法、クリティカル CSS の戦略については、references/css-performance.md を参照してください。
• アクセシビリティ：コントラストの計算方法、見出し階層のルール、Lighthouse に影響する ARIA パターンについては、references/accessibility-perf.md を参照してください。

PageSpeed でよく発生する失敗と修正方法

監査	原因	修正方法
"Eliminate render-blocking resources"	外部フォント CSS、大きな CSS ファイル	フォントをセルフホストし、クリティカル CSS をインライン化する
"Reduce unused JavaScript"	ページ全体のバンドルを最初に読み込む	動的インポートでコード分割する
"Avoid non-composited animations"	background-position、width などのアニメーション	transform／opacity／filter に置き換える
"Serve static assets with efficient cache policy"	Cache-Control ヘッダーがない、または有効期間が短い	ハッシュ付きアセットに max-age=31536000, immutable を設定する
"Background/foreground colors do not have sufficient contrast"	テキストカラーの不透明度修飾子	不透明度 100％のカラートークンを使用する
"Heading elements not in sequential order"	見出しレベルが飛んでいる（h1 -> h4）	階層を修正するか、構造上の見出しではない場合は <p> を使用する
"Browser errors logged to console"	CSP によってスクリプト／スタイルがブロックされている	CSP で必要なオリジンを許可リストに追加する
"Image elements do not have [alt] attributes"	代替テキストがない、または重複している	内容を説明する代替テキストを追加するか、装飾画像には alt="" を指定する
"Avoid chaining critical requests"	ブロックするリソースがウォーターフォール状に連続している	重要なリソースをプリロードし、セルフホストする
"Legacy JavaScript"	最新の API に対するポリフィル	browserslist のターゲットを更新する

パフォーマンス予算テンプレート

ランディングページには、以下の上限を設定します。

リソース	予算
ページ全体のサイズ	< 1.5 MB
JavaScript（圧縮後）	< 200 KB
CSS（圧縮後）	< 50 KB
フォント（合計）	< 150 KB
ヒーロー画像	< 200 KB
LCP	< 2.5s（モバイル）
FCP	< 1.8s（モバイル）
CLS	< 0.1
TBT	< 200ms

関連スキル

• sheleg-design -- ページの見た目と動きについて。ここに記載された数値が制約するモーション予算も含みます
• super-ux -- インターフェースに必要な機能と、ページの表示が遅いと失われるユーザーフローについて
• seo-aeo-audit -- 技術 SEO とクロール可能性について。ラボではなく実環境から同じ Core Web Vitals を確認します

以前ここに記載されていた 4 つの名前、frontend-design、landing-page-design、 next-best-practices、responsive-design は、インストール可能なものに解決されず、 seo-audit は実際の seo-aeo-audit と文字クラス 1 つ分しか違わなかったため、 レビューをすり抜ける誤字が生まれました。

制約

• Claude Code 以外の場合（Cursor、Codex、skills CLI、API コンテナ）：このパックの PreToolUse ゲートは実行されません。ここに記載されたルールはすべて引き続き適用されますが、 フックではなく人が徹底します。
• ブラウザチャンネルがない場合（safaridriver、Playwright の webkit、Chrome DevTools MCP がない場合）：ページは差分から評価され、 数値はこのマシンでは測定されません。より限定的な主張を記録してください。 誰も測定していない Lighthouse スコアは、スコアではありません。
• ネットワークがない場合：PageSpeed Insights とフィールドデータは利用できません。ラボデータに基づく 推論にも価値はあります。どちらを実施したかを明記してください。

トリガー

ここに振り分けるその他のフレーズ：「パフォーマンス監査」、「LCP」、「CLS」、「INP」、「レンダリングをブロックする」、 「コード分割」、「遅延読み込み」、「キャッシュヘッダー」、「速度の最適化」。

0.16.2 の説明からここに移動：「バンドルサイズ」。