プレースホルダー画像ジェネレーター

仕組み

1. 寸法を定義: プレースホルダー画像の幅と高さをピクセルで入力します。
2. 外観をカスタマイズ: 背景色、テキストの色、表示するラベル(空白のままにすると寸法が表示されます)を選択します。
3. 使用またはダウンロード: HTML/CSSで使用するために画像URLをコピーするか、モックアップとデザイン用に直接PNGをダウンロードします。

なぜプレースホルダー画像ジェネレーターを使うのか?

ウェブ開発とモックアップ作成中に、実際のコンテンツが準備される前に画像が必要になることがよくあります。プレースホルダー画像は、レイアウトのスペースを埋めて、比率を表示し、レスポンシブな動作をテストし、デザイン意図をクライアントに伝えます。ストック写真を検索したり、空白の画像を手動で作成したりする代わりに、このツールは目的の寸法と色で正しくサイズ調整された画像を瞬時に生成します。

機能

• カスタム寸法: 任意の幅と高さをピクセル単位で, 正方形、ポートレート、ランドスケープ、またはバナー形式。
• 色のカスタマイズ: hexコードまたはカラーピッカーを介して背景とテキストの色を定義します。
• カスタムラベルテキスト: 画像に任意のテキストを表示するか、デフォルトの寸法ラベル(例: 400×300)を残します。
• 瞬時のURL: テスト用にsrc属性に直接貼り付けられるデータURIを取得します。
• PNGダウンロード: プレースホルダーをデザインツールで使用するためのPNGファイルとしてダウンロードします。

よくある質問

HTMLのsrc属性で使用できますか?

はい。生成された画像は、HTMLの<img src="">属性に直接貼り付けることができるデータURIとして利用できます。ホスティングや外部URLは不要です。

プレースホルダー画像の一般的なサイズは?

一般的なサイズ: ヒーロー画像(1200×630)、記事サムネイル(400×300)、アバター(100×100)、Open Graph画像(1200×628)、広告バナー(728×90)。必要に応じて任意のカスタムサイズを入力します。

CSSでプレースホルダー画像を使用するには?

データURIをコピーして、CSS背景で使用します: background-image: url("data:image/png;base64,…")。これはすべての最新ブラウザで動作し、外部ファイルは不要です。

プレースホルダー画像サービスの簡単な歴史

プレースホルダー画像サービスは、Webデザイナーが最終アセットが到着する前にモックアップを埋める迅速な方法を必要とした2010年に登場しました。placehold.itは2010年にDave Reillyによってローンチされ、最初に広く使われたサービスでした:placehold.it/300x200のようなURLを任意の<img>タグに貼り付けるとグレーの長方形が得られます。placekitten.comが同年に続き、長方形をランダムな子猫に置き換え、dummyimage.com(Russell Heimlich、2010年)が色のカスタマイズを追加しました。気まぐれな派生が増殖しました:fillmurray.com(Bill Murrayの写真、2013年)、placebeard.it(ヒゲ、2014年)、placecage.com(Nicolas Cage)。本格的な後継者は後に登場しました:Lorem Pixel(2017年頃に廃止)とDavid MarbyによるLorem Picsum(2018年)で、Unsplashから任意のサイズでランダムな写真を提供します。2014年頃、Facebookは「スケルトンスクリーン」パターンを普及させました:コンテンツが読み込まれる場所にグレーの形を表示します。2019年までに、WoltはBlurHashをリリースしました。これは実際の画像の低解像度ぼかしプレースホルダーにデコードする20バイトの文字列です。今日、ThumbHash(Evan Wallace、2023年)とネイティブCSSプロパティaspect-ratio(Chrome 88、2021年1月)により、外部サービスなしで画像スペースを予約できます。

覚えておくべき標準画像サイズ

• Open Graph(1200×630)。FacebookのOpen Graphプロトコルで定義された標準的なリンクプレビューサイズ。LinkedIn、Slack、Discord、Twitter(Twitter Cardが設定されていない場合)はすべてこれにフォールバックします。アスペクト比1.91:1。
• Twitter Card summary_large_image(1200×675)。フィード内プレビュー用の16:9比率。引用される1200×628は古い標準であり、2023年に1200×675に置き換えられました。
• Instagram(1080×1080正方形、1080×1350縦長、1080×1920ストーリー)。幅1080を超えるものはダウンサンプリングされます。ストーリーのアスペクト比は9:16です。
• YouTubeサムネイル(1280×720)。16:9。YouTubeは動画フレームから自動的にこれらを生成します;アップロードされたカスタムサムネイルは2 MB未満である必要があります。
• IAB広告サイズ。Interactive Advertising Bureauはバナー寸法を標準化しました:728×90(リーダーボード)、300×250(中型長方形、世界で最も購入されているサイズ)、300×600(ハーフページ)、160×600(ワイドスカイスクレイパー)、320×50と320×100(モバイル)。
• Favicon。ブラウザタブ用に16×16と32×32、Apple touchアイコン用に180×180、Androidのmanifest.json用に192×192と512×512、PWAインストールプロンプト用に最低512×512。
• メールヘッダー(600×200)。ほとんどのメールクライアントはレンダリング幅を600 pxに制限します。それを超えるとOutlookデスクトップで押しつぶされたりスクロールバーが表示されます。

