我想建立一个类似亚马逊、eBay、flipkart等网站，它需要大量图片和图像操作。有人建议我使用Cloudinary、Imgix等服务来调整我的图片大小，因为只需存储每个图像的一个版本，尽管我需要不同大小的几个版本。我想知道这些服务的效率如何？是否存在任何问题？我希望我的网站非常快速和响应迅速。我听说了一些关于性能问题的担忧，例如：“请考虑你至少会将传输延迟翻倍，这往往会占用完成图像操作所需的时间。”
正常情况：终端用户->您的用户->终端用户
通过这些服务：终端用户->您的用户->您->您的用户->终端用户
（免责声明：我在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`.
└─────────────────┘
一旦图像被缓存（在单个用户请求后），循环变得更加紧凑：
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`.
└─────────────────┘
在我们的渲染集群中缓存原始图像后，生成派生版本也会更快（在此情况下，是 600 像素宽度的版本），因为它们不需要额外的访问您的起源服务器:
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`.
└─────────────────┘
即时图像处理
您想对图片进行的所有操作都可以在即时处理中完成。您不需要使用Photoshop进行小型图像处理，这会显著降低设计速度。
更好的SEO排名
图像大小是页面加载速度的重要贡献者，而页面加载速度又是确定页面搜索结果排名的关键指标。减小图像大小可以大大改善您的排名，特别是如果您可以让完整页面加载速度低于许多用户开始因为耐心不足而退出的阈值。
[声明，我是提供ImageEngine服务的公司的CTO]
在这里提到我们自己的ImageEngine。ImageEngine与其他被OP提到的解决方案处于完全相同的领域，但有一些额外的优势：它的CDN从头开始就考虑了移动优化问题。除了桌面浏览器外，ImageEngine的边缘服务器可以准确检测屏幕大小、分辨率和支持的图像编解码器，并相应地优化图像。这得益于WURFL，这是Facebook和Google采用的同一设备检测解决方案，这对附加的优化（可达80%的带宽节省）和减少CDN账单至关重要。我们称这个概念为“智能字节”。
另一个重要的区别在于易于集成。ImageEngine不需要组织将图片上传到任何地方。这对于处理遗留图片的公司非常有用。虽然ImageEngine允许通过URL参数指定如何优化给定的图像，但它也支持“自动模式”，即ImageEngine将从原始网站检索图像（无需将图像托管在其他人的服务器上），并根据设备检测组件和客户端提示自动优化图片到最佳格式。例如，支持.webp的设备和浏览器将得到.webp。客户只需在其现有站点之前激活ImageEngine，就可以实现不需要额外调整的魔法。目前的客户（特别是电子商务）非常喜欢这个功能。
在工作中，我们使用了多种方法来优化图片：
方案通常因客户成本和预算而异，但我们发现Cloudinary实际上更便宜，特别是对于那些不想让我们或他们内部团队花时间进行图片优化，只想专注于功能的客户。
通过将图片和视频转移到Cloudinary，我们有更多的时间专注于改善网站、AB测试和其他收入产生活动。由于缓存和CDN的存在，传输延迟并不是一个大问题，这是为了节省数小时/数天的时间去专注于产品开发和业务发展所需要支付的一小笔代价。
您应该计算出自己的时间价值，并思考如果将其用于其他事情，您可以赚取多少更多的钱。您会尝试什么其他事情呢？
只加载所需大小的图像绝对有优势。最大的好处将是加载时间。我们都知道用户不喜欢等待页面加载。因此，如果您有多个副本或根据屏幕大小压缩所有图像，则会提供更好的用户体验。Google还基于加载时间进行搜索显示，其中图像大小起到作用。我还建议使用提供图像CDN服务的服务，以便您可以利用缓存。
作为这些服务的用户并考虑到你的问题是关于这些服务中出现的任何问题，请参考以下要点。
这些服务在缓存图像方面进行了优化。当您上传图像时，它们会同时创建不同尺寸和转换的版本，并将其中一些缓存到最近的服务器上，以便下次请求时能够快速查看。