Cloudinary、Imgix等服务的效率
我想要建立一个有很多图片的网站，然后是像amazon、ebay、flipkart等等的图像处理。有人建议我使用Cloudinary、Imgix等服务来调整我的图片大小，因为存储每个图像的一个版本会更好，尽管我需要几个不同大小的版本。我想知道这些服务有多高效。有什么问题吗？我希望我的网站是非常快速和响应。我听说过这样的担忧：“考虑到你至少要加倍所涉及的传输延迟，这将经常支配完成一个图像操作所需的时间。
正常: end_user->your_user->end_user
通过这些服务: end_user->your_user->you->your_user->end_user“
回答 7
Stack Overflow用户
发布于 2016-05-11 20:00:19
(免责声明:我在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 to宽的版本)，因为它们不需要额外访问原始服务器：。
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`.
└─────────────────┘Stack Overflow用户
发布于 2016-05-28 04:19:13
我使用imgix已经超过一年了。我认为由专业的映像服务器托管图像要比由服务器托管图像要好得多。
高性能
正如Paul所说: Imgix有一个适当的缓存策略。它不增加加载图像的延迟时间。它甚至还减少了延迟，因为每次页面加载时，它都不会获取主图像。它从缓存中获取图像。
2- Cloudinary和imgix都使用宽而快速的CDN。因此，需要下载图像的用户可以从离自己位置更近的CDN边缘获取文件。因此，延迟将被删除，并且下载速度更快。
3-为给定设备(或尽可能接近)提供正确的图像尺寸是确保图像不会对页面加载时间产生不利影响的最佳方法。即使图像的实际大小与所需大小之间的微小差异也会增加文件大小，dramatically.The图像托管服务的最基本功能是动态调整图像大小以满足任何需要的设备。
除了这些服务的高性能外，我还看到了一些其他好处，我在这里提到其中一些：
响应图像
现在，许多网站所有者，销售和营销主管和..。关心许多营销方面。他们仔细选择图片，以便将用户转换为买家，或者在他们的网站上达到一定的目标。调整不同屏幕的图像大小可能对响应性设计是足够的，但它不足以提高您的网站的转化率。有时你需要裁剪图像来调整它的大小。有了图像托管服务，您可以准确地选择在哪里裁剪，哪一部分的图像是必要的营销目的，以及哪一部分可以被裁剪。您可以使用这些服务动态地拥有所有这些控件，而无需使用Photoshop并脱机准备几张图片。
Retina Support
大多数图像在普通屏幕上可能都很好，但当你在高密度屏幕上看到它们时，比如Apple或一些Android设备根本就不太好。设备像素比用于设备独立像素和设备像素之间的转换。这使得在各种设备上以正确的像素密度显示图像成为可能，比如Apple显示器和Android设备。在imgix中，如果屏幕能够支持高密度图像，您可以选择加载具有较高DPR的图片。您可以使用srcset标记来完成它。在这里读更多
图像在苍蝇上的处理
你想在一张照片上做的每一件事都可以随心所欲。您不需要使用Photoshop进行小的图像处理。这大大降低了设计速度。
更好的SEO排名
图像大小是页面加载速度的重要贡献者，而页面加载速度又是确定页面搜索结果排名的关键指标。缩小图片大小可以很大程度上提高你的排名，特别是如果你能把整个页面的负荷降低到很多用户开始不耐烦的阈值以下。
Stack Overflow用户
发布于 2017-12-18 22:12:04
披露，我是提供ImageEngine的公司的首席技术官
这里应该提到我们自己的ImageEngine。ImageEngine与OP提到的其他解决方案处于完全相同的空间，有一些额外的优势:它的CDN是从底层构建的，考虑到了移动优化。除了桌面浏览器之外，ImageEngine的边缘服务器还可以准确地检测屏幕大小、分辨率和支持的图像编解码器等功能，并相应地优化图像。这要归功于WURFL，也就是Facebook和Google采用的同样的设备检测解决方案，它带来了额外的优化(高达80%的带宽节省)和减少CDN的开销。我们称这个概念为“聪明的拜特斯”。
另一个很大的不同是集成的易用性。ImageEngine不要求组织将图像上传到任何地方。这对于拥有遗留图像的公司来说是很棒的。虽然ImageEngine允许指令(通过URL参数)指定如何优化给定的图像，但它也支持“自动模式”，即ImageEngine将从原始网站检索图像(不需要在其他服务器上托管图像)，并自动优化图片以设备检测组件和客户端提示确定的最佳格式。例如，支持.webp的设备和浏览器将获得.webp。客户只需在他们现有的站点前激活ImageEngine，就可以在不需要额外调整的情况下实现这一魔术。目前的客户(特别是电子商务)喜欢这个功能。
https://stackoverflow.com/questions/37159599
复制相似问题
腾讯云开发者
