imgタグのsrcにある画像ファイルを参照し、画像タグに直接埋め込まれた画像を参照することとの違いは何ですか？

Question

<img src=pathto.png />と<img src=data:image/png;base64,encodedpngdata... />をサーバーの観点から使用する場合に違いはありますか？

src=pathto.pngの場合、サーバーはイメージをエンコードしてブラウザに送信しますか？

Answer 1

最初の例では、URIを指定して外部リソースを参照しています。これにより、そのリソースにデータを受信するための追加要求が行われます。

2番目の例でもリソースを参照していますが、そのリソースのデータはURIに直接埋め込まれています（data URI scheme参照）。したがって、追加のリクエストは必要ありません。

どちらの方法も長所と短所があります。

     external embedded 
separate request (-)  ✓   ✗ 
cachable (+)    ✓   ✗ 
referencable (+)   ✓   ✗ 
compression (+)   ✓   ✗ 

• 外部リソースデータを
  外部リソースを使用する利点は、そのようなリソースがキャッシュされたとすることなく、別のドキュメントで使用することができるということですそのリソースのすべての出現を要求する。
  欠点は、最初の追加要求がかかることです。

• 埋め込まれたリソースデータ
  直接文書にリソースデータを埋め込むことの利点は、追加のリクエストを保存することです。
  ただし、このようなリソースは、1つのドキュメントまたは異なるドキュメントの複数の外観でキャッシュまたは参照できないという欠点があります。また、deflateやgzipを使って圧縮することもできません。実際、Base64エンコーディングは、サイズを4/3倍に膨らませます。

はあなたのウェブサイトをスピードアップするためにも、最初のルールベストプラクティスのMake Fewer HTTP Requests参照してください。

Answer 2

別のイメージにリンクするには、イメージを取得するための2回目の要求が必要ですが、データを再度送信せずに複数のページにキャッシュして再利用することができます。インラインでの埋込み

データを<img src="/path/to/image.png" />の場合（画像がページ内に複数回使用された場合には複数回）画像を含むすべてのページ要求

Answer 3

で送信されることを要求する、サーバウォン't エンコードイメージ。ブラウザはの別の要求でそれを要求し、サーバは短いヘッダをダンプし、ファイルのデータをワイヤにダンプします。上手く書かれたHTTPサーバーでは、処理が最小限に抑えられているので、これは非常に高速です。ブラウザは画像をキャッシュすることもできるので、後で検索する必要はありません（他の人が言っているように）。

インラインで埋め込むと、ページの重量が増え、イメージを別々にキャッシュすることができなくなります。