要点：プレースホルダー画像は、正確な寸法のグレー（または色付き）のダミー画像で、設計中に本番画像の代わりを務めます。真の価値は、正しい領域を早期に確保することです。これにより、最終アセット到着の前後でレイアウトが同じに振る舞い——リフローも予期せぬ崩れもありません。本ガイドでは、いつ使うか、どの形式で書き出すか、レイアウトシフトの防ぎ方を扱います。
レイアウトを組む前に最終写真を待つのは、順序が逆です。プレースホルダー画像なら、まず寸法を決め、次に本番画像を差し込めます。レイアウトが突然ずれることはありません。
領域を埋めるのでなく、確保する
プレースホルダーの最も価値ある働きは、実画像が使う正確な幅と高さを保持することです。寸法を確保していない画像を軸にレイアウトを組むと、最終アセットを入れた瞬間にすべてが跳ねます——テキストが回り込み、ボタンが動き、web では累積レイアウトシフト（CLS）として現れます。最初から正しいサイズのプレースホルダーで設計すれば、最終の差し替えは画像を変え、位置は変えません。
実寸とアスペクト比を合わせる
プレースホルダーは、最終画像に合ってこそ役立ちます。最終画像の実際のピクセル寸法とアスペクト比を設定しましょう——16:9 のヒーロー、1:1 のアバター、4:3 のサムネイル——モックアップが現実を映すように。各プレースホルダーにサイズを表示すれば（多くのジェネレーターが画像に印字します）、レビューで不一致を見つけやすくなります。
Retina と高 DPI
高密度画面では、画像はレイアウト上のサイズより多くの物理ピクセルを必要とします。プレースホルダーを 2×・3×・4× で書き出せば、本番画像が Retina でどう見えるかを試し、最終版に必要な大きめのファイルを見込んだことを確認できます。
どの形式で書き出すか
- PNG / WebP——画面上のモックアップやプロトタイプに。
- SVG——解像度非依存で極小、寸法がまだ流動的なときに最適。
- Base64 / Data URI——プレースホルダーを HTML や CSS に直接埋め込み、外部ファイルなしの自己完結プロトタイプに便利。
実用的なワークフロー
- レイアウトに必要な画像枠と、その実寸を書き出す。
- プレースホルダー画像ジェネレーターで生成する——バッチモードで全サイズを一度に作る。
- 設計に入れ、ビューポートをリサイズしても何もずれないことを確認する。
- 本番画像を一つずつ差し替える。領域が確保されているので、レイアウトは動かない。
それらの画像の周りを埋めるダミーテキストも必要なら、Lorem Ipsum ジェネレーターを併用し、モックアップ全体を現実的な密度で読ませましょう。
避けたいよくある間違い
- アスペクト比の違うプレースホルダーを使い、本番画像が想定外に切り取られる。
- 画像の寸法を確保せず、最終が来たときにレイアウトシフトを起こす。
- Retina スケーリングを無視し、ファイルサイズを過小に見積もる。
- 一度も差し替えず、プレースホルダーを本番に送ってしまう。