異なるサイズの画像を Web サイト上で動的に呼び出すことはできますか?

ページには、異なる場所に異なるサイズの画像が必要な場合があります

たとえば、記事を公開してタイトル画像をアップロードすると、580*700 の元の画像と 100*100 の最終画像が生成されます

この画像をホームページで呼び出すと、サイズが 200*240 になります。元の画像が 580*700 の場合、幅を 200 に制限する必要がありますか? (元の画像を読み込むと、パフォーマンスに影響する可能性があります)。または、画像をアップロードするときに、必要なサイズの画像をすべて入れてアップロードします（これはあまり良くありません。たとえば、ホームページや他のページで異なるサイズを使用する場合、異なるサイズの写真を大量にアップロードする必要があるのではないでしょうか） )

何か良い解決策はありますか

ディスカッションに返信 (解決策)

私たちのウェブサイトのアプローチは、写真をアップロードし、保存用に異なるサイズの 7 つの写真を生成することです

これらの 7 つの写真はニーズに応じて設定されています。次に、対応する位置で対応するサイズの画像を呼び出します


img タグの幅と高さを強制的に拡大縮小すると、Web ページがフリーズします

通常、さまざまなサイズに縮小されます。これはストレージ容量を省略していると思われます。

トラフィックを 100k から 10k に削減した後を比較します。毎日 10,000 人がこの画像を使用すると設定されており、その全員がこれらの 10 ページを閲覧しています。クライアントのキャッシュは 1 日の閲覧に十分であると仮定します (同じ日にページを更新しても画像は再送信されません)

100k*10*10000*30=300G/月
削減後 自然に 10 で割ります、30G/月

これは 10 ページにのみ使用される 1 枚の写真であり、ページの更新、より多くの写真、より多くのページ呼び出しはカウントされません (「再投稿」を過小評価しないでください)
したがって、Web サイトが大きくなるほど、画像の数も多くなりますもちろん、画像のバイト数を減らす必要があります。トラフィックを節約するだけでなく、サービスの品質も考慮する必要があります

元の画像を表示する画像サイトについては、別の問題です。それはサービスの質に依存します 視点を考慮すると、元の画像が複数のページに繰り返し表示されることはほとんどありません

上の人は正しいです ストレージ容量はトラフィック/帯域幅よりもはるかに安いです....

さて、上記を修正します。同じ画像画像 (同じ URL) の場合、クライアントがキャッシュを使用し、この画像が既に存在する場合、ページ数に関係なく、繰り返しアップロードされることはありませんが、それでも異なるブラウザーが必要です

異なる場所にあり、異なるサイズの写真が必要です

たとえば、記事を公開してタイトル画像をアップロードすると、580*700 の元の画像と 100*100 のラフ画像が生成されます

ホームページ上のこの画像のサイズは 200*240 ですが、580*700 の元の画像の幅を 200 に制限する必要がありますか? (元の画像を読み込むとパフォーマンスに影響します)

または、画像をアップロードするときに、幅を 200 に制限する必要がありますか? 、必要なサイズの画像をすべてアップロードします（これはあまり良くありません、私と同じように、ホームページや他のページで使用されているサイズが異なります。異なるサイズの写真をたくさんアップロードする必要があるのではないでしょうか？）

良い解決策です
データベース構造を設計するにはどうすればよいですか? 7 つの異なるサイズのタイトル画像と 7 つのフィールドがあります

ページには、異なる場所に異なるサイズの画像が必要になる場合があります

たとえば、タイトル画像をアップロードすると、580*700 の元画像と 100*100 の最終画像が生成されます

この画像をホームページ上で呼び出したい場合、サイズが 200*240 の場合、幅を 200 に制限する必要がありますか? 580*700 の元の画像の場合は? (元の画像を読み込むとパフォーマンスに影響します)

または、画像をアップロードするときに、必要なサイズの写真をすべてアップロードします (たとえば、異なるサイズを使用する場合、これはあまり良くありません)ホームページや他のページに、さまざまなサイズの写真をたくさんアップロードする必要があるのではないでしょうか)

何か良い解決策はありますか
データベース 構造を設計する方法 7 つの異なるサイズのタイトル画像を作成できますか?

例をあげましょう

たとえば、画像 123.jpg

データ インベントリ 123.jpg

異なるサイズの 7 つの画像は、 a_123 .jpg b_123.jpg ...

です。データベース内のエントリは 1 つだけです...プログラムを呼び出すときに、サイズに対応するプレフィックスを追加するだけです
私のアプローチは、各サイズを生成することです

私のa.jpgはオリジナルであり、それを使用するたびにリクエスト時間は異なります。サイズはサーバーに送信されます。サーバーはimg.phpを使用します元のサイズを顧客が必要とするサイズに調整するため、調整が完了すると、出力がクライアントに直接エクスポートされます。このアプローチの利点は、ファイルがサーバーに直接保存されないことです。多くのファイルを保存する必要はなく、トラフィック状況を心配する必要はありませんが、サーバーの CPU 処理能力を活用できます

良いアイデアですので、検討してみましょう。

私のアプローチは、php を使用してさまざまなサイズの画像を生成することです。たとえば、

私??a.jpg は、ユーザーがリクエスト時に異なるサイズをサーバーに送信するたびに、サーバーは img.php を使用して元のサイズを顧客がリクエストしたサイズに調整し、その後リクエストを直接クライアントにエクスポートします。この方法の利点は、多くのビデオを保存する必要がなく、トラフィックを心配する必要がないことですが、CPU の処理能力を消費します。

ファイルを直接読み取る場合と比べて、応答速度はどうですか?

