每个供应商都声称速度快。供应商演示文稿中的任何数字，包括我们的，都不应该决定集成，因为图像 API 性能取决于用户的位置、请求内容以及缓存方式。供应商能诚实给你的是架构和方法。这里有两者。
速度究竟由什么决定
- 边缘缓存：图像是从用户附近的CDN节点提供，还是按需渲染
- 载荷大小：格式和尺寸。1200px 的 WebP 只是全尺寸 PNG 的一小部分
- 冷与暖：对于不寻常的车型-颜色-角度组合的首次请求，工作量比流行组合的百万次请求更多。
- 您自己的缓存：存储在您的 CDN 或存储桶中的图像 URL 每次后续查看都不会产生 API 延迟
从边缘缓存的传递通常在数十毫秒内完成，基本上是网络距离。冷渲染需要更长时间，任何诚实的提供商都会这么说。因此，性能问题实际上是一个缓存命中率问题，您的访问模式决定了这一点，而不是供应商
值得衡量的四个数字
| 指标 | 它告诉您什么 | 如何 |
|---|---|---|
| TTFB，热启动 | 边缘交付速度 | 重复请求相同的 URL |
| TTFB，冷启动 | 渲染管道速度 | 罕见组合的首次请求 |
| p95，而不是平均值 | 慢速用户的体验是什么 | 数百个请求，看看尾部 |
| 线路上的字节 | 移动用户下载什么 | 比较格式和宽度变体 |
下午就能跑通的基准
从自己的目录中取出二十辆实际车辆，包括不受欢迎的车型。对于每辆车，请求您实际将显示的角度，以您实际将提供的格式和尺寸，例如front_left?format=webp&width=1200。从用户所在的地区分别运行每个URL两次，并单独记录冷启动和热启动时间。在高峰时段的等效并发下重复。
两个细节决定结果的真实性。首先：测量尾部，而不是平均值。一个隐藏在快速平均值中的慢速渲染，正是用户会注意到的。其次：在测量延迟的同时，也要测量负载，因为一个提供商在相同的TTFB下返回两倍的字节，在每一款真实的手机上都会变慢。
载荷规范
- 除非您特别需要 PNG 透明度用于打印或合成，否则请求 WebP
- 请求您渲染的宽度。将 2400px 的图像发送到 600px 的槽位是纯粹的浪费
- 有意识地使用质量参数；车辆剪影在压缩后依然完好
- 在您的端口上积极缓存：最快的请求是您从未发出的请求
诚实地阅读结果
当数字返回时，抵制将它们平均为一个得分的诱惑。一个具有快速热路径和慢速冷路径的提供商适合一个市场，其中前一千辆车吸引了大部分流量，但对长尾保险报价流程则适合得多。将延迟特性的形状与访问模式的形状匹配，因为这种契合度比哪个供应商赢得头条中位数更重要。
我们自己的架构，包括请求参数、格式和交付，在车辆图像 API 页面和API 文档中有详细说明。将下午的基准测试对比我们和您正在考虑的任何其他服务提供商；这种对比胜过我们能发布的任何表格
