Cloudinary、Imgix 等服务的效率
Efficiency of services like Cloudinary, Imgix
我想建立一个包含大量图片的网站，并因此进行图片处理，例如 amazon、ebay、flipkart 等。有人建议我使用 Cloudinary、Imgix 等服务来调整我的图像大小，因为最好存储每个图像的一个版本，尽管我需要多个不同大小的版本。我想知道这些服务的效率如何。有什么问题吗？我希望我的网站非常快速且响应迅速。我听说过这样的担忧“考虑到您至少将所涉及的传输延迟加倍，这通常会占用完成图像操作所需的时间。
正常：end_user->your_user->end_user
通过这些服务：end_user->your_user->你->your_user->end_user"
（免责声明：我在 imgix 处理开发人员关系，并将回答这个 post 因为它适用于我们的堆栈）
您完全正确，对于完全未缓存的图像，需要更多 "hops" 来提供图像。对于第一个查看图像的用户，这可能会导致延迟略微增加。然而，在那之后，图像被我们的渲染集群和全球 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- 为给定设备提供正确的图像尺寸（或尽可能接近）是确保图像不会对您的页面加载时间产生不利影响的最佳方式。即使图像的实际大小和所需大小之间的微小差异也会增加文件大小 dramatically.The 图像托管服务的最基本功能是能够根据需要即时调整图像大小以适应任何设备。
除了这些服务的高性能之外，我还看到了其他一些好处，我在这里提到了其中的一些：
响应式图片
如今，许多网站所有者、销售和营销主管以及...关心许多营销方面。他们仔细选择图片，以便将用户转化为买家或在他们的网站上达到某个目标。为不同的屏幕调整图像的大小对于响应式设计来说可能就足够了，但对于提高网站的转化率来说还不够。有时您需要裁剪图像以调整其大小。借助图像托管服务，您可以准确选择裁剪位置、保留图像的哪一部分对于营销目的至关重要以及可以裁剪哪一部分。您可以在不使用 Photoshop 的情况下使用这些服务即时进行所有这些控制，并离线准备多张图片。
视网膜支持
大多数图像在普通屏幕上可能看起来不错，但是当您在 Apple Retina 或某些 Android 设备等高密度屏幕上看到它们时，一点也不好。设备像素比用于在设备独立像素和设备像素之间轻松转换。这使得在各种设备（例如 Apple Retina 显示器和 Android 设备）上以正确的像素密度显示图像成为可能。在 imgix 中，如果屏幕可以支持高密度图像，您可以选择加载具有更高 DPR 的图片。你可以用 srcset 标签来做。 Read more here
动态图像处理
您想在图片上做的所有事情都可以即时完成。您不需要使用 Photoshop 进行小的图像处理。这大大降低了设计速度。
更好的 SEO 排名
图片大小是影响页面加载速度的一个重要因素，而页面加载速度又是决定页面搜索结果排名的关键指标。减小图像大小可以大大提高您的排名，特别是如果您可以使整个页面加载量低于许多用户因不耐烦而开始退出的阈值。
在工作中我们结合使用
- 通用管道图像优化，例如 grunt 插件
- 让客户设计团队使用应用程序进行图像优化
- 我们还在很多网站上使用 Cloudinary。
解决方案通常根据客户的成本和预算而有所不同，但我们发现 Cloudinary 实际上更便宜，特别是对于那些不希望我们或他们的内部团队花时间在图像优化上而只想专注的客户在功能上。
通过将图像和视频卸载到 cloudinary - 它为我们腾出时间来专注于改进网站、AB 测试和其他创收活动。由于缓存和 CDN，传输延迟似乎不是一个大问题，这将是一个很小的代价，可以腾出数小时/数天的时间来专注于构建产品和发展业务。
你应该弄清楚你的时间值多少钱——如果你腾出时间去做其他事情，你能多赚多少钱。您还会尝试哪些其他操作？
为了使您的图像加载速度更快，您希望它们的大小尽可能小，并且您需要良好的缓存和交付架构
当您使用服务传送图像时，它们是使用 CDN 提供的，因此缓存和传送部分已解决。
有几种强大的 CDN 服务，如 Cloudinary 或 Imagix。每个服务都有自己的优点和缺点，提出几个问题：
- 哪种 CDN 服务最能覆盖您的目标地区？
- 是否有您的网站或应用需要的特定 CDN 功能，但所有服务都没有解决？
- 当您使用的 CDN 服务中断或变慢时会发生什么？
- 流量峰值对所有 CDN 的影响是否相同？
- 您是否可以针对不同的地理区域、一天中的时间或其他性能变量使用不同的 CDN 服务来进一步优化交付？
这些问题的答案具有挑战性且不断变化。为了在不同时间和不同地区优化交付，Cloudinary 启用了多个 CDN。
完成初始设置过程后，Cloudinary 客户可以利用以下两个选项之一 multi-CDN optimization solutions：
动态多 CDN 切换：使用实时数据自动 select 为每个用户请求和每个位置提供性能最佳或最合适的受支持 CDN 服务。
智能 CDN selection：专门的支持工程师帮助您确定哪些受支持的 CDN 服务最适合您所需的功能和目标受众
关于图像优化问题，Cloudinary 支持缩放图像以显示大小、调整图像质量、根据客户端检测自动selecting 文件格式、图像格式转换等。
免责声明：我在 Cloudinary 担任软件工程师。
只加载您需要的大小的图像绝对有优势。最大的好处是加载时间。我们都知道用户不喜欢等待页面加载。因此，如果您有多个副本或根据屏幕尺寸压缩所有图像，您将提供更好的用户体验。 Google 还根据加载时间显示搜索显示，其中图像大小会影响加载时间。我还建议使用为图像提供 CDN 的服务，以便您可以利用缓存。
[爆料，我是提供ImageEngine的公司的CTO]
我们自己的 ImageEngine 是按顺序提及的。 ImageEngine 与 OP 提到的其他解决方案完全相同 space，但有一些额外的优势：它的 CDN 是从头开始构建的，考虑到了移动优化。
除了桌面浏览器之外，ImageEngine 的边缘服务器还可以准确检测屏幕尺寸、分辨率和支持的图像编解码器等特性，并相应地优化图像。这要归功于 WURFL，它是 Facebook 和 Google 采用的相同 Device Detection 解决方案，并且考虑了额外的优化（高达 80% 的带宽节省）和减少的 CDN 费用。我们称这个概念为"Smart Bytes"。
另一个很大的区别是易于集成。 ImageEngine 不要求组织在任何地方上传图像。这对于需要处理遗留图像的公司来说非常有用。虽然 ImageEngine 允许指令（通过 URL 参数）指定给定图像的优化方式，但它也支持 "auto-mode"，即ImageEngine 将从原始网站检索图像（无需在其他人的服务器上托管图像）并自动将图片优化为设备检测组件和客户端提示确定的最佳格式。例如，支持 .webp 的设备和浏览器将获得 .webp。客户只需在其现有站点前激活 ImageEngine，魔法就会发生，无需额外调整。当前客户（尤其是电子商务客户）喜欢此功能。
要回答您作为这些服务的用户的问题并牢记您的问题询问这些服务中的任何问题的方式，请参阅以下几点。
- 这些服务在缓存图像方面进行了优化。 当您上传图片时，他们会在那时创建不同的尺寸和变形。其中一些会同时将其缓存到最近的服务器，以便您下次请求时可以快速查看。
- 您可以指定要缓存的默认大小。例如，在您的服务器上，您将上传 3 个版本的图像 200x200 用于移动缩略图、300x300 用于平板电脑缩略图和 400x400 用于桌面。 您可以通过将图像上传到这些服务器来节省时间，它们可以在几毫秒内调整到所有三个服务器的大小并将它们分发到多个缓存服务器。
- 您可能会遇到的问题是，如果您经常更改图像，那么这些服务将需要清除缓存或更改 URL 等才能获得最新版本。您将不得不等待缓存过期等。但是根据我的使用，在各种设备上以毫秒为单位加载图像所带来的好处 远远超过破坏缓存的努力，而且大多数这些服务中的一些提供了方便的方法来做到这一点。
- 这些服务减少了您服务器上的 space 并且 使用它们托管图像的大部分时间成本比将图像与服务代码一起存储要便宜得多。如果您要上传高分辨率或大尺寸图像，则差异很大。例如，将 500GB 的图像存储在 Web 托管机器或带缓存的存储 blob 上是其中一项服务成本的 4 倍。 备份和版本控制是这些服务附带的另一个好处。
- 如果您实施漂亮的图像 upload/view/tag/remove 策略，您可以通过使用这些服务中的任何一种随着时间的推移节省大量时间和金钱。我建议寻找适合您用例的服务。例如，您可能还想使用 css/js 缓存，或者您可能想将图像用于私人用途，或者您想要上传视频，或者您想要在您的项目中进行对象识别。大量的选择只是需要时间来研究哪个是最好的。
您提到的关于双重延迟的担忧是错误的，因为他们假设所有调用都会到达您的服务器。这些图像服务为您提供 url 可以直接访问他们的服务器或者更好的图像的本地缓存版本。他们处理了很多您可能还没有考虑过的事情。
我想建立一个包含大量图片的网站，并因此进行图片处理，例如 amazon、ebay、flipkart 等。有人建议我使用 Cloudinary、Imgix 等服务来调整我的图像大小，因为最好存储每个图像的一个版本，尽管我需要多个不同大小的版本。我想知道这些服务的效率如何。有什么问题吗？我希望我的网站非常快速且响应迅速。我听说过这样的担忧“考虑到您至少将所涉及的传输延迟加倍，这通常会占用完成图像操作所需的时间。
正常：end_user->your_user->end_user
通过这些服务：end_user->your_user->你->your_user->end_user"
（免责声明：我在 imgix 处理开发人员关系，并将回答这个 post 因为它适用于我们的堆栈）
您完全正确，对于完全未缓存的图像，需要更多 "hops" 来提供图像。对于第一个查看图像的用户，这可能会导致延迟略微增加。然而，在那之后，图像被我们的渲染集群和全球 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- 为给定设备提供正确的图像尺寸（或尽可能接近）是确保图像不会对您的页面加载时间产生不利影响的最佳方式。即使图像的实际大小和所需大小之间的微小差异也会增加文件大小 dramatically.The 图像托管服务的最基本功能是能够根据需要即时调整图像大小以适应任何设备。
除了这些服务的高性能之外，我还看到了其他一些好处，我在这里提到了其中的一些：
响应式图片
如今，许多网站所有者、销售和营销主管以及...关心许多营销方面。他们仔细选择图片，以便将用户转化为买家或在他们的网站上达到某个目标。为不同的屏幕调整图像的大小对于响应式设计来说可能就足够了，但对于提高网站的转化率来说还不够。有时您需要裁剪图像以调整其大小。借助图像托管服务，您可以准确选择裁剪位置、保留图像的哪一部分对于营销目的至关重要以及可以裁剪哪一部分。您可以在不使用 Photoshop 的情况下使用这些服务即时进行所有这些控制，并离线准备多张图片。
视网膜支持
大多数图像在普通屏幕上可能看起来不错，但是当您在 Apple Retina 或某些 Android 设备等高密度屏幕上看到它们时，一点也不好。设备像素比用于在设备独立像素和设备像素之间轻松转换。这使得在各种设备（例如 Apple Retina 显示器和 Android 设备）上以正确的像素密度显示图像成为可能。在 imgix 中，如果屏幕可以支持高密度图像，您可以选择加载具有更高 DPR 的图片。你可以用 srcset 标签来做。 Read more here
动态图像处理
您想在图片上做的所有事情都可以即时完成。您不需要使用 Photoshop 进行小的图像处理。这大大降低了设计速度。
更好的 SEO 排名
图片大小是影响页面加载速度的一个重要因素，而页面加载速度又是决定页面搜索结果排名的关键指标。减小图像大小可以大大提高您的排名，特别是如果您可以使整个页面加载量低于许多用户因不耐烦而开始退出的阈值。
在工作中我们结合使用
- 通用管道图像优化，例如 grunt 插件
- 让客户设计团队使用应用程序进行图像优化
- 我们还在很多网站上使用 Cloudinary。
解决方案通常根据客户的成本和预算而有所不同，但我们发现 Cloudinary 实际上更便宜，特别是对于那些不希望我们或他们的内部团队花时间在图像优化上而只想专注的客户在功能上。
通过将图像和视频卸载到 cloudinary - 它为我们腾出时间来专注于改进网站、AB 测试和其他创收活动。由于缓存和 CDN，传输延迟似乎不是一个大问题，这将是一个很小的代价，可以腾出数小时/数天的时间来专注于构建产品和发展业务。
你应该弄清楚你的时间值多少钱——如果你腾出时间去做其他事情，你能多赚多少钱。您还会尝试哪些其他操作？
为了使您的图像加载速度更快，您希望它们的大小尽可能小，并且您需要良好的缓存和交付架构
当您使用服务传送图像时，它们是使用 CDN 提供的，因此缓存和传送部分已解决。
有几种强大的 CDN 服务，如 Cloudinary 或 Imagix。每个服务都有自己的优点和缺点，提出几个问题：
- 哪种 CDN 服务最能覆盖您的目标地区？
- 是否有您的网站或应用需要的特定 CDN 功能，但所有服务都没有解决？
- 当您使用的 CDN 服务中断或变慢时会发生什么？
- 流量峰值对所有 CDN 的影响是否相同？
- 您是否可以针对不同的地理区域、一天中的时间或其他性能变量使用不同的 CDN 服务来进一步优化交付？
这些问题的答案具有挑战性且不断变化。为了在不同时间和不同地区优化交付，Cloudinary 启用了多个 CDN。
完成初始设置过程后，Cloudinary 客户可以利用以下两个选项之一 multi-CDN optimization solutions：
动态多 CDN 切换：使用实时数据自动 select 为每个用户请求和每个位置提供性能最佳或最合适的受支持 CDN 服务。
智能 CDN selection：专门的支持工程师帮助您确定哪些受支持的 CDN 服务最适合您所需的功能和目标受众
关于图像优化问题，Cloudinary 支持缩放图像以显示大小、调整图像质量、根据客户端检测自动selecting 文件格式、图像格式转换等。
免责声明：我在 Cloudinary 担任软件工程师。
只加载您需要的大小的图像绝对有优势。最大的好处是加载时间。我们都知道用户不喜欢等待页面加载。因此，如果您有多个副本或根据屏幕尺寸压缩所有图像，您将提供更好的用户体验。 Google 还根据加载时间显示搜索显示，其中图像大小会影响加载时间。我还建议使用为图像提供 CDN 的服务，以便您可以利用缓存。
[爆料，我是提供ImageEngine的公司的CTO]
我们自己的 ImageEngine 是按顺序提及的。 ImageEngine 与 OP 提到的其他解决方案完全相同 space，但有一些额外的优势：它的 CDN 是从头开始构建的，考虑到了移动优化。 除了桌面浏览器之外，ImageEngine 的边缘服务器还可以准确检测屏幕尺寸、分辨率和支持的图像编解码器等特性，并相应地优化图像。这要归功于 WURFL，它是 Facebook 和 Google 采用的相同 Device Detection 解决方案，并且考虑了额外的优化（高达 80% 的带宽节省）和减少的 CDN 费用。我们称这个概念为"Smart Bytes"。
另一个很大的区别是易于集成。 ImageEngine 不要求组织在任何地方上传图像。这对于需要处理遗留图像的公司来说非常有用。虽然 ImageEngine 允许指令（通过 URL 参数）指定给定图像的优化方式，但它也支持 "auto-mode"，即ImageEngine 将从原始网站检索图像（无需在其他人的服务器上托管图像）并自动将图片优化为设备检测组件和客户端提示确定的最佳格式。例如，支持 .webp 的设备和浏览器将获得 .webp。客户只需在其现有站点前激活 ImageEngine，魔法就会发生，无需额外调整。当前客户（尤其是电子商务客户）喜欢此功能。
要回答您作为这些服务的用户的问题并牢记您的问题询问这些服务中的任何问题的方式，请参阅以下几点。
- 这些服务在缓存图像方面进行了优化。 当您上传图片时，他们会在那时创建不同的尺寸和变形。其中一些会同时将其缓存到最近的服务器，以便您下次请求时可以快速查看。
- 您可以指定要缓存的默认大小。例如，在您的服务器上，您将上传 3 个版本的图像 200x200 用于移动缩略图、300x300 用于平板电脑缩略图和 400x400 用于桌面。 您可以通过将图像上传到这些服务器来节省时间，它们可以在几毫秒内调整到所有三个服务器的大小并将它们分发到多个缓存服务器。
- 您可能会遇到的问题是，如果您经常更改图像，那么这些服务将需要清除缓存或更改 URL 等才能获得最新版本。您将不得不等待缓存过期等。但是根据我的使用，在各种设备上以毫秒为单位加载图像所带来的好处 远远超过破坏缓存的努力，而且大多数这些服务中的一些提供了方便的方法来做到这一点。
- 这些服务减少了您服务器上的 space 并且 使用它们托管图像的大部分时间成本比将图像与服务代码一起存储要便宜得多。如果您要上传高分辨率或大尺寸图像，则差异很大。例如，将 500GB 的图像存储在 Web 托管机器或带缓存的存储 blob 上是其中一项服务成本的 4 倍。 备份和版本控制是这些服务附带的另一个好处。
- 如果您实施漂亮的图像 upload/view/tag/remove 策略，您可以通过使用这些服务中的任何一种随着时间的推移节省大量时间和金钱。我建议寻找适合您用例的服务。例如，您可能还想使用 css/js 缓存，或者您可能想将图像用于私人用途，或者您想要上传视频，或者您想要在您的项目中进行对象识别。大量的选择只是需要时间来研究哪个是最好的。
您提到的关于双重延迟的担忧是错误的，因为他们假设所有调用都会到达您的服务器。这些图像服务为您提供 url 可以直接访问他们的服务器或者更好的图像的本地缓存版本。他们处理了很多您可能还没有考虑过的事情。