7

私は大きなサイト (Google、Facebook、Youtube など) から、クライアント側の希望する測定値に「近い」画像のサイズを変更していることにますます気づいています。彼らは怠惰です。

数十万、場合によっては数百万に上る一連の製品 (e コマース) の特定のサイズで、標準的な一連の画像に新しい画像サイズを追加するシナリオを考えてみましょう。

300x350 などの元の画像のコピーがあり、クライアント側で 200x250 にサイズ変更するとします。1 ページに 20 個の製品があるため、各製品に対してこれを行います。

この新しいサイズに対応するためのサーバー側の作業と問題は、クライアント側のメリットに本当に値するのでしょうか?

そうでない場合、特定のサイズをいつ前処理する必要があるかを判断する良い方法は何ですか?

はいの場合、サーバー側の処理とキャッシングが過剰になる場合はありますか (つまり、110x220、120x230、150x190 などの 8 つの画像を格納するなど)?

4

2 に答える 2

1

次のことを考慮してください。画像のサイズ変更は、サーバーにとって負荷の高いプロセスです。それはまず第一にそれ自体が高価です。次に、非常に遅いのはハードドライブの IO 操作です。だからそれはすべて、サーバーの負荷に依存します。

クライアントにとっては、次の 2 つの点で重要です。

1) サムネイルはファイル サイズが小さいため、ダウンロードがはるかに高速です。そのため、それらははるかに速く表示されます。しかし、それはすべて、日々増加しているインターネット接続の速度に依存します。読み込まれる画像のサイズを見たことがありますか? それらは一度に全体を表示するのではなく、「線」ごとに表示されます

2) 大きな画像を小さなサイズで表示しようとすると、品質が大幅に低下します。これは、ブラウザがそれを処理する方法が原因です。Photoshop の機能がなく、適切な品質のサイズ変更を行うことができません。

3) 1 つのページに多くの大きな画像があると、そのページのメモリ使用量が増加します。それほど強力ではない一部のコンピューターでは、スクロールして開くときにひどい遅延が発生する可能性があります。

この質問の解決策として、私は Drupal モジュールの 1 つで見たことを実行する傾向があります (imagecache私が正しければ)。

画像のアップロード時にサムネイルは作成されません。代わりに、.htaccess および mod_rewrite 機能を使用して、要求時にそれらを作成します。要求されたファイルが存在しないかどうかを確認し、存在しない場合は、サムネイルを作成し、ファイル システムに書き込み、クライアントに出力する小さくて軽量な PHP スクリプトに要求をリダイレクトします。

したがって、次の訪問者は、以前に作成されたサムネイルを既に取得しています。

したがって、延期された/遅延した画像のサイズ変更を実装すると、読み込みがスムーズになります (時間内にストレッチされます)。

于 2012-11-23T13:25:02.990 に答える
0

最初にページ上の 1 つの画像でこれをテストすることにし、複数の画像を予測するために乗算計算を行いました。私は注意する必要があります：

  • このテストにはpngを使用していましたが、pngはかなり標準的なようです。
  • サイズを変更した画像の元の縦横比に常に合うように、widthapativeが画像のサイズを変更する特定の関数を使用していました。height

450x450 (おおよそ) の画像を取得し、クライアント側で 200x200 にサイズを変更することにしました (この回答のすべての測定値はピクセルです)。サイズ変更が画像の合計サイズの半分以上であるにもかかわらず、CPUジャンプはほとんどありませんでした。

Chrome、Opera、Firefox、IE など、すべての最新ブラウザで品質も良好で、Photoshop や GD で行った場合と同じくらい鮮明な画像が表示されました。

IE7 では、CPU ジャンプの多くに気付かず、画像サイズの制約に基づいてパーセンタイル サイズ変更を使用した場合、品質は良好でした。

全体として、このサイズのキャッシュサーバー側でも作成するために必要な追加のストレージ、計算、およびコーディングは、ユーザー側で暗示される可能性のある能力にとって不利であるように思われました.

そうは言っても、このタイプのサイズ変更を複数回（私の質問のように20回と言う）やり始めると、おそらく問題が発生し始めるでしょう。

少し調整した後、画像の幅または高さが 1000px 未満であれば、元の画像サイズの 1/3 未満のものは、CPU および一般的なコンピューターのパフォーマンスにとって無視できるように思われることがわかりました。

私が使用していた追加機能を使用すると、サーバー側と同じようにクライアント側のサイズを変更しても品質が向上しました。私が（利害関係者のために）使用した特定の機能は次のとおりです。

function pseudoResize($maxWidth = 0, $maxHeight = 0){

$width = $this->org_width;
$height = $this->org_height;

$maxWidth = intval($maxWidth);
$maxHeight = intval($maxHeight);

$newWidth = $width;
$newHeight = $height;

// Ripped from the phpthumb library in GdThumb.php under the resize() function
if ($maxWidth > 0)
{
    $newWidthPercentage = (100 * $maxWidth) / $width;
    $newHeight          = ($height * $newWidthPercentage) / 100;

    $newWidth = intval($maxWidth);
    $newHeight = intval($newHeight);

    if ($maxHeight > 0 && $newHeight > $maxHeight)
    {
        $newHeightPercentage    = (100 * $maxHeight) / $newHeight;

        $newWidth = intval(($newWidth * $newHeightPercentage) / 100);
        $newHeight = ceil($maxHeight);
    }
}

if ($maxHeight > 0)
{
    $newHeightPercentage    = (100 * $maxHeight) / $height;
    $newWidth               = ($width * $newHeightPercentage) / 100;

    $newWidth = ceil($newWidth);
    $newHeight = ceil($maxHeight);

    if ($maxWidth > 0 && $newWidth > $maxWidth)
    {
        $newWidthPercentage = (100 * $maxWidth) / $newWidth;

        $newHeight = intval(($newHeight * $newWidthPercentage) / 100);
        $newWidth = intval($maxWidth);
    }
}

return array(
    'width' => $newWidth,
    'height' => $newHeight
);
}

したがって、私自身のテストから、使用するすべての画像のすべてのサイズを収容しているように見えます。つまり、質問で尋ねたように:

はいの場合、サーバー側の処理とキャッシングが過剰になる場合はありますか (つまり、110x220、120x230、150x190 などの 8 つの画像を格納するなど)?

現代のコンピューティングではやり過ぎのように思われます。多くの異なるサイズの多くの画像を使用する場合は、厳密な測定を行う必要があります。

ただし、サイズの標準セットがあり、それらが小さい場合、実際にはサーバー側のサイズ変更とすべてのサイズのストレージに利点があることがわかりました。クライアントにサイズ変更を強制すると、常にコンピューターの速度が少し低下しますが、元のサイズの 3 分の 1 のサイズでも、それほど大きな違いはないようです。

したがって、FB や Google や Youtube などのサイトがすべての画像の正確な測定値を保存することについてあまり心配していない理由は、「測定値に近い」スケーリングが全体的にパフォーマンスが向上する可能性があるためだと思います。

于 2012-11-27T12:26:59.207 に答える