Cloudinary、Imgixなどのサービスの効率
たくさんの画像を使ってウェブサイトを作りたいので、Amazon、ebay、flipkartなどの画像操作を行います。サイズの異なる複数のバージョンが必要ですが、各画像の1つのバージョンを保存する方がよいため、Cloudinary、Imgixなどのサービスを使用して画像のサイズを変更することをお勧めします。これらのサービスがどれほど効率的か知りたいのですが。何か問題はありますか？私のウェブサイトは非常に高速で応答性が高いものにしたいと思います。 「画像操作を完了するために必要な時間を支配することが多い、関連する転送遅延を少なくとも2倍にしていることを考慮に入れてください。
通常：end_user-> your_user-> end_user
これらのサービスを通じて：end_user-> your_user-> you-> your_user-> end_user "
（免責事項：私はimgixで開発者関係を処理し、スタックに適用されるのでこの投稿に回答します）
完全にキャッシュされていない画像の場合、画像を提供するために必要な「ホップ」が増えることは間違いありません。最初のユーザーが画像を表示する場合、これにより遅延がわずかに増加する可能性があります。ただし、その後、画像はレンダリングクラスターとグローバルCDNの両方によってキャッシュされます。これにより、元の画像に基づく画像の後続のリクエストがはるかに高速になります。いずれにせよ、正しいサイズの画像をブラウザに提供することによるバイトの節約は、ほとんどの場合、画像の最初の要求による追加の遅延を上回ります。
画像がまだキャッシュされていないときのフローを示す簡単な図です：
┌─────────────────┐ 4. Origin responds
│ Your Origin │ with full-size
│ (S3/web folder) │ `dogs.png` image.
└─────────────────┘
▲ │
│ │
│ │
│ ▼
3. Image is not ┌─────────────────┐ 5. imgix caches the
cached at imgix, send │ imgix │ full-size image, then
request to Origin for │ │ resizes it to 300px
`dogs.png` └─────────────────┘ wide and caches that
▲ │ derivative.
│ │
│ ▼
2. Image is not ┌─────────────────┐ 6. The imgix CDN
cached at CDN, │ imgix CDN (Edge │ caches the 300px wide
forward to imgix │nodes worldwide) │ variant and serves it
rendering cluster. └─────────────────┘ to the browser.
▲ │
│ │
│ │
│ ▼
1. Browser requests ┌─────────────────┐ 7. The browser
`dogs.png?w=300` │ User's Browser │ receives and renders
│ │ 300px wide `dogs.png`.
└─────────────────┘
画像がキャッシュされると（1人のユーザーが画像を要求した後）、ループは非常にタイトになります：
2. The imgix CDN has ┌─────────────────┐
this variant cached, │ imgix CDN (Edge │
and serves it to the │nodes worldwide) │
browser. └─────────────────┘
▲ │
│ │
│ │
│ ▼
1. Browser requests ┌─────────────────┐ 3. The browser
`dogs.png?w=300` │ User's Browser │ receives and renders
│ │ 300px wide `dogs.png`.
└─────────────────┘
元の画像がレンダリングクラスターにキャッシュされた後、派生サーバーへの追加のアクセスを必要としないため、派生物の生成もはるかに高速になります（この場合は600px幅のバージョン）：
3. Full-size image is ┌─────────────────┐ 4. imgix resizes the
already cached at │ imgix │ cached full-size image
imgix, no Origin │ │ to 600px wide and
request needed. └─────────────────┘ caches that
▲ │ derivative.
│ │
│ ▼
2. Image is not ┌─────────────────┐ 5. The imgix CDN
cached at CDN, │ imgix CDN (Edge │ caches the 600px wide
forward to imgix │nodes worldwide) │ variant and serves it
rendering cluster. └─────────────────┘ to the browser.
▲ │
│ │
│ │
│ ▼
1. Browser requests ┌─────────────────┐ 6. The browser
`dogs.png?w=600` │ User's Browser │ receives and renders
│ │ 600px wide `dogs.png`.
└─────────────────┘
私は1年以上imgixを使用しています。プロの画像サーバーで画像をホストする方が、サーバーで画像をホストするよりもはるかに優れていると思います。
高性能
1- Paul Strawが言ったように：Imgixには適切なキャッシュ戦略があります。イメージをロードするためのレイテンシーは追加されません。ページが読み込まれるたびにマスターイメージをフェッチしないため、レイテンシーも差し引かれます。キャッシュから画像をフェッチします。
2- Cloudinaryとimgixはどちらも、幅広く高速なCDNを使用しています。したがって、画像をダウンロードする必要があるユーザーは、自分の場所に近いCDNEdgeからファイルを取得できます。したがって、待ち時間が短縮され、ダウンロードが速くなります。
3-特定のデバイスに適切な画像サイズを提供する（または可能な限り近い）ことは、画像がページの読み込み時間に悪影響を与えないようにするための最良の方法です。画像の実際のサイズと希望のサイズのわずかな違いでも、ファイルサイズが劇的に大きくなる可能性があります。画像ホスティングサービスの最も基本的な機能は、必要に応じて任意のデバイスに合わせて画像のサイズをその場で変更できることです。
これらのサービスの高性能に加えて、私はここでそれらのいくつかに言及する他のいくつかの利点も見ました：
レスポンシブ画像
今日では、多くのWebサイトの所有者、販売およびマーケティングの幹部、そして...多くのマーケティングの側面に関心があります。ユーザーを購入者に変えたり、ウェブサイトで特定の目標を達成したりするために、写真を慎重に選択します。レスポンシブデザインには画像のサイズを変更するだけで十分かもしれませんが、ウェブサイトのコンバージョン率を上げるには十分ではありません。サイズを変更するために画像をトリミングする必要がある場合があります。画像ホスティングサービスを使用すると、トリミングする場所、画像のどの部分を残すために不可欠な画像の部分、およびトリミングできる部分を正確に選択できます。 Photoshopを使用せずに、これらのサービスを使用してこれらすべてのコントロールをオンザフライで実行し、いくつかの写真をオフラインで準備できます。
Retinaサポート
ほとんどの画像は通常の画面では良好に表示されますが、Apple Retinaまたは一部のAndroidデバイスはまったく良好ではありません。デバイスのピクセル比は、デバイスに依存しないピクセルとデバイスのピクセルを簡単に変換するために使用されます。これにより、Apple Retinaディスプレイおよび= Androidデバイス。imgixでは、画面が高密度画像をサポートできる場合、より高いDPRで画像をロードすることを選択できます。srcsetタグを使用してロードできます。 詳細はこちら
オンザフライでの画像操作
写真でやりたいことはすべてその場で行うことができます。小さな画像の操作にPhotoshopを使用する必要はありません。これにより、設計速度が大幅に低下します。
より良いSEOランキング
画像サイズはページの読み込み速度に大きく影響します。これは、ページの検索結果のランキングを決定する際の重要な指標です。画像サイズを小さくすると、ランキングの向上に大いに役立つ可能性があります。特に、多くのユーザーが焦りから脱落し始めるしきい値を下回るページ全体の読み込みを取得できる場合はそうです。
[開示、私はImageEngineを提供する会社のCTOです]
私たち自身の言及 ImageEngine はここに順番にあります。 ImageEngineは、OPが言及した他のソリューションとまったく同じスペースにありますが、いくつかの追加の利点があります。そのCDNは、モバイルの最適化を念頭に置いてゼロから構築されました。デスクトップブラウザに加えて、ImageEngineのエッジサーバーは、画面サイズ、解像度、サポートされている画像コーデックなどの機能を正確に検出し、それに応じて画像を最適化できます。これは、FacebookとGoogleで採用されているのと同じ デバイス検出 ソリューションであるWURFLのおかげで発生し、追加の最適化（最大80％の帯域幅節約）とCDN料金の削減を説明します。この概念を「スマートバイト」と呼びます。
もう1つの大きな違いは、統合のしやすさです。 ImageEngineでは、組織がどこにでも画像をアップロードする必要はありません。これは、レガシーイメージを処理する企業に最適です。 ImageEngineでは、ディレクティブ（URLパラメーターを介して）で特定の画像を最適化する方法を指定できますが、「自動モード」もサポートしています。 ImageEngineは、OriginのWebサイトから画像を取得し（他の人のサーバーで画像をホストする必要はありません）、デバイス検出コンポーネントとクライアントヒントによって決定された最適な形式に画像を自動的に最適化します。たとえば、.webpをサポートするデバイスとブラウザは.webpを取得します。顧客は既存のサイトの前でImageEngineをアクティブ化するだけで、特別な調整を行うことなく魔法が起こります。現在の顧客（特にeコマース）はこの機能を気に入っています。
職場では、
- 一般的なパイプラインイメージの最適化（例：gruntプラグイン）
- クライアントの設計チームに画像の最適化のためにアプリを使用させる
- また、多くのサイトでCloudinaryを使用しています。
ソリューションは通常、お客様のコストと予算によって異なりますが、Cloudinaryは、特に私たちやその内部チームが画像の最適化に時間を費やすことを望まず、単に機能に集中したいお客様にとって、実際には安価に機能していることがわかりました。
画像とビデオをcloudinaryにオフロードすることで、サイトの改善、ABテスト、その他の収益を生み出す活動に集中するための時間を解放できます。キャッシュとCDNのために大きな問題とは思われない転送遅延は、製品の構築とビジネスの開発に集中するために解放された文字通り数時間/数日の時間に対して支払うための小さな代償になります。
あなたは自分の時間の価値と、他のことをするためにそれを解放した場合にどれだけ多くのお金を稼ぐことができるかを理解する必要があります。他にどのようなことを試みますか？
画像の読み込みを高速化するには、画像のサイズをできるだけ小さくし、優れたキャッシュと配信アーキテクチャが必要です。
サービスを使用して画像を配信する場合、画像はCDNを使用して提供されるため、キャッシュと配信の部分が解決されます。
CloudinaryやImagixのような強力なCDNサービスがいくつかあります。各サービスには独自の長所と短所があり、いくつかの疑問が生じます。
- どのCDNサービスがターゲット地域に最も到達しやすいですか？
- サイトまたはアプリに必要な特定のCDN機能はありますが、すべてのサービスで対応されているわけではありませんか？
- 使用しているCDNサービスに停止や速度低下が発生するとどうなりますか？
- トラフィックの急増はすべてのCDNに等しく影響しますか？
- さまざまな地理的領域、時間帯、またはその他のパフォーマンス変数に対してさまざまなCDNサービスを使用することで、配信をさらに最適化できる可能性はありますか？
これらの質問への答えは挑戦的であり、絶えず変化しています。 Cloudinaryは、さまざまな時間とさまざまな地域での配信を最適化するために、複数のCDNを有効にします。
初期設定プロセスを完了した後、Cloudinaryのお客様は2つのうちの1つを利用できます マルチCDN最適化ソリューション ：
動的マルチCDNスイッチング：リアルタイムデータを使用して、すべてのユーザー要求とすべての場所で、サポートされているCDNサービスの中で最高のパフォーマンスまたは最も適切なものを自動的に選択します。
スマートCDNの選択：専任のサポートエンジニアが、サポートされているCDNサービスのどれが必要な機能と対象読者に最適かを判断するのに役立ちます
画像の最適化問題に関して、Cloudinaryは、画像の表示サイズへのスケーリング、画質の調整、クライアント検出に基づくファイル形式の自動選択、画像形式の変換などをサポートしています。
免責事項：私はCloudinaryでソフトウェアエンジニアとして働いています。
必要なサイズの画像のみをロードすることには、間違いなく利点があります。最大のボーナスはロード時間です。ユーザーはページが読み込まれるのを待ちたくないことは誰もが知っています。したがって、複数のコピーがある場合、または画面サイズに基づいてすべての画像を圧縮する場合は、ユーザーエクスペリエンスが向上します。グーグルはまた、画像サイズが影響するロード時間に基づいて検索表示を行います。また、キャッシュを利用できるように、画像にCDNを提供するサービスを使用することをお勧めします。