要約：ぼかしプレースホルダーは装飾ではない——それは読み込みエフェクトに偽装したCumulative Layout Shiftの修正策だ。正しくサイズ設定されたプレースホルダーは、実際の画像が読み込まれる前に画像の正確なスペースを確保するからだ。このガイドはCharacter Counter、Encoding Converter、Text Difference、AI Hidden Charactersと組み合わせて使ってください。

LQIP（Low Quality Image Placeholder）は本物の画像の非常に小さく、高度に圧縮されたバージョンだ——多くの場合20×20ピクセル以下、数百バイト——フル解像度のファイルが読み込まれている間、ぼかされて拡大表示される。

LQIPが実際に解決する問題：見た目ではなくレイアウトシフト

画像の最終的な寸法を確保するプレースホルダーがなければ、ページは画像のためのスペースなしでレンダリングされ、ファイルが到着した瞬間にその下のすべてを押し下げてしまう——Cumulative Layout Shift（CLS）、Googleのコアウェブバイタルの一つは、まさにこの状態を低く評価する。同じアスペクト比のプレースホルダー（ぼかされているかどうかにかかわらず）は最初のレンダリングから正しいスペースを占めるため、本物の画像が読み込まれても何も動かない——ぼかしは、実際の修正策であるスペースの確保の上に加わる嬉しいおまけにすぎない。

非常に小さな画像が即座に埋め込まれる仕組み

LQIPプレースホルダーは通常、Base64エンコードされたデータURIとしてHTMLに直接埋め込まれる——<img src="data:image/jpeg;base64,...">——そのためプレースホルダーは追加のネットワークリクエストなしでレンダリングされる。これが重要なのは、目的全体が、本物の画像のリクエストが完了する前にすら何かを表示することだからだ。ソース画像が非常に小さい（エンコード前でしばしば1KB未満）ため、base64のオーバーヘッド——生のバイトよりおよそ33%大きい——は、フルサイズの画像には無駄であっても、プレースホルダーには無視できるほど小さい。

LQIP対単色の主要色プレースホルダー

ぼかされたマイクロサムネイルは、単色の長方形よりも多くの視覚情報（おおまかな形、色の分布）を運ぶが、それはより多くの設定作業も意味する——写真ごとに小さな画像を生成・保存すること対、単一の平均色を計算すること。画像そのものが重要な写真中心のギャラリーでは、LQIPの追加の忠実度は通常価値がある。より小さなUI画像やアイコンでは、フラットカラーのプレースホルダーが、より少ないオーバーヘッドで同じCLS防止の仕事をこなす。

プレースホルダーを正しく追加するワークフロー

  1. すべての画像タグに明示的なwidthとheight（またはCSSのaspect-ratio）を設定する——これが実際にスペースを確保するものだ。プレースホルダー画像自体はそれを単独では行わない。
  2. 一致しない固定サイズではなく、画像の本当のアスペクト比でプレースホルダーを生成する——一致しない比率は、本物の画像がそれを置き換えるときにシフトを生む。
  3. ゼロリクエストの読み込みのために、プレースホルダーをbase64データURIとして埋め込む。これは本当に小さいプレースホルダー画像にのみ使うべきだ。
  4. ブラウザのネットワークスロットリングでテストする——プレースホルダーの価値は、本物の画像の到着が遅い場合にのみ現れる。

避けるべきよくある間違い

  • 明示的な寸法も設定せずにぼかしエフェクトだけを追加すること——ぼかしだけではレイアウトシフトに対して何もしない。
  • 本物の画像とは異なるアスペクト比のプレースホルダーを使うこと——これは置き換えられるときにいずれにせよシフトを引き起こす。
  • "一貫性のために"フルサイズの画像をbase64で埋め込むこと——プレースホルダーの利点なしにページの重さを膨らませてしまう。
  • LQIPを純粋に視覚的なエフェクトとして扱い、その本当の仕事がレイアウトスペースを確保することであるのを見落とすこと。

ぼかしはユーザーが気づくものであり、寸法指定によって確保されたスペースこそが、実際にあなたのCore Web Vitalsスコアを守っている。