dea*_*ode 18 image cloudinary imgix-js
我想建立一个有很多图像的网站,因此像亚马逊,ebay,flipkart等图像操作.我被建议使用Cloudinary,Imgix等服务来调整我的图像大小,因为尽管我需要多个不同大小的版本,但最好存储每个图像的一个版本.我想知道这些服务的效率如何.有什么问题吗?我希望我的网站能够快速响应.我听到过这样的担忧:"考虑到你至少将所涉及的传输延迟加倍,这将经常主导完成图像操作所需的时间.
正常:end_user-> your_user-> end_user
通过以下服务:end_user-> your_user-> you-> your_user-> end_user"
小智 35
(免责声明:我在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`.
???????????????????
Run Code Online (Sandbox Code Playgroud)
一旦图像被缓存(在单个用户请求之后),循环变得更加紧密:
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`.
???????????????????
Run Code Online (Sandbox Code Playgroud)
在我们的渲染群集中缓存原始图像后,生成衍生物的速度也快得多(在这种情况下,600px宽版本),因为它们不需要额外的原始服务器访问:
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`.
???????????????????
Run Code Online (Sandbox Code Playgroud)
我使用imgix超过1年.我认为专业图像服务器托管图像要比服务器托管图像好得多.
高性能
1-正如Paul Straw所说:Imgix有一个适当的缓存策略.它不会增加加载图像的延迟.它甚至可以减少延迟,因为它不会在每次页面加载时获取主映像.它从缓存中获取图像.
2- Cloudinary和imgix都使用宽而快的CDN.因此,需要下载图像的用户可以从更接近其位置的CDN边缘获取文件.因此延迟将被丢弃并且下载速度更快.
3-为给定设备提供正确的图像尺寸(或尽可能接近)是确保图像不会对页面加载时间产生负面影响的最佳方法.即使图像的实际尺寸和期望尺寸之间的微小差异也可以显着增加文件尺寸.图像托管服务的最基本特征是能够根据需要动态调整图像大小以适应任何设备.
除了这些服务的高性能之外,我还看到了其他一些好处,我在这里提到了其中一些:
响应式图像
如今许多网站所有者,销售和营销高管......关心许多营销方面.他们仔细选择图片,以便将用户转换为买家或达到他们网站的某个目标.为不同的屏幕调整图像大小可能足以响应设计,但它不足以提高您网站的转换率.有时您需要裁剪图像以调整其大小.使用图像托管服务,您可以准确选择要裁剪的位置,图像的哪一部分对于保留营销目的以及哪些部分可以裁剪至关重要.您可以使用这些服务即时拥有所有这些控件,而无需使用Photoshop并离线准备多张图片.
视网膜支持
大多数图像在普通屏幕上看起来都不错,但是当你在Apple Retina等高密度屏幕上看到它们时,或者某些Android设备都不是很好.器件像素比用于在器件无关像素和器件像素之间轻松转换.这使得可以在诸如Apple Retina显示器和Android设备的各种设备上以正确的像素密度显示图像.在imgix中,如果屏幕可以支持高密度图像,您可以选择加载具有更高DPR的图片.你可以用srcset标签来做.在这里阅读更多
动态图像处理
你想在图片上做的一切都可以在飞行中完成.您不需要使用Photoshop进行小图像处理.这大大降低了设计速度.
更好的SEO排名
图像大小是页面加载速度的重要因素,而页面加载速度又是确定页面搜索结果排名的关键指标.缩小图像大小可以大大提高您的排名,特别是如果您可以将整页加载低于阈值,许多用户开始摆脱不耐烦.