我想建立一个包含大量图像的网站，因此需要像 amazon、ebay、flipkart 等图像处理。有人建议我使用 Cloudinary、Imgix 等服务来调整我的图像大小，因为最好存储每个图像的一个版本，尽管我需要几个不同大小的版本。我想知道这些服务的效率如何。有什么问题吗？我希望我的网站非常快速且响应迅速。我听说过诸如“考虑到您至少将所涉及的传输延迟加倍，这将经常支配完成图像操作所需的时间。
正常：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`.
└─────────────────┘
一旦图像被缓存（在单个用户请求之后），循环变得更加紧密：
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`.
└─────────────────┘
我使用 imgix 超过 1 年。我认为由专业图像服务器托管图像比由您的服务器托管要好得多。
高性能
1- 正如 Paul Straw 所说：Imgix 有一个适当的缓存策略。它不会增加加载图像的延迟。它甚至会扣除延迟，因为它不会在每次页面加载时都获取主图像。它从缓存中获取图像。
2- Cloudinary 和 imgix 都使用广泛而快速的 CDN。所以需要下载图片的用户，可以从离自己位置较近的CDN边缘获取文件。因此延迟将被降低并且下载速度更快。
3- 为给定设备提供正确的图像尺寸（或尽可能接近）是确保图像不会对您的页面加载时间产生不利影响的最佳方法。即使图像的实际大小和所需大小之间的微小差异也会显着增加文件大小。图像托管服务的最基本功能是能够根据需要动态调整图像大小以适应任何设备。
除了这些服务的高性能之外，我还看到了其他一些好处，我在这里提到了其中的一些：
响应式图像
如今，许多网站所有者、销售和营销主管和......关心许多营销方面。他们仔细选择图片以便将用户转换为买家或在他们的网站上达到某个目标。为不同的屏幕调整图像的大小对于响应式设计来说可能已经足够了，但对于提高网站的转化率来说还不够。有时您需要裁剪图像以调整其大小。使用图像托管服务，您可以准确选择在哪里裁剪，图像的哪一部分对于保留营销目的至关重要，哪一部分可以裁剪。您可以在不使用 Photoshop 的情况下通过这些服务即时获得所有这些控件，并离线准备多张图片。
视网膜支持
大多数图像在普通屏幕上可能看起来不错，但是当您在 Apple Retina 或某些 Android 设备等高密度屏幕上看到它们时，它们根本就不好看。设备像素比用于在设备独立像素和设备像素之间轻松转换。这使得在各种设备（如 Apple Retina 显示器和 Android 设备）上以正确的像素密度显示图像成为可能。在 imgix 中，如果屏幕可以支持高密度图像，您可以选择加载具有更高 DPR 的图片。你可以用 srcset 标签来做到这一点。在这里阅读更多
动态图像处理
您想在图片上做的所有事情都可以即时完成。您无需使用 Photoshop 进行小图像处理。这会显着降低设计速度。
更好的SEO排名
图片大小是页面加载速度的重要因素，而这反过来又是确定页面搜索结果排名的关键指标。减小图像大小可以大大提高您的排名，特别是如果您可以使整个页面加载低于阈值，许多用户开始因不耐烦而放弃。
[披露，我是提供 ImageEngine 的公司的 CTO]
在这里提到我们自己的ImageEngine。ImageEngine 与 OP 提到的其他解决方案处于完全相同的空间，但有一些额外的优势：它的 CDN 是从头开始构建的，并考虑了移动优化。除了桌面浏览器之外，ImageEngine 的边缘服务器还可以准确检测屏幕尺寸、分辨率和支持的图像编解码器等功能，并相应地优化图像。这要归功于 WURFL，Facebook 和 Google 采用了相同的设备检测解决方案，并考虑了额外的优化（高达 80% 的带宽节省）并减少了 CDN 费用。我们将此概念称为“智能字节”。
另一个很大的区别是易于集成。ImageEngine 不需要组织在任何地方上传图像。这对于需要处理遗留图像的公司来说非常有用。虽然 ImageEngine 允许指令（通过 URL 参数）指定如何优化给定图像，但它也支持“自动模式”，即 ImageEngine 将从源网站检索图像（无需在其他人的服务器上托管图像）并自动将图片优化为由设备检测组件和客户端提示确定的最佳格式。例如，支持的设备和浏览器.webp将获得.webp. 客户只需在其现有站点前激活 ImageEngine，无需额外调整即可实现奇迹。当前客户（尤其是电子商务）喜欢此功能。
在工作中，我们结合使用
该解决方案通常会根据客户的成本和预算而有所不同，但我们发现 Cloudinary 实际上的成本更低，特别是对于不希望我们或其内部团队花时间在图像优化上而只想专注于功能的客户而言。
通过将图像和视频卸载到云端——我们可以腾出时间专注于改进网站、AB 测试和其他创收活动。由于缓存和 CDN 的存在，传输延迟似乎不是一个大问题，这对于花数小时/天的时间来专注于构建产品和开发业务来说是一个很小的代价。
你应该计算出你的时间值多少钱——如果你腾出时间去做其他事情，你能赚多少钱。你还会尝试什么其他的事情？
为了使您的图像加载速度更快，您希望它们的大小尽可能小，并且您需要良好的缓存和交付架构
当您使用服务交付图像时，它们使用 CDN 提供服务，因此解决了缓存和交付部分。
有几个强大的 CDN 服务，例如 Cloudinary 或 Imagix。每个服务都有自己的优点和缺点，提出了几个问题：
这些问题的答案具有挑战性并且不断变化。为了在不同时间和不同地区优化交付，Cloudinary 启用了多个 CDN。
完成初始设置过程后，Cloudinary 客户可以利用以下两种多 CDN 优化解决方案之一：
动态多 CDN 切换：使用实时数据为每个用户请求和每个位置自动选择性能最佳或最合适的受支持 CDN 服务。
智能 CDN 选择：专门的支持工程师帮助您确定哪些受支持的 CDN 服务最适合您所需的功能和目标受众
关于图像优化问题，Cloudinary支持缩放图像显示大小、调整图像质量、根据客户端检测自动选择文件格式、图像格式转换等。
免责声明：我在 Cloudinary 担任软件工程师。
仅加载所需大小的图像绝对有优势。最大的好处是加载时间。我们都知道用户不喜欢等待页面加载。因此，如果您有多个副本或根据屏幕尺寸压缩所有图像，您将提供更好的用户体验。谷歌还将搜索显示基于加载时间，即图像大小。我还建议使用为图像提供 CDN 的服务，以便您可以利用缓存。
作为这些服务的用户，要回答您的问题并牢记您的问题询问这些服务中任何问题的方式，请参阅以下几点。
您提到的关于双重延迟的担忧是错误的，因为他们假设所有呼叫都会到达您的服务器。这些图像服务为您提供可以直接访问其服务器的 URL，甚至更好的是本地缓存版本的图像。他们会处理很多你可能还没有考虑过的事情。