パフォーマンス

Web パフォーマンスの目標と、画像・JavaScript・配信について守る判断基準を定める

このページは、museum アプリの Web パフォーマンスについて、チームの目標と守るべき判断基準を定める。一般的な解説は外部の出典に譲り、本ページには本チーム固有の決定だけを書く。閾値や予算は機械的な合否判定ではなく、実ユーザーで検証する目標として扱う。

このアプリは画像を主体とするデジタルアーカイブであり、パフォーマンスの最大のレバーは画像と JavaScript である。まず目標と計測の考え方を示し、その後でレバーごとの具体的な指針を述べる。

目標（Core Web Vitals）

実ユーザー（フィールド）の 75 パーセンタイルで、次を目標とする。

補助指標として TTFB・FCP・TBT も参考にする。これらの数値はあくまで目標であり、絶対の合否基準としては運用しない。最終的な良し悪しはフィールドで判断する。

推測で最適化しない。まず計測し、ボトルネックを特定してから手を入れる。早すぎる最適化は、効果の無い複雑さを持ち込むため避ける。

画像はこのアプリで最大のレバーである。

表示領域をアスペクト比で予約し、読み込み後のズレ（CLS）を防ぐ。Thumbnail はこの方針で実装してある。
用途に応じた派生サイズを要求する（一覧は小さく、詳細は大きく）。可能なら srcset / sizes で解像度を出し分ける。
ファーストビューの外にある画像は遅延読込（loading="lazy"）にする。ファーストビュー内で最大の画像（LCP の候補）は遅延させず優先的に読み込む。
画像の配信元が別オリジン（IIIF など）のときは、その origin へ preconnect して接続確立の待ちを減らす。

本アプリは任意の IIIF オリジンを扱うため、Thumbnail は next/image ではなく意図的にプレーンな img 要素を使う（remotePatterns の制約を回避するためである）。その代償として、next/image が自動化する次の項目を自前で守る必要がある。

送る量を減らすことが効く。

既定は Server Component とする。'use client' は対話が要る末端に限定し、クライアント境界を小さく保つ。
重い依存（高解像度ズームの DeepZoomViewer など）は動的 import でコード分割し、必要になったときにだけ読み込む。
集約バレルを作らずツリーシェイクを効かせる。Icon は curated registry を介し、使うアイコンだけを静的 import する。
アニメーションは Composite のみで処理できる transform と opacity に限定し、レイアウトを動かすプロパティをアニメートしない。理由と詳細はアニメーションに従う。これはメインスレッドを空け、INP を守ることにもつながる。