Efficiency of services like Cloudinary, Imgix

Question

I want to build a website with a lot of images and hence image manipulations like amazon, ebay, flipkart,etc. I have been suggested to use services like Cloudinary, Imgix, etc to resize my images since it would be better to store one version of each image although I'd need several versions with different sizes. I'd like to know how efficient these services are. Are there any issues? I'd like my website to be very fast and responsive. I have heard concerns like "Take into account that you're at least doubling the transfer latency involved, which will frequently dominate the time required to complete an image operation.

Normal: end_user->your_user->end_user

Through these services: end_user->your_user->you->your_user->end_user"

Answer 1

(Disclaimer: I handle developer relations at imgix, and will be answering this post as it applies to our stack)

You're absolutely correct that for a completely uncached image, there are more "hops" involved to serve an image. For the first user to view an image, this can result in a slightly increased latency. After that, however, the image is cached by both our rendering cluster and global CDN, which makes subsequent requests for any image based off of the original much faster. Either way, the byte savings from serving correctly-sized images to the browser will almost always outweigh any additional latency from initial requests for an image.

Here's a simple diagram that shows the flow when an image has not yet been cached:

                      ┌─────────────────┐  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`.                       └─────────────────┘ 

Once the image has been cached (after a single user requests it), the loop becomes much tighter:

 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`.                       └─────────────────┘ 

After an original image is cached at our rendering cluster, generating derivatives is also much faster (in this case, a 600px wide version), since they don't require an additional trip to your origin server:

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`.                       └─────────────────┘ 

Answer 2

I am using imgix over 1 year. I think hosting images by a professional image server is much better than hosting it by your servers.

High performance

1- As Paul Straw said: Imgix has a proper caching strategy. It doesn't add the latency to load image. It even deduct the latency as its not fetching the master image every time the page loads. It fetches the image from cache.

2- Both Cloudinary and imgix use wide and fast CDN. So the user who needs to download an image, can get the file from the CDN edge which is closer to his location. Therefore latency will be dropped and it downloads faster.

3- Serving the correct image dimensions for a given device (or as close as possible) is the best way to make sure that images aren’t adversely affecting your page load times. Even small differences between the actual and desired sizes of an image can increase the file size dramatically.The most basic feature of image hosting services is the ability to resize images on the fly to fit any device as needed.

In addition of high performance of these services, I have seen some other benefits too which I mention some of them here:

Responsive images

Nowadays many website owners, Sales and Marketing executives and ... care about many marketing aspects. They choose pictures carefully in order to convert a user to buyer or to reach a certain goal in their website. Resizing an image for different screen maybe is enough for responsive design but its not enough for increasing the conversion rate of your website. Sometimes you need to crop the image to resize it. With image hosting services you can choose exactly where to crop, which part of the image is essential for marketing purposes to be remained and which part can be cropped. you can have all of these controls on the fly with these services without using Photoshop and prepare several pictures offline.

Retina Support

Most of images may be seen good in normal screens but when you see them in high density screens like Apple Retina or some Android devices are not good at all. The device pixel ratio is used to easily convert between device independent pixels and device pixels. This makes it possible to display images at the correct pixel density on a variety of devices such as Apple Retina displays and Android devices. In imgix you can choose to load pictures with higher DPR if the screen can support high density images. you can do it with srcset tags. Read more here

Image manipulation on the fly

Everything you wanna do on a picture can be done on the fly. You don't need to use Photoshop for small image manipulations. That's reduce design speed significantly.

Better SEO ranking

Image size is a big contributor to page load speed , which in turn is a key metric in determining search result rankings for your pages. Reducing image size can go a long way toward improving your rankings, especially if you can get the full page load below the threshold where many users start to drop away out of impatience.