実際、ほとんどすべてがタイトルから明確になっているはずです。 しかし、この画像はあまり関連性がありません。IEに追いついた後、FoxいながらFoxを描く必要があります。
この投稿は、 「丘を越えて」への答えです。何時間かは自由時間があり、それらを占有する何かがあったからです。
UPDプラグイン-Wappalyzer-が発見されました。これにより、FirefoxのデータURIの表示が大幅に遅くなりました。 しかし、それをオフにしても、Firefoxはほとんどすべてのブラウザーで失われ続けています。
しかし、すべて順番に。
背景
数か月前、アメリカ人（ロシア語のような名前）が私のSkypeをノックして、Yahoo！からの最新の最適化について知っていることを尋ねました。 （まあ、 最終的にデータを実装したもの：URI ）、特にデータのパフォーマンス：URI。 おそらく（データ：URIはbase64の画像なので）後者は通常の背景画像よりも動作が少し遅く、速度が低下するように見えると言いました。
予備環境をすばやく収集し、30分後に予備結果を作成しました。データ：URIは遅くなりますが、時々非常に遅くなります。 そのようなレイアウトは私には疑わしいように思えたので、より良い時までアイデアを押し進めました。 そして、彼らは到着しました:)
テスト環境
簡単に言うと、ブラウザーでのページレンダリングを正しく測定することは、非常に難しい作業です。 この場合、非常に大まかな近似で解決されました（状況の一般的な評価には十分ですが、他の場所では使用されません）。 ページの上部にタイマーを挿入し、
onload
カウントダウンの終わりを切ります。 メカニズム全体は、ローカルコンピューター（ネットワーク遅延を排除するため）またはハードキャッシングを使用するサーバー（ブラウザーは、1つのセッションで条件付きキャッシュヘッダーを使用してリソースを再要求しません：これはチェックされます。このトピックに関する記事も投稿します）。
素晴らしい。 その結果、「ローカル」ページ（ページへの最初のリクエストの後、タブを閉じ、新しいタブを開き、元のページを開きます：これにより、実験に必要な「クリーン」が作成されます）は、ハードドライブからブラウザーに表示されます。 その後、レンダリング時間（99％）は、リソースの取得速度ではなく、ブラウザーの機能に依存します。
さらに、当然、すべてのテストは10回実行されました。 3-デルタエミッションは考慮されていません。 その結果、全体の精度は10％以上になります（つまり、最も可能性の高いエラーは3-5％です）。
テスト1：背景の写真
むかしむかし、従来の画像の使用に対する推奨事項がありました。 背景画像ですべてを行うことが推奨されました。 これはそうではありません（キャッシュされたページをミリ秒で表示した結果）。
| テスト | Chrome2 | Fx3.5 | Opera10 | IE8 | IE6 / 7 |
|---|---|---|---|---|---|
| 「きれいな」写真 | 33 | 10 | 52 | 189 | 182 |
| 背景画像 | 124 | 11 | 47 | 181 | 130 |
ご覧のとおり、Chromeのみが「オフ」になりました（ 「非常に高速」に動作するように大幅に最適化されたタイマーにより、Safariは考慮されませんでした）が、メインブラウザーの背景からは見えません。
結論：本質的に違いはありません。 特に、670,000平方ピクセルの画像の総作業領域を考慮すると（これが十分ではない理由を以下に説明します）。
テスト2：パフォーマンスデータ：URI / mhtml
さらに進んでいます。 data：URIはIE8でのみサポートされています。IE6/ 7ではmhtmlを使用する必要があります 。 また、IE8は24 KBの大きな画像をサポートしていません。 したがって、IEの表では、結果はmhtmlであり、残りはデータ：URIです。
| テスト | Chrome2 | Fx3.5 | Opera10 | IE8 | IE6 / 7 |
|---|---|---|---|---|---|
| データ：URIおよびmhtml | 56 | 162 | 70 | 225 | 442 |
ここでは「いくつかのブレーキ」がすでに顕著になっています。 Firefoxの場合、同じ画像のレンダリングには10倍の費用がかかります。 しかし、これらの手法を背景画像に適用することを検討していますか？ そして彼らのために：
| テスト | Chrome2 | Fx3.5 | Opera10 |
|---|---|---|---|
| データ内の背景画像：URI | 83 | 155 | 69 |
私たちが見るように、一般的な傾向は持続します。 しかし、それだけではありません
結論：データ：FirefoxではURIが遅くなり、IEではmhtmlが遅くなります。
テスト3：大量のデータのパフォーマンス：URI / mhtml
熱心な読者は長い間質問を用意してきました。同じ信じられないほど大きな画像が私たちに何を示しているのでしょうか？ ただし、「実際の」サイトでは、すべてが異なります。 がっかりさせてしまいました。サイズが1000×1000ピクセル（100万平方ピクセル）のCSSスプライトはそれほど珍しいものではありません。 平均して、背景画像は各サイトのページ領域の5〜20％を占めています。 1200x1024の解像度では、これは約60〜25万平方ピクセルです（つまり、元の画像よりも3〜10倍小さい）。
では、80個の画像（合計16万ピクセル）を使用して、ブラウザーがどのようにレンダリングされるかを見てみましょう。 そのため（IE8はデータを使用します：URI）：
| テスト | Chrome2 | Fx3.5 | Opera10 | IE8 |
|---|---|---|---|---|
| データ内の多くの写真：URI | 65 | 105 | 85 | 99 |
何か思い出させますよね？ はい、画像の合計サイズを4倍に削減しましたが、オブジェクトの数が40倍（2から80）増加したため、状況は事実上繰り返されました。 実際のページには、数十個、時には数百個の背景画像があります。 つまり テストはますます現実に近づいています。
結論：遅いbase64レンダリングは、領域のサイズだけでなく、オブジェクトの数にも依存します。
テスト4：顔を合わせて顔を見ない
しかし、ここでも少しずるいことがありました。結局、ページ上に同じ数の通常の画像が表示された場合のブラウザーの動作はわかりません。この場合、ブラウザーはどのように「スローダウン」しますか？ この目的のために、さらに2つの同一の環境が収集されました。 それぞれについて、2つの異なる画像と10のオブジェクトを使用して、それらから背景を切り取りました。
| テスト | Chrome2 | Fx3.5 | Opera10 | IE8 | IE6 / 7 |
|---|---|---|---|---|---|
| 背景写真 | 124 | 24 | 63 | 166 | 131 |
| データ内の背景画像：URI | 41 | 140 | 73 | - | - |
IE6 / 7/8では、mhtmlページから取得した結果を推定したり、mhtml背景画像で環境を再構築したりできます。 しかし、主な結果は今言うことができます。
ブラウザの使用統計を取得し、データに対してURIを使用してCSSスプライト（背景画像）を使用する場合、ブラウザのシェアに相対的な加速を掛けます：URI / mhtmlアプローチ。 5 * 670,000 = 335万ピクセル（および10個のオブジェクト）の合計面積に対して100ミリ秒の数値が得られます。 背景画像を含む50個のオブジェクトと合計10万ピクセルの「平均」サイトの場合、 各ページの表示に約15ミリ秒の遅延が発生します（ブラウザーのキャッシュにあるリソースの数に関係なく、ネットワーク遅延は既に独自に再生されています）。 背景画像を持つ数百のオブジェクトと百万ピクセルの総面積（たとえば、ある種の複雑なWebインターフェース）がある場合、ユーザーの平均遅延は0.5秒以上に達する可能性があります。 これらはパイです。
結論：データ：URI + mhtmlは大幅に遅くなる可能性があります。
どうする
FirefoxとIEが高速なページレンダリングを処理し、base64データを通常の画像と同じ速さで表示できれば、すべてが素晴らしいでしょう。 この場合、複数のbase64イメージを使用することは、一般に、CSSスプライトより悪くありません。 最善の解決策は、CSSスプライトを事前に使用し、最小数の画像をbase64形式に変換することです。これにより、すべてのコストが最小限に抑えられます。
PSテストページの写真が本当に気に入らない場合は、適切なサイズへのリンクを破棄してください-交換します。 手元には他に何もありませんでした:)
PPSこのノートの計算はすべて推定値です。 これらは、base64形式の画像の「弱点」のみを表示するように設計されており、使用できる場合と使用できない場合に明確な計算アルゴリズムを提供するようには設計されていません。