プレースホルダーとCore Web Vitals

GoogleのCore Web Vitals(2020年5月にローンチ)はユーザー体験を測定し、検索ランキングに影響します。3つのメトリクスのうち2つは画像の扱い方に直接依存します。CLS(累積レイアウトシフト)はページ読み込み時にジャンプするコンテンツにペナルティを課します。最も一般的な原因:明示的なwidthとheight属性がない<img>で、画像のダウンロードが完了するまでブラウザがスペースを予約できません。スコアが0.1を超えるとメトリクスが失敗します。修正は簡単です:レスポンシブ画像でも常にwidthとheightを設定し、ブラウザがアスペクト比を計算できるようにします。LCP(最大コンテンツ描画)は最大の可視要素が読み込まれる時間を測定します。ほとんどのページではその要素はヒーロー画像です。2.5秒を超えるものは失敗します。戦略:モダンフォーマット(WebP、AVIF)を提供する、折り畳み下の画像でloading="lazy"を使用する(Chrome 76、2019年8月)、ヒーローでfetchpriority="high"を使用する。プレースホルダーは視覚的にギャップを埋めます:レイアウト用のスケルトンスクリーン、実際の画像カラーパレットの即時プレビュー用のBlurHashまたはThumbHash。

画像フォーマット決定ガイド

• PNG(1996年)。ロスレス、透明度をサポート、特許問題なし。ロゴ、アイコン、スクリーンショット、シャープなエッジを持つグラフィックに最適。インデックスカラーPNG-8(256色)はRGB PNG-24よりも劇的に小さく、UIアイコンではしばしば見分けがつきません。
• JPEG(1992年)。非可逆、透明度なし、写真用に最適化されています。品質75-85はWebのスイートスポットです;視覚的に品質95と区別がつかず、サイズは半分です。シャープなエッジ(テキスト、ロゴ)のあるものにはJPEGを避けてください:目に見えるリンギングアーティファクトが発生します。
• WebP(Google、2010年)。同じ視覚品質でJPEGより25-35%小さく、ロスレスでもPNGより小さいです。透明度、アニメーション、非可逆と可逆両モードをサポート。ブラウザサポート:2024年時点で97%。新規サイトのデフォルト選択。
• AVIF(Alliance for Open Media、2019年)。AV1ビデオコーデックに基づきます。JPEGより約50%小さく、WebPより20%小さいです。エンコードのCPUコストが高くなります。ブラウザサポート:2024年時点で約93%、古いSafariには欠落しています。<picture>フォールバックの背後で使用してください。
• SVG。ベクター。品質損失なしで無限にスケールします。SVGのロゴはしばしば500バイトで、512×512 PNGの10 KBに対してです。HTML内のインラインSVGは追加のHTTPリクエストを完全に回避します。写真には使用しないでください。
• Data URI。data:image/png;base64,...は画像バイトをHTMLまたはCSSに直接埋め込みます。周囲のファイルを約33%(base64オーバーヘッド)膨らませることでHTTPリクエストを節約します。極小のプレースホルダーサムネイルには価値がありますが、ヒーロー画像には絶対使わないでください。

プレースホルダー画像が実際に使用される場所

• ワイヤーフレームとモックアップ。Figma、Sketch、Adobe XD、Penpotはすべてプレースホルダー画像のドラッグアンドドロップをサポートしています。デザイナーはアートディレクションが到着する前にレイアウトをスケッチし、グレーの長方形や寸法テキストを視覚的なプレースホルダーとして使用します。
• スケルトンスクリーン。Twitter、Facebook、YouTube、LinkedInはすべて、コンテンツが読み込まれる間グレーのブロックプレースホルダーを表示します。Luke Wroblewskiの研究(2013年)は、スケルトンスクリーンが知覚される読み込み時間をスピナーよりも最大20%速く感じさせることを示しています。
• デザインシステムストーリー。Storybook、Histoire、Ladleは代替画像を必要とするコンポーネントプレビューをレンダリングします。一貫したプレースホルダーセットは、CIビルド間でスクリーンショットを再現可能にします。
• メールモックアップ。Litmus、Email on Acid、Mailchimpテンプレートビルダー。メールクライアントは画像サポートが大きく異なります(Outlookデスクトップ、Gmail Web、iOS Mail)ので、デザイナーは本番アセットに切り替える前にプレースホルダーでテストします。
• 印刷校正。本のレイアウト、雑誌ページ、パッケージデザインは組版中にFPO(「for position only」)プレースホルダーを使用します。寸法は写真家が納品するずっと前にレイアウトに存在します。
• チュートリアルとドキュメント。「カードコンポーネントを作る方法」を書くとき、ソースが変わっても壊れない画像の代替物が必要です。セルフホストされたプレースホルダーは、外部サービスが停止しても(Lorem Pixelがしたように)生き残ります。
• A/Bテストとプロトタイプ。3つの異なる画像サイズでレイアウトを素早くテストすることは、実際のアセットを再レンダリングするよりも、生成されたプレースホルダーで速くなります。

