どのプロバイダーも速いと主張します。ベンダーデックの数字、私たちのものも含めて、統合を決めるべきではありません。画像APIのパフォーマンスは、ユーザーの場所、リクエスト内容、キャッシュの方法によって異なります。ベンダーが正直に提供できるのは、アーキテクチャと方法です。両方を紹介します。
速度は何によって決まりますか
- エッジキャッシング: 画像がユーザーに近いCDNノードから提供されるか、オンデマンドでレンダリングされるか
- ペイロードのサイズ：フォーマットと次元。1200pxのWebPはフルサイズのPNGの一部分です
- 冷たい対温かい：珍しいトリム・カラー・アングルの組み合わせの最初のリクエストは、人気のあるものの百万回目のリクエストよりも多くの作業を行います
- 独自のキャッシュ：CDNまたはバケットに保存された画像URLは、その後の表示ごとにAPIレイテンシがゼロです
エッジからのキャッシュされた配信は通常数十ミリ秒で、ほとんどがネットワーク距離です。コールドレンダリングは時間がかかり、正直なプロバイダーならそう言います。パフォーマンスの問題は、実際にはキャッシュヒット率の問題で、アクセスパターンがそれを決めるのに、ベンダーよりも影響を与えます
測定に値する四つの数字
| メトリック | それが教えてくれること | どのように |
|---|---|---|
| TTFB、暖かい | エッジ配送速度 | 同じURLのリクエストを繰り返す |
| TTFB、冷却 | レンダリングパイプラインの速度 | まれな組み合わせの最初のリクエスト |
| p95、平均ではありません | 遅いユーザーが経験するもの | 数百のリクエスト、テールを見てみましょう |
| 通信量 | モバイルユーザーがダウンロードするもの | フォーマットと幅のバリアントを比較 |
午後に実行できるベンチマーク
自社のカタログから20台の車両を取得し、実際のもの、不人気なトリムを含めます。各車両について、実際に表示する角度を、実際に提供するフォーマットとサイズでリクエストします。例えば、front_left?format=webp&width=1200。各URLを2回実行し、ユーザーがいる地域から実行し、冷却と温暖のタイミングを別々に記録します。ピーク時間相当の同時実行で繰り返します。
結果の正直さを左右するのは二つの細部です。まず：平均ではなく、尾を測定します。速い平均値に隠れた一回の遅いレンダリングは、ユーザーが気づくものです。次に：ペイロードとレイテンシーを一緒にベンチマークします。同じ TTFB で二倍のバイトを返すプロバイダーは、どの実機でも遅いのです。
ペイロードの規律
- PNGの透明度が印刷や合成に必要でない限り、WebPをリクエスト
- レンダリングする幅をリクエスト。2400pxの画像を600pxのスロットに送るのは無駄です。
- 品質パラメータを意図的に使用する。車両のカットアウトは圧縮に強い
- 積極的にキャッシュする：最速のリクエストは行わないものです
結果を正直に読む
数字が戻ってきたとき、1つのスコアに平均化するのを抵抗してください。ウォームパスが速く、コールドパスが遅いプロバイダーは、上位1000台の車両が大部分のトラフィックを吸収するマーケットプレイスに適していますが、長いテールの保険見積もりフローにはあまり適していません。レイテンシプロファイルの形状をアクセスパターンの形状に合わせるのが、どのベンダーが見出しの中央値を勝ち取るかよりも重要です。
独自のアーキテクチャを採用しており、リクエストパラメータ、フォーマット、および配信については、車両画像APIページおよびAPIドキュメントに記載されています。午後のベンチマークを私たちと他の候補者に対して実行してください。その比較は、私たちが公開できるどの表よりも優れています
