mcpField
T
taste-web-performance

taste-web-performance

github.com/madebymustafa開発20054 回インストール11 週間前に更新
リポジトリ

taste-web-performance について

ウェブデザインや開発を行うエージェント向けのパフォーマンス最適化スキルです。モバイルの Core Web Vitals とページ容量の予算を軸に、リソースごとの指針と Lighthouse による検証を示します。

主な機能

  1. 01モバイル性能と容量の予算設定
  2. 02フォント読み込みとレイアウト安定性の最適化
  3. 03画像の寸法、形式、レスポンシブ配信の指定
  4. 04CSS、JavaScript、外部スクリプトの制御
  5. 05Lighthouse による指標の検証と再確認

活用シーン

  1. 01マーケティングページの予算設定
  2. 02フォントや画像によるレイアウトシフトの調査
  3. 03静的ページのブロッキングリソース削減
  4. 04リソース変更後の性能指標の再確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/madebymustafa/design-taste --skill taste-web-performance

インストール後、Claude Code で/taste-web-performanceを入力して読み込まれたか確認します。

詳細

taste-web-performance

速度もデザインの一部です。見出しがずれたまま900msで描画されるヒーローは、壊れたヒーローです。

1. 予算(まず記録する)

モバイル端末(Macではなく、平均的なスマートフォン)でのp75を目標にします。

  • LCP < 2.5s — ヒーローのテキストまたは画像が最大のコンテンツ要素となり、すばやく描画される必要があります。
  • CLS < 0.1 — 最初に描画された後、要素が動かないようにします。フォント、画像、広告サイズのボックスはすべてCLSのリスクになります。
  • INP < 200ms — クリック時に長いタスクを待たせないこと。インタラクション時に、メインスレッドで重い処理を行うJavaScriptを実行しないこと。
  • マーケティングページの総ページ容量は≤ 1.5MB。「シンプルな」ページは500KB未満に抑えます。
  • ビルドノートに予算を明記します。予算が明記されていないページには、計画がありません。

2. フォントの読み込み(エージェントが最も失敗しやすい項目)

  • フォントファミリーは2つまで、スタイルは約4種類まで(デザインテイストのスキルですでに上限を設けています。コードでも徹底します)。
  • すべてのWebフォントにfont-display: swapを指定し、フォントの読み込み後にテキストがずれないようにします。スペースを確保するか、移動を≤ 3pxに抑えます。
  • ヒーローのフォントフェイスをpreloadします(woff2のみ)。それ以外は遅延読み込みするか、適切なunicode-rangeのサブセットから読み込みます。
  • CSSで@importを使わないでください(描画をブロックします)。初回描画をブロックするフォント読み込みスクリプトも、現在のルートで使わないフォントの読み込みも禁止です。
  • パックのディスプレイフォントが装飾的な場合は、ヒーローより下ではすべてシステムフォントをフォールバックにすることを検討します。そのフォントの個性が活きるのは見出しです。

3. 画像(すべての画像について方針を決める)

  • すべての画像に明示的なwidth/height(またはaspect-ratio)を指定します。コストのかからないCLS対策です。
  • フォーマットは実行時にAVIF/WebPを使い、PNGは本当に透過が必要な場合のみ使用します。マーケティングページで2MBのJPEGを使うのは禁止です。
  • レスポンシブ配信にはsrcset/sizesを使用します。ファーストビューより下の画像にはloading="lazy"を、LCP画像にはfetchpriority="high"を指定します。
  • 装飾画像はCSS(グラデーション、ノイズ、パターン)で表現します。400KBの画像で背景を「解決」するエージェントは、予算だけでなくデザインにも失敗しています。
  • ヒーロー画像はCSSで無理に引き伸ばさず、マークアップで適切なアスペクト比にトリミングします。

4. CSSとJSの配信

  • CSSは1ファイルにまとめるか、ルートごとにクリティカルCSSを使います。2セクションのページにフレームワークのスタイルシートを使ったり、初期状態で不要なユーティリティを大量に含めたりしないでください。
  • インタラクションに不可欠でないものはすべてJSにdeferを指定します。静的ページにフレームワークは不要です(ランディングページにReactを含める理由はありません)。
  • 重要な読み込み経路に、同期実行されるサードパーティスクリプト(チャットウィジェット、分析ツール)を置かないでください。分析ツールを読み込む場合は、インタラクション後に読み込みます。
  • アニメーションにはtransform/opacityのみを使用します(taste-motionを参照)。スクロール時にtop/width/box-shadowをアニメーションさせるのは、機能ではなくカクつきの原因です。

5. 検証の手順(必ず実施する)

  1. ビルド後、スロットリングしたプロファイル(モバイル、Slow 4G)でLighthouseを実行します。localhostのMacでは実行しないでください。
  2. 3つのバイタルとページ容量を報告します。予算を超えた場合は修正するか、理由を記録します。
  3. 画像またはフォントを変更したら再確認します。気づかないうちにリグレッションするのは、この2つが原因です。
  4. prefers-reduced-motionへの対応と、オフラインでも使えるフォントは追加の選択肢ではなく、必須要件です。

6. チェックリスト(該当するページは不合格)

  • swapを指定せず、テキストの寸法も確保していないフォントがある。またはフォントファミリーが2つを超えている。
  • 寸法やフォーマットの方針が決まっていない画像がある。またはヒーロー画像を遅延読み込みしている。
  • 再読み込み時に目に見えるレイアウトシフトがある(実際にテストしてください。シフトは自分のことを隠します)。
  • 描画をブロックするスクリプト/スタイルシート、@import、または静的ページに含めたフレームワークがある。
  • ページ容量またはバイタルが予算を超えており、理由も明記されていない。
  • そのページのLighthouse実行記録がない。
  • デザインは今風でも、動作は2015年のようである。

コメント