本文に画像を一枚も置かないまま、記事だけが増えていた。カバー画像はビルドのたびに最適化されているのに、本文内の img は一度も描画されたことがない——つまり画像まわりの CSS も配信挙動も、実は未検証のままだ。このノートでは、想定しうる画像と表の置き方を一つの記事に全部詰め込み、配信される HTML を読んで確かめる。
画像の基本三形
まず横長・縦長・小型の三形。レイアウト側の関心は「本文幅より大きい画像が縮むか」「小さい画像が原寸で止まるか」の二点に尽きる。
横長は本文幅いっぱいに縮小されるはず。次は縦長。スクロール量に効くぶん、縦リズムへの影響が最も大きい形だ。
最後に本文幅より狭い小型画像。拡大されず原寸で止まるのが正しい。
連続配置と縦リズム
図版を二枚続けて置くと、間隔には段落と同じリズムが入るだけのはず。境界が分かるよう、地色の異なるパターンを続けて置く。
リスト項目内の画像
手順書では箇条書きの途中に図が挟まる。リストのインデントに画像が従うかを見る。
- 計測前にキャッシュを消す
- 対象ページを開いて図の位置まで進む:
- 表示された寸法をそのまま記録する
透過図版とダーク背景
図解は透過 PNG で書き出すことが多い。地色を持たないので、ライトの白地とダークの #000 の両方で線が読めるかは線色だけで決まる。中間トーンの線で試す。
透過図版の線色は「白地でも黒地でも読める中間トーン」を既定にしておくと、テーマ切替のたびに画像を差し替えずに済む。
逆に純黒・純白の線は片方のテーマで消える。図解の作画規約はここで固定しておきたい。
表は二種類で試す
表は列数で挙動が変わる。まず 4 列の普通の表。
| フォーマット | 圧縮 | 透過 | 主な用途 |
|---|---|---|---|
| PNG | 可逆 | 可 | 線画・図解 |
| WebP | 両対応 | 可 | 本文の図版全般 |
| AVIF | 非可逆 | 可 | 高圧縮が要る大判 |
8 列の広い表
次に 390px では絶対に収まらない 8 列。セルの文も意図的に長くしてある。狭い画面では表の内側だけが横にスクロールし、ページ全体は動かないのが期待値だ。
| 画像名 | 元寸法 | 出力寸法 | 変換 | 元サイズ | アルファ | 読み込み属性 | 備考 |
|---|---|---|---|---|---|---|---|
| 横長ストライプの大判見本 | 1600×900 | 原寸のまま | PNG→WebP | 30KB | なし | lazy（ファーストビュー外） | 本文幅へは CSS で縮小され、寸法属性が予約領域を確保する |
| 縦長バンドと点列の見本 | 900×1350 | 原寸のまま | PNG→WebP | 11KB | なし | lazy（ファーストビュー外） | 縦に長いぶんスクロール量と CLS の観察に向く |
| 透過線画のノード図解 | 1200×700 | 原寸のまま | PNG→WebP | 14KB | あり | lazy（ファーストビュー外） | 変換後もアルファが保持されるかを確認する対象 |
キャプション二案の並置
キャプションの書き方は二案ある。同じ画像で並べて出し、見た目を比較する。
案A: 画像直後の斜体段落
案A: 画像の直後に斜体の段落を置く。Markdown だけで完結するが、和文の斜体は擬似傾斜になる。
案B: figure と figcaption
操作メモと締め
計測は毎回 Cmd+Shift+R の強制再読み込みから始める。配信 HTML の確認は開発者ツールより curl が確実だ。
curl -s https://example.com/blog/sample-13/ | grep -o '<img[^>]*>'ここまでの全要素が、この一本の記事に同居している。配信 HTML の width/height、フォーマット変換、390px での横スクロール有無は、実測値としてレポート側に記録する。