2026年、静的 HTML のレスポンシブ画像：srcset と sizes、AVIF／WebP の picture、LCP の fetchpriority、CLS の寸法、クラウド Mac mini での Safari WebKit 査証

手書きに近い静的マーケページは読みやすい一方、3840 ピクセル級のJPEG一枚を載せて CSS で縮めるだけでは Largest Contentful Paint（LCP） が静かに崩れます。2026年 の現実的な下限は、<picture> でフォーマットを切り替え、幅記述子付き srcset とグリッドに忠実な sizes をそろえ、描画サイズに関係なく縦横比が漏れない width／height、必要ならプリロードと協調する優先度ヒントです。合成スコアだけで議論が終わらないよう、ラボとフィールドの読み比べは Core Web Vitals の Lighthouse と Safari フィールド を参照してください。

Apple Silicon の Mac mini を MacHTML 経由でおよそ 日 $16.9 で借りると、WebKitGTK の代理ではなく本物の Safari で AVIF／WebP の交渉やメモリ圧力下のデコード停滞を確認できます。自動化と実機の差は Playwright WebKit と実機 Safari の差 にもまとめています。

srcset の密度記述子と幅記述子

1x／2x のような x 記述子はカードやサムネのようにレンダリング幅がほぼ固定なら依然有用です。フルードレイアウトでは w 記述子と sizes の組が主流です。ディスクに無い幅を並べると Safari は近い候補を選びますが、実ファイルがレンダリングより 700 ピクセルも大きいとバイトの無駄だけが残ります。ランディングヒーローなら 480〜1920 ピクセル程度まで五段階ほど用意するのが運用上の楽です。

カード画像では密度記述子でも構いませんが、同一要素で w と x を混ぜないルールを README に書いておくと、無効フォールバックで最初の候補だけが選ばれる事故を防げます。

レスポンシブグリッドに合わせた sizes

sizes はファイル幅ではなく「描画される幅」を書きます。(min-width:1024px) 50vw, 100vw のようにメディア条件はコンポーネントの実際に合わせ、ページ全体のテンプレだけを写すとズレます。レイアウトが三分割に変わったら即座に更新しないとブラウザが過大なソースを取りに行き、LCP が悪化します。

コンテナクエリ対応のラッパに container-type:inline-size を置けば、静的 HTML でもモジュール入れ替え時に sizes の前提を崩しにくくなります。

picture・AVIF・WebP・JPEG

type="image/avif" を先に、続けて image/webp、最後に img でプログレッシブ JPEG。写真では AVIF が同品質比でおおむね三五〜五割バイト削減し、WebP は互換の安全網です。alt は img 側だけに置きます。

<picture>
  <source type="image/avif" srcset="/media/hero-800.avif 800w,
    /media/hero-1200.avif 1200w" sizes="(min-width:960px) 720px, 100vw">
  <source type="image/webp" srcset="/media/hero-800.webp 800w,
    /media/hero-1200.webp 1200w" sizes="(min-width:960px) 720px, 100vw">
  <img src="/media/hero-1200.jpg" width="1200" height="750"
       alt="製品ワークスペース" decoding="async" fetchpriority="high">
</picture>

観点	AVIF	WebP	JPEG
写真の粒立ち	高い	高い	基準
Apple Silicon でのデコード負荷	中程度	低め	極めて低い
2026年時点の Safari 到達	デスクトップ＋現行 iOS	広い	広い
CDN のキー設計	Vary 前提	別パス推奨	長尾も許容

fetchpriority・プリロード・遅延読み込みの境界

フォールド上のヒーローを一つだけ fetchpriority="high" にします。複数の high は帯域を奪い合います。ヒーローが週替わりキャンペーンなら条件付きプリロードは慎重に。折りたたみ線より下は loading="lazy"、ただし LCP 候補を遅延させないでください。モバイルでは Chrome と Safari で可視判定がずれることがあります。

decoding="async" はカードやギャラリー向き。ヒーローは計測次第で sync も検討しますが、M 系チップでは非同期でもペイント順が効くケースが多いです。

CLS を抑える固有サイズ

CSS が max-width:100% でも、属性の width／height はファイルの縦横比に合わせておくとブラウザが即座にアスペクト比ボックスを確保し、プレースホルダ無しでも 0.08 を超える CLS を避けやすくなります。アートディレクションでトリミングが変わるなら <picture> を分岐させ、一枚の矩形を無理に伸ばさないでください。

Safari におけるデコードとメモリ圧力

WebKit はメモリ逼迫時に存在する高解像度ソースを選ばないことがあります。低電力モードやサーマルスロットリング下ではデコードのバッチングも変わるため、スクロール録画で遅延ペイントを見逃さないでください。広色域資産は color-gamut:p3 を媒体クエリに入れた枝を増やさないと、sRGB 前提の二重デコードが起きることがあります。

静的サイト作者の書き出しチェック

1. マスタ写真は 480・800・1200・1600 ピクセルなど固定ストップで書き出す。
2. ブランド許容の画質では SSIM 0.96 以上を目安に知覚ベースで圧縮する。
3. AVIF／WebP／JPEG でファイル名規則を揃え、ハッシュによるキャッシュバスタを同期させる。
4. CMS フィールドに必須の sizes 断片を添付し、コピー編集だけでレイアウトが壊れないようにする。
5. Safari のメジャー更新のたびに四半期リグレッションを入れる。

CDN・Accept・キャッシュキー

同一 URL でフォーマットだけ変える構成では、モダンな Accept を送らないクローラに誤ったバリアントが届くことがあります。immutable なハッシュ付きファイル名でパスを分けるか、エッジで Accept に応じてキーを分けます。HTML シェルは 300〜600 秒、ハッシュ付き資産は七日以上が扱いやすいです。

HTTP/2 の多重化では sizes がやや悲観的に見積もっている間に複数の w 候補が並列で走るため、クリティカル CSS と帯域を奪い合わないよう同時接続数にも配慮します。4G プロファイルでヒーローが 900 KB を超えるなら、最幅のソースを削るかアートディレクションを締めます。

画像に文字を載せるのはアクセシビリティ的にリスクが高いので、可能なら SVG や HTML へ。写真に載せる場合は近傍にテキストを重複提示し、装飾画像の alt は空にします。

ブレークポイントを 960 から 1024 に移すだけでスロット幅が広がり、見えないうちにダウンロードが増えるので、画像バイナリを触らなくてもリグレッション対象です。Mac mini をクラウドで抑えると、sips や ffmpeg のバッチ変換もノートより熱くならず回せます。