ページパフォーマンスを損なうミス

• widthとheight属性を忘れる。CLSスコア不良の最も一般的な原因。CSS駆動のレスポンシブ画像でも、本来のwidthとheightを設定して、ブラウザが正しいアスペクト比を予約できるようにします。モダンブラウザは2020年からこれらの属性からaspect-ratio: width/heightを自動的に計算します。
• 200×200の表示に4096×4096のプレースホルダーを提供する。視覚的利点なしで20倍のバイト。プレースホルダーの寸法を実際のレンダリングサイズに合わせるか、複数のバリアントでsrcsetを使用してください。
• 空または欠落したaltテキスト。スクリーンリーダーはコンテキストなしで「画像」とアナウンスします。純粋に装飾的なプレースホルダーには、明示的にalt=""を使用して「これをスキップ」と通知します。コンテンツ画像には、QAが欠落コピーを検出できるように、プレースホルダー上でも説明を書いてください。
• 巨大なdata URIをインライン化する。base64として100 KBの画像はHTML内で約133 KBになり、解析をブロックし、キャッシュを破壊します(HTMLは通常積極的にキャッシュされず、画像はキャッシュされます)。data URIは約2-4 KB未満でのみ使用してください。
• 本番でplacehold.it / lorempixel / 外部サービスに依存する。それらはダウンします。Lorem Pixelは2017年頃に消え、何千ものデモサイトを壊しました。チュートリアル、デモ、ストーリーには、プレースホルダーを自分で生成するかセルフホストしてください。
• 写真にPNG、ロゴにJPEG。PNGとしての写真は、同じ画像のJPEGの3-5倍大きいです。JPEGとしてのロゴは、エッジの周りに醜い圧縮リングが発生します。習慣ではなくコンテンツタイプでフォーマットを選択してください。
• loading="lazy"をスキップする。熱心に読み込まれる折り畳み下の画像は、ヒーローと帯域幅を競います。ビューポート下のすべてにloading="lazy"を追加します。ネイティブ、ライブラリ不要、Chrome 76(2019年8月)とSafari 15.4(2022年)以降サポート。

その他のよくある質問

プレースホルダーで寸法ラベルがなぜそんなに有用なのですか?

レイアウトに異なるサイズのプレースホルダーがいくつもある場合、ラベルはどのスロットがどれかを即座に教えてくれます。グレーの長方形上の「400×300」は、カードが4:3か16:9かを推測するよりも有益です。モックアップをレビューするデザイナーと開発者は、部屋の向こうから誤ったサイズの要素を発見できます。

BlurHash、ThumbHash、LQIPの違いは何ですか?

3つすべて、ぼかしプレースホルダーにデコードする画像の小さなプレビューをエンコードします。LQIP(「low-quality image placeholder」)は単に小さなJPEG(約100バイトから2 KB)です。BlurHash(Wolt、2019年)は任意の画像をデータベースに保存する20-30文字のASCII文字列にエンコードします;デコード時間はマイクロ秒です。ThumbHash(Evan Wallace、2023年)は同様ですが、同じ品質で30-50%小さく、よりシャープなエッジをレンダリングします。モダンフレームワーク(Next.js、Astro、Hugo)はすべてBlurHashをデフォルトでサポートしています。

プレースホルダーサムネイルにはSVGとPNGのどちらを使用すべきですか?

プレースホルダーが単純な形状(長方形、アイコン、幾何学的パターン)の場合はSVG。50バイトのインラインSVGは毎回2 KBのPNGに勝ちます。ピクセル正確なテキストレンダリングや特定のフォントフォールバックが必要な場合はPNG:SVGテキストレンダリングはブラウザとプラットフォーム間で異なります。クライアントサイドで生成される動的プレースホルダーの場合、このツールはPNGを生成します。これはキャンバステキストレンダリングがブラウザ間で予測可能だからです。

生成されたPNGにEXIFや隠しメタデータが含まれていますか?

いいえ。HTMLキャンバスのtoBlob()またはtoDataURL() APIによって生成されたPNGには、IHDR、IDAT、IENDチャンクと一部のブラウザで最小限のtEXtチャンクのみが含まれます。GPS、カメラ情報、編集履歴、ユーザー識別子はありません。GPS座標やデバイスのシリアル番号を漏らす電話カメラのJPEGと比較してください。

ここで画像を生成するとき、何かがサーバーに送信されますか?

いいえ。画像はブラウザのHTML5 Canvas 2D APIを介してローカルで描画されます。生成中にDevToolsのNetworkタブを開く:画像のアウトバウンドリクエストはゼロです。機密モックアップ、NDA、クライアントワーク、未公開製品デザインに安全です。