現状
記事画像は原稿に置いたファイルをほぼそのまま配信しており、表示幅に応じた srcset を持たない。
代表記事を幅375pxで確認すると、次の画像が配信されていた。
top.jpg: 元1024×559、表示約351×192、srcsetなしcockpit.png: 元1200×665、表示約351×195、srcsetなし
mobile Lighthouse:
- Performance: 87
- LCP: 4.0秒
- 画像最適化による推定削減: 540KiB
cockpit.png: 約433KiBの削減余地top.jpg: 約121KiBの削減余地
問題
- モバイルでも表示寸法の約3倍の画像を取得する
- PNG / JPEG / GIF等の選択と圧縮品質が著者ごとに異なる
- 著者の画像作成方法が読者の通信量とLCPへ直接影響する
- 原稿側へ「各自でWebPにして複数サイズを作る」と求めると運用されない
やりたいこと
ビルド時に記事画像を一元変換し、表示幅に合った画像を配信する。
たたき台:
- AVIF / WebP / 元形式の3系統を生成
- 480 / 768 / 1200px程度の幅バリエーションを生成
<picture>、srcset、sizes を自動生成- 先頭画像だけ
fetchpriority="high"、以降は loading="lazy"
- 元画像は保持する
- 既存の
width / height と縦横比を維持する
- GIF / AVIFアニメーション、スクリーンショット、写真、図表で変換方針を分ける
- CIで「表示幅に対して過大」「圧縮率が異常」「アニメーションが巨大」を検知する
調べること
- Hexoのrender/filter段階で
<img> を <picture> へ変換できるか
- sharp等の導入コストとGitHub Actionsの生成時間
- 既存画像全件を変換するか、新規・高PV記事から始めるか
- 図表や小さい文字を含む画像でAVIF/WebPの品質が落ちないか
- OGP画像と本文画像を同じパイプラインに含めるか
- キャッシュキーと生成物の保存場所
既存Issueとの境界
このIssueは複数形式・複数幅をビルド時に生成し、ブラウザへ選ばせる仕組みを扱う。
完了条件
- 代表記事のmobile LCPが2.5秒未満、または現状から明確に改善する
srcset / sizes により表示幅に近い画像が選ばれる- AVIF / WebP非対応環境で元形式へフォールバックする
- CLSを増やさない
- 原稿執筆者の手作業を増やさない
- 変換前後の見た目を写真・スクリーンショット・図表で確認する
現状
記事画像は原稿に置いたファイルをほぼそのまま配信しており、表示幅に応じた
srcsetを持たない。代表記事を幅375pxで確認すると、次の画像が配信されていた。
top.jpg: 元1024×559、表示約351×192、srcsetなしcockpit.png: 元1200×665、表示約351×195、srcsetなしmobile Lighthouse:
cockpit.png: 約433KiBの削減余地top.jpg: 約121KiBの削減余地問題
やりたいこと
ビルド時に記事画像を一元変換し、表示幅に合った画像を配信する。
たたき台:
<picture>、srcset、sizesを自動生成fetchpriority="high"、以降はloading="lazy"width/heightと縦横比を維持する調べること
<img>を<picture>へ変換できるか既存Issueとの境界
width/heightやlazy属性を補う話このIssueは複数形式・複数幅をビルド時に生成し、ブラウザへ選ばせる仕組みを扱う。
完了条件
srcset/sizesにより表示幅に近い画像が選ばれる