ウェブ向けのデザインと開発の学習期間にかかわらず、<img> 要素の概要はほとんど必要ありません。1993 年に Netscape（当時は「Mosaic」）でリリースされ、1995 年に HTML 仕様に追加された <img> は、長い間、ウェブ プラットフォーム内でシンプルながら強力な役割を果たしてきました。画像をレンダリングできない場合や、支援技術が代替テキストをリクエストした場合、デベロッパーは src 属性を使用して「ソース」画像ファイルを追加し、alt 属性を使用して代替テキストを指定します。そこから、ブラウザは画像データを取得して、できるだけ早くレンダリングするという 1 つの仕事しか行いません。
ウェブ開発におけるほとんどの歴史において、画像の処理はそれほど複雑ではありませんでした。現代のウェブは複雑であるにもかかわらず、画像を扱う際の基本事項は変わりません。互換性のためにウェブに適した画像形式を使用し、帯域幅を節約するための適切な圧縮方法、ページのレイアウト内で画像が占有するスペースに適したサイズなどです。
固定幅のレイアウトを使用することで、ウェブの使い勝手についてもっとよく話せると考えていたときのように、このレイアウトは複雑でないものになりました。画像ソースのサイズの設定は特に簡単でした。幅 500 ピクセル、高さ 300 ピクセルのスペースを占める画像の場合、同じサイズのソース画像を指定します。
レスポンシブ レイアウトの画像
柔軟なレイアウトと CSS メディアクエリの使用に加え、「柔軟な画像とメディア」は、レスポンシブ ウェブ デザインを構成する 3 つの側面のうちの 1 つです。画像に柔軟性を持たせるために、デベロッパーは CSS を使用して画像（またはサイト全体の画像）に max-width: 100% を設定し、画像が縮小されて親コンテナがオーバーフローしないようにブラウザのレンダリング エンジンに指示するようになりました。視覚的には、これは完全に機能します。ラスター画像のダウンスケーリングは視覚的にシームレスに行われます。1 行か 2 行の CSS を使用すると、縮小された画像は、常にそのサイズで表示されるはずの画像ソースが指定されているかのように見えます。レンダリング エンジンに、画像がレイアウト内で占めるスペースに必要な以上の画像データを渡すと、縮小画像のレンダリング方法について、十分な情報に基づいて判断できます。これにより、視覚的なアーティファクトやぼかしを発生させることもありません。
通常は、画像をアップスケールする（つまり、ソース画像の本来のサイズより大きいサイズで <img> をレンダリングする）ことは望ましくありません。表示される画像はぼやけて画質が粗くなります。
img { max-width: 100% } を使用すると、柔軟なコンテナのサイズ変更に合わせて、画像が適切にスケールダウンされます。固定の width: 100% を設定する場合とは異なり、これにより画像が本来のサイズを超えて拡大されることもなくなります。長い間、画像を扱う際のルールとして、ブラウザが理解できる形式を使用し、適切なレベルの圧縮を使用し、画像を決して拡大しない、というルールが守られてきました。
しかし、このアプローチは視覚的にシンプルかつ効果的でしたが、パフォーマンス コストも非常に高くなりました。<img> は画像データのソースを 1 つだけサポートしていたため、この方法では、表示できる最大サイズと同程度の固有のサイズの画像アセットを用意する必要がありました。ユーザーのビューポート サイズに応じて幅が 300px～2000px のレイアウト内のスペースを占有する画像には、少なくとも 2000px の固有の幅を持つ画像ソースが必要でした。小さなビューポートからしかページを閲覧しないユーザーには、すべてが想定どおりに表示され、画像は問題なく拡大されます。レンダリングされたページでは、大規模であるものの縮小されたソース画像は、適切なサイズの画像と変わりません。ただし、2000px 幅の画像を転送してレンダリングするため、目に見えるメリットはありません。そのため、大量の帯域幅と処理能力が消費されます。
最初の「Retina」デバイスが登場するにつれ、状況はさらに悪化しました。ビューポートのサイズだけでなく、ディスプレイの密度も問題になったからです。画像ソースに高密度ディスプレイに対応するには、固有の幅を大幅に広げる必要があります。簡単に言うと、密度が 2 倍のディスプレイで画像を鮮明にレンダリングするには、2 倍の画像ピクセルが必要になります。
ここでも、デベロッパーはレンダリング エンジンの機能を利用して、画像を視覚的にダウンスケールできるようになりました。src で 800px 幅のソース画像をブラウザに提供し、その画像を CSS で幅 400px で表示するように指定すると、2 倍のピクセル密度でレンダリングされた画像になります。
もちろん、レイアウトと高密度ディスプレイで可能な限り最大のスペースに合わせてカットされた 1 つのソース画像は、視覚的にすべてのユーザーに機能します。小型で低密度のディスプレイでレンダリングされた巨大な高解像度の画像ソースは、他の小型で低密度の画像と同じように見えますが、はるかに遅く感じられます。ユーザーは、幅が 4,000 ピクセルという膨大な画像ソースのパフォーマンス コストをすべて負うことになり、メリットはありません。
長い間、<img> は主に「画像データを取得して画面上に配置する」という 1 つのことを行っていました。ある程度はうまくいきましたが、<img> は、直面しているブラウジング環境における急進的な変化に対応するタスクには対応できていませんでした。レスポンシブ ウェブ デザインは開発の主流になりましたが、ブラウザは 20 年近くにわたり img のパフォーマンスを最適化してきました。しかし、最も特権的なユーザーを除き、ページの画像コンテンツは最初から非効率なものでした。ブラウザがどれだけ迅速に画像ソースをリクエスト、解析、レンダリングできたとしても、そのアセットはユーザーが必要としていたよりもはるかに大きくなる可能性があります。