web-dev-qa-db-ja.com

空白の画像。使用するもの：Base64 vs 1x1 JPEG image

Webサイトを構築していますが、Webサイトの速度とseoを向上させるために、HTTPクエリをできる限り少なくしたいと考えています。作成したばかりのページにスクロール画像が表示されています（画像には、ユーザーがそれぞれの画像を下にスクロールしたときにsrcに変換される属性data-scrがあります）。

すべての画像にはsrcではなくdata-src属性があるため、W3Cにはエラーが表示されます。

この時点で、この問題を解決するための2つのオプションが見つかりました。

  1. すべての画像の最初のsrcは、空白の1x1画像のURLになります
  2. データベース64の空白画像となるすべての画像の最初のsrc

空白の1x1画像のURLを使用している場合（tools.pingdom.comでテスト済み）、1つのHTTPリクエストが表示されます。データベース64の空白画像を使用している場合、ページ上の画像の数と同じ数のリクエストが表示されます。

Webサイトを高速化し、HTTP要求をより少なくするために、どちらがより効率的な方法ですか？（ユーザーが14.4kbpsのインターネット速度-最初のインターネット速度でWebページを読み込んでいると仮定します）。

ただしSEOの場合

他のオプションはありますか？

seoimagesperformancepage-speed
11
MM PP

Base64 imageオプションは、ごく少数の画像しかなく、サーバーから画像を取得するネットワークオーバーヘッドを排除したい場合に使用する必要があります。しかし、あなたが質問で示していることから、これは多数の画像に拡大する可能性があると思います。この場合、サーバーから取得され、ブラウザと中間プロキシサーバーにキャッシュされると、キャッシュライフタイムが長い単一の1px x 1pxの透過イメージをサーバーから使用します。

例として、この画像のサイズは約95バイト（ https://commons.wikimedia.org/wiki/File:1x1.png ）で、base64でエンコードされた画像文字列の場合、サイズがわかりますこの画像ファイルサイズと同等ですが、追加する画像ごとに繰り返されます。

2-5枚の画像の場合、サイズと速度は無視でき、1回のフェッチ全体を排除することでサーバーのトラフィックを減らしますが、それ以上ではページサイズが大きくなり始め、読み込み時間とSEOランキングに影響します。

12
Chris Rutherfurd

IE <8のサポートが必要な場合を除き、データURIを使用してください（ Browser support 。）

多くの小さな画像をHTMLに直接埋め込むと、直接リンクするよりも多くの帯域幅を使用するように見えますが、増加は gzip ;によって緩和されます。ページのサイズの唯一の違いは、空白の画像のoneデータURIとの長さの違いに由来しますoneサーバー上の画像のURL。 空白GIF は、43バイトまで小さくできます。 Base 64エンコード、82バイトです。 > 500-byte HTTP request 、同様のサイズの応答よりもパフォーマンスが低下することはありません。そして、TCPパケットサイズなどを取りませんアカウントへのオーバーヘッド。

以下は、Base 64でエンコードされた43バイトのGIFイメージです。

data:image/gif;base64,R0lGODlhAQABAIAAAP///////yH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==

SEOに関しては、たとえば Google News のようなGoogleサイトのソースコードを見て、data:image/gif,base64…を検索してください。

5
user2428118

この時点で、この問題を解決するための2つのオプションを見つけました。

このオプションは最新のブラウザを必要とするだけでなく、ブラウザが画像を生成するために画像データをbase-64でデコードする必要があるため、クライアント側で遅くなる可能性があります。

すべての画像の最初のsrcは、空白の1x1画像のURLになります

それはOKですすべての画像スロットの空白の画像URLがまったく同じURLであり、HTTPヘッダー「cache-control」で定義された長いキャッシュ有効期間を持っている場合に移動します。これの問題は、新しい画像ファイルがロードされると、画像の四角が新しいサイズにジャンプするため、ユーザーエクスペリエンスがそれほど素晴らしいものにならない可能性があることです。

ほぼ完璧なアイデアはこれです...

ページが起動したら、各画像に対応できる固定サイズのボックスでグリッドを表示します。グリッド全体が画面に収まらない場合でも問題ありません。次に、HTMLの読み込み後に実行されるjavascriptを作成し、そのjavascriptで新しい画像要素を作成してグリッドの各セルに添付し、画像のソースを正しい画像ファイルに設定します。最初の画面がいっぱいになるまでこれを行います。次に、javascript内でスクロールを検出し、スクロールが発生したら、新しいセルに対して上記のプロセスを繰り返します。

今、最高の最高のものを望んでいて、品質が大きな関心事ではない場合、私がお勧めするのは（私のサイトにも実装していること）、グリッドを構築し、そのグリッドの背景画像が画像の正方形としてフォーマットされたすべての画像のスプライトシート。この方法は、すべての画像に対して1つの要求が必要なため、柔軟で高速にロードできます。

高速ルートを使用する場合に使用するテンプレートHTMLは次のとおりです。 2つの要求のみが行われます。 HTMLコード、および1つの画像。このコードでは、シートからの各画像は幅100ピクセル、高さ200ピクセルであり、各画像は隙間なく完全に隣接していると想定しています。

<html>
<head>
<style type="text/css">
#imagegrid {background-color: black; background-image:url('http://example.com/url/to/imagesheet.jpg');}
A {display:block;width:100px;height:200px;margin:10px;float:left;}
#image1{background-position: 0px 0px}
#image2{background-position: 100px 0px}
#image3{background-position: 200px 0px}
...
#imageN{background-position: XXXpx 0px}
</style>
</head>
<body>
<div id="imagegrid">
<a href="image_one.htm" id="image1"></a>
<a href="image_two.htm" id="image2"></a>
<a href="image_three.htm" id="image3"></a>
...
<a href="image_N.htm" id="imageN"></a>
</div>
</body>
</html>

私のコードでは、3つのドットを追加しました。つまり、Spriteシートに画像の行が1行しかない場合は、番号を増やし、位置を100ずつ増やすことで、画像を追加し続けることができます。また、Operaなどの一部のブラウザーでは、バックグラウンド位置の値の前にマイナス記号を追加して、それらを機能させる必要がある場合があります。

2
Mike

保守性のため、イメージ。

私のexperienceでは、画像を使用する方が適切です。これは実際のコードでより明白であり、覚えやすいです。透明な画像のエンコードされた文字列を覚えているとは思いません。たとえ覚えていても、後継者/大学は忘れないでしょう。
数週間後にこのコードに戻ってきたら、base64を忘れてしまいました。

画像を使用する場合、コードを維持するのは非常に簡単です。最小限のプロはこれに重きを置きません。

1
Martijn

〜3余分なバイト、0余分なhttp要求、および0余分なimg src長（または0のキャッシュされていないデータイメージプレースホルダー）のみについてはどうでしょうか。画像に空白のsrcを使用できますか？

<img src data-src="banannanannas.jpg" />

また、altタグがある場合は、エラー/失敗イメージからそれらを非表示にできます。

<img src data-src="banannanannas.jpg" onerror="this.alt=''" alt="some desc" />

ディスプレイ：なし。 altタグをハックすると、画像プレースホルダーの境界からわずかなFOUCの遅延が発生します。おそらくそれも同様にきれいにすることができます。

1
dhaupin