2

そこで、ウェブページを高速にダウンロードするための私の計画は次のとおりです...

  1. すべての画像を 1 つの png-24 画像スプライトに配置します。
  2. その画像を base64 としてエンコードし、Web ページの HTML コードに含めます。
  3. 元の画像スプライトの SRC を複製し、ロゴ、共有ボタン、その他の画像などに再利用します。

私が予測できる唯一の問題は、base64 でエンコードされた画像ソースの複製です。

jQuery を使用して画像ソースを簡単に抽出し、それをすべての空の画像 (スプライトを作成する必要がある画像) に再挿入することはできますか?

編集: 一部の人々は、base64 画像がキャッシュされていないと述べていますが、そうするように指示した場合、(base64 画像を含む) Web ページ全体がキャッシュされませんか?

4

4 に答える 4

4

これは、CSS アイコン/再利用可能な画像の一般的な手法です。

srcを使用して画像を取得できます$(element).attr('src');。

ただし、HTMLマークアップに含めるために、画像バイナリ（画像ファイル自体を意味していると思います）をbase64にエンコードする利点はわかりません。あなたはこれを少し考えすぎているかもしれません。

111主にベース64は元のデータで使用されているエンコーディングよりも狭い文字セットであるため（バイナリ=デシマルと考えてください）、画像データをベース64に再エンコードすることでバイトを「節約」できるとは思わない7ので、実際にはより大きな出力。（しかし、それは私の理論作成にすぎないので、間違っている場合は修正してください。）

ただし、たとえば、最大で同じサイズのマークアップに再エンコードすることができた場合、「より高速なダウンロード」で前進することはありません。あなたはまだ同じ量のデータをダウンロードしています。おそらくもっと。

より小さなペイロードを管理する場合、エンコード/再エンコードのパフォーマンスへの影響は価値がありますか? クロスブラウザの互換性は言うまでもありません。

より良い手法は、画像を 1 つの画像ファイルにパッケージ化して (これが演習の精神です)、ブラウザーに通常どおりダウンロードさせることです。画像の 1 つのコピーがダウンロードされると、ブラウザによってキャッシュされている限り、それ以上ダウンロードされることはありません。

編集

Web ページのキャッシュに関する編集に答えるには、はい、Web ページはキャッシュされます。base-64 でエンコードされた画像も同様です。ただし、画像は事実上 HTML マークアップの一部であるため、HTML ページと共にキャッシュされます。

たとえばfoo.html、(エンコードされたスプライト ファイルを含む) ダウンロードすると、通常どおりマークアップを確実に取得できます。そのページはキャッシュされます。

ここで、ダウンロードしますbar.html(私のスプライト ファイルも使用します)。ブラウザbar.htmlに関する限り、その画像はfoo.html. そこにイメージが挟まれていることに気付かないかもしれません。

キャッシュが機能する方法 (私が理解できる限り) はURL マッチングです。これが、あるページでダウンロードし、別のページで再度facepalm.jpg要求すると、ブラウザーは既にダウンロードしたことを認識し、そうしない理由です。facepalm.jpg

あなたのエンコーディング プランでは、私は にリクエストfoo.html(またはその一部) を行うつもりはありませbar.htmlん。

foo.html ただし、もう一度アクセスすると、「以前にダウンロードした」ため、そのページのキャッシュのすべての利点が得られます。

于 2012-06-25T21:02:21.387 に答える
2

私は同意します。より良い計画は、多くのスプライトを含む単一の画像を使用することです。

background: url(...)
background-position: 0px 0px;

CSS の属性。そうすれば、キャッシュするイメージを 1 つだけロードできます。

于 2012-06-25T21:01:47.717 に答える
1

base64 は悪い考えだと思います。スプライトを普通にロードするだけです。

どんな犠牲を払っても、考えられるすべての HTTP リクエストを排除しようと盲目的に考えないでください。(たとえ「それが Google のやり方だ」としても。) 優れたパフォーマンスを達成することはバランスをとる行為であり、ブラウザー間の違いを考えると、それは科学というよりも芸術に近いものです。

これをしたくない理由:

  • 画像スプライトはページ間でキャッシュされません。つまり、すべてのページで画像全体を転送する必要があります。個別に提供される画像に適切なキャッシュ ヘッダーがあると仮定すると、後続のページ リクエストは遅くなり、帯域幅が浪費されます。
  • Base 64 エンコーディングは、その性質上、帯域幅を浪費します。base64 でエンコードされたファイルは、元のファイルより 33% 大きくなります。これは数キロバイトのサイズのファイルではそれほど問題になりませんが、イメージ スプライトのような大きなファイルでは大きな問題になります。
  • お気づきのとおり、ページのすべてのタグで base64 でエンコードされたスプライトを複製する必要があり<img>、これは非常に無駄であり、スクリプトを使用してこれを修正すると...
  • 画像が JavaScript に依存するようになりますが、これは悪い考えです。スクリプトがロードされない場合はどうなりますか? JavaScript がオフになっていますか?
  • この画像の HTTP リクエストを排除しても、ページが表示されるまでの時間に関しては、実際にはあまり効果がありません。画像は DOM の準備をブロックしないためです。重要なのは、レンダリングをブロックするコンテンツ (スクリプトと CSS) に対する HTTP 要求を減らすことです。(ほとんどの場合、それぞれ 1 つの要求です。) スクリプトと CSS が完全に読み込まれるまで、ページはまったくレンダリングされません。ただし、画像がダウンロードされる前に、ページはレンダリングされます (空のスペースがありますが)。
  • 画像の種類と HTTP リクエストの数のバランスを取る必要があります。できるだけ多くの画像が 1 つの HTTP リクエストでダウンロードされるように、アイコンなどは通常、PNG でスプライトする必要があります。写真的なものはすべて、独自のJPEG に変換する必要があります。 画像に PNG を使用しないでください。 これは間違った圧縮アルゴリズムであり、同等の JPEG よりも 1000% 大きいファイルになります。
于 2012-06-25T21:38:45.893 に答える
1

あなたが求めていることを達成するためにvar imgSrc = $("#yourImage").attr("src");使用してから使用することができます。$("img").attr("src", imgSrc);

base64 画像はキャッシュされないため、base64 にエンコードすることが最適なオプションであるかどうかはわかりません。そのため、ページにアクセスするたびに再読み込みされます。また、base64 エンコーディングによってファイル サイズが約 33% 増加することは、今ではかなり広く受け入れられています。

続きを読む: http://davidbcalhoun.com/2011/when-to-base64-encode-images-and-when-not-to

于 2012-06-25T20:57:08.247 に答える