サーバー上のハードファイルに単純にリンクするよりも、base64/line を使用して画像を表示する方がどれくらい高速ですか?
url(data:image/png;base64,.......)
これに関するパフォーマンス指標のタイプを見つけることができませんでした。
いくつか懸念事項があります。
「高速」を次のように定義しましょう: ユーザーが完全にレンダリングされた HTML Web ページを表示するのにかかる時間
「より速い」というのは、さまざまな解釈や状況が考えられるため、答えるのが難しいです。
Base64 エンコーディングでは、画像が 3 分の 1 に拡大され、帯域幅の使用率が向上します。一方、それをファイルに含めると、サーバーへの別の GET ラウンド トリップが削除されます。そのため、スループットは高くてもレイテンシーが低いパイプ (衛星インターネット接続など) は、個別の画像ファイルを使用する場合よりも、インライン画像を含むページを高速に読み込む可能性があります。私の (地方の、遅い) DSL 回線でも、多くの往復を必要とするサイトは、比較的大規模で GET が数回しか必要ないサイトよりも、読み込みにかなりの時間がかかります。
リクエストごとにソース ファイルから base64 エンコーディングを行うと、より多くの CPU を使用したり、データ キャッシュをスラッシングしたりすることになり、サーバーの応答時間が遅くなる可能性があります。(もちろん、いつでも memcached などを使用してその問題を解決できます)。
もちろん、これを行うと、ほとんどの形式のキャッシュが防止されます。画像が頻繁に表示される場合、たとえば、すべてのページに表示されるロゴなど、通常はブラウザによってキャッシュされる可能性があります (または、squid や squid などのプロキシキャッシュ)。なんでも）、月に 1 回リクエストします。また、sendfile(2) などのカーネル API を使用して静的ファイルを提供するために Web サーバーが持っている多くの最適化も妨げます。
基本的に、これを行うと、特定の状況では役立ち、他の状況では害になります. これがあなたにとって価値のあるトリックであるかどうかを本当に理解する前に、どの状況があなたにとって重要であるかを特定する必要があります.
キャッシングの恩恵を受けられなくなった
それが重要かどうかは、キャッシュにどれだけ依存しているかによって異なります。
もう 1 つの (おそらくもっと重要な) ことは、多数の画像がある場合、ブラウザーはそれらを同時に (つまり、並行して) 取得するのではなく、一度に少数しか取得しないため、プロトコルがおしゃべりになってしまうことです。ネットワークのエンドツーエンドの遅延がある場合、多くの画像を一度に数枚の画像で割って、画像ごとのエンドツーエンドの遅延を掛けると、最後の画像が読み込まれるまでにかなりの時間がかかります。
base64 のサイズは、PNG/JPEG ファイルのサイズよりもはるかに大きくありませんか?
ファイル形式/画像圧縮アルゴリズムは同じです。つまり、PNG です。
Base-64 を使用すると、各 8 ビット文字は 6 ビットを表します。したがって、バイナリ データは 8 対 6 の比率、つまりわずか約 35% で圧縮解除されます。
どれくらい速いですか
「より速く」を定義します。HTTP パフォーマンス (以下を参照) またはレンダリング パフォーマンスのことですか?
キャッシングの恩恵を受けられなくなった
実際、これを CSS ファイルで実行している場合でもキャッシュされます。もちろん、CSS を変更すると、キャッシュが無効になります。
状況によっては、これを使用して、多くの HTTP 接続でパフォーマンスを大幅に向上させることができます。ほとんどの場合、画像スプライトなどのテクニックを利用できる可能性が高いため、いくつかの状況について説明しますが、武器庫に別のツールを用意しておくことは常に良いことです!