私は最近src
、画像の属性を使用すると、未加工の Base 64 画像データをそのまま挿入できることを知りました。画像に対する追加のリクエストを行う必要がないため、これは個別の画像ファイルよりも技術的に効率的であると思いますか? それとも、オーバーヘッドが小さすぎて価値がないのでしょうか?
また、私がこれをやったと仮定すると、その生データを取得する最良の方法は何でしょうか? (たとえば、私がペイントで作り上げたイメージから?)
「より効率的」とはどういう意味かによって異なります。尺度が時間であれば、より効率的です。
あなたが参照している手法は、data URIを使用することです。通常、画像データを取得し、base64 でエンコードして、ASCII 文字のみが含まれるようにします。base64 でエンコードされたデータには、33% 大きくなる効果があります (6 ビットごとに 8 ビットになります)。
したがって、これは小さな画像では機能しますが、大きな画像では 33% のプレミアムが多すぎる可能性があります。
これが良い考えである理由は、多くの場合、待ち時間がブラウザー リクエストの制限要因となるためです。(昔は) 帯域幅が制限だったので、リソースを分割するのが一般的なアドバイスでしたが、今はそうではありません。データ URI イメージを使用すると、ブラウザは 2 回目のラウンド トリップを行う必要がありません。
それとは別に、ブラウザのサポートを考慮する必要があります。バージョン 8 より前の IE は、データ URI をサポートしていません。IE 8 では、32KB のデータの上限があります。
お役に立てれば!
これにはサイズ制限があります。頭の中ではっきりとはわかりませんが、2Kがほぼ正しいようです。
base64 エンコーディングにはオーバーヘッドがあることに注意してください。500 バイトのイメージがある場合はこれで問題ないかもしれませんが、それ以外の場合は問題ありません。
実際には、互換性のために今これを行うべきではありません。おそらく今後数年で...
送信する画像の数と、リクエストされる頻度によって異なります。画像を base 64 にすることは、30 個の http リクエストよりもはるかに効率的です。
頻繁に要求される場合は、各画像のキャッシュを実装することもできます。これは、私の職場で実施したものです。base64 を一時ディレクトリに保存し、既にエンコードされているかどうかを確認します。そうであれば、応答時間はさらに短縮されます。それ以外の場合は、PHP スクリプトでその場で作成されます。より人気のあるページは、キャッシュで非常に迅速にウォームアップされます。