私のアプローチは、php を使用してさまざまなサイズのファイルを生成することです (例:

私の a.jpg はオリジナルですが、それを使用するたびに、リクエストしたときに異なるサイズが届きます。サーバーは img.php を使用して元の画像をクライアントが必要とするサイズに調整します調整が完了すると、出力イメージはサーバーに直接保存されずに直接エクスポートされますが、トラフィックを気にしないことが最善です。サーバーの CPU 処理能力を使用できます。

ファイルを直接読み取る場合と比べて、応答速度はどのようになりますか? 複数のサイズの保存されたファイルを直接取得する場合よりも遅くなります。その理由は次のとおりです。 ?? そして私の方法では、CPU が最初にチップ全体のサイズを調整してからクライアントにエクスポートする必要があるため、どれくらい遅くなるかについては、サーバーの CPU 速度に依存します。

私のアプローチは、php を使用してさまざまなサイズの画像を生成することです。たとえば、

私??a.jpg はオリジナル?、毎回使用してください。 リクエスト時に、さまざまなサイズをサーバーに転送すると、サーバーは img.php を使用して元のサイズを顧客が要求したサイズに調整します。調整が完了すると、直接エクスポートされます。一方、プログラムによって生成されたビデオ クリップはサーバーに直接保存されません。この方法の利点は、多くのクリップを保存する必要がなく、トラフィック フローを心配しないことです。サーバーの CPU 処理能力を使用します。

ファイルを直接読み取る場合と比較して、応答速度はどの程度ですか? サイズが大きい保存ファイルを直接取得する場合よりも遅い理由は次のとおりです。画像は消費するだけでよく、私の方法ではまず CPU が画像のサイズを調整してからクライアントにエクスポートする必要があるため、どれくらい遅いかについてはサーバーによって異なります。

わかりますが、これは良いアイデアです

珍しい写真など、それを使用する場所があるはずです

私のアプローチはphpを使用することです。 ?? それぞれのフィルムのサイズを指定します。例:

私の a.jpg は、私が使用するたびに元のファイルですサーバーへの異なるサイズの送信を要求する場合、サーバーは img.php を使用して、調整が完了した後、クライアントに直接エクスポートされます。このアプローチの利点は、多くのファイルを保存する必要がなく、サーバーの CPU 処理能力を使用することです。ファイルを直接読み込むと、保存されている大きなサイズのファイルを直接取得するよりも時間がかかります。その理由は次のとおりです。保存されたファイルを直接取得する場合、消費するのは ?? だけであり、私の方法では最初に CPU がチップ全体のサイズを調整する必要があります。それをクライアントにエクスポートするので、どれくらい遅くなるかについては、サーバーの CPU 速度に依存します

わかりましたが、これは良い考えです。普段は使用しない画像など、使用できる場所があるはずです。テストする必要があるのは、コピーをサーバーに保存することです。外部 CPU が必要ですか?

私のアプローチは、php を使用してさまざまなサイズのフィルムを生成することです。たとえば、

私??a .jpg はユーザーが要求するたびに、サーバーは img.php を使用して元のファイルを要求されたサイズに調整し、ファイルが完成した後、クライアントに直接エクスポートします。エクスポートされたファイルはサーバーに直接保存されません。これを行うための最善の方法は、大量のファイルを保存しないことです。ただし、サーバーの CPU 処理能力を使用します。ファイルを直接読み取る場合と比べて、応答速度が遅くなります。なぜなら、サイズの大きいファイルを直接読み取る場合と比べて、速度が遅くなります。ただし、この方法では、最初に CPU がファイルのサイズを調整する必要があります。ファイルを作成してからクライアントにエクスポートするため、サーバーの CPU 速度に応じてさらにステップが 1 つあります。

使える場所、珍しい写真などもあるはずです

これも考えました 例えば記事の一覧をループで出力する場合、それぞれのサムネイルを出力するにはimg.phpを呼び出す必要がありますウェブサイトのアクセス数が多い場合、ページが別の場所にあり、別のサイズの写真が必要になる可能性があります

たとえば、記事を公開し、元の写真をアップロードするとします。 580*700 と 100*100 のラフな画像が生成されます

この画像をホームページ上で呼び出したい場合、サイズは 200*240 です。はい、580 の場合は幅を 200 に制限する必要がありますか? * 700 枚の元の画像? (元の画像を読み込むとパフォーマンスに影響する可能性があります)

または、画像をアップロードするときに、必要なサイズの画像をすべてアップロードします (これはあまり良くありません。たとえば、ホームページや他のページで異なるサイズを使用する場合) 、異なるサイズの写真をたくさんアップロードする必要はないでしょうか?)

何か良い解決策はありますか? データベース構造を設計する方法はありますか? タイトル画像には 7 つの異なるサイズがあり、各フィールドを 7 つ保存する必要がありますか?
これを長時間行うと、Web サイトでは使用されない余分な写真が大量に生成されますが、それらは常にサーバー上に存在し、スペースを占有します。ファイルが大きい場合は、静的な画像を作成する方が良いでしょう。 #1 と同様に、画像がアップロードされるたびに変換を実行し、複数の固定サイズの画像を一度に保存します。その後、別のページで適切なサイズを呼び出します。ページの要件と完全に一致していない可能性がありますが、HTML で幅/高さを少し変更しても大きな影響はありません?? ヨンイ

大規模なサイトでは CDN キャッシュも必要です

画像を動的に生成するとサーバーに負担がかかりすぎるため、結局のところ、複数の異なるフォーマットを直接生成する方が良いのです。

写真が多すぎるのが怖い場合は、解像度に応じて別のフォルダーに保存でき、後で整理するときに簡単に削除できます