ファイル全体がダウンロードされるまで、すべての画像の「初期表示」を遅らせるため、すべてを 1つの画像に結合することはお勧めしません。目に見えるものをできるだけ早くロードし、残りを全体的なスループットのために最適化することをお勧めします。
たとえば、画像がそれぞれ 50KB 未満の場合、それらをスプライト画像として結合することは理にかなっているかもしれませんが、一度に 10 個ずつ結合することをお勧めします。画像がそれぞれ 5KB のように小さい場合は、一度に 30 個が妥当です。
ここには、心配すべき一連のボトルネックがあります
- HTTP のオーバーヘッドと同時接続の制限 (スプライト画像がこれに役立ちます)
- サーバーのスループット オーバーヘッド (正しいディスク キャッシングとエッジ キャッシングで解決可能)
- ブラウザのレンダリング オーバーヘッド (スプライトはアイコンや小さなサムネイルに最適です。巨大であってはなりません。1 メガピクセル未満に保つようにしてください)。
既存の画像を結合して jpeg 形式で再圧縮すると、圧縮が改善される場合もありますが、アーティファクトが発生する場合もあります。たとえば、線画と写真を混ぜるのはよくありません。jpegは線画が苦手です。必要に応じて、PNG、さらには PNG-8 を使用してください。場合によっては、100% 品質の JPEG が GIF または PNG バージョンよりも小さくなることがありますが、ほとんどの場合、線画は PNG 形式で保存するのが最適です。
これらの写真の ID を持っていて、ディスク キャッシュを使用した動的ルートを計画している場合は、タスクが大幅に簡素化されます。
ImageResizerライブラリを使用すると、動的パイプラインとディスク キャッシング システムに非常に簡単に「プラグイン」できます。
この場合、 と を実装IVirtualImageProviderしIVirtualBitmapFileます。ビットマップを生成し、残りをパイプラインに処理させる簡単な例については、 Gradient プラグインを参照してください。
URL 構文を定義し、FileExists メソッドと GetFile メソッドでそれを探す必要があります。/combine-images.ashx?idlist=34,56,79,23&dir=horizontal&width=50&height=50 のようなもの。
次に、各画像を読み込み、マネージ APIを使用してビットマップ インスタンスにサイズ変更し、割り当てたキャンバスに描画する必要があります。
ボトルネックのほとんどは、おそらく SQL からイメージをプルすることにあるでしょう。サーバーの RAM が限られている場合は、並列アプローチよりもシリアル アプローチの方が安全かもしれません (つまり、SQL から一度に 1 つのイメージを取得し、サイズを変更して描画し、データを破棄して先に進みます)。ソース イメージが小さい場合は、マルチスレッド アプローチで問題ない可能性があります。リクエストはデフォルトで 30 秒後にタイムアウトするため、ディスク キャッシュであっても高速にする必要があることを覚えておいてください。適切に実行すると、空のディスク キャッシュを使用して 2 秒未満で 10 個の画像スプライトを提供できるはずです。キャッシュ後は 20 ミリ秒かかります。
これが少し難しいと思われる場合は、カスタム プラグイン開発を提供しますが、待ち行列があります。
リクエストごとに 1 ファイルのアプローチには多くの利点があり、スプライト バンドワゴンに飛び乗る前に、ImageResizer のディスク キャッシュと SqlReader プラグインを試す価値があるかもしれません。それが間違ったアプローチだと言っているわけではありませんが、キャッシュされていない MVC+SQL は、寄与している可能性のある多くのオーバーヘッドを追加する可能性があります。