11

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

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

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

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

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

それらのうちどれがウェブサイトの速度を上げ、HTTPリクエストを少なくするためのより効率的な方法ですか？（ユーザーが14.4kbpsのインターネット速度-最初のインターネット速度でWebページをロードしているとしましょう）。

しかし、SEOについては？

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

— MM PP
ソース

8

「データベース64の空白の画像を使用している場合、ページ上の画像の数と同じ数のリクエストが表示されます。」-何か問題がありますか？data-URIを使用する重要な点は、外部HTTPリクエストがないことです。（data-URIを理解しないユーザーエージェントのみがHTTPリクエストを

— 起動

空白の画像が1x1ピクセルよりも大きい場合（私はそうだと思います）、レンダリングが高速になるため、より大きい背景画像（10x10ピクセル、100x100ピクセル）をお勧めします。

— totymedli

3

何も使用しませんか？data-srcをsrcに変換すると同時にimgタグを動的に作成できます。data-srcで空の画像を作成する代わりに、画像のリストを保存し、必要に応じてタグを生成できます。

— the_lotus

ブラウザが画像を非表示にしてもダウンロードするため、機能しない@Pharap。

— DisgruntledGoat

コンテンツを配信するためにどちらを選択しても、それをpng8としてエンコードすると、JPEGよりも高速になります。

— symcbean、2016年

12

base64画像オプションは、画像の数が非常に少なく、サーバーから画像を取得するネットワークオーバーヘッドを排除したい場合に使用してください。しかし、あなたが質問で示していることから、これは多数の画像にスケーリングできると思います。この場合は、サーバーから1ピクセルx 1ピクセルの透明な画像を1つ使用します。これは、サーバーから一度フェッチされ、ブラウザーと中間プロキシサーバーにキャッシュされるため、キャッシュの有効期間が長くなります。

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

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

— クリス・ラザファード
ソース

6

空のbase64イメージは55バイトになる可能性がありますdata:image/gif;base64,R0lGODlhAQABAAAAACwAAAAAAQABAAA=。画像のURLが少し長い場合（例：example.com/templates/template-name/files/1x1.png）、HTTPクエリを実行せず、バイト数が小さいため、base64画像が推奨されます画像のURL（ページ上の画像ごとに繰り返されます）+外部画像のサイズより。

— NETCreatorホスティング、

@ NETCreatorHosting-WebDesignコメントありがとうございます。base64画像と外部画像を使用した場合のウェブサイトサイズを比較しましたが、base64画像を使用した場合はサイズが小さくなります。1ページあたり約40枚の画像を使用しています。

— MM PP

または、ウェブサイトのルートに画像をアップロードし、相対URLを使用して、ウェブサイトをはるかに小さくすることもできます。

— NETCreatorホスティング、

3

gzipは繰り返しを処理するため、ページに400 base-64でエンコードされた画像が含まれていても、画像のURLが400よりも多くの帯域幅を消費することはありません。

— user2428118

3

@Aronページが25.6 MB大きい場合（その間に64kBを含む400バイトの82バイトのデータURI = 25,568,800バイト）、base64でエンコードされた32.8 kBの画像よりも大きな問題が発生します。

— user2428118

5

IE <8のサポートが必要でない限り、間違いなくデータURIを使用してください（ブラウザサポート）。

たくさんの小さな画像を直接HTMLに埋め込むと、直接リンクするよりも多くの帯域幅を消費するように見えるかもしれませんが、その増加はgzipによって緩和されます。ページのサイズの唯一の違いは、空白の画像の1つのデータURIとサーバー上の画像の1つの URLの長さの違いに由来します。ブランクGIFは 43のバイトと小さくすることができます。Base 64エンコード、つまり82バイト。500バイトを超えるHTTPリクエスト（同様のサイズの応答）よりもパフォーマンスが低下することはありません。そのため、TCPパケットサイズやその他のオーバーヘッドも考慮に入れていません。

Base 64でエンコードされた43バイトのGIF画像は次のとおりです。

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

SEOについては、GoogleニュースなどのGoogleサイトのソースコードを見て、data:image/gif,base64… を検索します。

— user2428118
ソース

画像が大きいです。55バイトバージョンの上記のコメントを確認してください。

— ジョシュア

1

報告されたテスト（2014年5月）でのStackOverflowに関するこの回答は、1pxの画像を大量（約1800）に埋め込むと、同じ外部画像に繰り返しリンクするよりもかなり遅いことを示しているようです。外部画像は1回リクエストされてキャッシュされますが、ブラウザはHTML解析プロセスの一環としてすべてのデータURIを個別にデコードする必要があります。これがボトルネックになると思われます。これは、データURIを少数の（小さい）画像に制限する必要があることを示唆しているようです。

— DocRoot

@Joshuaその画像は私のブラウザ（Firefox）では正しく表示されますが、他のプログラム（例：ペイント）で開くことができないため、使用しないようにします。

— user2428118

2

この時点で、私はこの問題を解決するために2つのオプションを見つけました：すべての画像の初期srcがデータベース64の空白の画像になる

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

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

すべての画像スロットの空白の画像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つのドットを追加しました。つまり、スプライトシートに画像の行が1つしかない場合は、番号を増やし、位置を毎回100ずつ増やすことで、画像を追加し続けることができます。また、Operaなどの一部のブラウザーでは、バックグラウンドの位置の値の前に負の符号を追加して、それらを機能させる必要がある場合があります。

— マイク
ソース

2

画像のサイズが半ギガバイトでない限り、画像をbase64でデコードしてもパフォーマンスに測定可能な影響が及ぶことはありません。

— user2428118

また、コンピューターシステムにも依存します。クライアントがまだペンティアム1などの旧式のコンピューターを使用している場合は、パフォーマンスに影響がある可能性があります。

— マイク、

1

メンテナンス性のため画像です。

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

画像を使用する場合、コードを保守することは非常に単純になります。最小限のプロはこれまでの重みはありません。

— マルティン
ソース

多くの人がスクリプトを使用してbase-64値を生成しているため、OPが彼のWebサイトのコードを表すためにHTMLファイルのセットのみを使用しない限り、そのような値を覚えておく必要はありません。

— マイク、

1

わずか約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がわずかに遅れます。おそらくそれも同様にきれいにすることができます。

— ドーピン
ソース

2

ただし、空のsrc属性を指定しても、W3Cバリデーターでエラーが発生します（これは問題のようです）。

— MrWhite

@ w3dkうん、それはうんざりするが、それでもまた非常に少数の近代化が成功する。

— dhaupin

W3Cルールを渡す場合は、404エラーを返すURLであっても、srcに何かを指定する必要があります。また、ロードプロセスの途中で膨張する小さなボックスではなく、実際のプレースホルダーが最初に表示されるように、画像の幅と高さの属性の値を指定することをお勧めします。

— マイク

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

メンテナンス性のため画像です。