web-dev-qa-db-ja.com

Base 64エンコードと画像ファイルの読み込み

そのため、base64でエンコードされるSQLデータベースから画像を取得する必要があるphpの何かに取り組んでいます。これらの画像を表示する速度は非常に重要なので、データベースデータを画像ファイルに変換してからブラウザーにロードする方が速いのか、それとも生のbase64データをエコーし​​て使用するだけなのかを考えています。

<img src="data:image/jpeg;base64,/9j/4AAQ..." />

これは、FireFoxや他のGeckoブラウザーでサポートされています。

要約すると、実際の画像ファイルまたはbase64コードを転送する方が高速でしょうか。画像をロードするためにajaxを使用する場合、必要なHTTPリクエストは少なくなりますか？

画像は合計で100ピクセルを超えません。

phpmysqlhtmlimagebase64
29
teh_noob

さて、私はあなたの誰にも同意しません。より多くの画像をロードする必要がある場合があります。すべてのページに3つの画像が含まれているわけではありません。実際、私は200以上の画像をロードしなければならないサイトで作業しています。非常に負荷の高いサイトで100,000人のユーザーが200枚の画像を要求するとどうなるかサーバーのディスクは、画像を返すように崩壊する必要があります。さらに悪いことに、base64を使用するのではなく、サーバーに大量の要求を行う必要があります。あまりにも多くのサムネイルについては、データベースに事前に保存されたbase64表現を使用します。 http://www.stoimen.com/2009/04/23/when-you-should-use-base64-for-images/ で解決策と強力な議論が見つかりました。男は本当にその場合であり、いくつかのテストを行いました。私は感銘を受け、私のテストも行いました。現実はそれが言うようです。 1ページに大量の画像が読み込まれる場合、サーバーからの1つの応答が非常に役立ちます。

20
Peter Novak
  • Base64エンコードではファイルが大きくなるため、転送が遅くなります。
  • ページに画像を含めることにより、毎回ダウンロードする必要があります。外部イメージは通常、一度だけダウンロードされ、その後ブラウザによってキャッシュされます。
  • すべてのブラウザと互換性があるわけではありません
26
some

変更されない場合にイメージを何度も再生成する理由。仮に、1000の異なる条件に基づいて表示できる1000の異なる画像がある場合でも、ディスク上の1000の画像の方が良いと思います。ディスクベースの画像はブラウザによってキャッシュされ、帯域幅などを節約できることを覚えておいてください。

4
Mir Nazim

考えないでくださいdata://はIE7以下で動作します。

画像が要求されたら、それをファイルシステムに保存して、それ以降それを提供することができます。データベース内の画像データが変更された場合は、ファイルを削除してください。 img.domain.comのような別のドメインからも提供します。 PHP必要な場合を除き、起動することなく、Webサーバーから最終変更または電子タグのすべての利点を無料で利用できます。

Apacheを使用している場合：

# If the file doesn't exist:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^/(image123).jpg$ makeimage.php?image=$1
3
rojoca

最初の質問に答えるために、96ppiで400x300 pxのjpeg画像を測定するテストを実行しました。

base64ImageData.Length
177732

bitmap.Length
129882
2
esbenr

これは非常に高速で簡単なソリューションです。画像サイズは約33％増加しますが、base64を使用すると、httpリクエストの数が大幅に減少します。

Google画像とYahoo画像はbase64を使用しており、画像をインラインで提供しています。ソースコードを確認してください。

もちろん、このアプローチには欠点がありますが、メリットよりコストの方が勝ると思います。私が見つけた短所は遅いデバイスにあります。たとえば、iPhone 3GSでは、画像がサーバーからgzipで圧縮され、ブラウザーで圧縮解除する必要があるため、Google画像で提供される画像のレンダリングは非常に遅くなります。したがって、顧客が遅いデバイスを使用している場合、画像をレンダリングするときに少し苦しみます。

2
user2377782

一般に、base64エンコーディングを使用すると、バイトサイズが約1/3増加します。そのため、データベースからサーバーに1/3バイトを移動し、それらの余分な同じ1/3バイトをワイヤ経由でブラウザに移動する必要があります。

もちろん、画像のサイズが大きくなると、それに比例してオーバーヘッドが増加します。

そうは言っても、ファイルをdbのバイト表現に変更して送信するのは良い考えだと思います。

1
casperOne

アイコン（10x10ピクセル程度）にbase64画像を1〜2回使用しました。

Base64画像のプロ：

  • コンパクト-あなたは単一のファイルを持っています。また、ファイルが圧縮されている場合、base64画像は通常の画像のサイズにほぼ圧縮されます。
  • ページは単一のリクエストで取得されます。

Base64画像の短所：

  • 現実的にするには、画像を含むすべてのページでスクリプトエンジン（PHPなど）を使用する必要があります。
  • 画像が変更された場合は、キャッシュされたすべてのページを再ダウンロードする必要があります。
  • 画像がインラインであるため、CDNまたは静的コンテンツWebサーバーを使用できません。

通常の画像のプロ：

  • sPDYプロトコルを使用している場合、少なくとも理論的には、ページ+画像+ CSSは単一のリクエストでもロードされます。
  • 画像に有効期限を設定できるため、コンテンツはブラウザーからキャッシュされます。
0
Nick

最速の速度が必要な場合は、アップロード/変更時にディスクに書き込み、Webサーバーに静的ファイルを提供させる必要があります。 phpの呼び出しを最小限に抑えるため、Rojocaの提案も有効です。別のドメインからサービスを提供することの追加の利点は、（ほとんどの）ブラウザーが要求を並行して発行することです。

すべてを除外して、データを照会するときに、データが最後に変更されたかどうかを確認し、それをディスクに書き込んでそこから提供します。不必要にデータを転送しないように、If-Modified-Sinceヘッダーを尊重するようにしてください。

ディスクやその他のキャッシュに書き込めない場合は、それをバイナリデータとしてデータベースに格納し、ストリーミングするのが最も高速です。バッファーサイズを調整すると、その時点で役立ちます。

0
Richard Levasseur